Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)

2005-12-04 Thread Simon Pepping
(Cross-posting to fop-user)

On Fri, Dec 02, 2005 at 01:58:39PM +0100, Jeremias Maerki wrote:
 
 On 02.12.2005 13:39:53 Adam Strzelecki wrote:
  Hello Jeremias,
  
  3) Last thing I would really appreciate is I would love to generate PDF
  directly from XML files using stylesheets but FOP XSLT routine is
  somehow broken so I need to do the conversion with XSLTPROC which does
  it without the problem.
  
  This is the error when I use FOP with:
  fop -xml myfile.xml -xsl docbook/fo/docbook.xsl -pdf myfile.pdf
  
  Compiler warnings:
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 433:
  Attribute 'border-left-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 434:
  Attribute 'border-right-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 435:
  Attribute 'border-top-style' outside of element.
file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 436:
  Attribute 'border-bottom-style' outside of element.
  ERROR:  'Syntax error in '* or $generate.index != 0'.'
  FATAL ERROR:  'Could not compile stylesheet'
  Exception
  javax.xml.transform.TransformerConfigurationException: Could not compile
  stylesheet
  
  Problem is in the XSL file of DocBook XLS 1.69.1 sheets:
  docbook/fo/autotoc.xsl
 
 Sounds more like a problem in either the stylesheet itself or in Xalan
 which FOP calls for doing XSLT. Maybe I should finally install DocBook
 on my machine. :-)

It is indeed not really a FOP issue.

The docbook stylesheets seem to be a pain for most XSLT
processors. Restricting myself to Java XSLT processors, I
have only been successful with Saxon6. Xalan and the Xalan processor
built into Java 5 cannot compile the docbook/fo stylesheets.

This can be achieved by putting saxon.jar first in the classpath. It
must come before xalan.jar, in order to configure the Transformer
factory to use Saxon. Unfortunately, this is not possible with the
current fop shell script, because it puts the CLASSPATH variable at
the end of the class path. (Sometimes this is what you want, here
it is not.) The fop.bat batch file ignores the CLASSPATH variable
completely.

Another issue I have with FOP and Docbook is that FOP out of the box
does not use catalogs. I think we should do something about this. It
is unrealistic to expect Docbook users to write their own startup Java
file. They want something that works from the command line. But before
we try, it would be useful to hear how other people use FOP with
Docbook.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)

2005-12-04 Thread Andreas L Delmelle

On Dec 4, 2005, at 13:35, Simon Pepping wrote:


On Fri, Dec 02, 2005 at 01:58:39PM +0100, Jeremias Maerki wrote:

snip /
Sounds more like a problem in either the stylesheet itself or in  
Xalan
which FOP calls for doing XSLT. Maybe I should finally install  
DocBook

on my machine. :-)


It is indeed not really a FOP issue.

The docbook stylesheets seem to be a pain for most XSLT
processors. Restricting myself to Java XSLT processors, I
have only been successful with Saxon6. Xalan and the Xalan processor
built into Java 5 cannot compile the docbook/fo stylesheets.

This can be achieved by putting saxon.jar first in the classpath.


FYI other options include:
- modifying your %JAVA_HOME%/lib/jaxp.properties file (or creating  
one if it doesn't exist)

- supplying the property via java's '-D' command-line option

jaxp.properties would look something like:
javax.xml.transformer.TransformerFactory=com.icl.saxon.TransformerFactor 
yImpl


(analogous for 'java -D...')

The first one has the advantage that it is completely independent of  
our FOP shell scripts, but it affects all Java Apps, so is really  
only useful when the user wants to use Saxon everywhere instead of  
Xalan (the default).


The second one would still require a modification to the shell  
script, maybe in the form of an optional parameter you can pass to  
the script. If the parameter is present, the java command-line at the  
bottom of the script can be made to take into account the override  
for that particular system property. (So, this could turn out to be  
beneficial in other areas as well, where the user needs to override  
sysprops... Could this solve the issue of using catalogs?)


How about allowing:

fop -sysprop ... -fo ... -pdf ...

The -sysprop switch is caught by the shell script, and incorporated  
into the java command-line.
(Using '-D' here would create confusion with FOP's own '-d' switch,  
unless we were to allow only the slightly more verbose '-debug')


Just a thought.

Cheers,

Andreas



PNG renderer not closing output streams properly.

2005-12-04 Thread Amin Ahmad

Hi Team FOP,

I was playing around with the PNG Renderer, and I think I noticed a problem 
-- when it produces multiple files (one per page) it does not appear to be 
explicity closing the files it creates. Java GC takes care of closing the 
files automatically, but, running Java 5, the final file is left open until 
the JVM terminates.


In the code below from PNGRenderer, on the last line of the for loop, the 
output stream is flushed but never closed. At the top of the loop, os is 
reassigned to a new output stream for the next page.


thanks,
Amin


   public void stopRenderer() throws IOException {

   super.stopRenderer();

   for (int i = 0; i  pageViewportList.size(); i++) {

   OutputStream os = getCurrentOutputStream(i);
   if (os == null) {
   log.warn(No filename information available.
   +  Stopping early after the first page.);
   break;
   }
   // Do the rendering: get the image for this page
   RenderedImage image = (RenderedImage) 
getPageImage((PageViewport) pageViewportList

   .get(i));

   // Encode this image
   log.debug(Encoding page  + (i + 1));
   renderParams = PNGEncodeParam.getDefaultEncodeParam(image);

   // Set resolution
   float pixSzMM = userAgent.getPixelUnitToMillimeter();
   // num Pixs in 1 Meter
   int numPix = (int)((1000 / pixSzMM) + 0.5);
   renderParams.setPhysicalDimension(numPix, numPix, 1); // 1 means 
'pix/meter'


   // Encode PNG image
   PNGImageEncoder encoder = new PNGImageEncoder(os, renderParams);
   encoder.encode(image);
   os.flush();
   }
   }




Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)

2005-12-04 Thread Andreas L Delmelle

On Dec 4, 2005, at 16:14, Simon Pepping wrote:


On Sun, Dec 04, 2005 at 02:25:22PM +0100, Andreas L Delmelle wrote:

snip / Could this solve the issue of using catalogs?)


No. Catalogs can only be used by registering an EntityResolver with
the XMLReader and a URIResolver with the Transformer. FOP's CLI code
currently just does not do this.


Good, that settles that. We'll have to look at other options here...




How about allowing:

fop -sysprop ... -fo ... -pdf ...

The -sysprop switch is caught by the shell script, and incorporated
into the java command-line.
(Using '-D' here would create confusion with FOP's own '-d' switch,
unless we were to allow only the slightly more verbose '-debug')


Users do not like to have to know the name of such an obscure
property. Configuring the class path is already a lot to ask from
someone not interested in Java per se.


Well then, maybe the solution would be to shield the user from the  
fact that it's a system property by having them supply only the name  
of the TransformerFactory implementation to use.


Besides that, I don't really think it's an obscure property (quite on  
the contrary). It's not because someone isn't aware of the existence  
of something, that that something is to be considered as obscure.  
Given proper documentation, the user might learn something new while  
configuring FOP...


Oh, sorry, I forgot that most people don't like to learn anything at  
all. :-P



Cheers,

Andreas



Bug report for Fop [2005/12/04]

2005-12-04 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font  |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row|
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly  |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables   |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body  |
| 3497|New|Cri|2001-09-07|id already exists error when using span=all attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling=uniform does not work on images...  |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored?  |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG   |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values   |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render   |
| 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect   |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7140|New|Enh|2002-03-15|page-position attribute set to last on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space   |
| 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page  |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block  |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images  |
| 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly   |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables  |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
|