[jira] [Updated] (FOP-2355) Issues with stacking of diacritics while trying to render PDFs in Thai language
[ https://issues.apache.org/jira/browse/FOP-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sougata Bhattacharya updated FOP-2355: -- Description: Let us take 3 examples, where the first two are rendering ok in the PDF, whereas the 3rd is not. 1. ยี = ย + ี (consonant + vowel) 2. ยี่ = ย + ี + ่ (consonant + vowel + diacritic) 3. ย่ = ย + ่ (consonant + diacritic) The third complex alphabet is showing ok when you see it in notepad/MSWord/webpage, etc. but in the PDF, it renders with a vertical space in between the diacritic and the consonant, as if a vowel is missing. Though this does not alter the meaning of the script, it looks unprofessional. Details on how i want the characters to be rendered in the PDF, can be found in the 2nd example of the link: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=CmplxRndExamples Fonts used: PSL096pro.ttf, PSL095pro.ttf, PSL094pro.ttf, PSL053pro.ttf, PSL052pro.ttf, PSL051pro.ttf, PSL050pro.ttf, etc.. was: Let us take 3 examples, where the first two are rendering ok in the PDF, whereas the 3rd is not. 1. ยี = ย + ี (consonant + vowel) 2. ยี่ = ย + ี + ่ (consonant + vowel + diacritic) 3. ย่ = ย + ่ (consonant + diacritic) The third complex alphabet is showing ok when you see it in notepad/MSWord/webpage, etc. but in the PDF, it renders with a vertical space in between the diacritic and the consonant, as if a vowel is missing. Though this does not alter the meaning of the script, it looks unprofessional. Similar details on what exactly I am facing can be found in the 2nd example of the link: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=CmplxRndExamples Fonts used: PSL096pro.ttf, PSL095pro.ttf, PSL094pro.ttf, PSL053pro.ttf, PSL052pro.ttf, PSL051pro.ttf, PSL050pro.ttf, etc.. Issues with stacking of diacritics while trying to render PDFs in Thai language --- Key: FOP-2355 URL: https://issues.apache.org/jira/browse/FOP-2355 Project: Fop Issue Type: Bug Components: fonts, pdf Affects Versions: 1.1, trunk Environment: Win 7, JDK1.6 Reporter: Sougata Bhattacharya Attachments: example pdf.jpg Let us take 3 examples, where the first two are rendering ok in the PDF, whereas the 3rd is not. 1. ยี = ย + ี (consonant + vowel) 2. ยี่ = ย + ี + ่ (consonant + vowel + diacritic) 3. ย่ = ย + ่ (consonant + diacritic) The third complex alphabet is showing ok when you see it in notepad/MSWord/webpage, etc. but in the PDF, it renders with a vertical space in between the diacritic and the consonant, as if a vowel is missing. Though this does not alter the meaning of the script, it looks unprofessional. Details on how i want the characters to be rendered in the PDF, can be found in the 2nd example of the link: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=CmplxRndExamples Fonts used: PSL096pro.ttf, PSL095pro.ttf, PSL094pro.ttf, PSL053pro.ttf, PSL052pro.ttf, PSL051pro.ttf, PSL050pro.ttf, etc.. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2355) Issues with stacking of diacritics while trying to render PDFs in Thai language
[ https://issues.apache.org/jira/browse/FOP-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930030#comment-13930030 ] Glenn Adams commented on FOP-2355: -- Please provide the following: (1) minimal input FO file containing the least content that demonstrates the problem; (2) the PDF output file produced by running FOP on this input FO file; (3) your fop.xconf configuration file; (4) any console output when running FOP; (5) information about which version of FOP you used to produce the output PDF file; Issues with stacking of diacritics while trying to render PDFs in Thai language --- Key: FOP-2355 URL: https://issues.apache.org/jira/browse/FOP-2355 Project: Fop Issue Type: Bug Components: fonts, pdf Affects Versions: 1.1, trunk Environment: Win 7, JDK1.6 Reporter: Sougata Bhattacharya Attachments: example pdf.jpg Let us take 3 examples, where the first two are rendering ok in the PDF, whereas the 3rd is not. 1. ยี = ย + ี (consonant + vowel) 2. ยี่ = ย + ี + ่ (consonant + vowel + diacritic) 3. ย่ = ย + ่ (consonant + diacritic) The third complex alphabet is showing ok when you see it in notepad/MSWord/webpage, etc. but in the PDF, it renders with a vertical space in between the diacritic and the consonant, as if a vowel is missing. Though this does not alter the meaning of the script, it looks unprofessional. Details on how i want the characters to be rendered in the PDF, can be found in the 2nd example of the link: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=CmplxRndExamples Fonts used: PSL096pro.ttf, PSL095pro.ttf, PSL094pro.ttf, PSL053pro.ttf, PSL052pro.ttf, PSL051pro.ttf, PSL050pro.ttf, etc.. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2356) default JAVA_HOME is not compatible with Oracle's JDK on Mac OS X
Gaëtan Lehmann created FOP-2356: --- Summary: default JAVA_HOME is not compatible with Oracle's JDK on Mac OS X Key: FOP-2356 URL: https://issues.apache.org/jira/browse/FOP-2356 Project: Fop Issue Type: Bug Affects Versions: 1.1, trunk Reporter: Gaëtan Lehmann fop uses a java path that was specific to Apple's java and is not compatible with Oracle's java. This problem has already been fixed in other tools - see http://svn.apache.org/viewvc/ant/core/trunk/src/script/ant?r1=1238725r2=1434680pathrev=1434680view=patch for example. The same patch can be applied as is to fop. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2354: --- Attachment: test.fo fop.xconf [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[
https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930252#comment-13930252
]
Vincent Hennebert commented on FOP-2354:
I have an ArrayIndexOutOfBoundsException when I use an accented character:
{noformat}
java.lang.ArrayIndexOutOfBoundsException: 225
at org.apache.fop.pdf.PDFFactory.makeFont(PDFFactory.java:1394)
at org.apache.fop.pdf.PDFResources.addFonts(PDFResources.java:121)
at
org.apache.fop.render.pdf.PDFDocumentHandler.endDocument(PDFDocumentHandler.java:181)
at
org.apache.fop.render.intermediate.util.IFDocumentHandlerProxy.endDocument(IFDocumentHandlerProxy.java:187)
at
org.apache.fop.render.intermediate.IFRenderer.stopRenderer(IFRenderer.java:294)
at
org.apache.fop.area.RenderPagesModel.endDocument(RenderPagesModel.java:265)
at
org.apache.fop.area.AreaTreeHandler.endDocument(AreaTreeHandler.java:342)
at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:169)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endDocument(TransformerIdentityImpl.java:962)
at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown
Source)
at org.apache.xerces.xinclude.XIncludeHandler.endDocument(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.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:285)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:177)
at org.apache.fop.cli.Main.main(Main.java:208)
{noformat}
[PATCH] Subset support for Type 1 fonts
---
Key: FOP-2354
URL: https://issues.apache.org/jira/browse/FOP-2354
Project: Fop
Issue Type: New Feature
Components: fonts
Affects Versions: trunk
Reporter: Robert Meyer
Assignee: Robert Meyer
Fix For: trunk
Attachments: c0419bt_.pfb, fop.xconf, patch.diff, test.fo
This patch adds subsetting support to Type 1 fonts. Currently the only two
supported output formats for this are PDF and Postscript.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [VOTE] Applying the Type 1 subset patch
Hi Rob, +1 from me. Good work. Thanks, Chris On 07/03/2014 11:23, Robert wrote: Hi All, About a week ago I posted a patch to add Type 1 subset support to FOP. All referenced Type 1 fonts (unless set to embedding-mode=full) will now be subset by default much like the behaviour exhibited by TrueType and OpenType. As this is a big feature and quite involved I think it is necessary to vote on whether to add this feature in it's current state to FOP. I'm not sure if anyone has taken a look at what has gone into this or tried it out yet, but it might be worth doing so before making your decision. I am going to be away for the next week or so but will tally up the votes and post the result once I am back. Here is a link to the patch and issue: https://issues.apache.org/jira/browse/FOP-2354 Regards, Robert Meyer
Re: [VOTE] Applying the Type 1 subset patch
On 07/03/14 12:23, Robert wrote: Hi All, About a week ago I posted a patch to add Type 1 subset support to FOP. All referenced Type 1 fonts (unless set to embedding-mode=full) will now be subset by default much like the behaviour exhibited by TrueType and OpenType. As this is a big feature and quite involved I think it is necessary to vote on whether to add this feature in it's current state to FOP. I'm not sure if anyone has taken a look at what has gone into this or tried it out yet, but it might be worth doing so before making your decision. I am going to be away for the next week or so but will tally up the votes and post the result once I am back. Here is a link to the patch and issue: https://issues.apache.org/jira/browse/FOP-2354 Regards, Robert Meyer From the quick look I had at the patch, I must say that some things are sources of concern to me: • The PostScript parser seems to be mixing lexical analysis, syntax analysis and interpretation. This makes it hard to follow and I could not figure out the meanings of the conditions in the various ‘if’ statements inside the ‘parse’ method. Also, part of the parsing seems to be leaking into Type1SubsetFile. I’m concerned about the robustness of the thing. For example, there are unguarded calls to Integer.parseInt. How tolerant will that be to malformed font files? • It seems that Type1SubsetFile tries to infer the mapping of character codes to glyph names. That essentially re-does what the mapChar method has already done earlier, with probable mismatch between the outputs of the two methods. In Type1SubsetFile.readEncoding I see references to the WinAnsi encoding, which may have nothing to do at all with the font’s own encoding. I suspect this is the source of the exception thrown when running the FO I attached to the issue. • there is a lot of memory allocation. First, the font is entirely loaded in memory in Type1SubsetFile.createSubset, then again in PFBParser, plus data copied around when creating the subset. Surely some of this memory allocation can be avoided. Have you profiled the code? How much more slow is it compared to fully embedding the font? Due to the possible regressions and the potential impact on performance, I must vote -1 against enabling Type 1 subsetting by default. If Type 1 subsetting is left as an option that can be manually configured by the user, then I vote +0. Vincent
[jira] [Commented] (FOP-2321) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931147#comment-13931147 ] Cédric Pronzato commented on FOP-2321: -- thank you for the bugfix, is your patch allow to generate the RTF or just not fall into NPE? [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Assignee: Robert Meyer Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(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:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(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
Re: [VOTE] Applying the Type 1 subset patch
Since apparently Macs have no type1 fonts I had to look for some and I tried the first one from http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bakoma (cmb10) which gave a problem: java.util.NoSuchElementException at java.util.Scanner.throwFor(Scanner.java:907) at java.util.Scanner.next(Scanner.java:1530) at java.util.Scanner.nextInt(Scanner.java:2160) at java.util.Scanner.nextInt(Scanner.java:2119) at org.apache.fop.fonts.type1.PostscriptParser$PSFixedArray.addEntry(PostscriptParser.java:379) at org.apache.fop.fonts.type1.PostscriptParser$PSFixedArray.parseToken(PostscriptParser.java:329) . So it seems this needs to be tested with more fonts. But I will test next in with the default Linux type1 fonts. On 3/7/14, 11:23 AM, Robert wrote: Hi All, About a week ago I posted a patch to add Type 1 subset support to FOP. All referenced Type 1 fonts (unless set to embedding-mode=full) will now be subset by default much like the behaviour exhibited by TrueType and OpenType. As this is a big feature and quite involved I think it is necessary to vote on whether to add this feature in it's current state to FOP. I'm not sure if anyone has taken a look at what has gone into this or tried it out yet, but it might be worth doing so before making your decision. I am going to be away for the next week or so but will tally up the votes and post the result once I am back. Here is a link to the patch and issue: https://issues.apache.org/jira/browse/FOP-2354 Regards, Robert Meyer
