Re: DOCBOOK-APPS: Customizing PDF look and feel using DocBook,Epic Print Composer and XSL-FO

[Paul Grosso <pgrosso@arbortext.com>]

I just subscribed to this list, so pardon the late response
(and the fact that this will probably not be properly linked
in the archive).

I'll try to inject some info into the discussion, but if things
get into too many Epic-specific details, we should probably 
take it offline (I'm not yet sure how much this list tolerates
product-specific discussion, so just let me know if I get out
of line).


>Date: Tue, 22 Jan 2002 10:11:21 -0800
>From: Tristan Bishop <tristan@inviosoftware.com>
>Subject: DOCBOOK-APPS: Customizing PDF look and feel using DocBook, Epic
>    Print Composer and XSL-FO
>To: docbook-apps@lists.oasis-open.org
>
>I'm on Windows 2000. I'm using the DocBook XML DTD, more accurately, the
>Arbortext ATI XML DocBook V4.0 DTD. This is the DTD that works with the
>Arbortext Epic Print Composer product.
>
>For styling, I'm using the DocBook 1.48 style sheets that I downloaded from
>Source Forge. 

Distributed with Epic 4.2 are the 1.40 version style sheets,
and if you use the axdocbook samplefo.xsl driver file, it includes
various improvements and bug fixes to the 1.40 distribution.

We plan to update our stylesheets with newer ones from Source Forge
in a mid-year release.  Meanwhile, if you want to use a different version,
that should work too.

>I'm also using the Arbortext Epic 4.2 editor, and their Print
>Composer engine.  As far as I know, the Arbortext engine contains Xalan for
>XSL processing,

Correct, internally we use Xalan.

> as well as some kind of converter (possibly FOP?) to go from
>FO's to post script. I'm then using Adobe Acrobat distiller 5.0 for Windows to go
>from PS to PDF.

We do not use FOP, we have our own FO implementation that
feeds into our TeX-based formatting engine.

Our XSL FO composition support is being improved constantly, 
and there are patches available to apply the fixes to Epic 4.2 
or 4.2.1. Contact me if you want the patch (it'll be a 92KB
zip file I can email you).

>(Though I am using the Arbortext DTD, I'm not using any Arbortext
>extensions, nor did I enable these extensions via the Arbortext extensions
>parameter in the DocBook FO style sheets.)

There are no Arbortext extensions at this time, and the Arbortext extension
parameter in the DocBook FO style sheets doesn't really do anything
related to the XSL FO composition.

>CONVERSION:
>
>I was able to successfully generate PDF content using the default source
>forge style sheets. So, to move forward, I then created a customization
>layer, using instructions found at the following websites:
>
>http://www.dpawson.co.uk/docbook/styling/custom.html
>http://www.nwalsh.com/docs/articles/dbdesign/#parameterization
>
>As instructed, I placed my custom.xsl file in the FO directory, and used an
>import statement to trigger docbook.xsl.  See below:
>
><xsl:import href="docbook.xsl"/>
>
>That said, I now have two primary, and prohibitive issues:
>
>ISSUE NUMBER 1) Not all parameters respond to my customization layer.
>
>I used the FO parameter Reference list found at:
>
>http://docbook.sourceforge.net/projects/xsl/doc/fo/
>
>Many of the customized parameters work just fine. Such as:
>
><xsl:param name="admon.graphics" select="1"/>
><xsl:param name="body.font.family">Arial</xsl:param>
><xsl:param name="title.margin.left" select="'0pc'"/>
>
>Other recommended customization parameters simply do not change the
>resulting PDF output. Examples of ignored parameters include:
>
>page.margin.bottom
>page.margin.inner
>page.margin.outer
>page.margin.top

Page margins were not supported in Epic 4.2.  If the above
mentioned patch is applied, they should work.  (Note, the
Epic 4.2 release had its XSL FO code frozen last August,
so there has been a fair amount of work on it since then.
This patch to which I am referring will be reflected in
the Epic 4.2.3 release due to come out in April.)

>ISSUE NUMBER 2) The file path to reference graphics is being mangled
>
>Within my DocBook XML source, I use the <graphic> element to refer to screen
>shots. The syntax is:
>
><graphic fileref="abcdefg.jpg"/>
>
>When I run the conversion, I receive an error message stating:
>
>[A12630] Error: The graphics file cdefg.jpg could not be opened.
>
>No matter what the file name or file path, the conversion process cuts of
>the first two letters of the file name. So if my graphic is
>
>/12345/abcdefg.jpg
>
>The error will say:
>
>[A12630] Error: The graphics file 345/abcdefg.jpg could not be opened.

I don't know for sure about this without more details, but
graphics should work in the axdocbook sample using our stylesheets.
Perhaps you can try formatting our axdocbook sample with
our distributed stylesheets to make sure that is working.  If
that works but your customized stylesheets don't, then I'd have
to have more details (probably best done offline).

>(BTW, my admonishment graphics (called by the style sheets) show up just
>fine in the PDF output, but not the screen shots.)
>
>=======
>My questions:
>
>Why are some parameters ignored?

The XSL FO patch is needed.  Email me offline for this.

>What's going on with the <graphic> element?

I don't know, but if the problem persists with the patch,
I'd need more details.

>Are these troubles because I'm using the ATI XML DocBook V4.0 DTD with the
>Epic print composer?

No.

paul