Re: A C XSL-FO processor
Dear Arved & others, I'm willing to volunteer to help with the C implementation. I would also like to see a "data structures + algorithms" approach to the project. At least it will provide some interesting comparisons! Regards, Mick /"\ \ / X ASCII Ribbon Campaign / \ Against HTML Mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A C XSL-FO processor
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A C XSL-FO processor
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: [EMAIL PROTECTED] > For
Re: A C XSL-FO processor
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" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >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: [EMAIL PROTECTED] >> For additional commands, email: [EMAIL PROTECTED] >> >> > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A C XSL-FO processor
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A C XSL-FO processor
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: A C XSL-FO processor
>This is for all those developers out there that like the technology (XSL) >but aren't turning cartwheels over Java. That includes me. And me. Now you're speaking my language. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: A C XSL-FO processor
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: [EMAIL PROTECTED] >> For additional commands, email: [EMAIL PROTECTED] > >-- >Jason Bodnar >[EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: A C XSL-FO processor
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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- Jason Bodnar [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]