Re: Measurement accuracy in PDF vs PCL
I've tried to think through the "fudge factor" for this particular application and unfortunately haven't found anything that works. I have a pretty narrow target to hit with each label and by the time the differences add up, correcting for one extreme (i.e. too high or too low) inevitably causes problems at the other end of the sheet. As I said, I'm not sure that these particular labels will ever have cause to be printed from a PDF rendering, so I can develop the sheet for PCL and not worry about the problems at this point, but it does raise interesting questions in my mind about the reliability of the measurements we specify in general. How much confidence can we have that when we say Xmm, we will really be guaranteed Xmm? The line wrapping issue you mention is also intriguing. For the record, though, many thanks to all the FOP dev team for the work going on here. I poked through the code a little and there has been a ton of work to get FOP to this point. Dave >>> Roland Neilands 5/8/2008 7:13 PM >>> I'll second this. I also see difference in either text sizes or field width causing line wrapping in several places in PCL but not PDF with the same file. The workaround is to allow a fudge factor in the field/table row/table height sizes, but this can cause text overlapping or large blank areas, so it's hardly ideal. Regards, *Roland * David Gerdt wrote: > I'm curious as to the differences between how distances are measured > between different output formats. I've been trying to get a sheet of > address labels to align correctly and am noticing a vast difference > between how they are rendered in a PDF vs how they appear in PCL. > > I use a combination of Eclipse and the Orangevolt XSLT plugin to > develop my style sheets and generate PDFs on a WinXP box because I can > quickly see the results. Ultimately, the documents will be rendered on > an AIX system, normally (though not always) as PCL. There are > instances where the same document can be rendered in either of these > two formats, and that's why these differences make me nervous. > > In the case of the mailing labels, I'm noticing about a 1mm difference > in height for the table cells. PDF cells are right at 26mm and PCL at > 27mm. That sounds like a very slight difference, but it adds up to a > 1cm difference over the ten rows of the sheet of labels. Also, the top > margin has a difference of about 5mm between the two formats, with the > first table row starting at 17mm in the PDF output and about 12mm for > the PCL version. > > Can anyone give any insight? Is this just a driver thing? > > I am running the 0.95beta on both machines. The fo is attached if > you're interested. > > Thanks for the help! > > This e-mail is solely for the use of the intended recipient and may > contain information which is confidential or privileged. Any > unauthorised use of its contents is prohibited. If you have received > this e-mail in error, please notify the sender via return e-mail and > then delete the original e-mail. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Measurement accuracy in PDF vs PCL
I'll second this. I also see difference in either text sizes or field width causing line wrapping in several places in PCL but not PDF with the same file. The workaround is to allow a fudge factor in the field/table row/table height sizes, but this can cause text overlapping or large blank areas, so it's hardly ideal. Regards, *Roland * David Gerdt wrote: I'm curious as to the differences between how distances are measured between different output formats. I've been trying to get a sheet of address labels to align correctly and am noticing a vast difference between how they are rendered in a PDF vs how they appear in PCL. I use a combination of Eclipse and the Orangevolt XSLT plugin to develop my style sheets and generate PDFs on a WinXP box because I can quickly see the results. Ultimately, the documents will be rendered on an AIX system, normally (though not always) as PCL. There are instances where the same document can be rendered in either of these two formats, and that's why these differences make me nervous. In the case of the mailing labels, I'm noticing about a 1mm difference in height for the table cells. PDF cells are right at 26mm and PCL at 27mm. That sounds like a very slight difference, but it adds up to a 1cm difference over the ten rows of the sheet of labels. Also, the top margin has a difference of about 5mm between the two formats, with the first table row starting at 17mm in the PDF output and about 12mm for the PCL version. Can anyone give any insight? Is this just a driver thing? I am running the 0.95beta on both machines. The fo is attached if you're interested. Thanks for the help! This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Measurement accuracy in PDF vs PCL
I'm curious as to the differences between how distances are measured between different output formats. I've been trying to get a sheet of address labels to align correctly and am noticing a vast difference between how they are rendered in a PDF vs how they appear in PCL. I use a combination of Eclipse and the Orangevolt XSLT plugin to develop my style sheets and generate PDFs on a WinXP box because I can quickly see the results. Ultimately, the documents will be rendered on an AIX system, normally (though not always) as PCL. There are instances where the same document can be rendered in either of these two formats, and that's why these differences make me nervous. In the case of the mailing labels, I'm noticing about a 1mm difference in height for the table cells. PDF cells are right at 26mm and PCL at 27mm. That sounds like a very slight difference, but it adds up to a 1cm difference over the ten rows of the sheet of labels. Also, the top margin has a difference of about 5mm between the two formats, with the first table row starting at 17mm in the PDF output and about 12mm for the PCL version. Can anyone give any insight? Is this just a driver thing? I am running the 0.95beta on both machines. The fo is attached if you're interested. Thanks for the help! labels.fo Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Identify list in subject line
Andreas Delmelle wrote: > > On May 8, 2008, at 12:08, Jeremias Maerki wrote: > >> On 08.05.2008 12:01:51 John Brown wrote: >>> Hello all, >>> >>> I think that messages on the fop-users mailing list should identify >>> themselves in the subject line, like most mailing lists. For example: >>> >>> [fop-users] Problem using Lucida Console font >>> >> ezmlm adds the "List-Post" header entry. You can use that for >> filtering >> (assuming that was the cause for this message). > > The recipient would also be a reasonable choice, no? > I normally filter on the 'To:' line, but I have not got around to creating a filter for fop-users yet. I wanted to identify those messages just by looking. It's not a big deal. _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: variable size output (pages)?
Andreas Delmelle wrote: I think the problem is that you have to specify the eventual renderer to mimic. Try ../fop -xsl lineage.xsl -xml lineage_eg.xml -at image/tiff lineage.at.xml; Yes; that worked (in the standard sense of did what I wanted!) Thank you very much, for all your help. BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Identify list in subject line
On May 8, 2008, at 12:08, Jeremias Maerki wrote: On 08.05.2008 12:01:51 John Brown wrote: Hello all, I think that messages on the fop-users mailing list should identify themselves in the subject line, like most mailing lists. For example: [fop-users] Problem using Lucida Console font ezmlm adds the "List-Post" header entry. You can use that for filtering (assuming that was the cause for this message). The recipient would also be a reasonable choice, no? Only fails for those still posting to the old address --but that's a matter of tweaking the condition--, or people who do not use the 'To' header... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: variable size output (pages)?
On May 8, 2008, at 14:52, paul womack wrote: q1) May I assume that any particular version of FOP would be able to consume an area tree (XML) that it had itself generated? That's a reasonable assumption, I think. (I have noted your other information; thank you) This assumption may be reasonable, but it just failed a test (I think) generating tiff directly: ../fop -dpi 288 -xsl lineage.xsl -xml lineage_eg.xml -tiff a.tif gives me different line breaks to going via an "at" file: ../fop -xsl lineage.xsl -xml lineage_eg.xml -at lineage.at.xml; ../ fop -atin lineage.at.xml -dpi 288 -tiff b.tif Unless these are different for a "valid" reason that I am ignorant of? I think the problem is that you have to specify the eventual renderer to mimic. Try ../fop -xsl lineage.xsl -xml lineage_eg.xml -at image/tiff lineage.at.xml; ^^ HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: variable size output (pages)?
Andreas Delmelle wrote: On May 8, 2008, at 14:17, paul womack wrote: O.K. I've found this documentation on the "area tree" internal modelling: http://xmlgraphics.apache.org/fop/dev/design/areas.html I think this page: http://xmlgraphics.apache.org/fop/0.94/intermediate.html says that the XML format is "subject to change". q1) May I assume that any particular version of FOP would be able to consume an area tree (XML) that it had itself generated? That's a reasonable assumption, I think. (I have noted your other information; thank you) This assumption may be reasonable, but it just failed a test (I think) generating tiff directly: ../fop -dpi 288 -xsl lineage.xsl -xml lineage_eg.xml -tiff a.tif gives me different line breaks to going via an "at" file: ../fop -xsl lineage.xsl -xml lineage_eg.xml -at lineage.at.xml; ../fop -atin lineage.at.xml -dpi 288 -tiff b.tif Unless these are different for a "valid" reason that I am ignorant of? The "b.tif" files has lines going beyond the right hand side of the raster; the lines appears to have been wrapped for a large page width than I (actually) have. BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: variable size output (pages)?
On May 8, 2008, at 14:17, paul womack wrote: O.K. I've found this documentation on the "area tree" internal modelling: http://xmlgraphics.apache.org/fop/dev/design/areas.html I think this page: http://xmlgraphics.apache.org/fop/0.94/intermediate.html says that the XML format is "subject to change". q1) May I assume that any particular version of FOP would be able to consume an area tree (XML) that it had itself generated? That's a reasonable assumption, I think. q2) And, a detail question, which I have not been (easily) able to find an answer to: in the area tree, what are the units? 1/1000 of a point (= non-standard 'millipoints'), or 1/72000 inches. My present plan is to identify the lower bound of the last text line from the area tree, then use that to perform a second fop pass (all the way from the start) with a "carefully contrived" page-height. What I think would be the easiest approach: -> generate an area tree using a relatively large page-height (enough to fit the largest content) -> use forced breaks (break-before="page") in the FO to trigger the page-breaks -> if you look at the area tree, you will then see elements generated for the region-body of each page; if the initial used page-size is large enough, these should have the exact same dimensions on every page Finally, run the area tree through an XSLT transform, that simply copies the input, but adds special processing for those regionViewports: check the childnodes' accumulated 'bpd' attribute, and shrink the regionViewport's bounds so it will fit nicely around the content. This is all a bit speculative, but this seems the most efficient way I can come up with FTM, and it does presuppose some knowledge/ understanding of XSLT. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ClassCastException while loading image
Hello all, I just ran into rather strange problems during FO processing, causing the exception shown below. My research (web searching, FAQ & mail archive etc.) turned up blank. Started: "D:\Java\jre1.6.0_06\bin\java" ... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf D:\Tools\e33\xml-test\figures.pdf 08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S java.lang.ClassCastException: [B cannot be cast to [S at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source) at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174) at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75) at org.apache.fop.fo.FObj.processNode(FObj.java:125) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) at net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343) ... --- What I did and what happened: Two png images are to be included into a pdf. Exceptions occur, finally resulting in a null image. PDF is generated, can be viewed, but one image is missing. There's just empty space of correct dimensions in the document. Circumstances: Both images are fetched from a web server. Both are available by URL in a browser and both can be opened by an image editor program, meaning the files themselves seem to be ok. Loading the images from remote by a small java awt test application (using ImageIO) works fine. Both images were created by conversion to png (ImageMagick), one using a wmf as source the other having an emf as source. Both images share the same filename but are from different paths/URLs. Java 1.6.0_06 fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin) fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter 3.1 without VM)) What happened? Any ideas? Upon request I'll gladly provide both images, the minimal fo source, and the pdf result. Best regards and thanks in advance, Michael Glass -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple outputs
On May 8, 2008, at 14:06, paul womack wrote: Andreas Delmelle wrote: If you would use FOP multiple times in a row, without restarting the JVM, then over a few runs that will save you minutes... The very first run is always a lot slower due to static initialization, class loading etc. Once the VM is warmed up, the average runtime for a formatting run will drastically reduce. To see what I mean, you could already make the comparison: try 50 isolated runs from the command-line, and afterwards, perform the same 50 runs, but then looped in a single small class. Hmm. As a compromise, I may be able to create a java class that accepts multiple "commandlines" from stdin. A possible option: I once wrote a very small 'FOP server program'. No servlet container needed or anything, just a simple program that opens a socket, and listens for simple string requests in a form that suited me. A modified version of the example files, surrounded by an infinite loop. If you know just a bit of Java, this should take only very little time. Programming threads and sockets in Java is a piece of cake, when compared to C. Something like that suffices to keep the Java VM running until a forced shutdown, and avoid any startup overhead on all but the very first run. I have only very little experience with Perl, but IIC, it should be equally straightforward to send the client request from within a script. Maybe an idea for you. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: variable size output (pages)?
Andreas Delmelle wrote: On May 6, 2008, at 14:16, paul womack wrote: Hi In effect I want to generate "galleys" of text, where the formatting width is known, but the depth of the final output is determined by the amount of text formatted, in effect fitting the page to the content. What you would need: http://www.w3.org/TR/xsl/#page-height See the defined possible value of "indefinite" FOP does not implement this yet, unfortunately (while the compliance page /does/ indicate full compliance; correction/note needed) For the moment, your area tree idea is probably your best bet, unless you feel like joining us, and diving into the code yourself... ;-) O.K. I've found this documentation on the "area tree" internal modelling: http://xmlgraphics.apache.org/fop/dev/design/areas.html I think this page: http://xmlgraphics.apache.org/fop/0.94/intermediate.html says that the XML format is "subject to change". q1) May I assume that any particular version of FOP would be able to consume an area tree (XML) that it had itself generated? q2) And, a detail question, which I have not been (easily) able to find an answer to: in the area tree, what are the units? (I could reverse engineer, but I'd rather not) My present plan is to identify the lower bound of the last text line from the area tree, then use that to perform a second fop pass (all the way from the start) with a "carefully contrived" page-height. BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple outputs
Andreas Delmelle wrote: If you would use FOP multiple times in a row, without restarting the JVM, then over a few runs that will save you minutes... The very first run is always a lot slower due to static initialization, class loading etc. Once the VM is warmed up, the average runtime for a formatting run will drastically reduce. To see what I mean, you could already make the comparison: try 50 isolated runs from the command-line, and afterwards, perform the same 50 runs, but then looped in a single small class. Hmm. As a compromise, I may be able to create a java class that accepts multiple "commandlines" from stdin. This could be driven either via a pipe from a script (a sort of fop daemon) or via a command file, as per egrep --file (etc) I would prefer to avoid too much close-coupling with java in my particular environment (system intgration, coded in perl). In conjunction with my requirment to have variable size output, and 2 output formats, I think I need 3 runs in total, so reducing startup overhead seems a useful goal. BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue
On May 8, 2008, at 12:03, Andreas Delmelle wrote: Hi Jean-François, On May 8, 2008, at 12:57, Jean-François El Fouly wrote: Andreas Delmelle a écrit : OK. Just curious: Any chance you could test it on another build or maybe even Java 6? Probably, if required or useful. Our sys admins are very cooperative ;-) For the moment, that would be more a nice-to-know. Chances are that, if it's not JVM-related, this won't help a thing, so no need to go out of your way to do that Yes. That is exactly what happened to the stylesheet we use. I've reduced it drastically. One issue with stylesheets generated by StyleVision is that you must be careful when you tweak them to avoid certain [fo-block inside fo:inline] combinations that make FOP crash with a stack trace and no really useful information about what's happening or where. This bug is mentioned in the FOP bug tracker, though in a rather raw, loose manner. I removed all such constructs and that made the XSLT much simpler and cleaner. OK, so we can exclude that as well. AFAIU, this gives little opportunity for the XSLT processor to clean up anything. Java 1.5 uses Xalan XSLTC by default, which converts templates into Java objects. One giant template would then mean one very long-living object that may reference numerous others for the whole duration of the processing run. If you look at the chain, when using XML+XSLT input, FOP is always the first one to finish, then the XSLT processor, then the XML parser. If the XSLT processor cannot reclaim anything, this will give FOP less room to work with, so it ultimately runs slower. As the heap increases to reach the maximum, the points where the JVM will launch the GC by itself, will also increase. Since it cannot expand the heap anymore, it will try to clean up more frequently. Yep, that is why I've tried to be cautious not to accuse FOP publicly ;-) ... which is also why /we/ are so cooperative/responsive. ;-) BTW: If all users would have the time and motivation to be as thorough as yourself, the traffic on this list would probably drop significantly. The problem is in the (Xalan + FOP) subsystem and the profiling could well show that the issue is Xalan-related. Or maybe even Xerces...? Xerces is a very feature-complete parser, but reports in the past have shown that all those nice features come with a price-tag. For FOP this holds as well, of course, and to be honest, FOP can be a pretty memory-hungry beast if you're not careful (but you definitely seem to be). A relatively easy way to find out whether it's XSLT-related, would be to try out Saxon instead. I don't know if you have any experience with plugging in a different XSLT processor, but this is pretty straightforward (but might require re-starting the JBoss service, depending on how you go about it; for testing purposes, you could ultimately also change the app-code to reference Saxon directly instead of letting the JVM choose the javax.xml.transform.TransformerFactory implementation, and then redeploy). Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue
Andreas Delmelle a écrit : OK. Just curious: Any chance you could test it on another build or maybe even Java 6? Probably, if required or useful. Our sys admins are very cooperative ;-) In my personal experience, optimizing the stylesheet code usually does not offer much improvement in terms of global memory usage, but it could have a noticeable impact on the processing time. One of the things I've learned about generated XSL-FO stylesheets by Altova is that they add a lot of fo:inlines to specify, for example, font-properties on the lowest levels in the generated FO while, when comparing to the font-properties of the fo:inlines' parents nothing really changes, except for the size, style or weight. From FOP's point of view, that's somewhat of a waste. Much better to specify a global font-size on the page-sequence, and override on the lower levels only what is really necessary. After adapting the stylesheet manually, and removing the redundant fo:inlines, the stylesheet and the generated FO were reduced to not even half the original size. Yes. That is exactly what happened to the stylesheet we use. I've reduced it drastically. One issue with stylesheets generated by StyleVision is that you must be careful when you tweak them to avoid certain [fo-block inside fo:inline] combinations that make FOP crash with a stack trace and no really useful information about what's happening or where. This bug is mentioned in the FOP bug tracker, though in a rather raw, loose manner. I removed all such constructs and that made the XSLT much simpler and cleaner. Something else that bothered me, but I don't know if that was also generated by Altova, is that in one of the stylesheets I saw, the entire transformation was contained in one giant template... With the last version, or our XSLT ? this was no longer the case. AFAIU, this gives little opportunity for the XSLT processor to clean up anything. Java 1.5 uses Xalan XSLTC by default, which converts templates into Java objects. One giant template would then mean one very long-living object that may reference numerous others for the whole duration of the processing run. If you look at the chain, when using XML+XSLT input, FOP is always the first one to finish, then the XSLT processor, then the XML parser. If the XSLT processor cannot reclaim anything, this will give FOP less room to work with, so it ultimately runs slower. As the heap increases to reach the maximum, the points where the JVM will launch the GC by itself, will also increase. Since it cannot expand the heap anymore, it will try to clean up more frequently. Yep, that is why I've tried to be cautious not to accuse FOP publicly ;-) The problem is in the (Xalan + FOP) subsystem and the profiling could well show that the issue is Xalan-related. BTW, we've made the Xalan-FOP coupling a parameter so that we can use tight coupling (with Sax events) or loose coupling (writing the intermediate FO files on disk). We usually use the second option, since the possibility to read the FO intermediate code is helpful when you debug. And I guess without being really sure that not to have Xalan and FOP working at the same time should use less memory. This separation probably accounts for the long execution time, but that is not an issue since document generation does not occur often in the target system (you can generate chapters for proofreading but you generate the whole document once-twice a day). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClassCastException while loading image
Smells like some class obfuscation gone wrong. Please run FOP outside of OxygenXML with FOP's own command-line to see if the same thing occurs there. Otherwise, no better idea, yet. On 08.05.2008 12:02:05 Michael Glass wrote: > Hello all, > > I just ran into rather strange problems during FO processing, causing the > exception shown below. My research (web searching, FAQ & mail archive etc.) > turned up blank. > > > > Started: "D:\Java\jre1.6.0_06\bin\java" > ... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... > org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf > D:\Tools\e33\xml-test\figures.pdf > 08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap > SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S > java.lang.ClassCastException: [B cannot be cast to [S > at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source) > at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174) > at > org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) > at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) > at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75) > at org.apache.fop.fo.FObj.processNode(FObj.java:125) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) > at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) > at > net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343) > ... > --- > > What I did and what happened: > > Two png images are to be included into a pdf. Exceptions occur, finally > resulting in a null image. PDF is generated, can be viewed, but one image is > missing. There's just empty space of correct dimensions in the document. > > Circumstances: > > Both images are fetched from a web server. Both are available by URL in a > browser and both can be opened by an image editor program, meaning the files > themselves seem to be ok. Loading the images from remote by a small java awt > test application (using ImageIO) works fine. Both images were created by > conversion to png (ImageMagick), one using a wmf as source the other having > an emf as source. Both images share the same filename but are from different > paths/URLs. > > Java 1.6.0_06 > fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin) > > fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter > 3.1 without VM)) > > What happened? Any ideas? Upon request I'll gladly provide both images, the > minimal fo source and the pdf result. > > Best regards and thanks in advance, > > Michael Glass Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ClassCastException while loading image
Hello all, I just ran into rather strange problems during FO processing, causing the exception shown below. My research (web searching, FAQ & mail archive etc.) turned up blank. Started: "D:\Java\jre1.6.0_06\bin\java" ... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf D:\Tools\e33\xml-test\figures.pdf 08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S java.lang.ClassCastException: [B cannot be cast to [S at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source) at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174) at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75) at org.apache.fop.fo.FObj.processNode(FObj.java:125) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) at net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343) ... --- What I did and what happened: Two png images are to be included into a pdf. Exceptions occur, finally resulting in a null image. PDF is generated, can be viewed, but one image is missing. There's just empty space of correct dimensions in the document. Circumstances: Both images are fetched from a web server. Both are available by URL in a browser and both can be opened by an image editor program, meaning the files themselves seem to be ok. Loading the images from remote by a small java awt test application (using ImageIO) works fine. Both images were created by conversion to png (ImageMagick), one using a wmf as source the other having an emf as source. Both images share the same filename but are from different paths/URLs. Java 1.6.0_06 fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin) fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter 3.1 without VM)) What happened? Any ideas? Upon request I'll gladly provide both images, the minimal fo source and the pdf result. Best regards and thanks in advance, Michael Glass -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Identify list in subject line
ezmlm adds the "List-Post" header entry. You can use that for filtering (assuming that was the cause for this message). On 08.05.2008 12:01:51 John Brown wrote: > Hello all, > > I think that messages on the fop-users mailing list should identify > themselves in the subject line, like most mailing lists. For example: > > [fop-users] Problem using Lucida Console font Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue
On May 8, 2008, at 11:38, Jean-François El Fouly wrote: Andreas Delmelle a écrit : Which Java VM are you using? Practically every time someone tells us about memory/GC issues, it appears they are using an implementation other than Sun (IBM, GNU...) Up to now, we still have to find out why precisely non-Sun VMs have difficulties with FOP... Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM 1.5.0_11, or maybe the very minor build after. OK. Just curious: Any chance you could test it on another build or maybe even Java 6? How large would the resulting FO-files be if you dump them to the filesystem? The XML by itself says very little. From a 1.5MB XML, you could get a FO of a few KB or one of 26MB, depending on the stylesheet. 5.08 Mb. That's not what I would call a large FO, so this should be no problem. Does the stylesheet adhere to XSLT best practices? Does it generate a lot of redundant fo:blocks, fo:inlines? I hope not. It has been a complicated thing generated by StyleVision in the very beginning but it has been simplified and tweaked a lot. In my personal experience, optimizing the stylesheet code usually does not offer much improvement in terms of global memory usage, but it could have a noticeable impact on the processing time. One of the things I've learned about generated XSL-FO stylesheets by Altova is that they add a lot of fo:inlines to specify, for example, font- properties on the lowest levels in the generated FO while, when comparing to the font-properties of the fo:inlines' parents nothing really changes, except for the size, style or weight. From FOP's point of view, that's somewhat of a waste. Much better to specify a global font-size on the page-sequence, and override on the lower levels only what is really necessary. After adapting the stylesheet manually, and removing the redundant fo:inlines, the stylesheet and the generated FO were reduced to not even half the original size. Something else that bothered me, but I don't know if that was also generated by Altova, is that in one of the stylesheets I saw, the entire transformation was contained in one giant template... AFAIU, this gives little opportunity for the XSLT processor to clean up anything. Java 1.5 uses Xalan XSLTC by default, which converts templates into Java objects. One giant template would then mean one very long-living object that may reference numerous others for the whole duration of the processing run. If you look at the chain, when using XML+XSLT input, FOP is always the first one to finish, then the XSLT processor, then the XML parser. If the XSLT processor cannot reclaim anything, this will give FOP less room to work with, so it ultimately runs slower. As the heap increases to reach the maximum, the points where the JVM will launch the GC by itself, will also increase. Since it cannot expand the heap anymore, it will try to clean up more frequently. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On 08.05.2008 10:48:33 John Brown wrote: > Jeremias Maerki jeremias-maerki.ch> writes: > > > > > I have an Ubuntu 8.04 in a VM to play with. So I copied over the Bodoni > > fonts from that ZIP file you indicated. However, the ZIP does not > > contain any AFM files for the Bodoni font, just the PFB and PFM. > > You are right. The timestamp was different for the AFM files (2007 as > opposed to 1990), so I looked inside one and saw: > > Comment AFM Generated by Ghostscript/pf2afm > > > Looking > > at these fonts, BTW, gives me a strong impression that these are illegal > > and altered copies (Some of the fonts give a BBS phone number). Anyway, > > I had no problems > > Oh well... > > > auto-detecting and using the fonts with FOP 0.95beta. > > fop-trunk also works. > > > If you've installed the fonts in a location other than the directory > > mentioned in the following Java class: > > > http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java > > you'll have to use the "directory" element in the font configuration. > > > > It worked. All fonts that I have tried so far (TT and Type1) can now > be used. Great. Thanks for the feedback. BTW, I've added the additional Unix font directory: http://svn.apache.org/viewvc?rev=654453&view=rev > By the way, the FOP-trunk online documentation says: > > "Font registration via XML font metrics file is still supported and is still > necessary if you want to use a TrueType Collection (*.ttc). Direct support for > TrueType collections may be added later." > > This should be updated, as I can use such fonts. Cambria is an MS font that > comes with Office 2007, but, for whatever reason, it is included in the > latest PowerPoint viewer, the installer of which runs on Linux. Cambria.ttf > contains "Cambria" and "Cambria Math" (which I know only because FOP > told me) and I can select either one. I've updated the documentation in SVN. It will go live the next time the website is published. Thanks for the hint. > Thanks. > > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Identify list in subject line
Hello all, I think that messages on the fop-users mailing list should identify themselves in the subject line, like most mailing lists. For example: [fop-users] Problem using Lucida Console font - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue
Andreas Delmelle a écrit : Which Java VM are you using? Practically every time someone tells us about memory/GC issues, it appears they are using an implementation other than Sun (IBM, GNU...) Up to now, we still have to find out why precisely non-Sun VMs have difficulties with FOP... Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM 1.5.0_11, or maybe the very minor build after. How large would the resulting FO-files be if you dump them to the filesystem? The XML by itself says very little. From a 1.5MB XML, you could get a FO of a few KB or one of 26MB, depending on the stylesheet. 5.08 Mb. Does the stylesheet adhere to XSLT best practices? Does it generate a lot of redundant fo:blocks, fo:inlines? I hope not. It has been a complicated thing generated by StyleVision in the very beginning but it has been simplified and tweaked a lot. A nit, for the record: There is no such thing as 'forcing garbage collection'. The most you can do with System.gc() is indicate to the VM that it should run the GC as soon as possible. Admitted, most implementations do run the algorithm virtually immediately upon execution of the statement, but the Java spec does not mandate such behavior. In theory, if the VM is too busy, it could still postpone the actual GC-run, until it acquires the necessary resources... Indeed, but the log4j log has timestamps and they show that 20 seconds are spent around System.gc() so my guess is that something really happens at that time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On May 8, 2008, at 09:06, Jeremias Maerki wrote: It looks like /usr/local/share/fonts is another place where fonts can be on Unixes but that's not used by FOP, yet. Can a Unix Guru confirm that it would be correct to add this directory to the other ones in UnitFontDirFinder? FWIW, no Guru over here, but anyway: I think this can be safely added. If the directory does not exist, I assume IOCommons' DirectoryHandler simply adds nothing to the result list (see FontInfoFinder.find())? Only if the DirectoryWalker would not handle non-existing directories, we'd have to take care of that on our side as well, but checking the Javadocs, DirectoryWalker.walk () only throws an IOException if you pass null as the starting-point. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
Jeremias Maerki jeremias-maerki.ch> writes: > > I have an Ubuntu 8.04 in a VM to play with. So I copied over the Bodoni > fonts from that ZIP file you indicated. However, the ZIP does not > contain any AFM files for the Bodoni font, just the PFB and PFM. You are right. The timestamp was different for the AFM files (2007 as opposed to 1990), so I looked inside one and saw: Comment AFM Generated by Ghostscript/pf2afm > Looking > at these fonts, BTW, gives me a strong impression that these are illegal > and altered copies (Some of the fonts give a BBS phone number). Anyway, > I had no problems Oh well... > auto-detecting and using the fonts with FOP 0.95beta. fop-trunk also works. > If you've installed the fonts in a location other than the directory > mentioned in the following Java class: > http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java > you'll have to use the "directory" element in the font configuration. > It worked. All fonts that I have tried so far (TT and Type1) can now be used. By the way, the FOP-trunk online documentation says: "Font registration via XML font metrics file is still supported and is still necessary if you want to use a TrueType Collection (*.ttc). Direct support for TrueType collections may be added later." This should be updated, as I can use such fonts. Cambria is an MS font that comes with Office 2007, but, for whatever reason, it is included in the latest PowerPoint viewer, the installer of which runs on Linux. Cambria.ttf contains "Cambria" and "Cambria Math" (which I know only because FOP told me) and I can select either one. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple outputs
On May 8, 2008, at 10:22, paul womack wrote: Hi I see Jeremias has already given info about the AT, so I'll restrict myself to some other pointers that may be of use. If I want a TIFF and a PDF from the same input (xml + xsl), what's my best course? One very convenient way to generate multiple outputs is to use FOP's Ant task. That would not require much intervention or Java knowledge. Clearly, running fop from the command line twice would work, but can I get a performance "win" by converting to an intermediate fo file, then doing a render run? We can't really say, without knowing more about the XSL transform. It depends on whether performing the same transform two times in a row weighs up to writing the fo to disk and reading it back again. Note that you can optimize multiple identical transforms by using a cached javax.xml.transform.Templates based on the same stylesheet. That at least saves you from having to parse the stylesheet twice (or more?) Or can I reduce the fop startup overhead by running two commands (how?) in the same instance? Have a look at the embedding examples: http://xmlgraphics.apache.org/fop/0.95/embedding.html#examples If you would use FOP multiple times in a row, without restarting the JVM, then over a few runs that will save you minutes... The very first run is always a lot slower due to static initialization, class loading etc. Once the VM is warmed up, the average runtime for a formatting run will drastically reduce. To see what I mean, you could already make the comparison: try 50 isolated runs from the command-line, and afterwards, perform the same 50 runs, but then looped in a single small class. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple outputs
That has come up a number of times. To a certain degree, this is possible, but PDF and TIFF(Java2D) use different font sources with different font metrics which can lead to small differences between the two output formats. See: http://fop-users.markmail.org/message/n3myr6scq6afh7uz?q=tiff+pdf+output&page=2 The above example does the whole thing from the command-line but of course, it's possible to do this in one JVM instance. See here for more information about the intermediate format (AT): http://xmlgraphics.apache.org/fop/0.94/intermediate.html From this information you should be able to derive how you can render the same intermediate file twice to two different renderers. On 08.05.2008 10:22:31 paul womack wrote: > If I want a TIFF and a PDF from the same input (xml + xsl), what's > my best course? > > Clearly, running fop from the command line twice would work, > but can I get a performance "win" by converting to an intermediate fo > file, then doing a render run? > > Or even making (and then using) a AT file? > > Or can I reduce the fop startup overhead by running two > commands (how?) in the same instance? > > BugBear Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiple outputs
If I want a TIFF and a PDF from the same input (xml + xsl), what's my best course? Clearly, running fop from the command line twice would work, but can I get a performance "win" by converting to an intermediate fo file, then doing a render run? Or even making (and then using) a AT file? Or can I reduce the fop startup overhead by running two commands (how?) in the same instance? BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolve image url
If you're talking about SVG you have to look into Batik. AFAIK, it doesn't support URI resolution with a catalog. FOP just passes Batik a base URI which Batik can use for relative URIs but advanced URI resolution may not be possible. Better ask on [EMAIL PROTECTED] On 08.05.2008 09:48:18 mjatromp wrote: > > Hi, > > I am trying to resolve url's that point to local image files (svg). As the > location varies per document, I am trying to use catalogs, but can't get it > to work. > > What is the recommended way to do this? > > Thanks, > > Marcel > -- > -- > View this message in context: > http://www.nabble.com/Resolve-image-url-tp17122107p17122107.html > Sent from the FOP - Users mailing list archive at Nabble.com. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Resolve image url
Hi, I am trying to resolve url's that point to local image files (svg). As the location varies per document, I am trying to use catalogs, but can't get it to work. What is the recommended way to do this? Thanks, Marcel -- -- View this message in context: http://www.nabble.com/Resolve-image-url-tp17122107p17122107.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)
On May 8, 2008, at 08:40, Jean-François El Fouly wrote: Hi Jeremias Maerki a écrit : And my next problem is to find a way to force memory recycling after this long and hefty FOP processing, but until further investigated this is OT ;-) You probably didn't get my hint earlier but with the new image loading framework you should actually get away with lower memory settings. In my tests I have been able to produce PDF with little text and many images with 40MB of VM memory which wasn't possible with 0.94 and earlier. Well, I got the hint, but it seems in contradiction with what I read. There are, of course, other factors to take into account than simply document/image sizes. Which Java VM are you using? Practically every time someone tells us about memory/GC issues, it appears they are using an implementation other than Sun (IBM, GNU...) Up to now, we still have to find out why precisely non-Sun VMs have difficulties with FOP... What options does the Java VM offer to tweak the GC? What options does it use by default? So to take the picture from a bit higher: - all XSL-FO transformation + FOP generation now work OK. - this generates 20-30 documents (chapters) for a grand total of about 150 Mb, to be bound together by iText. - source XML is 1.5 Mb - 1011 PNG images for a total of 151 Mb, the largest image is 715 kb. Now the figures: - XML -> XSL-FO transformation + FOP generation take 15 minutes on a pretty decent DELL Server (running Debian 4.0) having all the physical RAM possible (staging server for several customers) How large would the resulting FO-files be if you dump them to the filesystem? The XML by itself says very little. From a 1.5MB XML, you could get a FO of a few KB or one of 26MB, depending on the stylesheet. Does the stylesheet adhere to XSLT best practices? Does it generate a lot of redundant fo:blocks, fo:inlines? - JVM has 2000 Mb (which is BTW the grand max on this processor/ server/OS/JVM architecture) On my end, that has proven to be more than enough to generate one page-sequence with a table of 15 columns, spanning 500+ pages. (Note: only text-content, no images; more a test to check the memory usage without doing anything special, just a whole lot of FOs) If I try to investigate memory usage using Runtime.getRuntime ().getFreeMemory() and logging the figures with log4j, these are the figures I get: - before XSLT + FOP: 1900 Mb free/2000 Mb - end of XSLT + FOP: 241 Mb free Yikes! That looks troublesome indeed... :/ - set FopFactory instance to null as a desperate hint to the GC that FOP objects could be/should be recycled - I force garbage collection using System.gc()[OK, in an application server this is a brute force approach, but could not see a more clever maneuver ATM] A nit, for the record: There is no such thing as 'forcing garbage collection'. The most you can do with System.gc() is indicate to the VM that it should run the GC as soon as possible. Admitted, most implementations do run the algorithm virtually immediately upon execution of the statement, but the Java spec does not mandate such behavior. In theory, if the VM is too busy, it could still postpone the actual GC-run, until it acquires the necessary resources... Now I don't take runtime.getXXXMemory() for bible word but at least it "looks like" the Xalan + FOP subsystem hogs 1500 Mb of RAM which I cannot recover. So I hired the team member who's competent in profiler usage next week but I must say at the moment I'm still stuck :-( If you're not on a Sun VM, then I have a very vague feeling that he's going to discover the issue to be related to arrays, a special type of object, but I could be wrong about this. Someone once reported that the VM seemed to hold on to a lot of arrays. When profiling, he discovered that the arrays were referenced nowhere, but still the GC did not clean them up. Of course I've made my homework and read the f...riendly manual before daring to ask. Did I miss any important indication ? I don't think so, but it seems we might do well by putting some of the info concerning JVM/GC implementation we have gathered so far, on the website or a Wiki. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)
I've done extensive tests about memory allocation with FOP when implementing the new image loading framework and in my case the memory was always released. So, some results from a profiler would be helpful. Anyway, what I meant with my hint was that the iText step might not be necessary anymore and that you should be able to safely reduce -Xmx on the JVM (provided your document doesn't contain to much non-image content). But if you release FopFactory and the memory is still not reclaimed something's wrong somewhere and I have a somewhat hard time believing that FOP itself somehow still holds on to it. Please make sure you don't hold on to the FOUserAgent and other FOP-related objects because they might have a reference to the FopFactory. On 08.05.2008 08:40:55 Jean-François El Fouly wrote: > Jeremias Maerki a écrit : > >> And my next problem is to find a way to force memory recycling after > >> this long and hefty FOP processing, but until further investigated this > >> is OT ;-) > >> > > > > You probably didn't get my hint earlier but with the new image loading > > framework you should actually get away with lower memory settings. In my > > tests I have been able to produce PDF with little text and many images > > with 40MB of VM memory which wasn't possible with 0.94 and earlier. > > > > Well, I got the hint, but it seems in contradiction with what I read. > So to take the picture from a bit higher: > - all XSL-FO transformation + FOP generation now work OK. > - this generates 20-30 documents (chapters) for a grand total of about > 150 Mb, to be bound together by iText. > - source XML is 1.5 Mb > - 1011 PNG images for a total of 151 Mb, the largest image is 715 kb. > > Now the figures: > - XML -> XSL-FO transformation + FOP generation take 15 minutes on a > pretty decent DELL Server (running Debian 4.0) having all the physical > RAM possible (staging server for several customers) > - JVM has 2000 Mb (which is BTW the grand max on this > processor/server/OS/JVM architecture) > - only one instance of FOP launched (one document generation) > - the second next step in the publication process (opening the 150 Mb > with iText to add the bookmarks) fails immediately (at file open) saying > it cannot allocate memory > > If I try to investigate memory usage using > Runtime.getRuntime().getFreeMemory() and logging the figures with log4j, > these are the figures I get: > - before XSLT + FOP: 1900 Mb free/2000 Mb > - end of XSLT + FOP: 241 Mb free > - set FopFactory instance to null as a desperate hint to the GC that FOP > objects could be/should be recycled > - I force garbage collection using System.gc()[OK, in an application > server this is a brute force approach, but could not see a more clever > maneuver ATM] > - 350 Mb free/2000 Mb total > - Bind all chapters with iText > - 250 Mb free > - Force another GC > - 350 Mb free again (so the binding operation has no effect on the > available memory). > - the next iText step still fails. > > Now I don't take runtime.getXXXMemory() for bible word but at least it > "looks like" the Xalan + FOP subsystem hogs 1500 Mb of RAM which I > cannot recover. > So I hired the team member who's competent in profiler usage next week > but I must say at the moment I'm still stuck :-( > > Of course I've made my homework and read the f...riendly manual before > daring to ask. > Did I miss any important indication ? > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
I have an Ubuntu 8.04 in a VM to play with. So I copied over the Bodoni fonts from that ZIP file you indicated. However, the ZIP does not contain any AFM files for the Bodoni font, just the PFB and PFM. Looking at these fonts, BTW, gives me a strong impression that these are illegal and altered copies (Some of the fonts give a BBS phone number). Anyway, I had no problems auto-detecting and using the fonts with FOP 0.95beta. If you've installed the fonts in a location other than the directory mentioned in the following Java class: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java you'll have to use the "directory" element in the font configuration. It looks like /usr/local/share/fonts is another place where fonts can be on Unixes but that's not used by FOP, yet. Can a Unix Guru confirm that it would be correct to add this directory to the other ones in UnitFontDirFinder? On 07.05.2008 22:16:06 John Brown wrote: > Andreas Delmelle telenet.be> writes: > > > > > > > On May 7, 2008, at 10:30, Andreas Delmelle wrote: > > > > > > > > > Can you try to checkout and build FOP 0.95 (*), and see if that > > > helps already? > > > > > If you still need it, the URL to use with SVN for 0.95 head: > > http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_95 > > > > Cheers > > > > Andreas > > > > > I am on Linux (Kubuntu Gutsy Gibbon (7.10?)). Auto-detection of > fonts does not work most of the time. For example, I cannot use > Bodoni (Type 1 font - the download page says that it is shareware, > but neither the site nor the ZIP file says who should be paid). > I downloaded the font at > http://www.winsite.com/bin/Info?50017011. > > Scribus lets me embed this font in a PDF, and Scribus itself > says that it is strict about the fonts that it allows to be > embedded, so I assume that nothing is wrong with the font. > > 'fc-list Bodoni' gives: > Bodoni:style=Bold > Bodoni:style=Normal-Italic > Bodoni:style=Normal > > 'ls /usr/local/share/fonts/bodoni*' gives: > /usr/local/share/fonts/bodoni.afm /usr/local/share/fonts/bodonii.pfb > /usr/local/share/fonts/bodonib.afm /usr/local/share/fonts/bodonii.pfm > /usr/local/share/fonts/bodonib.pfb /usr/local/share/fonts/bodoni.pfb > /usr/local/share/fonts/bodonib.pfm /usr/local/share/fonts/bodoni.pfm > /usr/local/share/fonts/bodonii.afm > > AFM, PFM and PFB files are all present. > > However fop-trunk svn (653186, 2008-05-03) and fop-0.95beta svn > (653537, 2008-05-05) both say: > WARNING: Font 'Bodoni,normal,400' not found. Substituting > with 'any,normal,400'. > > I used the same FO and fop.xconf that was posted. > > I noticed that fop printed a lot of warnings like: > > May 7, 2008 2:05:22 PM org.apache.fop.fonts.truetype.TTFFile determineAscDesc > WARNING: Ascender and descender together are larger than the em box. This > could lead to a wrong baseline placement in Apache FOP. > > and > > May 7, 2008 2:05:35 PM org.apache.fop.fonts.truetype.TTFFile > guessVerticalMetricsFromGlyphBBox > WARNING: xHeight value could not be determined. The font may not work as > expected. > May 7, 2008 2:05:35 PM org.apache.fop.fonts.type1.PFMFile loadExtMetrics > WARNING: Size of extension block was expected to be 52 bytes, but was 0 bytes. > > The messages do not say which fonts cause the warnings. I do > not know if it matters. > > By the way, I have found a few Type 1 fonts that fop > recognises, but no TrueType fonts so far. > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]