XSL-FO?

[David]

Hello list,

I'm using XML + XSL + CSS to display my data to the web. I also want to
publish my pages in PDF format. To accomplish this I first must
transform my XML + XSL + CSS in XSL-FO. Is there a know technique to
transform my data to XSL-FO without loosing my markup. For example,
transformation my data to XHTML first and later from XHTML to XSL-FO?

Hope someone can help me on this one.

Thanks in advance,

David

 

[Keith Davies]

Hello list,

I'm using XML + XSL + CSS to display my data to the web. I also want
to publish my pages in PDF format. To accomplish this I first must
transform my XML + XSL + CSS in XSL-FO. Is there a know technique to
transform my data to XSL-FO without loosing my markup. For example,
transformation my data to XHTML first and later from XHTML to XSL-FO?

You're probably better off drawing from the initial XML (which has all
the domain markup) for both the XHTML and XSL-FO. That is

XML -> XHTML
-> XSL-FO

will probably be better for you than

XML -> XHTML -> XSL-FO

XHTML and XSL-FO are both presentation models. They'll have elements
that are there in order to get things formatted the way you want. Even
if you add attributes that would allow you to reconstruct the original
structure, it'd be a lot of work (possibly very tricky work) to get it
right.

For instance, you might have an array of things (field descriptions for
a database table is one I run across often). It may may sense to
display this as a table, but then you might having something like

<table class='fielddefs'>
<tr>
<th>#</th>
<th>Field Name</th>
<th>Type</th>
<th>Size</th>
</tr>
<tr class='fielddef'>
<td>1</td>
<td>Item_ID</td>
<td>char</td>
<td>10</td>
</tr>
</table>

You could probably pull this back out if you had to. However, if you
had more complete documentation (description of constraints, behavior,
acceptable values, etc. for each table), with field summaries in a table
such as above and full descriptions below[1], you'll have to find a way
to join them up again... which results in juggling more information and
making your script more complex.

OTOH, if you have an XHTML transformation for 'dbtable' and 'dbfield' it
is fairly simple (even for the presentation described above), and the
XSL-FO transformation for the same is about as simple. Each is
insulated from the other, you can share common code between the two
scripts, and they stay relatively simple.

[1] useful, IMO -- most of the time people just need a reminder of
structure, so the table is very useful, but having full doco below
makes it better.

All IMO, of course. It depends a lot on the complexity of the data and
layout for presentation.


Keith

 

[David Vaartjes]

Hello list,

I'm using XML + XSL + CSS to display my data to the web. I also want
to publish my pages in PDF format. To accomplish this I first must
transform my XML + XSL + CSS in XSL-FO. Is there a know technique to
transform my data to XSL-FO without loosing my markup. For example,
transformation my data to XHTML first and later from XHTML to XSL-FO?

You're probably better off drawing from the initial XML (which has all
the domain markup) for both the XHTML and XSL-FO. That is

XML -> XHTML
-> XSL-FO

will probably be better for you than

XML -> XHTML -> XSL-FO

XHTML and XSL-FO are both presentation models. They'll have elements
that are there in order to get things formatted the way you want. Even
if you add attributes that would allow you to reconstruct the original
structure, it'd be a lot of work (possibly very tricky work) to get it
right.

For instance, you might have an array of things (field descriptions for
a database table is one I run across often). It may may sense to
display this as a table, but then you might having something like

<table class='fielddefs'>
<tr>
<th>#</th>
<th>Field Name</th>
<th>Type</th>
<th>Size</th>
</tr>
<tr class='fielddef'>
<td>1</td>
<td>Item_ID</td>
<td>char</td>
<td>10</td>
</tr>
</table>

You could probably pull this back out if you had to. However, if you
had more complete documentation (description of constraints, behavior,
acceptable values, etc. for each table), with field summaries in a table
such as above and full descriptions below[1], you'll have to find a way
to join them up again... which results in juggling more information and
making your script more complex.

OTOH, if you have an XHTML transformation for 'dbtable' and 'dbfield' it
is fairly simple (even for the presentation described above), and the
XSL-FO transformation for the same is about as simple. Each is
insulated from the other, you can share common code between the two
scripts, and they stay relatively simple.

[1] useful, IMO -- most of the time people just need a reminder of
structure, so the table is very useful, but having full doco below
makes it better.

All IMO, of course. It depends a lot on the complexity of the data and
layout for presentation.


Keith

Thanks for the explanation!

If I get you right, it's better to do a direct XML to XSL-FO conversion
with XSLT? But I don't quite understand how i can transform my server
xhtml pages to PDF without loosing my markup/layout which I've created
with XSL and CSS. I'nt their some kind of program which will accept my
XML + XSL + CCS as input and render an XSL-FO file for me? I know some
programs that will do a XML + XSL to XSL-FO conversion. But then my CSS
is'nt read, which will create very ugly PDF documents.

Maybee I'm to lazy and should create a XSL file to convert my XML into a
well formatted XSL-FO file, but something is telling me such a
possibillity is out there...

Thanks again,
David

 

[Keith Davies]

If I get you right, it's better to do a direct XML to XSL-FO
conversion with XSLT? But I don't quite understand how i can transform
my server xhtml pages to PDF without loosing my markup/layout which
I've created with XSL and CSS. Isn't their some kind of program which
will accept my XML + XSL + CCS as input and render an XSL-FO file for
me? I know some programs that will do a XML + XSL to XSL-FO
conversion. But then my CSS is'nt read, which will create very ugly
PDF documents.

There may be, but I'm not familiar with it; it hasn't come up in my
processing because my HTML and PDF documents are structured differently
enough that I've always had two channels for processing.

If I recall your original question, you wanted to build PDF based on the
XHTML. In my experience, the formatting differences between web and
print media are usually great enough to warrant different formatting.

For instance, on screen your horizontal space is very limited -- there's
only so much information you can present on a screen. On a page,
though, you have much more space (you can fit more legible text across a
page than across a screen), and that changes certain formatting
decisions. Footnotes are a pain in the ass on a web site; on paper they
can be very effective. Floats[1] are meaningless on a web page, but
very useful on paper. Two-column display doesn't generally look good on
a web page but again can be very effective on paper.

I have built some very good-looking documents, both in HTML and PDF.
I've written a number of reference documents for work where my 'base'
XML is highly domain specific. I run it through a transformation that
generates DocBookXML (which takes me from 'domain specific' to 'document
specific', which then gets run through other transformations. The HTML
version can connect to CSS (getting pretty web pages), the PDF might be
generated through a transformation to XSL-FO (which, from what I can
see, has a superset of CSS capabilities) or through LaTeX, which has
very impressive formatting capabilities.

[1] remember high school textbooks, where there would be a reference to
a table, but that table didn't appear until the top of the next
page? The table 'floated' to the next good place to place it. I've
had web pages print very oddly because a table split unnecessarily
or -- almost *worse* -- didn't quite fit and the entire thing got
moved to the next page, leaving a huge white area on the page where
it 'started'.

Maybee I'm to lazy and should create a XSL file to convert my XML into
a well formatted XSL-FO file, but something is telling me such a
possibillity is out there...

I'm sure it is. If nothing else, you can load the HTML pages into a
browser, print to PDF (or PostScript and convert using Distiller or
other tool). If you do that, though, you limit yourself to the
formatting of the web pages, unless you load enough content indicators
(class attributes, etc.) into the HTML. In this case you're trying to
extract domain-specific information from the HTML to reconstruct the
initial state... a challenging task, to be sure, and fragile -- changes
to the HTML formatting might break everything you've done to convert
from HTML to PDF.

In my experience, it's much easier to run both series of transformations
up to the presentational transformation, then split at that point. In
both cases you have the richest, most domain-specific information
available and insulate yourself from changes to presentation, in either
direction.


Keith

 

[Patrick TJ McPhee]

% If I get you right, it's better to do a direct XML to XSL-FO conversion
% with XSLT? But I don't quite understand how i can transform my server
% xhtml pages to PDF without loosing my markup/layout which I've created
% with XSL and CSS.

You have to do the layout over with xsl:fo. This can give you greater
control over the layout than CSS alone, but it is not an automatic
process.

% I'nt their some kind of program which will accept my
% XML + XSL + CCS as input and render an XSL-FO file for me?

You could use a web browser to print to a PS file, then distill it.

% I know some
% programs that will do a XML + XSL to XSL-FO conversion. But then my CSS
% is'nt read, which will create very ugly PDF documents.

The PDF documents will likely be different from the HTML+CSS equivalent,
but it would be difficult to make them uglier than a typical browser.