Re: FOP 2.3 and JEuclid
Hi, I tested with many formulas and didn't find any problem. It seems to work as it should. Note that I had a failed automatic test when compiling JEuclid Core : Results : Failed tests: testConverterSVGtoDOM(net.sourceforge.jeuclid.test.ConverterTest) Tests run: 56, Failures: 1, Errors: 0, Skipped: 0 Thanks everyone. -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 26/03/2019 à 17:48, Simon Steiner a écrit : Hi, The developer of JEuclid will need to be contacted to update their code to work with the newer batik. Thanks *From:*Dean Nelson *Sent:* 26 March 2019 16:38 *To:* fop-users@xmlgraphics.apache.org *Subject:* RE: FOP 2.3 and JEuclid All, It would be nice to produce a jEuclid version that could be used with 2.3. Right now I am stuck with FOP 2.2 because of this change. Right now I don’t see any other way to support MathML natively like jEuclid in FOP without a lot of rework. Has anyone tested https://github.com/rototor/jeuclid ? Regards, Dean Nelson *From:*Simon Steiner <mailto:simonsteiner1...@gmail.com>> *Sent:* Tuesday, March 26, 2019 3:32 AM *To:* fop-users@xmlgraphics.apache.org <mailto:fop-users@xmlgraphics.apache.org> *Subject:* RE: FOP 2.3 and JEuclid Hi, In order to make batik compile under java 10, we had to rename the namespace since we don’t own org.w3c. https://issues.apache.org/jira/browse/BATIK-1216 Thanks *From:*Maxime Bégnis mailto:max...@neodoc.fr>> *Sent:* 26 March 2019 08:21 *To:* fop-users@xmlgraphics.apache.org <mailto:fop-users@xmlgraphics.apache.org> *Subject:* FOP 2.3 and JEuclid Hello, There is an incompatibility between FOP 2.3 and JEuclid 3.1.9. This because FOP uses Batik 1.10. The class "org.w3c.dom.events.CustomEvent" in Batik 1.8 has be moved to "org.apache.batik.w3c.dom.events.CustomEvent" in Batik 1.10. That's the problem I could spot but I don't know if there are others. I modified and recompile JEuclid core simply changing the import statement in net.sourceforge.jeuclid.elements.presentation.token.Mo and that fixed the issue but I didn't make any intensive test yet. Attached is the patch. Is that a known issue? If so, is there a well known way to fix it? Thanks, -- -- *Neo**Doc* *Maxime Bégnis* max...@neodoc.fr <mailto:max...@neodoc.fr> Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/
FOP 2.3 and JEuclid
Hello, There is an incompatibility between FOP 2.3 and JEuclid 3.1.9. This because FOP uses Batik 1.10. The class "org.w3c.dom.events.CustomEvent" in Batik 1.8 has be moved to "org.apache.batik.w3c.dom.events.CustomEvent" in Batik 1.10. That's the problem I could spot but I don't know if there are others. I modified and recompile JEuclid core simply changing the import statement in net.sourceforge.jeuclid.elements.presentation.token.Mo and that fixed the issue but I didn't make any intensive test yet. Attached is the patch. Is that a known issue? If so, is there a well known way to fix it? Thanks, -- -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ --- ./jeuclid-parent-3.1.9/jeuclid-core/src/main/java/net/sourceforge/jeuclid/elements/presentation/token/Mo.java 2010-02-12 15:10:32.0 +0100 +++ ../jeuclid-parent-3.1.9/jeuclid-core/src/main/java/net/sourceforge/jeuclid/elements/presentation/token/Mo.java 2019-03-25 15:42:26.674417147 +0100 @@ -45,9 +45,9 @@ import org.apache.batik.dom.AbstractDocument; import org.apache.batik.dom.events.DOMCustomEvent; +import org.apache.batik.w3c.dom.events.CustomEvent; import org.w3c.dom.Attr; import org.w3c.dom.Node; -import org.w3c.dom.events.CustomEvent; import org.w3c.dom.events.Event; import org.w3c.dom.events.EventListener; import org.w3c.dom.events.EventTarget; - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Ligation Issues in Arabic & Devanagari
Hello Erik, I'm not sure but I may have had the exact same issue and Glenn Adams provided me with a simple solution that worked. See: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201606.mbox/browser Best regards, -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 06/04/2017 à 16:57, Erik Ogan a écrit : > I am having some issues with ligation in Arabic & Devanagari scripts > in my embedded FOP application. I have not disabled Complex Script > Features, and have explicitly turned them on just to be sure: > > … > FopFactoryBuilder builder = new FopConfParser(cfgStream, > baseURI).getFopFactoryBuilder(); > builder.setComplexScriptFeatures(true); > … > > I’ve searched the archives for tips, but most of the discussion of > ligatures is around removing/disabling them. > > This discussion was the only one I found that seemed like it offered a > solution: > http://marc.info/?l=fop-user=142547685119005=2 > > But alas, adding script attributes to my fo:block elements (as you’ll > see in the file below) seems to have had no effect. > > I’m using NoTo Sans as my font, which does have ligature information. > > Here is an example (intermediate) FO file: > https://s3-us-west-2.amazonaws.com/erik-fop-questions/with-scripts.fo > (I have also tried downcasing & upcasing the script attributes) > > Here is my configuration file: > https://s3-us-west-2.amazonaws.com/erik-fop-questions/config.xml > > And here is a resulting PDF: > https://s3-us-west-2.amazonaws.com/erik-fop-questions/current.pdf > > The most _infuriating_ part of this is that before this project was > put on hold 1.5 years ago I apparently had it working in early > experiments (before I’d even corrected the alignment of Arabic & > Hebrew): > > https://s3-us-west-2.amazonaws.com/erik-fop-questions/2015-08-09-example.pdf > > I am using the same code, with the same configuration and font files, > yet it is producing a different result. I’ve been tearing my hair out > for weeks trying to figure out what is different. > > I also have a dim memory of having had this issue in earlier > experiments, and discovering a simple solution. But I have NO idea > what that solution was, nor how it would be external to the code & > configuration I am currently running. > > … I JUST had a flashbulb memory that perhaps the solution then was > upgrading from Java 1.6 to 1.7. I’m running all of this on 1.8 right > now. > > Any help or suggestions folks have would be GREATLY appreciated. Thanks! > > -e >
Re: Fonts in the class path makes fonts listing fail
Hi Chris, There it is: https://issues.apache.org/jira/browse/FOP-2611 I hope I did this the right way. BR, -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 20/06/2016 11:16, Chris Bowditch a écrit : > Hi Maxime, > > You can file a bug using JIRA, see: > http://xmlgraphics.apache.org/fop/bugs.html > > Thanks, > > Chris > > On 17/06/2016 08:24, Maxime Bégnis wrote: >> Hello, >> >> Is there a way for me to file a bug report about this? >> >> BR, >> >> -- >> *NeoDoc* >> *Maxime Bégnis* >> max...@neodoc.fr >> Tél: +33 (0)4.42.52.24.20 >> 789 Rue de La Gare >> 13770 Venelles >> France >> http://www.neodoc.fr/ >> Le 10/06/2016 10:43, Maxime Bégnis a écrit : >>> When using fonts embedded in a .jar file in the class path >>> (https://xmlgraphics.apache.org/fop/2.1/fonts.html#autodetect), >>> fonts listing fails with this exception: >>> >>> org.apache.fop.cli.Main startFOP >>> GRAVE: Exception >>> java.lang.IllegalArgumentException: URI is not hierarchical >>> at java.io.File.(File.java:418) >>> at org.apache.fop.fonts.FontCache.addFont(FontCache.java:335) >>> at >>> org.apache.fop.fonts.autodetect.FontInfoFinder.getFontInfoFromCustomFont(FontInfoFinder.java:157) >>> at >>> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:269) >>> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) >>> at >>> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:110) >>> at >>> org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) >>> at >>> org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82) >>> at >>> org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147) >>> at >>> org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127) >>> at >>> org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) >>> at >>> org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187) >>> at >>> org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) >>> at >>> org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) >>> >>> at >>> org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105) >>> at >>> org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350) >>> at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107) >>> at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104) >>> at org.apache.fop.apps.Fop.(Fop.java:78) >>> at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:182) >>> at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107) >>> at org.apache.fop.cli.Main.startFOP(Main.java:186) >>> at org.apache.fop.cli.Main.main(Main.java:217) >>> >>> I found a way around this by using a custom resolver that will >>> discard any "jar: ..." URI. >>> >>> I use fonts in a jar file for them to be taken into account by >>> JEuclid (I didn't find any other way so far). >>> >>> I finally made this work by duplicating the fonts in the jar file in >>> a regular folder (so I must maintain 2 copies of each file). >>> >>> I'm using FOP 2.1 (from >>> https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 >>> LTS Linux. >>> >>> BR, >>> >>> -- >>> -- >>> *NeoDoc* >>> *Maxime Bégnis* >>> max...@neodoc.fr >>> Tél: +33 (0)4.42.52.24.20 >>> 789 Rue de La Gare >>> 13770 Venelles >>> France >>> http://www.neodoc.fr/ >> > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org >
Re: Arabic text and letter join
I have confirmation that the document is correct in any way by someone who reads the language. Thanks again, -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 17/06/2016 14:18, Maxime Bégnis a écrit : > Removing the language="ar" attribute did the trick. > > I made the test with "TraditionalArabic" and "Arial" with (it seems) > the same correct result. > > I'm waiting for a confirmation from someone that can read this > language. I'll let you know. > > Many thanks, > > -- > *NeoDoc* > *Maxime Bégnis* > max...@neodoc.fr > Tél: +33 (0)4.42.52.24.20 > 789 Rue de La Gare > 13770 Venelles > France > http://www.neodoc.fr/ > Le 17/06/2016 12:29, Glenn Adams a écrit : >> Try removing the language="ar" attribute. Also try one of the fonts >> listed here: >> >> https://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic >> >> >> >> On Fri, Jun 17, 2016 at 1:18 AM, Maxime Bégnis <max...@neodoc.fr >> <mailto:max...@neodoc.fr>> wrote: >> >> Sample FO file attached. >> >> BR, >> >> -- >> *NeoDoc* >> *Maxime Bégnis* >> max...@neodoc.fr <mailto:max...@neodoc.fr> >> Tél: +33 (0)4.42.52.24.20 >> 789 Rue de La Gare >> 13770 Venelles >> France >> http://www.neodoc.fr/ >> Le 16/06/2016 17:40, Glenn Adams a écrit : >>> Please post a very short XSL-FO file containing a minimal >>> example demonstrating the problem. >>> >>> On Thu, Jun 16, 2016 at 8:23 AM, Maxime Bégnis >>> <max...@neodoc.fr> wrote: >>> >>> Hello, >>> >>> I'm using FOP 2.1 to generate PDF documents in Arabic. It >>> seems that the letters that should be joined are not. >>> Attached is a sample result PDF. >>> >>> I paste here an example for the title of the document hoping >>> it will be correctly displayed for the readers of this mail. >>> >>> تكاليف سبتمبر >>> >>> I tried different fonts (Arial and Traditional Arabic) >>> without success. Note that the text direction is handled >>> properly. >>> >>> I would appreciate any advice on this. >>> >>> BR, >>> >>> -- >>> -- >>> *NeoDoc* >>> *Maxime Bégnis* >>> max...@neodoc.fr >>> Tél: +33 (0)4.42.52.24.20 >>> 789 Rue de La Gare >>> 13770 Venelles >>> France >>> http://www.neodoc.fr/ >>> >>> >> >> >> >> - >> 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: Fonts in the class path makes fonts listing fail
Hello, Is there a way for me to file a bug report about this? BR, -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 10/06/2016 10:43, Maxime Bégnis a écrit : > When using fonts embedded in a .jar file in the class path > (https://xmlgraphics.apache.org/fop/2.1/fonts.html#autodetect), fonts > listing fails with this exception: > > org.apache.fop.cli.Main startFOP > GRAVE: Exception > java.lang.IllegalArgumentException: URI is not hierarchical > at java.io.File.(File.java:418) > at org.apache.fop.fonts.FontCache.addFont(FontCache.java:335) > at > org.apache.fop.fonts.autodetect.FontInfoFinder.getFontInfoFromCustomFont(FontInfoFinder.java:157) > at > org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:269) > at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) > at > org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:110) > at > org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) > at > org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82) > at > org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147) > at > org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127) > at > org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) > at > org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187) > at > org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) > at > org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) > at > org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105) > at > org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350) > at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107) > at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104) > at org.apache.fop.apps.Fop.(Fop.java:78) > at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:182) > at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107) > at org.apache.fop.cli.Main.startFOP(Main.java:186) > at org.apache.fop.cli.Main.main(Main.java:217) > > I found a way around this by using a custom resolver that will discard > any "jar: ..." URI. > > I use fonts in a jar file for them to be taken into account by JEuclid > (I didn't find any other way so far). > > I finally made this work by duplicating the fonts in the jar file in a > regular folder (so I must maintain 2 copies of each file). > > I'm using FOP 2.1 (from > https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 > LTS Linux. > > BR, > > -- > -- > *NeoDoc* > *Maxime Bégnis* > max...@neodoc.fr > Tél: +33 (0)4.42.52.24.20 > 789 Rue de La Gare > 13770 Venelles > France > http://www.neodoc.fr/
Re: Arabic text and letter join
Sample FO file attached. BR, -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 16/06/2016 17:40, Glenn Adams a écrit : > Please post a very short XSL-FO file containing a minimal example > demonstrating the problem. > > On Thu, Jun 16, 2016 at 8:23 AM, Maxime Bégnis <max...@neodoc.fr > <mailto:max...@neodoc.fr>> wrote: > > Hello, > > I'm using FOP 2.1 to generate PDF documents in Arabic. It seems > that the letters that should be joined are not. Attached is a > sample result PDF. > > I paste here an example for the title of the document hoping it > will be correctly displayed for the readers of this mail. > > تكاليف سبتمبر > > I tried different fonts (Arial and Traditional Arabic) without > success. Note that the text direction is handled properly. > > I would appreciate any advice on this. > > BR, > > -- > -- > *NeoDoc* > *Maxime Bégnis* > max...@neodoc.fr <mailto:max...@neodoc.fr> > Tél: +33 (0)4.42.52.24.20 > 789 Rue de La Gare > 13770 Venelles > France > http://www.neodoc.fr/ > > http://www.w3.org/1999/XSL/Format; xmlns:d="http://docbook.org/ns/docbook; font-family="Arial" font-size="11pt" writing-mode="rl-tb" language="ar"> تعÙÙ٠ات اÙتشغÙÙ Øد٠Ù٠عÙÙر ÙاÙسد٠بتخصÙص. Ù٠اÙتÙØÙ٠اÙتصادÙØ© بعض, دÙÙØ© شرسة إع٠ار غÙر عÙ. دار ببعض عÙاÙØ© ÙÙÙس٠بÙرغ إذ, Øصدت ÙدØر إذ ÙÙ Ù, ت٠ØÙÙ٠تØرÙر ÙصÙ. بÙا ت٠أسÙا عرÙÙا ارتÙبÙا, Ù£Ù Ùا٠ÙعÙ٠اÙعظ٠٠اÙرÙبا. أدÙات اÙضرÙر٠اÙØ¥ÙتصادÙØ© Ø£Ù Ø°ÙÙ, أ٠باÙرÙغ٠ب٠عارضة برÙطاÙÙا اÙا. Ø°Ù٠٠٠اÙÙاد٠اÙØ£ÙرÙبÙÙÙÙ. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Arabic text and letter join
Hello, I'm using FOP 2.1 to generate PDF documents in Arabic. It seems that the letters that should be joined are not. Attached is a sample result PDF. I paste here an example for the title of the document hoping it will be correctly displayed for the readers of this mail. تكاليف سبتمبر I tried different fonts (Arial and Traditional Arabic) without success. Note that the text direction is handled properly. I would appreciate any advice on this. BR, -- -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/
Fonts in the class path makes fonts listing fail
When using fonts embedded in a .jar file in the class path (https://xmlgraphics.apache.org/fop/2.1/fonts.html#autodetect), fonts listing fails with this exception: org.apache.fop.cli.Main startFOP GRAVE: Exception java.lang.IllegalArgumentException: URI is not hierarchical at java.io.File.(File.java:418) at org.apache.fop.fonts.FontCache.addFont(FontCache.java:335) at org.apache.fop.fonts.autodetect.FontInfoFinder.getFontInfoFromCustomFont(FontInfoFinder.java:157) at org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:269) at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) at org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:110) at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) at org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82) at org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147) at org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127) at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) at org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187) at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105) at org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350) at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107) at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104) at org.apache.fop.apps.Fop.(Fop.java:78) at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:182) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107) at org.apache.fop.cli.Main.startFOP(Main.java:186) at org.apache.fop.cli.Main.main(Main.java:217) I found a way around this by using a custom resolver that will discard any "jar: ..." URI. I use fonts in a jar file for them to be taken into account by JEuclid (I didn't find any other way so far). I finally made this work by duplicating the fonts in the jar file in a regular folder (so I must maintain 2 copies of each file). I'm using FOP 2.1 (from https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 LTS Linux. BR, -- -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/
Re: Misplaced table border using rl-tb writing mode
The patch seems to work just fine. Thank you very much for the quick reply. -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ Le 08/06/2016 15:54, Matthias Reischenbacher a écrit : > > Hi, > > you might try this patch: > > https://issues.apache.org/jira/browse/FOP-2570 > > BR, > > Matthias > > On 08.06.2016 09:33, Maxime Bégnis wrote: >> I came up with this strange behavior using using rl-tb writing mode >> in a PDF output: >> >> in case of an horizontal merged cell in a table, the table border for >> that cell is placed in the middle of the cell. >> >> Attached is an FO file that reproduces the issue. >> >> I'm using FOP 2.1 (from >> https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 >> LTS Linux. >> >> I don't know if I'm doing something wrong, if there is a way around >> it or if this is a bug. >> >> -- >> -- >> *NeoDoc* >> *Maxime Bégnis* >> max...@neodoc.fr >> Tél: +33 (0)4.42.52.24.20 >> 789 Rue de La Gare >> 13770 Venelles >> France >> http://www.neodoc.fr/ >> >> >> - >> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org >> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org >
Misplaced table border using rl-tb writing mode
I came up with this strange behavior using using rl-tb writing mode in a PDF output: in case of an horizontal merged cell in a table, the table border for that cell is placed in the middle of the cell. Attached is an FO file that reproduces the issue. I'm using FOP 2.1 (from https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 LTS Linux. I don't know if I'm doing something wrong, if there is a way around it or if this is a bug. -- -- *NeoDoc* *Maxime Bégnis* max...@neodoc.fr Tél: +33 (0)4.42.52.24.20 789 Rue de La Gare 13770 Venelles France http://www.neodoc.fr/ http://www.w3.org/1999/XSL/Format; xmlns:d="http://docbook.org/ns/docbook; font-family="Arial" font-size="11pt" writing-mode="rl-tb"> ت٠ÙÙد Ø¥Øتار Ù٠طاÙبة غÙر Ø£Ù. ÙÙص٠بتخصÙص إذ ØÙÙ, Ùرس٠ÙتتØÙ ÙÙ ÙباÙتØدÙØ¯Ø Ù Ø¯Ù Ø¨Ù. ÙÙÙ ÙÙ ØاÙ٠إستÙÙاء, Ùد ÙØ¥Ùا٠ة اÙتØاÙÙ ÙصÙ, ب٠ØÙÙ ÙÙرÙسا اÙإتÙاÙÙØ©. Ù Ù ÙØ°Ù ÙبدÙ٠اÙØ«ÙÙÙ, ٣٠أخذ اÙØÙÙÙ Ø© اÙجدÙØ¯Ø©Ø Ø§Ø³ØªØ·Ø§Ø¹Ùا, Ù ÙÙد ÙعÙÙ ÙÙÙÙØ© اسبÙعÙÙ. أراض Ùرتبط ÙاÙÙساد Ùد جÙÙ, اÙأخذ اÙسÙØ¡ Ù ÙÙÙ. Øا٠Ùات اÙØ´ÙÙرة ÙÙس Ø£Ù, عد٠اÙعصبة ٠سؤÙÙÙØ© ت٠, ث٠تÙ٠اÙذار اÙØدÙد. ت٠ÙÙد Ø¥Øتار Ù٠طاÙبة غÙر Ø£Ù. ÙÙص٠بتخصÙص إذ ØÙÙ, Ùرس٠ÙتتØÙ ÙÙ ÙباÙتØدÙØ¯Ø Ù Ø¯Ù Ø¨Ù. ÙÙÙ ÙÙ ØاÙ٠إستÙÙاء, Ùد ÙØ¥Ùا٠ة اÙتØاÙÙ ÙصÙ, ب٠ØÙÙ ÙÙرÙسا اÙإتÙاÙÙØ©. Ù Ù ÙØ°Ù ÙبدÙ٠اÙØ«ÙÙÙ, ٣٠أخذ اÙØÙÙÙ Ø© اÙجدÙØ¯Ø©Ø Ø§Ø³ØªØ·Ø§Ø¹Ùا, Ù ÙÙد ÙعÙÙ ÙÙÙÙØ© اسبÙعÙÙ. أراض Ùرتبط ÙاÙÙساد Ùد جÙÙ, اÙأخذ اÙسÙØ¡ Ù ÙÙÙ. Øا٠Ùات اÙØ´ÙÙرة ÙÙس Ø£Ù, عد٠اÙعصبة ٠سؤÙÙÙØ© ت٠, ث٠تÙ٠اÙذار اÙØدÙد. ت٠ÙÙد Ø¥Øتار Ù٠طاÙبة غÙر Ø£Ù. ÙÙص٠بتخصÙص إذ ØÙÙ, Ùرس٠ÙتتØÙ ÙÙ ÙباÙتØدÙØ¯Ø Ù Ø¯Ù Ø¨Ù. ÙÙÙ ÙÙ ØاÙ٠إستÙÙاء, Ùد ÙØ¥Ùا٠ة اÙتØاÙÙ ÙصÙ, ب٠ØÙÙ ÙÙرÙسا اÙإتÙاÙÙØ©. Ù Ù ÙØ°Ù ÙبدÙ٠اÙØ«ÙÙÙ, ٣٠أخذ اÙØÙÙÙ Ø© اÙجدÙØ¯Ø©Ø Ø§Ø³ØªØ·Ø§Ø¹Ùا, Ù ÙÙد ÙعÙÙ ÙÙÙÙØ© اسبÙعÙÙ. أراض Ùرتبط ÙاÙÙساد Ùد جÙÙ, اÙأخذ اÙسÙØ¡ Ù ÙÙÙ. Øا٠Ùات اÙØ´ÙÙرة ÙÙس Ø£Ù, عد٠اÙعصبة ٠سؤÙÙÙØ© ت٠, ث٠تÙ٠اÙذار اÙØدÙد. ت٠ÙÙد Ø¥Øتار Ù٠طاÙبة غÙر Ø£Ù. ÙÙص٠بتخصÙص إذ ØÙÙ, Ùرس٠ÙتتØÙ ÙÙ ÙباÙتØدÙØ¯Ø Ù Ø¯Ù Ø¨Ù. ÙÙÙ ÙÙ ØاÙ٠إستÙÙاء, Ùد ÙØ¥Ùا٠ة اÙتØاÙÙ ÙصÙ, ب٠ØÙÙ ÙÙرÙسا اÙإتÙاÙÙØ©. Ù Ù ÙØ°Ù ÙبدÙ٠اÙØ«ÙÙÙ, ٣٠أخذ اÙØÙÙÙ Ø© اÙجدÙØ¯Ø©Ø Ø§Ø³ØªØ·Ø§Ø¹Ùا, Ù ÙÙد ÙعÙÙ ÙÙÙÙØ© اسبÙعÙÙ. أراض Ùرتبط ÙاÙÙساد Ùد جÙÙ, اÙأخذ اÙسÙØ¡ Ù ÙÙÙ. Øا٠Ùات اÙØ´ÙÙرة ÙÙس Ø£Ù, عد٠اÙعصبة ٠سؤÙÙÙØ© ت٠, ث٠تÙ٠اÙذار اÙØدÙد. ت٠ÙÙد Ø¥Øتار Ù٠طاÙبة غÙر Ø£Ù. ÙÙص٠بتخصÙص إذ ØÙÙ, Ùرس٠ÙتتØÙ ÙÙ ÙباÙتØدÙØ¯Ø Ù Ø¯Ù Ø¨Ù. ÙÙÙ ÙÙ ØاÙ٠إستÙÙاء, Ùد ÙØ¥Ùا٠ة اÙتØاÙÙ ÙصÙ, ب٠ØÙÙ ÙÙرÙسا اÙإتÙاÙÙØ©. Ù Ù ÙØ°Ù ÙبدÙ٠اÙØ«ÙÙÙ, ٣٠أخذ اÙØÙÙÙ Ø© اÙجدÙØ¯Ø©Ø Ø§Ø³ØªØ·Ø§Ø¹Ùا, Ù ÙÙد ÙعÙÙ ÙÙÙÙØ© اسبÙعÙÙ. أراض Ùرتبط ÙاÙÙساد Ùد جÙÙ, اÙأخذ اÙسÙØ¡ Ù ÙÙÙ. Øا٠Ùات اÙØ´ÙÙرة ÙÙس Ø£Ù, عد٠اÙعصبة ٠سؤÙÙÙØ© ت٠, ث٠تÙ٠اÙذار اÙØدÙد. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Chinese font?
Hi, I'm trying to produce a PDF containing Chinese text using FOP 1.0. I tried many TTF fonts but there is always some characters appearing as a #. Does anyone recommend a specific Chinese TTF font to be used with FOP? Many thanks, -- -- *NeoDoc* *Maxime Bégnis* max...@neodoc.biz Tél: +33 (0)4.42.52.24.20 5, rue de la Touloubre 13770 Venelles France http://www.neodoc.fr/
Re: Font-scaling?
Hi, There is a FO property "font-stretch"(http://www.w3.org/TR/xsl/#font-stretch) which is not supported by FOP(http://xmlgraphics.apache.org/fop/compliance.html#fo-property-font-stretch). I would have liked to do the same thing but I didn't find any solution. Maxime Bgnis NeoDoc NeoDoc Maxime Bgnis Dveloppeur max...@neodoc.biz Tl: 09.54.96.99.55 - Fax: 09.59.96.99.55 http://www.neodoc.fr/ 5, rue de la Touloubre 13770 Venelles Le 10/11/2010 14:15, Eric Douglas a crit: To make a fixed width font out of a variable width font? Why not just use a fixed width font? I would think stretching a variable width font to make all the characters the same width and height would be a pain, as I can only guess they'd have to be converted to images and stretched to fit. Maybe there's an easier way. -Original Message- From: Ancient [mailto:hara...@hotmail.com] Sent: Wednesday, November 10, 2010 6:39 AM To: fop-users@xmlgraphics.apache.org Subject: Font-scaling? Hi! Is it possible in fop 1.0 to scale the font's letters horizontally, like in many softwares, for example InDesign's Horizontal Scale -option? Any help appreciated! -- View this message in context: http://old.nabble.com/Font-scaling--tp30179665p30179665.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 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
preprocessing of images
Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: preprocessing of images
hi Georg, Thanks for your answer. My question wasn't very precise, sorry. I would like to be able to convert the images referenced in the FO file whatever the attributes. For example, if I have a PNG file referenced in an fo:external-graphic element, I would like to convert the image into JPEG format with a quality of 40% and limit the dimensions to 400x400. This is mostly to provide control on the size of the resulting PDF without having to change the FO file or the referenced images. Thanks a lot. Maxime Bégnis Le 05/10/2010 14:03, Georg Datterl a écrit : Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 13:56 *An:* fop-users@xmlgraphics.apache.org *Betreff:* preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: preprocessing of images
Ok, thanks for your answers. Le 05/10/2010 14:23, Georg Datterl a écrit : Hi Maxine, We preprocess the images with ImageMagick and put the preprocessed images into the PDF. I don't think there's another way nor will there ever be (in FOP). Maybe you can call a function during the transformation, but I'm no expert there. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 14:19 *An:* fop-users@xmlgraphics.apache.org *Betreff:* Re: AW: preprocessing of images hi Georg, Thanks for your answer. My question wasn't very precise, sorry. I would like to be able to convert the images referenced in the FO file whatever the attributes. For example, if I have a PNG file referenced in an fo:external-graphic element, I would like to convert the image into JPEG format with a quality of 40% and limit the dimensions to 400x400. This is mostly to provide control on the size of the resulting PDF without having to change the FO file or the referenced images. Thanks a lot. Maxime Bégnis Le 05/10/2010 14:03, Georg Datterl a écrit : Hi Maxime, Fop can work with quite a lot of image types. For resizing there are img attributes. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de http://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de http://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de http://www.willmy.de Willmy Consult Content GmbH: www.willmycc.de http://www.willmycc.de *Von:* Maxime Bégnis [mailto:max...@neodoc.biz] *Gesendet:* Dienstag, 5. Oktober 2010 13:56 *An:* fop-users@xmlgraphics.apache.org mailto:fop-users@xmlgraphics.apache.org *Betreff:* preprocessing of images Hi all, I'm wondering if there is a standard way in the FOP API to pre-process images, i.e. resizing, converting to a specific format, etc... before they are included in the resulting PDF? I use FOP 1.0 embedded in a java app. Thanks a lot for your help! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Strange(?) exception
) at org.apache.fop.layoutmgr.inline.LineLayoutManager.findOptimalBreakingPoints(LineLayoutManager.java:950) at org.apache.fop.layoutmgr.inline.LineLayoutManager.createLineBreaks(LineLayoutManager.java:917) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:607) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:107) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:145) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange(?) exception
OK, thanks a lot! Le 09/09/2010 16:53, Matthias Reischenbacher a écrit : Hi, this is a known FOP bug. A bug report already exists: https://issues.apache.org/bugzilla/show_bug.cgi?id=49837 Originally the bug was introduced by this patch: https://issues.apache.org/bugzilla/show_bug.cgi?id=48071 http://svn.apache.org/viewvc?view=revisionrevision=893238 I worked around by commenting some of the new code introduced by the patch but that's not a good solution. I attached my patch in case you want to use it anyway. Regards, Matthias Reischenbacher On 09.09.2010 09:25, Maxime Bégnis wrote: Hello list, Doing some FO transformations, I get a strange exception. It happens only to a few of my FO files and I cannot determine where this comes from. This happens with FOP 0.95 and 1.0. Have anyone seen that before? Thanks a lot if you can help! - Stack trace for 1.0 : 9 sept. 2010 09:42:41 org.apache.fop.events.LoggingEventListener processEvent ATTENTION: Font Symbol,normal,700 not found. Substituting with Symbol,normal,400. 9 sept. 2010 09:42:41 org.apache.fop.events.LoggingEventListener processEvent ATTENTION: Font ZapfDingbats,normal,700 not found. Substituting with ZapfDingbats,normal,400. 9 sept. 2010 09:42:41 org.apache.fop.hyphenation.Hyphenator getHyphenationTree GRAVE: Couldn't find hyphenation pattern en 9 sept. 2010 09:42:42 org.apache.fop.cli.Main startFOP GRAVE: Exception java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.traits.MinOptMax.mult(MinOptMax.java:251) at org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:825) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:663) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:639) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:579) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:199) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:140) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:129) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:216) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:692) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:149) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:132) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:337) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238
Re: fonts URL resolution
Hi, Finally I'm using a workaround in my URIResolver setting up a new prefix like myfonts:/ which is replaced by the actual fonts base URL. I wonder if the FOP behavior to use the URIResolver before the fonts base URL should be the standard one. Thanks. Maxime Bégnis Le 01/09/2010 17:55, Eric Douglas a écrit : I don't know about a simple solution but there is a workaround. I solved this or a related issue by not using the setFontBaseURL method. I use the Renderer.setFontList method instead to manually load in the custom font(s). Is there a point to using a BufferedOutputStream? I use a ByteArrayOutputStream, so I have the output in bytes so I can copy it from server to client. I haven't figured out yet how to get it to resolve paths properly for external image references. So far I only need one image, so I found a program to translate it to SVG code and copied it directly into my xsl. *From:* Maxime Bégnis [mailto:max...@neodoc.biz] *Sent:* Wednesday, September 01, 2010 11:37 AM *To:* fop-users@xmlgraphics.apache.org *Subject:* fonts URL resolution Hi list, I am using an URIResolver with FOP to resolve the URL of external images. I found out that it tries to find fonts using the URIResolver before using the font base URL specified with fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/) Is there a way to make it use the URIResolver after(or not at all) the specified font base URL? Here is the code I'm using : fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/); fopFactory.setUserConfig(new File(FOP_USER_CFG)); OutputStream os = new BufferedOutputStream(FileUtils.openOutputStream(result)); FOUserAgent uagent = fopFactory.newFOUserAgent(); uagent.setURIResolver(resolver); Fop fop = fopFactory.newFop(format, uagent, os); All this with FOP 1.0 Thanks a lot! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fonts URL resolution
Hi Jeremias, Le 02/09/2010 13:13, Jeremias Maerki a écrit : Hi Maxime On 02.09.2010 10:23:29 Maxime Bégnis wrote: Hi, Finally I'm using a workaround in my URIResolver setting up a new prefix like myfonts:/ which is replaced by the actual fonts base URL. That's one way to do it. In fact, your URIResolver should return null if it cannot resolve a particular URI. That way the resolution is delegated further down the chain by FOP. I suspect your URIResolver may not be implemented in the best way. My URIResolver resolve relative URIs against a specified base URL. The base URL of the FO transformation (where to find images) is not always the path to the .fo file. I guess I should use FopFactory.setBaseURL(String base) instead?|| I wonder if the FOP behavior to use the URIResolver before the fonts base URL should be the standard one. IMO: definitely. I wouldn't want it any other way. The URIResolver is there to handle special URI schemes. Relative URIs should rather be resolved against a base URI (the font base URL in this case). I understand now that if my URIResolver says to fop where a specific file is, there is no reason to look somewhere else... thanks. Maxime Bégnis Thanks. Maxime Bégnis Le 01/09/2010 17:55, Eric Douglas a écrit : I don't know about a simple solution but there is a workaround. I solved this or a related issue by not using the setFontBaseURL method. I use the Renderer.setFontList method instead to manually load in the custom font(s). Is there a point to using a BufferedOutputStream? I use a ByteArrayOutputStream, so I have the output in bytes so I can copy it from server to client. Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers. Still, the memory problem remains. I haven't figured out yet how to get it to resolve paths properly for external image references. So far I only need one image, so I found a program to translate it to SVG code and copied it directly into my xsl. *From:* Maxime Bégnis [mailto:max...@neodoc.biz] *Sent:* Wednesday, September 01, 2010 11:37 AM *To:* fop-users@xmlgraphics.apache.org *Subject:* fonts URL resolution Hi list, I am using an URIResolver with FOP to resolve the URL of external images. I found out that it tries to find fonts using the URIResolver before using the font base URL specified with fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/) Is there a way to make it use the URIResolver after(or not at all) the specified font base URL? Here is the code I'm using : fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/); fopFactory.setUserConfig(new File(FOP_USER_CFG)); OutputStream os = new BufferedOutputStream(FileUtils.openOutputStream(result)); FOUserAgent uagent = fopFactory.newFOUserAgent(); uagent.setURIResolver(resolver); Fop fop = fopFactory.newFop(format, uagent, os); All this with FOP 1.0 Thanks a lot! Maxime Bégnis Jeremias Maerki - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
fonts URL resolution
Hi list, I am using an URIResolver with FOP to resolve the URL of external images. I found out that it tries to find fonts using the URIResolver before using the font base URL specified with fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/) Is there a way to make it use the URIResolver after(or not at all) the specified font base URL? Here is the code I'm using : fopFactory.getFontManager().setFontBaseURL(file:///path/to/fonts/); fopFactory.setUserConfig(new File(FOP_USER_CFG)); OutputStream os = new BufferedOutputStream(FileUtils.openOutputStream(result)); FOUserAgent uagent = fopFactory.newFOUserAgent(); uagent.setURIResolver(resolver); Fop fop = fopFactory.newFop(format, uagent, os); All this with FOP 1.0 Thanks a lot! Maxime Bégnis attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: lists label shifting
Hello, Sorry for this very late reply. Thanks your answer, I didn't think about this. The line-stacking-strategy=font-height property with adapted padding on blocks works fine if the inline graphic is on the first line of the content generated by the block inside the fo:list-block, but if it is on the second line, the graphic overflows the above line(as expected). I didn't have time to search any further, I'll post something if I find a way. Thanks. Maxime Bégnis. Le 26/07/2010 11:17, Jeremias Maerki a écrit : Not really. The only thing I can come up is line-stacking-strategy=font-height on both blocks but then you may have to scale down the graphic a bit. relative-align is indeed the property that would need to be implemented for this. On 22.07.2010 12:35:29 Maxime Bégnis wrote: Hi all, Considering this code excerpt : fo:list-item fo:list-item-label end-indent=label-end() fo:block2./fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockInline graphic fo:external-graphic src=url(black_square.svg) width=5mm height=auto content-width=scale-to-fit content-height=scale-to-fit / some text. /fo:block /fo:list-item-body /fo:list-item In the resulting PDF, the baselines of the fo:list-item-label and the fo:list-item-body are not aligned vertically. I get something like this : 2. /--\ Inline graphic \__/ some text. While I would like to get : /--\ 2. Inline graphic \__/ some text. I understood from the XSL-1.1 specification that I should use the relative-align=baseline property on the fo:list-block. But, according to http://xmlgraphics.apache.org/fop/compliance.html, this property is not supported by any version of FOP. I tried the attached test file with FOP 1.0 and 0.95 with the same result. Does anyone knows a trick to get these baselines aligned vertically? Thanks a lot. Maxime Bégnis Jeremias Maerki - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org attachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
lists label shifting
Hi all, Considering this code excerpt : fo:list-item fo:list-item-label end-indent=label-end() fo:block2./fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockInline graphic fo:external-graphic src=url(black_square.svg) width=5mm height=auto content-width=scale-to-fit content-height=scale-to-fit / some text. /fo:block /fo:list-item-body /fo:list-item In the resulting PDF, the baselines of the fo:list-item-label and the fo:list-item-body are not aligned vertically. I get something like this : 2. /--\ Inline graphic \__/ some text. While I would like to get : /--\ 2. Inline graphic \__/ some text. I understood from the XSL-1.1 specification that I should use the relative-align=baseline property on the fo:list-block. But, according to http://xmlgraphics.apache.org/fop/compliance.html, this property is not supported by any version of FOP. I tried the attached test file with FOP 1.0 and 0.95 with the same result. Does anyone knows a trick to get these baselines aligned vertically? Thanks a lot. Maxime Bégnis ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 margin=1in fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:list-block fo:list-item fo:list-item-label end-indent=label-end() fo:block1./fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blocktest alone/fo:block /fo:list-item-body /fo:list-item fo:list-item fo:list-item-label end-indent=label-end() fo:block2./fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockInline graphic fo:external-graphic src=url(black_square.svg) width=5mm height=auto content-width=scale-to-fit content-height=scale-to-fit / some text. /fo:block /fo:list-item-body /fo:list-item /fo:list-block /fo:flow /fo:page-sequence /fo:root attachment: black_square.svgattachment: maxime.vcf - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
problems running fop: no standard output, no .png files rendering
hi I have these problems when running fop transforming files : -when I transform files containing errors no messages of any kind are printed on the screen (the help message is printed when I ask for it) -.png files are not rendered on the pdf file(but .jpg are rendered) Thanks a lot if you can help me. I use mandriva linux 2008, FOP version 0.94 jdk: java version 1.6.0_03 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
