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 additional commands, email: [EMAIL PROTECTED]
>
>
>
--
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
