Re: document production options

Subject: Re: document production options
From: Francis Norton <francis@xxxxxxxxxxx>
Date: Tue, 12 Sep 2000 17:11:31 +0100

Sebastian Rahtz wrote:
> 
> Francis Norton writes:
> 
>  > We're currently developing a document production function for one or
>  > more commercial web applications.
> 
> you might want to look at http://www.reportlab.com/; their work is
> relevant in contexts like that (though I dont personally like the approach)
> 
Thanks - I'm checking it out now. 

>  > [1]  How stable and/or viable is the XSL/FO spec? I see that it is
>  > currently in last call working draft, and is supported with different
>  > levels of completeness by the tools mentioned in the
>  > http://www.w3.org/Style/XSL/ list of XSL-FO processors. This seems a
>  > reasonably strong case to me - have I overlooked any other major
>  > confidence or fear factors?
> 
> yes, the fact that none of the implementations is at all complete;
> therefore the spec is untested; therefore we do not know that it can
> solve all the real-world tasks it sets out to address. cf DSSSL.
> 
I take your point. Any document productions strategy developed at this
point needs to consider the scenario that XSL-FO doesn't in the end
solve enough problems to become a widely adopted and supported
standards.

>  > [2]  In the case of some letters and all statements we need to evaluate
>  > the space required to print variable length and/or variable count data
>  > items in order to get the page break in the right place. As Max
>  > Froumentin mentioned here recently, this is a well known problem (see
>  > http://redrice.com/xml/xslReporting.html for my analysis of the
>  > requirement) which is not addressed in XSL-FO. Does anyone have a
>  > framework for addressing it, for instance by the use of APIs to the
>  > XSL-FO processor? Or does any competitive technology address this
>  > problem?
> 
> it would be an absolute doddle in TeX, which has the much closer
> binding of markup language and formatting engine which you need. but
> hey, thats 20 years old and hasn't changed for 10 years, so its
> boring, no?
> 
Um. Maybe I'm being irrational in not having looked at TeX more closely.
I think of Tex as being rather oriented towards the production of
academic publications. Would it be suitable for creating dynamically
populated PDF documents on the fly, for client or server side printing?
Are there people using it for this kind of application? Any graphical
tools for generating the raw TeX files for merging data into?

>  > [3]  I'm aware that RenderX plan to release a utility to convert
>  > HTML+CSS2 to XML-FO. Are there any other routes for generating XSL-FO
>  > documents graphically or is that way down the road? How about RTF or
>  > PDF to XSL-FO?
> 
> RTF to FO might be easy. but PDF to FO? two different levels. and if
> yoh had PDF, why would you want FO?
>
Because I can merge stuff into FOs more easily than I can into
(normally) binary PDF, or into RTF. And I can generate them both
graphically - helpful when your clients include marketing types. But I
take your point about the two different levels - it might be daft for
PDF.
> 
>  > [4]  Are there any obvious alternative technologies?
> 
> Yes. make your own PDF in your own XML application, using something
> like PDFlib. That gives you access to font metrics, unless I
> misremember badly. Construct your pages by hand; I suspect FO is a
> sledgehammer to crack a nut, from what I can tell of your application.
>
Yes, PDFLib does it - PDF_show_boxed() with "blind", according to the
section 3.3 of the manual. Hmmm. May have to a look a bit closer at
this.

Many thanks for the well-informed comments, very much what I hoped for!

Francis.
-- 
Francis Norton.

Defy Convention? Deify Convention!


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread