Object reuse, and speeds
Hi, I've seen in the documentation about reusing objects: Fop instances shouldn't (and can't) be reused. Please recreate Fop and FOUserAgent instances for each rendering run using the FopFactory. This is a cheap operation as all reusable information is held in the FopFactory. That's why it's so important to reuse the FopFactory instance. But it seems that creating a newFop is a more expensive operation than I was expecting: FOUserAgent foUserAgent = fopFactory.newFOUserAgent(); Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, out); The 'newFop' call takes 600-700ms on my (not underpowered) desktop. I first started timing this after I'd made fonts work, so I've noticed that if I remove the font config from my fop config file[1], or just empty my fonts directory, then newFop takes 100-150ms. I have only 8 font files in my fonts directory (arial and arial narrow, bold/italic/underline versions). The font cache is being created, so I presume it is also being used. Is there any way to improve this speed? A lot of the documentation on the web seems to relate to earlier versions and I've seen it mentioned that the way I'm doing it is correct for 1.0 (I intend to move to 1.1 once it's in the central maven repositories). A 500ms delay might not seem like a lot, but I'm trying to replace an existing application, so I have a metric the newapp will be judged by, and 500ms before we even begin the transform (currently ~1500ms on an incomplete document) seems to be starting on the back foot. Thanks, [1] renderers renderer mime=application/pdf fonts directory recursive=true/home/davet/fop/1/fonts/directory /fonts /renderer /renderers -- dave thorn DBT; GBP. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: post 1.1 config changes
Hi Jason, The backwards incompatibility of this API has been discussed quite a lot, and I'm sorry you're having these issues. If you're looking for examples for how to configure the new FopFactory, I'd say look in the source [1], there are plenty of examples on how to do it, there's also quite a bit of information on the wiki [2]. Sorry for the inconvenience, Mehdi [1] http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote: I maintain the docx4j project I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which was apparently fixed in July, but didn't make it into FOP 1.1 (just released). So, I thought I'd test a FOP nightly (20121107) to verify it has been fixed. But config seems to have changed extensively post 1.1 Post 1.1, I can see FopFactoryBuilder, mentioned at http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which contains public FopFactoryBuilder setConfiguration(Configuration cfg) { fopFactoryConfigBuilder.setConfiguration(cfg); return this; } but that class didn't make it into 1.1 (it has FopFactoryConfigurator) So, Is it feasible/sensible to try to be interchangeable between FOP 1.1 and whatever is to come? Has someone written code which facilitates this? Please excuse if there are posts on this topic already. thanks .. Jason
Re: post 1.1 config changes
Hi Mehdi Thanks for your reply. I'm happy I can write configuration code for current SVN head. But my question is whether anyone has produced/shared configuration code which works with both current SVN head, and FOP 1.1 ie using reflection as necessary. If not, we may just wait for the next release of FOP, and support only that. thanks .. Jason On Thu, Nov 8, 2012 at 8:44 PM, Mehdi Houshmand med1...@gmail.com wrote: Hi Jason, The backwards incompatibility of this API has been discussed quite a lot, and I'm sorry you're having these issues. If you're looking for examples for how to configure the new FopFactory, I'd say look in the source [1], there are plenty of examples on how to do it, there's also quite a bit of information on the wiki [2]. Sorry for the inconvenience, Mehdi [1] http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote: I maintain the docx4j project I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which was apparently fixed in July, but didn't make it into FOP 1.1 (just released). So, I thought I'd test a FOP nightly (20121107) to verify it has been fixed. But config seems to have changed extensively post 1.1 Post 1.1, I can see FopFactoryBuilder, mentioned at http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which contains public FopFactoryBuilder setConfiguration(Configuration cfg) { fopFactoryConfigBuilder.setConfiguration(cfg); return this; } but that class didn't make it into 1.1 (it has FopFactoryConfigurator) So, Is it feasible/sensible to try to be interchangeable between FOP 1.1 and whatever is to come? Has someone written code which facilitates this? Please excuse if there are posts on this topic already. thanks .. Jason
Re: post 1.1 config changes
Hi Jason, I don't think anyone has, or if they have, they haven't published it to the community. Hope that helps, Mehdi On 8 November 2012 09:53, Jason Harrop jhar...@gmail.com wrote: Hi Mehdi Thanks for your reply. I'm happy I can write configuration code for current SVN head. But my question is whether anyone has produced/shared configuration code which works with both current SVN head, and FOP 1.1 ie using reflection as necessary. If not, we may just wait for the next release of FOP, and support only that. thanks .. Jason On Thu, Nov 8, 2012 at 8:44 PM, Mehdi Houshmand med1...@gmail.com wrote: Hi Jason, The backwards incompatibility of this API has been discussed quite a lot, and I'm sorry you're having these issues. If you're looking for examples for how to configure the new FopFactory, I'd say look in the source [1], there are plenty of examples on how to do it, there's also quite a bit of information on the wiki [2]. Sorry for the inconvenience, Mehdi [1] http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote: I maintain the docx4j project I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which was apparently fixed in July, but didn't make it into FOP 1.1 (just released). So, I thought I'd test a FOP nightly (20121107) to verify it has been fixed. But config seems to have changed extensively post 1.1 Post 1.1, I can see FopFactoryBuilder, mentioned at http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which contains public FopFactoryBuilder setConfiguration(Configuration cfg) { fopFactoryConfigBuilder.setConfiguration(cfg); return this; } but that class didn't make it into 1.1 (it has FopFactoryConfigurator) So, Is it feasible/sensible to try to be interchangeable between FOP 1.1 and whatever is to come? Has someone written code which facilitates this? Please excuse if there are posts on this topic already. thanks .. Jason
Re: Object reuse, and speeds
On Thu, Nov 08, 2012 at 09:37:57AM +, Mehdi Houshmand wrote: [snip] try trunk and let me know if that helps; what you should find is that the first creation of the Fop object is as costly as it was before, but subsequent instantiations of the object shouldn't have as much of a performance impact. Let me know if that does what you're looking for, Actually, that helps without me having to checkout the trunk. If I actually simulate more closely proper application behaviour (i.e. create one fopFactory and create-and-use multiple Fop objects) then for the subsequent Fop object creations the time drops to ~40-60ms. I should really have tried that first. But thank you. I will try to put off using 1.1 until it's in the central maven repository. -- dave thorn Hi, I'm from the Internet. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Need help to get Arabic working with FOP
Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop When I run FOP I use this command: $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf I get this message: SNIP Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. Glyph ? (0x627, afii57415) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Helvetica-Bold. Glyph ? (0x625, afii57413) not available in font Helvetica-Bold. Glyph ? (0x633, afii57427) not available in font Helvetica-Bold. Glyph ? (0x645, afii57445) not available in font Helvetica-Bold. Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold. Glyph ? (0x629, afii57417) not available in font Helvetica-Bold. Glyph ? (0x646, afii57446) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Times-Roman. Glyph ? (0x627, afii57415) not available in font Times-Roman. Glyph ? (0x625, afii57413) not available in font Times-Roman. Glyph ? (0x647, afii57470) not available in font Times-Roman. Glyph ? (0x62a, afii57418) not available in font Times-Roman. Glyph ? (0x642, afii57442) not available in font Times-Roman. Glyph ? (0x648, afii57448) not available in font Times-Roman. Glyph ? (0x649, afii57449) not available in font Times-Roman. Glyph ? (0x62e, afii57422) not available in font Times-Bold. Glyph ? (0x627, afii57415) not available in font Times-Bold. Glyph ? (0x641, afii57441) not available in font Times-Bold. Glyph ? (0x625, afii57413) not available in font Times-Bold. Glyph ? (0x650, afii57456) not available in font Times-Bold. Glyph ? (0x646, afii57446) not available in font Times-Bold. Glyph ? (0x651, afii57457) not available in font Times-Bold. Glyph ? (0x64e, afii57454) not available in font Times-Bold. Line 1 of a paragraph overflows the available area by 33725
Re: Need help to get Arabic working with FOP
Hi Bernardo, By the looks of the exception you've got an error in the FO you're creating, which probably has nothing to do with Arabic support. If you're wondering which fonts to use, I'd suggest you read the Apache FOP website, it should give you all the information you need [1]. As for your erroneous FO, I'd suggest the following; use an XSLT transformer to create the FO, then use that as the input to FOP and you should get some information from the error as to which FO construct is erroring. If you're still having issues, post the FO to this forum (though under a new thread, it's won't be relevant to the original thread). Hope that helps Mehdi [1] http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic On 8 November 2012 11:39, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote: Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop When I run FOP I use this command: $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf I get this message: SNIP Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. Glyph ? (0x627, afii57415) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Helvetica-Bold. Glyph ? (0x625, afii57413) not available in font Helvetica-Bold. Glyph ? (0x633, afii57427) not available in font Helvetica-Bold. Glyph ? (0x645, afii57445) not available in font Helvetica-Bold. Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold. Glyph ? (0x629, afii57417) not available in font Helvetica-Bold. Glyph ? (0x646, afii57446) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Times-Roman. Glyph ? (0x627, afii57415) not available in font Times-Roman. Glyph ? (0x625, afii57413) not available in font Times-Roman. Glyph ? (0x647,
Re: Need help to get Arabic working with FOP
an example is attached. in fact it was provided in this list by someone else by I am including also a fop.xconf file. On Thu, Nov 8, 2012 at 11:39 AM, Bernardo Gonzalez Kriegel bgkrie...@gmail.com wrote: Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.com wrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop When I run FOP I use this command: $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf I get this message: SNIP Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. Glyph ? (0x627, afii57415) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Helvetica-Bold. Glyph ? (0x625, afii57413) not available in font Helvetica-Bold. Glyph ? (0x633, afii57427) not available in font Helvetica-Bold. Glyph ? (0x645, afii57445) not available in font Helvetica-Bold. Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold. Glyph ? (0x629, afii57417) not available in font Helvetica-Bold. Glyph ? (0x646, afii57446) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Times-Roman. Glyph ? (0x627, afii57415) not available in font Times-Roman. Glyph ? (0x625, afii57413) not available in font Times-Roman. Glyph ? (0x647, afii57470) not available in font Times-Roman. Glyph ? (0x62a, afii57418) not available in font Times-Roman. Glyph ? (0x642, afii57442) not available in font Times-Roman. Glyph ? (0x648, afii57448) not available in font Times-Roman. Glyph ? (0x649, afii57449) not available in font Times-Roman. Glyph ? (0x62e, afii57422) not available in font Times-Bold. Glyph ? (0x627, afii57415) not available in font Times-Bold. Glyph ? (0x641, afii57441) not available in font Times-Bold. Glyph ? (0x625, afii57413) not available in font Times-Bold. Glyph ? (0x650, afii57456) not available in font Times-Bold. Glyph ?
Re: Need help to get Arabic working with FOP
Luis, I could re-generate the example, so I think my problem is in the fo generation side. Many thanks, Bernardo -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 9:26 AM, Luis Bernardo lmpmberna...@gmail.comwrote: an example is attached. in fact it was provided in this list by someone else by I am including also a fop.xconf file. On Thu, Nov 8, 2012 at 11:39 AM, Bernardo Gonzalez Kriegel bgkrie...@gmail.com wrote: Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.com wrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop When I run FOP I use this command: $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf I get this message: SNIP Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. Glyph ? (0x627, afii57415) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Helvetica-Bold. Glyph ? (0x625, afii57413) not available in font Helvetica-Bold. Glyph ? (0x633, afii57427) not available in font Helvetica-Bold. Glyph ? (0x645, afii57445) not available in font Helvetica-Bold. Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold. Glyph ? (0x629, afii57417) not available in font Helvetica-Bold. Glyph ? (0x646, afii57446) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Times-Roman. Glyph ? (0x627, afii57415) not available in font Times-Roman. Glyph ? (0x625, afii57413) not available in font Times-Roman. Glyph ? (0x647, afii57470) not available in font Times-Roman. Glyph ? (0x62a, afii57418) not available in font Times-Roman. Glyph ? (0x642, afii57442) not available in font Times-Roman. Glyph ? (0x648, afii57448) not available in font Times-Roman.
Re: Need help to get Arabic working with FOP
Hi Mehdi, You are right, I used the example and configuration sent by Luis Bernardo, and fop works well. As for the fonts, his (Luis) example used Arial, I also tested ArialUnicodeMS and works. Traditional arabic (BTW, the links on the page are wrong) produces this error: org.apache.fop.apps.FOPException: The font trado.ttf is not embeddable due to a licensing restriction. Thank you, Bernardo -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 9:12 AM, Mehdi Houshmand med1...@gmail.com wrote: Hi Bernardo, By the looks of the exception you've got an error in the FO you're creating, which probably has nothing to do with Arabic support. If you're wondering which fonts to use, I'd suggest you read the Apache FOP website, it should give you all the information you need [1]. As for your erroneous FO, I'd suggest the following; use an XSLT transformer to create the FO, then use that as the input to FOP and you should get some information from the error as to which FO construct is erroring. If you're still having issues, post the FO to this forum (though under a new thread, it's won't be relevant to the original thread). Hope that helps Mehdi [1] http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic On 8 November 2012 11:39, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote: Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop When I run FOP I use this command: $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf I get this message: SNIP Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. Glyph ? (0x627, afii57415) not available in font Helvetica-Bold. Glyph ? (0x644, afii57444) not available in font Helvetica-Bold. Glyph ? (0x625, afii57413) not available in font
Re: Need help to get Arabic working with FOP
Ahh yeah, that doesn't mean it doesn't work though. You can reference fonts [1], but you'll need them installed if you want to view them. Alternatively you could either 1) buy the license or 2) uhm *cough* change the bit flag which tells Fop the font is not embeddable [2] *cough*... Woahh that was an informative cough! Obviously any changes you make to the font are ill advised in a commercial setting, but may help you test the font before purchasing it. Mehdi [1] http://xmlgraphics.apache.org/fop/1.1/fonts.html *cough* [2] http://www.microsoft.com/typography/otspec/os2.htm#fst *cough* On 8 November 2012 13:30, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote: Hi Mehdi, You are right, I used the example and configuration sent by Luis Bernardo, and fop works well. As for the fonts, his (Luis) example used Arial, I also tested ArialUnicodeMS and works. Traditional arabic (BTW, the links on the page are wrong) produces this error: org.apache.fop.apps.FOPException: The font trado.ttf is not embeddable due to a licensing restriction. Thank you, Bernardo -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 9:12 AM, Mehdi Houshmand med1...@gmail.com wrote: Hi Bernardo, By the looks of the exception you've got an error in the FO you're creating, which probably has nothing to do with Arabic support. If you're wondering which fonts to use, I'd suggest you read the Apache FOP website, it should give you all the information you need [1]. As for your erroneous FO, I'd suggest the following; use an XSLT transformer to create the FO, then use that as the input to FOP and you should get some information from the error as to which FO construct is erroring. If you're still having issues, post the FO to this forum (though under a new thread, it's won't be relevant to the original thread). Hope that helps Mehdi [1] http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic On 8 November 2012 11:39, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote: Hello, I think that it's not so simple, but as Eduard pointed out you need: a) a correct font b) fop-1.1 c) fo generation d) fop configuration I am also frustrated, I have not been able to generate a PDF in Arabic. So, these are my questions/experiences: a) I'm using Arial Unicode MS [1]. It's a good choice? b) I downloaded the last version from [2] c) I tried xsltproc, that converts any gliph into character codes (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)), or saxon that leaves the gliphs intact (3.8 (بالعربية)) d) I've edited fop.xconf to register the font In any case, not only fop refuses to generate a pdf, complaining about missing glyphs and hyphenation, but aborts with many org.apache.fop.fo.ValidationException. So, anyone know's or can point to a document to learn about these questions a) What font is recommended, or have been used with success? b) What is the best way to generate the FO? c) What configuration do you use to register the font? d) There are any examples? Best regards, Bernardo [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24 [2] http://xmlgraphics.apache.org/fop/1.1/ -- Bernardo Gonzalez Kriegel bgkrie...@gmail.com On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote: Brian, It's simple. I'll try to explain. 1. Check if fonts, available on your system, support Arabic glyphs. 2. Write down (i.e. in any text editor) the names of these fonts. 3. Open your fo file and check the names of the fonts you are using. Please, note, that the font families in your fo file should have the same names as your font files in your system. 4. Try to use the exact fonts with Arabic glyphs instead of autodetect. Try to use the following: http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step 2 in your mind). Finally, you need to get: 1. The names of the fonts file in your system, that contains Arabic glyphs. 2. The fo file with font families that exists in your system and contains Arabic glyphs. 3. The configuration file that makes a dependency between the font files in your system and font names fo file. -- Best regards, Eduard Tibet -Original Message- From: Brian Hansen [mailto:greencopperm...@gmail.com] Sent: Thursday, November 08, 2012 11:06 AM To: fop-users@xmlgraphics.apache.org Subject: Need help to get Arabic working with FOP Hi I'm pulling my hair out in frustration! I have been trying for so long to get Arabic fonts to display correct when using Docbook (converting XML to FO using Xsltproc and then to PDF using FOP). I'm sorry, but I just don't understand the documentation for FOP. It's not clear enough for me. I'm running FOP 1.0 on Linux. I need to know exacty, step by step, what I need to do to get Arabic text rendered properly. Instead # is shown. I have created this file foprc.xconf: fop
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included).
RE: Fop download binary not working
I just found that one can download FOP from the Archive Download link referenced at the bottom of the below URL. That appears to be the only working URL for downloads unrelated to svn. http://xmlgraphics.apache.org/fop/download.html Thanks, Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 [University of Illinois at Urbana-Champaign logo]http://illinois.edu/ From: Campbell, Lance [mailto:la...@illinois.edu] Sent: Thursday, November 08, 2012 2:41 PM To: fop-users@xmlgraphics.apache.org Subject: Fop download binary not working I am trying to download fop binary from the below URL but none of the URLs listed seem to work: http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop Any suggestions? Thanks, Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 [University of Illinois at Urbana-Champaign logo]http://illinois.edu/ inline: image003.pnginline: image004.png
How to configure FOP with Tomcat 7
How do you configure FOP with Tomcat 7? I found the below instruction. But unfortunately I was unable to locate any instructions in Tomcat 7 that referenced FOP. Any pointers would be great. I found this referenced at: http://xmlgraphics.apache.org/fop/1.1/servlets.html#tomcat Tomcat Check Tomcat's documentation for detailed instructions about installing FOP and Cocoon. There are known bugs that must be addressed, particularly for Tomcat 4.0.3. If I am emailing the wrong list for these questions please let me know. Thanks, Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 [University of Illinois at Urbana-Champaign logo]http://illinois.edu/ inline: image002.png
Re: Fop download binary not working
Apache @infra has been notified of this problem. On Thu, Nov 8, 2012 at 12:57 PM, Campbell, Lance la...@illinois.edu wrote: I just found that one can download FOP from the Archive Download link referenced at the bottom of the below URL. That appears to be the only working URL for downloads unrelated to svn. ** ** http://xmlgraphics.apache.org/fop/download.html ** ** ** ** Thanks, ** ** Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 [image: University of Illinois at Urbana-Champaign logo]http://illinois.edu/ ** ** ** ** *From:* Campbell, Lance [mailto:la...@illinois.edu] *Sent:* Thursday, November 08, 2012 2:41 PM *To:* fop-users@xmlgraphics.apache.org *Subject:* Fop download binary not working ** ** I am trying to download fop binary from the below URL but none of the URLs listed seem to work: ** ** http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop ** ** Any suggestions? ** ** Thanks, ** ** Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 [image: University of Illinois at Urbana-Champaign logo]http://illinois.edu/ ** ** ** ** image003.pngimage004.png
INFRA-5498: xmlgraphics distribution artifacts have disappeared from dist servers
https://issues.apache.org/jira/browse/INFRA-5498 On Tue, Nov 6, 2012 at 8:22 AM, pct...@apache.org wrote: Author: pctony Date: Tue Nov 6 16:22:32 2012 New Revision: 957 Log: Adding XML Added: release/xmlgraphics/
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included).
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
When I reviewed sidebar.fo, I completely neglected the colours and borders added for debug purposes (oh so long ago). Let me get you a clean version. The spurious lines appear in the column which is not spanned by the inner cell in the first row. On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included).
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
Please find attached a new fo which defines the sidebar for the left pages only. The blue column will show the four lines separating each row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4)) On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included). ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xalan=http://xml.apache.org/xslt; xmlns:ec=xalan://com.amirsys.utilities.ElementConversion fo:layout-master-set fo:page-sequence-master master-name=sidebars fo:repeatable-page-master-alternatives fo:conditional-page-master-reference page-position=any odd-or-even=odd master-reference=sidebar-odd blank-or-not-blank=any / fo:conditional-page-master-reference page-position=any odd-or-even=even master-reference=sidebar-even blank-or-not-blank=any / /fo:repeatable-page-master-alternatives /fo:page-sequence-master fo:simple-page-master page-width=8.5in page-height=11in master-name=sidebar-even fo:region-body margin-left=0.75in / fo:region-start region-name=side-bar-left extent=0.75in / /fo:simple-page-master fo:simple-page-master page-width=8.5in page-height=11in master-name=sidebar-odd fo:region-body margin-right=0.75in / fo:region-end region-name=side-bar-right extent=0.75in / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=sidebars initial-page-number=30 fo:static-content flow-name=side-bar-left fo:table width=0.75in table-layout=fixed border-collapse=collapse fo:table-column column-width=0.5625in / fo:table-column column-width=0.1875in / fo:table-body fo:table-row height=9.6875in fo:table-cell border-top-width=1pt background-color=#142850 border-right=0.5pt solid black fo:block fo:external-graphic width=0.5in src=left.svg height=9in / /fo:block /fo:table-cell fo:table-cell number-rows-spanned=5 fo:block / /fo:table-cell /fo:table-row fo:table-row fo:table-cell background-color=#142850 border-right=0.5pt solid black fo:block text-align=center font-size=5pt font-family=Optima /fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell background-color=#142850
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
what i said about maximally minimizing your test FO; when you don't do so, you lead devs astray On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com wrote: Please find attached a new fo which defines the sidebar for the left pages only. The blue column will show the four lines separating each row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4)) On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com wrote: I have reviewed the sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included). - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
Hopefully this latest one is more direct. On 11/08/2012 04:00 PM, Glenn Adams wrote: what i said about maximally minimizing your test FO; when you don't do so, you lead devs astray On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: Please find attached a new fo which defines the sidebar for the left pages only. The blue column will show the four lines separating each row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4)) On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo http://sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included). - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
yes, I see the problem. it is indeed strange but I think it is the result of the fact that each cell is painted independently and even though they touch each other (the common edges of adjacent cells have exactly the same coordinates) the viewer (and apparently your printer) create an artificial line in between. maybe this will need to be revisited one day... in any case, in your particular example you probably can get around the problem by doing things differently. maybe putting the background color in the side region instead of giving a background color to the cells of the table. On 11/8/12 11:03 PM, Rob Sargent wrote: Hopefully this latest one is more direct. On 11/08/2012 04:00 PM, Glenn Adams wrote: what i said about maximally minimizing your test FO; when you don't do so, you lead devs astray On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: Please find attached a new fo which defines the sidebar for the left pages only. The blue column will show the four lines separating each row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4)) On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo http://sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included). - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org
Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED
Agree. As I mentioned in my RESOVED mail, we have remove the underlying black which somehow seeped through in Evince and for the print shop. Thanks for your efforts. I think there is an issue, but whose it is is not clear to me and we think we're past the pain point. Cheers, rjs On 11/08/2012 04:46 PM, Luis Bernardo wrote: yes, I see the problem. it is indeed strange but I think it is the result of the fact that each cell is painted independently and even though they touch each other (the common edges of adjacent cells have exactly the same coordinates) the viewer (and apparently your printer) create an artificial line in between. maybe this will need to be revisited one day... in any case, in your particular example you probably can get around the problem by doing things differently. maybe putting the background color in the side region instead of giving a background color to the cells of the table. On 11/8/12 11:03 PM, Rob Sargent wrote: Hopefully this latest one is more direct. On 11/08/2012 04:00 PM, Glenn Adams wrote: what i said about maximally minimizing your test FO; when you don't do so, you lead devs astray On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: Please find attached a new fo which defines the sidebar for the left pages only. The blue column will show the four lines separating each row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4)) On 11/08/2012 03:19 PM, Luis Bernardo wrote: Rob, I looked with more time at this issue and I think that my previous statement that I was seeing lines where they should not be was incorrect. I think they should be there because they are in the *fo source! It is true that no lines appear with Adobe, but they are visible both with Mac's Preview and Linux's Evince. But the lines are only in the column that does not spans rows, the one with the blue background. I do not see them in the column that spans rows. More than that I do not see any unexpected drawing commands in the PDF source. Can you please explain again what lines are you seeing in the printer output? Are they in the blue column or in the white column? On 11/8/12 5:40 PM, Rob Sargent wrote: We use iText as well as FOP in producing our printable product. Some pages get a black background from iText (certain graphics look better that way). When the black background is under the sidebar (as made with the referenced sidebar.fo http://sidebar.fo) the nuisance-some inter-cell lines expose the black underlay. (Our fix is to not put the black under the sidebar.) In the original thread Jeremias Maerki wrote I suspect it's once more Adobe's anti-aliasing to be blamed. And this won't show up in print, BTW. To get rid of this on display, go to Acrobat's Preferences Dialog, select Page Display and enable Enhance Thin Lines (AR X) or disable Smooth line Art. You may have to disable Use 2D graphics acceleration, too. Nothing FOP can do at the moment. I've recently explained on this list what would need to be done to work around Adobe's problem. Since there is a path whereon they do show up in print, I wonder if this suggested work-around should be revisited? It's not clear to me that this is still out of FOP's hands? Thank you for your indulgence, rjs On 11/05/2012 05:10 PM, Glenn Adams wrote: remove elements/attrs until the problem goes away and only comes back when adding the element/attr just removed (no matter what else is removed) On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com mailto:rsarg...@xmission.com wrote: I have reviewed the sidebar.fo http://sidebar.fo and it really cannot be substantially reduced. It simply fills the outer edge of our pages - region-start or region end - with a narrow two-column, five-row table stretching the length of the page. The inner column is just spacer and the outer column gets the section name(s) and number, a rule and a page number. The names are supplied in a rotated svg (not included). - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org
Re: Need help to get Arabic working with FOP
Thank you all for your replies. I haven't been succesfull in getting the result right. I downloaded the attached files and tried those, and arabic was displayed using Arial, I also tried different other fonts such as ScheherazadeRegOT, but in all cases the letters are not connected correctly, each letter is displayed standing alone. Also vocal signs are lost even with ScheherazadeRegOT. Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/ It uses webkit to convert from HTML to PDF and the result is great with regard to fonts. No FO file is needed. Links within the PDF file doesn't work, but I think I can live with that. I think I'm gonna give up on FOP for now and use webkit HTML to PDF instead. Best regards. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Need help to get Arabic working with FOP
don't give up so easily; send me your input FO file (or a sample) and I'll check what you are doing wrong... just to make sure, you are using fop 1.1 yes? note that others are regularly using fop 1.1 successfully for arabic, so it is probably a usage or config problem on your end On Thu, Nov 8, 2012 at 4:23 PM, Brian Hansen greencopperm...@gmail.comwrote: Thank you all for your replies. I haven't been succesfull in getting the result right. I downloaded the attached files and tried those, and arabic was displayed using Arial, I also tried different other fonts such as ScheherazadeRegOT, but in all cases the letters are not connected correctly, each letter is displayed standing alone. Also vocal signs are lost even with ScheherazadeRegOT. Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/ It uses webkit to convert from HTML to PDF and the result is great with regard to fonts. No FO file is needed. Links within the PDF file doesn't work, but I think I can live with that. I think I'm gonna give up on FOP for now and use webkit HTML to PDF instead. Best regards. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Need help to get Arabic working with FOP
I have been using FOP 1.0, but never mind, I have just fallin in love with wkhtmltopdf - the static version produces links inside the PDF file and the result is so much better than FOP. Thanks, but I wont be using FOP any longer I think the result from wkhtmltopdf is much better, even with the problems with Arabic fonts. 2012/11/9, Glenn Adams gl...@skynav.com: don't give up so easily; send me your input FO file (or a sample) and I'll check what you are doing wrong... just to make sure, you are using fop 1.1 yes? note that others are regularly using fop 1.1 successfully for arabic, so it is probably a usage or config problem on your end On Thu, Nov 8, 2012 at 4:23 PM, Brian Hansen greencopperm...@gmail.comwrote: Thank you all for your replies. I haven't been succesfull in getting the result right. I downloaded the attached files and tried those, and arabic was displayed using Arial, I also tried different other fonts such as ScheherazadeRegOT, but in all cases the letters are not connected correctly, each letter is displayed standing alone. Also vocal signs are lost even with ScheherazadeRegOT. Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/ It uses webkit to convert from HTML to PDF and the result is great with regard to fonts. No FO file is needed. Links within the PDF file doesn't work, but I think I can live with that. I think I'm gonna give up on FOP for now and use webkit HTML to PDF instead. Best regards. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Need help to get Arabic working with FOP
On Thu, Nov 8, 2012 at 5:11 PM, Brian Hansen greencopperm...@gmail.comwrote: I have been using FOP 1.0, but never mind, I have just fallin in love with wkhtmltopdf - the static version produces links inside the PDF file and the result is so much better than FOP. Thanks, but I wont be using FOP any longer I think the result from wkhtmltopdf is much better, even with the problems with Arabic fonts. It can't be better since FOP 1.0 never supported Arabic. You are comparing apples and oranges. If you wish to try FOP with Arabic, use a version that supports it. Otherwise, you are wasting our time. Whatever.
java.lang.IllegalArgumentException: 14 when processing math
I have three different XML files with a lot of math in them (quantum physics). With each of them, when I use FOP to generate pdf's I get the following exception (let me know if you want to see the full stack trace, here's the top with all the FOP lines): In one of the files, here is one snippet that will throw the error (it's not thrown when I comment this out): Are there any symbols in there that might be unsupported? Is there something else I should be considering that might trigger this error? Please let me know if there is other information I can provide to help track this down. Thanks in advance for any pointers. -- View this message in context: http://apache-fop.1065347.n5.nabble.com/java-lang-IllegalArgumentException-14-when-processing-math-tp37306.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org