You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/09/10 22:49:04 UTC
A C XSL-FO processor
Hi, all
I finally buckled, and initiated a SourceForge project to develop a
C-language XSL-FO formatter. The link is
https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
there...I want to get some people signing up, and register interest.
This is for all those developers out there that like the technology (XSL)
but aren't turning cartwheels over Java. That includes me.
I haven't been able to devote as much time to FOP as I would like, both
because of work and also because of a significant developing personal
relationship (yeah, yeah :-)), but my intention is definitely not to do less
with FOP. I have committed to helping out with the design ideas suggested by
Keiron, and have identified a portion that I want to do, and I want to
complete marker support. I am also very interested in ensuring that we seek
better integration with projects like Cocoon and X-Smiles.
The goal behind the SourceForge project is to develop a fast (and I mean
fast) low-memory footprint XSL formatter that is optimized for use as a C
library. I personally really like SWIG, and I would like to emphasize the
development of the APIs so that they are well-suited for SWIGging into
Python, Perl, Ruby, and what have you.
I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
listen to them, but I think OOP is unnecessary for a good solution to the
XSL formatting problem. In fact, I am now leaning towards the idea that a
procedural design that de-emphasizes the data somewhat, and emphasizes the
layout process, is the way to go. Ideas about flattening the area tree
figure in my thinking here. I think Java is really bad for promoting the
idea that everything should be an object, and I am not sure that this is not
complicating our work with FOP.
The idea is that this will eventually be folded back into XML Apache (I
hope) as a sub-sub-project under FOP. And I also want design ideas developed
during the work on 'xslproc' to inform work on FOP.
Anyway, there it is, and I hope to see C/C++/scripting language people who
are also interested in XSL-FO, support this project. BTW, I have no real
stake in being the design lead, although I obviously have ideas, so if
someone wants to take charge, feel free. If not, then I will.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A C XSL-FO processor
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Frank
Carlos reminded me that there are no project mailing lists yet, so I set one
up. It should be active sometime today. I'll announce it when it's up, so we
can transfer discussion over to it.
I am not a Python guru, although I've used it off and on. I _have_ done some
straight C extension stuff for Python, not just SWIG, but that was
exploratory - I can claim significant XS experience but not the equivalent
for Python. I think this is one of the key bindings, though, and I'm pleased
that you want to look at it.
Regards,
Arved
At 02:49 PM 9/11/01 +0800, you wrote:
>Hello:
>
>When I see XSL-FO, I know the time of personal publishers is coming.
>It is a very important technology I've ever seen around XML,...
>This project sounds very attractive. I am very interested in Python
>bindings,
>and I would like to giving it a try.
>
>Frank
>
>----- Original Message -----
>From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
>To: <fo...@xml.apache.org>
>Sent: Tuesday, September 11, 2001 4:49 AM
>Subject: A C XSL-FO processor
>
>
>> Hi, all
>>
>> I finally buckled, and initiated a SourceForge project to develop a
>> C-language XSL-FO formatter. The link is
>> https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
>> there...I want to get some people signing up, and register interest.
>>
>> This is for all those developers out there that like the technology (XSL)
>> but aren't turning cartwheels over Java. That includes me.
>>
>> I haven't been able to devote as much time to FOP as I would like, both
>> because of work and also because of a significant developing personal
>> relationship (yeah, yeah :-)), but my intention is definitely not to do
>less
>> with FOP. I have committed to helping out with the design ideas suggested
>by
>> Keiron, and have identified a portion that I want to do, and I want to
>> complete marker support. I am also very interested in ensuring that we
>seek
>> better integration with projects like Cocoon and X-Smiles.
>>
>> The goal behind the SourceForge project is to develop a fast (and I mean
>> fast) low-memory footprint XSL formatter that is optimized for use as a C
>> library. I personally really like SWIG, and I would like to emphasize the
>> development of the APIs so that they are well-suited for SWIGging into
>> Python, Perl, Ruby, and what have you.
>>
>> I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
>> listen to them, but I think OOP is unnecessary for a good solution to the
>> XSL formatting problem. In fact, I am now leaning towards the idea that a
>> procedural design that de-emphasizes the data somewhat, and emphasizes the
>> layout process, is the way to go. Ideas about flattening the area tree
>> figure in my thinking here. I think Java is really bad for promoting the
>> idea that everything should be an object, and I am not sure that this is
>not
>> complicating our work with FOP.
>>
>> The idea is that this will eventually be folded back into XML Apache (I
>> hope) as a sub-sub-project under FOP. And I also want design ideas
>developed
>> during the work on 'xslproc' to inform work on FOP.
>>
>> Anyway, there it is, and I hope to see C/C++/scripting language people who
>> are also interested in XSL-FO, support this project. BTW, I have no real
>> stake in being the design lead, although I obviously have ideas, so if
>> someone wants to take charge, feel free. If not, then I will.
>>
>> Regards,
>> Arved Sandstrom
>>
>> Fairly Senior Software Type
>> e-plicity (http://www.e-plicity.com)
>> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>> For additional commands, email: fop-dev-help@xml.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>For additional commands, email: fop-dev-help@xml.apache.org
>
>
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A C XSL-FO processor
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 04:32 PM 9/12/01 +1000, Peter West wrote:
>I concur with much of what you have said here, and I am much more
>comfortable in C than in Java. C++ I have always avoided. That said, I
>would personally prefer to pursue the Java development for career
>reasons - I have much more chance of getting work in Java than in C.
Can't argue with that. :-) Your design contributions are definitely welcome.
>What I think is most interesting about the C project is the chance to
>sit down and design the thing from the ground up in terms of good old
>algorithms + data structures. I believe that such a rethink is also
>necessary for the Java project. I also believe that the same design
>will serve both implementions. Is there any reason why it would not?
This is my intention. A FOP 2 was rejected by the community but I think
there is still a requirement for a new project, that starts clean. And I
know there is a developer base that simply does not want to work with Java.
But I definitely wish for design decisions made in xslfo-proc to inform
decisions made in FOP.
You are right...I do in fact believe that this comes down to good old
algorithms and data structures. I can't quite put my finger on it, but
Java-style OOP failed us (by us I mean FOP) at least a year ago. What
happened, I think, is that the initial design was very data-centric, and
although the base classes were pretty good, they broke down when a number of
XSL requirements had to be implemented. Keiron has now released a new design
doc, and the layout managers described in there, really follow up on
concepts that have been discussed for quite some time now. At some point,
when you have enough "managers", you start thinking, why am I doing this
with OOP?
>My own view is that the common design can be expressed in whatever
>combination of classes is most appropriate to that design.
>
>I have not volunteered for any particular aspect of the design for the
>simple reason that I am not yet comfortable with the spec and the design
>as a whole, but I will be following proceedings with great interest, and
>as soon as I am confident that I know where I am headed, I will put my
>hand up. I have lately (apart from battling the 'flu) been looking at
>the handling of properties, an area which I think is a good candidate
>for lots of static fields and class methods. I was looking at extending
>my experiments in the building of the FO tree, when I realized that I
>would have to know what to do with properties before I could do much
>with the FO tree.
I think Karen will appreciate assistance with the properties work.
Regards,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A C XSL-FO processor
Posted by "Peter B. West" <pb...@powerup.com.au>.
Arved,
I concur with much of what you have said here, and I am much more
comfortable in C than in Java. C++ I have always avoided. That said, I
would personally prefer to pursue the Java development for career
reasons - I have much more chance of getting work in Java than in C.
What I think is most interesting about the C project is the chance to
sit down and design the thing from the ground up in terms of good old
algorithms + data structures. I believe that such a rethink is also
necessary for the Java project. I also believe that the same design
will serve both implementions. Is there any reason why it would not?
My own view is that the common design can be expressed in whatever
combination of classes is most appropriate to that design.
I have not volunteered for any particular aspect of the design for the
simple reason that I am not yet comfortable with the spec and the design
as a whole, but I will be following proceedings with great interest, and
as soon as I am confident that I know where I am headed, I will put my
hand up. I have lately (apart from battling the 'flu) been looking at
the handling of properties, an area which I think is a good candidate
for lots of static fields and class methods. I was looking at extending
my experiments in the building of the FO tree, when I realized that I
would have to know what to do with properties before I could do much
with the FO tree.
Peter
A friend sent me this, from EWTN.
PRAYER FOR VICTIMS IN AMERICA:
Holy Lord, almighty and eternal God, hear our prayers for your servants,
whom you have summoned out of this world. Forgive their sins and
failings and grant them a place of refreshment, light, and peace. Let
them pass unharmed through the gates of death to dwell with the blessed
in light, as you promised to Abraham and his children for ever. Accept
them into your safekeeping and on the great day of judgment raise them
up with all the saints to inherit your eternal kingdom.
Lord our God, you are always faithful and quick to show mercy. Our
brothers and sisters were suddenly and violently taken from us. Come
swiftly to their aid, have mercy on them and comfort their families and
friends by the power and protection of the Cross. Amen.
St. Joseph, Patron of Departing Souls, pray for them.
Arved Sandstrom wrote:
> Hi, all
>
> I finally buckled, and initiated a SourceForge project to develop a
> C-language XSL-FO formatter. The link is
> https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
> there...I want to get some people signing up, and register interest.
>
> This is for all those developers out there that like the technology (XSL)
> but aren't turning cartwheels over Java. That includes me.
>
> I haven't been able to devote as much time to FOP as I would like, both
> because of work and also because of a significant developing personal
> relationship (yeah, yeah :-)), but my intention is definitely not to do less
> with FOP. I have committed to helping out with the design ideas suggested by
> Keiron, and have identified a portion that I want to do, and I want to
> complete marker support. I am also very interested in ensuring that we seek
> better integration with projects like Cocoon and X-Smiles.
>
> The goal behind the SourceForge project is to develop a fast (and I mean
> fast) low-memory footprint XSL formatter that is optimized for use as a C
> library. I personally really like SWIG, and I would like to emphasize the
> development of the APIs so that they are well-suited for SWIGging into
> Python, Perl, Ruby, and what have you.
>
> I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
> listen to them, but I think OOP is unnecessary for a good solution to the
> XSL formatting problem. In fact, I am now leaning towards the idea that a
> procedural design that de-emphasizes the data somewhat, and emphasizes the
> layout process, is the way to go. Ideas about flattening the area tree
> figure in my thinking here. I think Java is really bad for promoting the
> idea that everything should be an object, and I am not sure that this is not
> complicating our work with FOP.
>
> The idea is that this will eventually be folded back into XML Apache (I
> hope) as a sub-sub-project under FOP. And I also want design ideas developed
> during the work on 'xslproc' to inform work on FOP.
>
> Anyway, there it is, and I hope to see C/C++/scripting language people who
> are also interested in XSL-FO, support this project. BTW, I have no real
> stake in being the design lead, although I obviously have ideas, so if
> someone wants to take charge, feel free. If not, then I will.
>
> Regards,
> Arved Sandstrom
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: A C XSL-FO processor
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Jason
You can help with the design. Because right from the start that should
reflect optimal APIs for use with interfacing to scripting languages. I've
done both SWIG Perl and also Perl XS, so in my estimation if you can sketch
out scenarios for use of an XSL formatter in Perl (e.g. the API that you
would like to see, perhaps a complete module definition), that will be an
excellent start to defining APIs.
Try to register as a developer on the 'xslproc' project, and let me know how
that goes. I don't want to kill too much bandwidth here with this thing.
Regards,
Arved
At 05:46 PM 9/10/01 -0500, you wrote:
>I'm very interested but I haven't done alot of C programming so I may not
be of
>much help in the beginning. I'd especially be interested in Perl bindings for
>such a project and could definitely help out in that area as I've done
some XS
>stuff in the past.
>
>On 10-Sep-2001 Arved Sandstrom wrote:
>> Hi, all
>>
>> I finally buckled, and initiated a SourceForge project to develop a
>> C-language XSL-FO formatter. The link is
>> https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
>> there...I want to get some people signing up, and register interest.
>>
>> This is for all those developers out there that like the technology (XSL)
>> but aren't turning cartwheels over Java. That includes me.
>>
>> I haven't been able to devote as much time to FOP as I would like, both
>> because of work and also because of a significant developing personal
>> relationship (yeah, yeah :-)), but my intention is definitely not to do
less
>> with FOP. I have committed to helping out with the design ideas
suggested by
>> Keiron, and have identified a portion that I want to do, and I want to
>> complete marker support. I am also very interested in ensuring that we
seek
>> better integration with projects like Cocoon and X-Smiles.
>>
>> The goal behind the SourceForge project is to develop a fast (and I mean
>> fast) low-memory footprint XSL formatter that is optimized for use as a C
>> library. I personally really like SWIG, and I would like to emphasize the
>> development of the APIs so that they are well-suited for SWIGging into
>> Python, Perl, Ruby, and what have you.
>>
>> I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
>> listen to them, but I think OOP is unnecessary for a good solution to the
>> XSL formatting problem. In fact, I am now leaning towards the idea that a
>> procedural design that de-emphasizes the data somewhat, and emphasizes the
>> layout process, is the way to go. Ideas about flattening the area tree
>> figure in my thinking here. I think Java is really bad for promoting the
>> idea that everything should be an object, and I am not sure that this is
not
>> complicating our work with FOP.
>>
>> The idea is that this will eventually be folded back into XML Apache (I
>> hope) as a sub-sub-project under FOP. And I also want design ideas
developed
>> during the work on 'xslproc' to inform work on FOP.
>>
>> Anyway, there it is, and I hope to see C/C++/scripting language people who
>> are also interested in XSL-FO, support this project. BTW, I have no real
>> stake in being the design lead, although I obviously have ideas, so if
>> someone wants to take charge, feel free. If not, then I will.
>>
>> Regards,
>> Arved Sandstrom
>>
>> Fairly Senior Software Type
>> e-plicity (http://www.e-plicity.com)
>> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>> For additional commands, email: fop-dev-help@xml.apache.org
>
>--
>Jason Bodnar
>jason@shakabuku.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>For additional commands, email: fop-dev-help@xml.apache.org
>
>
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A C XSL-FO processor
Posted by Carlos Villegas <ca...@uniscope.co.jp>.
Hi,
Well, I can contribute the hyphenation package. Same algorithm as FOP's.
In fact, I first wrote the C++ version and then ported it to java for
FOP. I'll fix it so it can read the same pattern files format as FOP, so
we can share those.
I see there are no mailing lists defined yet, should do that first so we
can move these discussions there.
Carlos Villegas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A C XSL-FO processor
Posted by Frank Chen <fr...@ms5.hinet.net>.
Hello:
When I see XSL-FO, I know the time of personal publishers is coming.
It is a very important technology I've ever seen around XML,...
This project sounds very attractive. I am very interested in Python
bindings,
and I would like to giving it a try.
Frank
----- Original Message -----
From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
To: <fo...@xml.apache.org>
Sent: Tuesday, September 11, 2001 4:49 AM
Subject: A C XSL-FO processor
> Hi, all
>
> I finally buckled, and initiated a SourceForge project to develop a
> C-language XSL-FO formatter. The link is
> https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
> there...I want to get some people signing up, and register interest.
>
> This is for all those developers out there that like the technology (XSL)
> but aren't turning cartwheels over Java. That includes me.
>
> I haven't been able to devote as much time to FOP as I would like, both
> because of work and also because of a significant developing personal
> relationship (yeah, yeah :-)), but my intention is definitely not to do
less
> with FOP. I have committed to helping out with the design ideas suggested
by
> Keiron, and have identified a portion that I want to do, and I want to
> complete marker support. I am also very interested in ensuring that we
seek
> better integration with projects like Cocoon and X-Smiles.
>
> The goal behind the SourceForge project is to develop a fast (and I mean
> fast) low-memory footprint XSL formatter that is optimized for use as a C
> library. I personally really like SWIG, and I would like to emphasize the
> development of the APIs so that they are well-suited for SWIGging into
> Python, Perl, Ruby, and what have you.
>
> I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
> listen to them, but I think OOP is unnecessary for a good solution to the
> XSL formatting problem. In fact, I am now leaning towards the idea that a
> procedural design that de-emphasizes the data somewhat, and emphasizes the
> layout process, is the way to go. Ideas about flattening the area tree
> figure in my thinking here. I think Java is really bad for promoting the
> idea that everything should be an object, and I am not sure that this is
not
> complicating our work with FOP.
>
> The idea is that this will eventually be folded back into XML Apache (I
> hope) as a sub-sub-project under FOP. And I also want design ideas
developed
> during the work on 'xslproc' to inform work on FOP.
>
> Anyway, there it is, and I hope to see C/C++/scripting language people who
> are also interested in XSL-FO, support this project. BTW, I have no real
> stake in being the design lead, although I obviously have ideas, so if
> someone wants to take charge, feel free. If not, then I will.
>
> Regards,
> Arved Sandstrom
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: A C XSL-FO processor
Posted by Jason Bodnar <jb...@buzzard.kdi.com>.
I'm very interested but I haven't done alot of C programming so I may not be of
much help in the beginning. I'd especially be interested in Perl bindings for
such a project and could definitely help out in that area as I've done some XS
stuff in the past.
On 10-Sep-2001 Arved Sandstrom wrote:
> Hi, all
>
> I finally buckled, and initiated a SourceForge project to develop a
> C-language XSL-FO formatter. The link is
> https://sourceforge.net/projects/xslfo-proc/. Right now there is nothing
> there...I want to get some people signing up, and register interest.
>
> This is for all those developers out there that like the technology (XSL)
> but aren't turning cartwheels over Java. That includes me.
>
> I haven't been able to devote as much time to FOP as I would like, both
> because of work and also because of a significant developing personal
> relationship (yeah, yeah :-)), but my intention is definitely not to do less
> with FOP. I have committed to helping out with the design ideas suggested by
> Keiron, and have identified a portion that I want to do, and I want to
> complete marker support. I am also very interested in ensuring that we seek
> better integration with projects like Cocoon and X-Smiles.
>
> The goal behind the SourceForge project is to develop a fast (and I mean
> fast) low-memory footprint XSL formatter that is optimized for use as a C
> library. I personally really like SWIG, and I would like to emphasize the
> development of the APIs so that they are well-suited for SWIGging into
> Python, Perl, Ruby, and what have you.
>
> I prefer to avoid C++. If someone wishes to make arguments for C++ I'll
> listen to them, but I think OOP is unnecessary for a good solution to the
> XSL formatting problem. In fact, I am now leaning towards the idea that a
> procedural design that de-emphasizes the data somewhat, and emphasizes the
> layout process, is the way to go. Ideas about flattening the area tree
> figure in my thinking here. I think Java is really bad for promoting the
> idea that everything should be an object, and I am not sure that this is not
> complicating our work with FOP.
>
> The idea is that this will eventually be folded back into XML Apache (I
> hope) as a sub-sub-project under FOP. And I also want design ideas developed
> during the work on 'xslproc' to inform work on FOP.
>
> Anyway, there it is, and I hope to see C/C++/scripting language people who
> are also interested in XSL-FO, support this project. BTW, I have no real
> stake in being the design lead, although I obviously have ideas, so if
> someone wants to take charge, feel free. If not, then I will.
>
> Regards,
> Arved Sandstrom
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
--
Jason Bodnar
jason@shakabuku.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org