You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Adam Strzelecki <on...@java.pl> on 2005/12/01 19:44:41 UTC
ToUnicode table for CID embedded fonts patch available
Hello FOP devs,
I'm currently implementing some automatic system for project
documentation in my company. Since I've used DocBook for my thesis few
years ago successfully with FOP I'm also decided to use FOP for this
task instead some very very expensive commercial alternatives.
Since I needed to embed some custom TTF fonts in my PDF outputs I found
that ToUnicode CMaps were still missing (even the valid places for
implementing that were marked). Maybe it is not crucial, but it is very
nice to be able to copy the text from PDF files, isn't it ?
So I created the patch for FOP 0.20.5 (FOP 0.90alpha1 was running very
unstable for my DocBook documents with latest XSL stylesheets).
http://issues.apache.org/bugzilla/show_bug.cgi?id=5335
I created this code looking how FOray does the trick, but since FOray's
code differs a lot from FOP's one this porting wasn't very straight.
If you have a time please include it into the TRUNK (maybe you can take
a while to port it to 0.90).
I think this is feature that many people wish to see in FOP.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: ToUnicode table for CID embedded fonts patch available
Posted by Adam Strzelecki <on...@java.pl>.
> Sorry but the attachment doesn't appear to have come through....
It's at Bugzilla here:
http://issues.apache.org/bugzilla/attachment.cgi?id=17203
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: ToUnicode table for CID embedded fonts patch available
Posted by Chris Bowditch <bo...@hotmail.com>.
Adam Strzelecki wrote:
>>Vincent Hennebert is already working with the FOray project to integrate
>>its font subsystem with FOP so we will have ToUnicode CMaps. It's nice
>>that you share your patch with everyone but it won't be applied to the
>>old, frozen maintenance branch anymore.
>
> So once now I moved to FOP SVN TRUNK ... I just submitted ToUnicode map
> patch for SVN version of FOP. I know that FOray is very close.. however
> if anybody must now generate docs with custom fonts here it is...
Sorry but the attachment doesn't appear to have come through....
Chris
Re: ToUnicode table for CID embedded fonts patch available
Posted by Adam Strzelecki <on...@java.pl>.
> Vincent Hennebert is already working with the FOray project to integrate
> its font subsystem with FOP so we will have ToUnicode CMaps. It's nice
> that you share your patch with everyone but it won't be applied to the
> old, frozen maintenance branch anymore.
So once now I moved to FOP SVN TRUNK ... I just submitted ToUnicode map
patch for SVN version of FOP. I know that FOray is very close.. however
if anybody must now generate docs with custom fonts here it is...
Regards.. and thanks for great opensource alternative :))
--
Adam Strzelecki |: nanoant.com :|
Re: ToUnicode table for CID embedded fonts patch available
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've added support for properly parsing the font-family list in Subversion.
The new code should now behave much like FOP 0.20.5.
http://svn.apache.org/viewcvs?rev=351734&view=rev
Concerning the broken font embedding: I've just verified that it works
for me in PDF for both Type1 and TrueType fonts. Did you notice that the
configuration file format has changed since 0.20.5? Maybe it's something
related to that. If not, is your Garamond font a Type1 or a TrueType
font? What PDF Viewer gave you these error messages?
A note to fop-devs: I realize that the skipping of commas in
PropertyParser might be a little hacky. But it looked like the easiest
thing to do and no test cases broke. If anyone has a better suggestion,
set me right please.
On 02.12.2005 13:58:39 Jeremias Maerki wrote:
<snip/>
> > 2) FOP 0.90alpha1 misinterprets comma separated font family name list in
> > family-name tags at FO, which should be interpreted as kind of priority
> > list when font is found of not. I know this is broken also in 0.20.5, so
> > 0.20.5 will look just for Garamond and if not found it will be dropped
> > to default one... but 0.90alpha1 is looking for
> > "Garamond,Symbol,ZapfDingbats" which is total misbehavior:
> >
> > Font 'Garamond,Symbol,ZapfDingbats,normal,400' not found. Substituting
> > with default font.
> > Font 'Garamond,Symbol,ZapfDingbats,normal,700' not found. Substituting
> > with default font.
> > Font 'Garamond,Symbol,ZapfDingbats,italic,400' not found. Substituting
> > with default font.
> > javax.xml.transform.TransformerException: Some content could not fit
> > into a line/page after 50 attempts. Giving up to avoid an endless loop.
> > Exception
> > javax.xml.transform.TransformerException: java.lang.RuntimeException:
> > Some content could not fit into a line/page after 50 attempts. Giving up
> > to avoi
> > d an endless loop.
> >
> > Anyway 0.90 font embedding is totally broken since... I got some errors
> > like cannot open Garamond,Bold in generated PDF-s.
> >
> > So I'm waiting for FOray font subsystem in FOP.
>
> Well, it should be easy to at least let the new FOP behave like the old.
> I'll look into it.
<snip/>
Jeremias Maerki
Re: Using Docbook stylesheets in FOP
Posted by Adam Strzelecki <on...@java.pl>.
Simon wrote:
> 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.
I managed to pass over that problem using Xalan 2.7.0. However I cannot
still find out the way how to configure CATALOG files so it will work
with Xalan while I just use command:
fop -xml mybook.xml -xsl docbook.xsl -pdf mybook.pdf
however URIResolver and EntityResolver are specified only on Xalan's
command line... so no idea how to push that directly trough FOP without
mod to sourcecode.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sun, Dec 04, 2005 at 02:25:22PM +0100, Andreas L Delmelle wrote:
> On Dec 4, 2005, at 13:35, Simon Pepping wrote:
>
> >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
>
> 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?)
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.
> 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.
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)
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Re: PNG renderer not closing output streams properly.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks for spotting that one. I've just fixed it in Subversion:
http://svn.apache.org/viewcvs?rev=354537&view=rev
On 04.12.2005 15:35:50 Amin Ahmad wrote:
> 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();
> }
> }
Jeremias Maerki
PNG renderer not closing output streams properly.
Posted by Amin Ahmad <am...@hotmail.com>.
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();
}
}
Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
Posted by Simon Pepping <sp...@leverkruid.nl>.
(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: ToUnicode table for CID embedded fonts patch available
Posted by Adam Strzelecki <on...@java.pl>.
Hello Jeremias,
>> javax.xml.transform.TransformerException:
>> file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
>> Error(2/24687): No element mapping definition found for fox:outline
>> Exception javax.xml.transform.TransformerException:
>> org.apache.fop.apps.FOPException:
>> file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
>> Error(2/24687): No element mapping definition found for fox:outline
>
> I think something is in the works to support the XSL 1.1 Working Draft
> exquivalent (fo:bookmarks) of fox:outline in DocBook. See:
>
> https://sourceforge.net/tracker/?func=detail&atid=373750&aid=1357947&group_id=21935
> http://xmlgraphics.apache.org/fop/0.90/upgrading.html
> Well, it should be easy to at least let the new FOP behave like the old.
> I'll look into it.
For the moment none of FOP 0.20.5 and 0.90 is superior of the other.
In FOP 0.20.5:
- missing fo:block keep-together.within-column which does big trouble
that figure titles are often split over the pages with the images
(temporary fix - use the tables for that)
In FOP 0.90:
- missing boookmarks from DocBook (fop extenstions)
- wrong implementation of comma separated lists of font families
Both:
- no ToUnicode maps included
I just wonder when we can see release with all of the features :) ?
Wish it was soon.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: ToUnicode table for CID embedded fonts patch available
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 02.12.2005 13:39:53 Adam Strzelecki wrote:
> Hello Jeremias,
>
> > Vincent Hennebert is already working with the FOray project to integrate
> > its font subsystem with FOP so we will have ToUnicode CMaps. It's nice
> > that you share your patch with everyone but it won't be applied to the
> > old, frozen maintenance branch anymore.
> Okay I can understand that. At last if somebody needs that, it can be
> compiled anytime.
>
> > Anyway, I'd rather you shared with us the details of your experience
> > with 0.90alpha1 because that's where the fun is. If we knew what the
> > problems with the DocBook stylesheets are, then we could fix them and
> > let you migrate.
> Alright... so those are the annoyances that makes me stay with 0.20:
>
> 1) Fox extensions doesn't work, so I cannot generate PDF with Table of
> Contents tree anymore:
>
> javax.xml.transform.TransformerException:
> file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
> Error(2/24687): No element mapping definition found for fox:outline
> Exception javax.xml.transform.TransformerException:
> org.apache.fop.apps.FOPException:
> file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
> Error(2/24687): No element mapping definition found for fox:outline
I think something is in the works to support the XSL 1.1 Working Draft
exquivalent (fo:bookmarks) of fox:outline in DocBook. See:
https://sourceforge.net/tracker/?func=detail&atid=373750&aid=1357947&group_id=21935
http://xmlgraphics.apache.org/fop/0.90/upgrading.html
> 2) FOP 0.90alpha1 misinterprets comma separated font family name list in
> family-name tags at FO, which should be interpreted as kind of priority
> list when font is found of not. I know this is broken also in 0.20.5, so
> 0.20.5 will look just for Garamond and if not found it will be dropped
> to default one... but 0.90alpha1 is looking for
> "Garamond,Symbol,ZapfDingbats" which is total misbehavior:
>
> Font 'Garamond,Symbol,ZapfDingbats,normal,400' not found. Substituting
> with default font.
> Font 'Garamond,Symbol,ZapfDingbats,normal,700' not found. Substituting
> with default font.
> Font 'Garamond,Symbol,ZapfDingbats,italic,400' not found. Substituting
> with default font.
> javax.xml.transform.TransformerException: Some content could not fit
> into a line/page after 50 attempts. Giving up to avoid an endless loop.
> Exception
> javax.xml.transform.TransformerException: java.lang.RuntimeException:
> Some content could not fit into a line/page after 50 attempts. Giving up
> to avoi
> d an endless loop.
>
> Anyway 0.90 font embedding is totally broken since... I got some errors
> like cannot open Garamond,Bold in generated PDF-s.
>
> So I'm waiting for FOray font subsystem in FOP.
Well, it should be easy to at least let the new FOP behave like the old.
I'll look into it.
> 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. :-)
> I got a small question regarding Batik:
> Does Batik SVG rendering produce PostScript code when embedding SVG file
> into PDF or raster ?????
It does not create PostScript code, it creates PDF commands to paint
everything as vector graphics, or at least that applies to most of the
SVG features. Some feature like filters may cause parts of the image to
be rastered by Batik.
Jeremias Maerki
Re: ToUnicode table for CID embedded fonts patch available
Posted by Adam Strzelecki <on...@java.pl>.
Hello Jeremias,
> Vincent Hennebert is already working with the FOray project to integrate
> its font subsystem with FOP so we will have ToUnicode CMaps. It's nice
> that you share your patch with everyone but it won't be applied to the
> old, frozen maintenance branch anymore.
Okay I can understand that. At last if somebody needs that, it can be
compiled anytime.
> Anyway, I'd rather you shared with us the details of your experience
> with 0.90alpha1 because that's where the fun is. If we knew what the
> problems with the DocBook stylesheets are, then we could fix them and
> let you migrate.
Alright... so those are the annoyances that makes me stay with 0.20:
1) Fox extensions doesn't work, so I cannot generate PDF with Table of
Contents tree anymore:
javax.xml.transform.TransformerException:
file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
Error(2/24687): No element mapping definition found for fox:outline
Exception javax.xml.transform.TransformerException:
org.apache.fop.apps.FOPException:
file:/D:/Work/Digitech/IWS%209.x%20redesign/IWS-redesign.fo:2:24687:
Error(2/24687): No element mapping definition found for fox:outline
2) FOP 0.90alpha1 misinterprets comma separated font family name list in
family-name tags at FO, which should be interpreted as kind of priority
list when font is found of not. I know this is broken also in 0.20.5, so
0.20.5 will look just for Garamond and if not found it will be dropped
to default one... but 0.90alpha1 is looking for
"Garamond,Symbol,ZapfDingbats" which is total misbehavior:
Font 'Garamond,Symbol,ZapfDingbats,normal,400' not found. Substituting
with default font.
Font 'Garamond,Symbol,ZapfDingbats,normal,700' not found. Substituting
with default font.
Font 'Garamond,Symbol,ZapfDingbats,italic,400' not found. Substituting
with default font.
javax.xml.transform.TransformerException: Some content could not fit
into a line/page after 50 attempts. Giving up to avoid an endless loop.
Exception
javax.xml.transform.TransformerException: java.lang.RuntimeException:
Some content could not fit into a line/page after 50 attempts. Giving up
to avoi
d an endless loop.
Anyway 0.90 font embedding is totally broken since... I got some errors
like cannot open Garamond,Bold in generated PDF-s.
So I'm waiting for FOray font subsystem in FOP.
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
I got a small question regarding Batik:
Does Batik SVG rendering produce PostScript code when embedding SVG file
into PDF or raster ?????
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: ToUnicode table for CID embedded fonts patch available
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Adam
Vincent Hennebert is already working with the FOray project to integrate
its font subsystem with FOP so we will have ToUnicode CMaps. It's nice
that you share your patch with everyone but it won't be applied to the
old, frozen maintenance branch anymore.
Anyway, I'd rather you shared with us the details of your experience
with 0.90alpha1 because that's where the fun is. If we knew what the
problems with the DocBook stylesheets are, then we could fix them and
let you migrate.
On 01.12.2005 19:44:41 Adam Strzelecki wrote:
> Hello FOP devs,
>
> I'm currently implementing some automatic system for project
> documentation in my company. Since I've used DocBook for my thesis few
> years ago successfully with FOP I'm also decided to use FOP for this
> task instead some very very expensive commercial alternatives.
>
> Since I needed to embed some custom TTF fonts in my PDF outputs I found
> that ToUnicode CMaps were still missing (even the valid places for
> implementing that were marked). Maybe it is not crucial, but it is very
> nice to be able to copy the text from PDF files, isn't it ?
>
> So I created the patch for FOP 0.20.5 (FOP 0.90alpha1 was running very
> unstable for my DocBook documents with latest XSL stylesheets).
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=5335
>
> I created this code looking how FOray does the trick, but since FOray's
> code differs a lot from FOP's one this porting wasn't very straight.
>
> If you have a time please include it into the TRUNK (maybe you can take
> a while to port it to 0.90).
>
> I think this is feature that many people wish to see in FOP.
>
> Regards,
> --
> Adam Strzelecki |: nanoant.com :|
Jeremias Maerki