Re: Noisy output when formatting DocBook despite -q
Hi Warren, Warren Young wrote: Vincent Hennebert wrote: - fo:table, table-layout=auto is currently not supported by FOP I've tried disabling this one by trying to set the default table width to 100% in my fo.xsl customization layer, but it doesn't help. I'm aware that I could probably turn on FOP extensions to suppress it, but I'd rather use a standard method. You mean the ‘fop1.extensions’ stylesheet parameter? Yes. It seems to have no effect. I've tried setting it two ways. First, in the command that does .dbx to .fo processing: xsltproc --stringparam fop1.extensions 1 and in my fo.xsl file, which is a customization layer for the above process, so this should be equivalent: xsl:param name=fop1.extensions select=1/ Well it does have an effect if I add it to the fo.xsl customization file, and by using at least the 1.72.0 stylesheets. It might well be that this will work only with recent releases of the stylesheets. To avoid the other warning (‘... falling back to proportional- column-width(1)’), I had to modify the DocBook source and put two colspec with a colwidth attribute, instead of only one colspec: colspec colsep=1 rowsep=1 colwidth=*/ colspec colsep=1 rowsep=1 colwidth=*/ - Line 1 of a paragraph overflows the available area. (fo:block, location: 2/33495) Not sure you want to ignore this one. This usually means that some content goes in the margin, possibly resulting in text being clipped. Given that I'm using DocBook and not generating FO myself, why would this happen? Simply because there is no possibility to break the text over several lines/pages. This is not dependent on the toolchain but rather on the input document. In your particular case this is caused by the program listings, which have too long lines. I managed to reduce the number of warnings to only 3 by adding font-size=80% to the ‘monospace.verbatim.properties’ attribute set, but this is perhaps not what you want. You may let FOP automatically wrap the text, by removing the wrap-option=no-wrap from the same attribute set —but honestly the result won’t look very good. Or you may implement the line-wrapping in your source code extraction tool. HTH, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fonts problem - not embed
Hi, if I try to use Verdana and not embed it, the resulting PDF cannot be shown correctly in the Adobe Reader. The Font is identified (in the Reader) as Verdana -Type: TrueType(CID) -Coding: Identity-H -Originial-Font: Unknown I created the fonts-metrics with the Fop-Util-Application and used the following lines in the fop-Configuration. font metrics-url=verdana.xml kerning=true font-triplet name=Verdana style=normal weight=normal/ /font I think, the Adobe Reader cannot identify the Font as the Verdana font installed on the system (Windows XP). Any suggestions on how I can make the PDF reference the correct Verdana? Thanx Andreas -- Dipl.-Inf. Andreas Siepert Entwickler Bader Jene Software-Ingenieurbüro GmbH Schauenburgerstraße 116 24118 Kiel Fon: + 49.431.5 60 66 41 Fax: + 49.431.5 60 66 44 Web: www.bader-jene.de Ust-ID Nr: DE249078452 Amtsgericht Kiel, HRB 8298 Geschäftsführer: Dipl.-Ing. (FH) Thomas Bader Dipl.-Ing. (FH) Andreas Jene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fonts problem - not embed
Currently, you can only reference a TrueType font if you generate the font metrics in WinAnsi mode (-enc ansi). Obviously, that will restrict you to a subset of the available glyphs. It's a limitation of FOP. This is documented here: http://xmlgraphics.apache.org/fop/0.94/fonts.html#embedding (see red box) On 08.01.2008 16:50:23 Andreas Siepert wrote: Hi, if I try to use Verdana and not embed it, the resulting PDF cannot be shown correctly in the Adobe Reader. The Font is identified (in the Reader) as Verdana -Type: TrueType(CID) -Coding: Identity-H -Originial-Font: Unknown I created the fonts-metrics with the Fop-Util-Application and used the following lines in the fop-Configuration. font metrics-url=verdana.xml kerning=true font-triplet name=Verdana style=normal weight=normal/ /font I think, the Adobe Reader cannot identify the Font as the Verdana font installed on the system (Windows XP). Any suggestions on how I can make the PDF reference the correct Verdana? Thanx Andreas -- Dipl.-Inf. Andreas Siepert Entwickler Bader Jene Software-Ingenieurbüro GmbH Schauenburgerstraße 116 24118 Kiel Fon: + 49.431.5 60 66 41 Fax: + 49.431.5 60 66 44 Web: www.bader-jene.de Ust-ID Nr: DE249078452 Amtsgericht Kiel, HRB 8298 Geschäftsführer: Dipl.-Ing. (FH) Thomas Bader Dipl.-Ing. (FH) Andreas Jene Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error during make Open Type Font metric
Jeremias Maerki-2 wrote: As the exception suggests, the font probably contains CFF glyphs which are not supported by FOP, yet. You'll have to get a different font. On 14.12.2007 13:11:11 Miroslav Pukhalsky wrote: Hi, I try to make font metric for Open Type font Helvetica LT Standard Black When I type the next command: The other thing is - you should be able to get a copy of the .TTF version of the font, in fact we happen to be using almost the same one (HelveticaNeueLTStd) - and thus same issue as Miroslav, but this solve our issue. -- View this message in context: http://www.nabble.com/Error-during-make-Open-Type-Font-metric-tp14334751p14694897.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: Error during make Open Type Font metric
Hello mokeeffe, mokeeffe wrote: The other thing is - you should be able to get a copy of the .TTF version of the font, in fact we happen to be using almost the same one (HelveticaNeueLTStd) - and thus same issue as Miroslav, but this solve our issue. I was found someone who convert OTF fonts to TTF fonts for me (on Windows XP was used TransType utility from FontLab) and it was resolved my problem. After it I made font metrics (as described here http://xmlgraphics.apache.org/fop/0.93/fonts.html#truetype-metrics) and embed fonts into PDF. Regards, Miroslav. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Noisy output when formatting DocBook despite -q
Vincent Hennebert wrote: It seems to have no effect. I've tried setting it two ways. First, in the command that does .dbx to .fo processing: xsltproc --stringparam fop1.extensions 1 Well it does have an effect if I add it to the fo.xsl customization file, and by using at least the 1.72.0 stylesheets. It might well be that this will work only with recent releases of the stylesheets. Okay. I'm trying to avoid upgrading the stylesheets for testing reasons, because other things on this system generate DocBook, so if we're not using what we ship to customers... It's the old dogfood problem. To avoid the other warning (‘... falling back to proportional- column-width(1)’), I had to modify the DocBook source and put two colspec with a colwidth attribute, instead of only one colspec: colspec colsep=1 rowsep=1 colwidth=*/ colspec colsep=1 rowsep=1 colwidth=*/ This one I don't see, but it's probably a 1.72 thing. I'll keep this in mind for when I do decide to upgrade. In your particular case this is caused by the program listings, which have too long lines. I managed to reduce the number of warnings to only 3 by adding font-size=80% to the ‘monospace.verbatim.properties’ attribute set, but this is perhaps not what you want. No, in fact, that's perfect. I've actually removed all of these warnings with font-size=85% here. Or you may implement the line-wrapping in your source code extraction tool. Our coding style has a line length limit, so if this warning crops back up again, it's a good thing, because it means someone's not following the rules. Thanks for the help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Postscript printing on Mac OS X
Hi, on Mac OS X 10.5 the printing queue complains about No %%BoundingBox: comment in header! when sending a FOP-generated PS-File. The file will eventually print anyways, but some printers (namely XEROX Phaser 8400) show a message about missing paper ... It will print after a while (maybe some fallback mechanism) but things seem to take very long. Any ideas on this? Can this %%BoundingBox some be created, maybe some param/setting I am missing? I am using a SVN-Trunk checkout from about 6 weeks ago. The PS-File is sent through standard java-printing api, selecting specific trays and media-sizes. Thank you in advance, Alex __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
