RE: XSL-Fo to PDF

Comments below.

-----Original Message-----
From: www-xsl-fo-request@w3.org [mailto:www-xsl-fo-request@w3.org]On
Behalf Of David Tolpin
Sent: February 21, 2002 6:31 PM
To: Sterin, Ilya
Subject: Re: XSL-Fo to PDF

>
> David, thanks.  I totally understand your question of why C? :-)
>
> Well I'm currently implementing a Perl library for XSL-Fo to PDF and it is
> starting to get pretty complex with all the PDF formating and other
> internals, so I thought I would just extend the C libs with Perl's
extension
> facilities (XS) and be done and over with it:-)  But I guess it wasn't
meant
> to be that easy, so off on a mission I am.
>

The first version of RenderX XEP was written in perl with PDF backend
making use of pdflib (www.pdflib.com). While perl had been an excellent
prototyping tool I am inclined to think that XSL FO to PDF in perl is not
of much use unless it is a very limited implementation.

Since I'd gone through it once (XEP version in perl was capable of many
formatting features some widely used implementations don't have still,
including complex table layout, footnotes, multicolumn text and other
features) but perl is not the best tool to manipulate with data
structures suitable for complex rendering (at least not with those
I was able to design).

Time will show, but if I were offered a perl XSL-FO to PDF now again
I would choose a language I am comfortable with for manipulation
with complex data structures and dynamic data types (and with good
- not perl's reference counting - garbage collector) and a translator
from that language to C, and then connect the engine to perl as a C library
(A while ago I had wrote an Oberon-to-C translator -- would be almost
a perfect tool for that approach).

On the other hand, there have been several seemingly successful efforts
to integrate perl with Java. Why not just to use one of those tool
and a (the) free XSL FO to PDF formatter for your purposes?

David Tolpin

-----End Of Original Message-----

Just as an aside, I thought I should mention that I am in the throes of
doing what David mentions was done for the XEP prototype, and what Ilya is
in some stage of doing also. I have my xslfo-proc Sourceforge project, and a
prototype in Perl is proving to be much more useful than UML.

In any case, after getting laid off in October, working on a contract
through the end of the year, and having started with Hummingbird last month,
I've resumed open-source and started to make good progress with the
xslfo-proc prototype.  I made the mistake of announcing the project last
fall before code existed - something I'll not do again. :-) I expect to have
a first upload of code in about a week (quite a lot of it, actually), and
then continue work for a few months on the prototype until I feel ready to
advance to the real thing.

My general intention is to produce a C/C++ XSL-FO processor, and then
provide SWIG wrappers. So in fact Perl would be available but the guts of
the processor would be in C/C++. Based on prototype work so far I am leaning
towards C.

Oddly enough (or perhaps not) I also decided that the most suitable PDF
producer for the prototype (and very possibly for the final processor,
because why re-invent the wheel?) is PDFLib.

I generally support David's comments, although I must admit I am pleasantly
surprised so far by the performance of my prototype. I'm very comfortable
with Perl but I don't think I would want to produce a final production
release of an XSL-FO processor written in it. But time will tell.

I might note that since I am doing a prototype it is actually important for
me to make it as full-featured as possible, because I am trying to validate
the final design decisions. Without detracting from James Tauber's important
initial contributions, I must say that IMO one of the central problems with
Apache FOP is that it was designed and implemented so as to support a small
subset of XSL formatting objects and properties. It started showing
architectural problems over a year ago as a result. Good work is now being
done by some of my fellow FOP committers to re-work the design, but the
point is that that rework need never have happened. I am trying to avoid
that.

Regards,
Arved Sandstrom

Received on Friday, 22 February 2002 07:29:55 UTC