[jira] [Commented] (FOP-3173) cannot include attachment whose name contains hash ('#') in the name
[
https://issues.apache.org/jira/browse/FOP-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837666#comment-17837666
]
Chris Bowditch commented on FOP-3173:
-
Based on the last comment and the description of this, this will be closed as
not a bug, # is not legal in a URI and must be encoded
> cannot include attachment whose name contains hash ('#') in the name
>
>
> Key: FOP-3173
> URL: https://issues.apache.org/jira/browse/FOP-3173
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.9
>Reporter: BlueMountain
>Priority: Major
> Attachments: PDFAttachmentTestCase.java
>
>
> hi,
> we are relying on the fop to generate PDF given data held in database + file
> storage.
> we need to represent some ( file.name, file.data) as a pdf embedded
> attachment.
> some users have encountered issue when the file.name value carries hash sign
> ('#')
> upon generating the pdf, an exception is thrown about missing attachment name.
> I have added a new test to the PDFAttachmentTestCase class (see attachment)
> to reproduce the issue.
> The added test that generates the error is:
> @Test
> public void testAddEmbeddedFileDash () throws IFException {
> PDFDocumentHandler docHandler = new PDFDocumentHandler(new IFContext(ua));
> docHandler.setFontInfo(new FontInfo());
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> docHandler.setResult(new StreamResult(out));
> docHandler.startDocument();
> docHandler.startPage(0, "", "", new Dimension());
> docHandler.handleExtensionObject(new
> PDFEmbeddedFileAttachment("filename#1.txt", "src", "desc"));
> // issue occurs at this line
> *docHandler.getDocumentNavigationHandler().renderLink(new Link(*
> *new URIAction("embedded-file:filename#1.txt", false), new Rectangle()));*
> docHandler.endDocument();
> }
>
> running the command:
> mvn test -pl fop-core -Dtest=PDFAttachmentTestCase
> I get the following output:
> Running org.apache.fop.pdf.PDFAttachmentTestCase
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.15 sec <<<
> FAILURE! - in org.apache.fop.pdf.PDFAttachmentTestCase
> testAddEmbeddedFileDash(org.apache.fop.pdf.PDFAttachmentTestCase) Time
> elapsed: 0.003 sec <<< ERROR!
> {*}java.lang.IllegalStateException: No embedded file with name filename
> present{*}.
> at org.apache.fop.pdf.PDFFactory.getActionForEmbeddedFile(PDFFactory.java:728)
> at org.apache.fop.pdf.PDFFactory.getExternalAction(PDFFactory.java:600)
> at
> org.apache.fop.render.pdf.PDFDocumentNavigationHandler.getAction(PDFDocumentNavigationHandler.java:174)
> at
> org.apache.fop.render.pdf.PDFDocumentNavigationHandler.renderLink(PDFDocumentNavigationHandler.java:108)
> at
> org.apache.fop.pdf.PDFAttachmentTestCase.testAddEmbeddedFileDash(PDFAttachmentTestCase.java:119)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FOP-3173) cannot include attachment whose name contains hash ('#') in the name
[
https://issues.apache.org/jira/browse/FOP-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch closed FOP-3173.
---
Resolution: Not A Bug
> cannot include attachment whose name contains hash ('#') in the name
>
>
> Key: FOP-3173
> URL: https://issues.apache.org/jira/browse/FOP-3173
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.9
>Reporter: BlueMountain
>Priority: Major
> Attachments: PDFAttachmentTestCase.java
>
>
> hi,
> we are relying on the fop to generate PDF given data held in database + file
> storage.
> we need to represent some ( file.name, file.data) as a pdf embedded
> attachment.
> some users have encountered issue when the file.name value carries hash sign
> ('#')
> upon generating the pdf, an exception is thrown about missing attachment name.
> I have added a new test to the PDFAttachmentTestCase class (see attachment)
> to reproduce the issue.
> The added test that generates the error is:
> @Test
> public void testAddEmbeddedFileDash () throws IFException {
> PDFDocumentHandler docHandler = new PDFDocumentHandler(new IFContext(ua));
> docHandler.setFontInfo(new FontInfo());
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> docHandler.setResult(new StreamResult(out));
> docHandler.startDocument();
> docHandler.startPage(0, "", "", new Dimension());
> docHandler.handleExtensionObject(new
> PDFEmbeddedFileAttachment("filename#1.txt", "src", "desc"));
> // issue occurs at this line
> *docHandler.getDocumentNavigationHandler().renderLink(new Link(*
> *new URIAction("embedded-file:filename#1.txt", false), new Rectangle()));*
> docHandler.endDocument();
> }
>
> running the command:
> mvn test -pl fop-core -Dtest=PDFAttachmentTestCase
> I get the following output:
> Running org.apache.fop.pdf.PDFAttachmentTestCase
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.15 sec <<<
> FAILURE! - in org.apache.fop.pdf.PDFAttachmentTestCase
> testAddEmbeddedFileDash(org.apache.fop.pdf.PDFAttachmentTestCase) Time
> elapsed: 0.003 sec <<< ERROR!
> {*}java.lang.IllegalStateException: No embedded file with name filename
> present{*}.
> at org.apache.fop.pdf.PDFFactory.getActionForEmbeddedFile(PDFFactory.java:728)
> at org.apache.fop.pdf.PDFFactory.getExternalAction(PDFFactory.java:600)
> at
> org.apache.fop.render.pdf.PDFDocumentNavigationHandler.getAction(PDFDocumentNavigationHandler.java:174)
> at
> org.apache.fop.render.pdf.PDFDocumentNavigationHandler.renderLink(PDFDocumentNavigationHandler.java:108)
> at
> org.apache.fop.pdf.PDFAttachmentTestCase.testAddEmbeddedFileDash(PDFAttachmentTestCase.java:119)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-2983) [PATCH] Font auto-detection doesn't work
[ https://issues.apache.org/jira/browse/FOP-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836620#comment-17836620 ] Chris Bowditch commented on FOP-2983: - Great, but there is already a potential fix attached to the ticket. What would be helpful in progressing this is clear step by step instructions on how to replicate the issue as its not currently clear and we need to be able to see the problem and confirm the proposed fix solve it > [PATCH] Font auto-detection doesn't work > > > Key: FOP-2983 > URL: https://issues.apache.org/jira/browse/FOP-2983 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.5, 2.6 > Environment: Apache Maven 3.6.0 > Java version: 1.8.0_181, vendor: Oracle Corporation > Default locale: ru_RU, platform encoding: Cp1251 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Sergey Gorbunov >Priority: Critical > Attachments: fonts-auto-detect.patch > > > When constructing a tree with a configuration, the node for auto-detection is > added to the wrong parent node. As a result, the flag remains with a false. > Detected when trying to convert SVG to PDF with Cyrillic characters. Since > the correct font was not detected automatically, incorrect characters were > displayed after conversion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807780#comment-17807780
]
Chris Bowditch commented on FOP-2522:
-
Ok so that's explains why they can't use ZWSP, but SHY still needs to be drawn
when it is actually used to hyphenate a word, and your patch always excludes it
from the output so I still don't think the patch is the correct solution.
Instead the logic around when the SHY is shown needs to be debugged to
understand why its not always working
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807306#comment-17807306
]
Chris Bowditch commented on FOP-2522:
-
What I meant to say is I don't think that excluding soft hyphen from the output
in ALL cases in a blanket fashion is the correct solution
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807305#comment-17807305
]
Chris Bowditch commented on FOP-2522:
-
The patch is very specific to soft hyphen, I'm not sure the proposed fix is
correct. Why does docbook use Soft Hyphen to provide break opportunities. I
think ZWSP would be a better fit for the purpose
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FOP-3143) PDF/A validation error
[ https://issues.apache.org/jira/browse/FOP-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3143. --- Resolution: Not A Bug > PDF/A validation error > -- > > Key: FOP-3143 > URL: https://issues.apache.org/jira/browse/FOP-3143 > Project: FOP > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: zouari >Priority: Major > Attachments: error.zip > > > When the PDF/A documents generated by FOP *with the font > embedding-mode="subset"* are validated for PDF/A conformance, I get this > error: > "The following font CIDSet data is not consistent with embedded font program: > EA+ArialMT" > to test pdf validation I use: > https://avepdf.com/fr/pdfa-validation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3143) PDF/A validation error
[ https://issues.apache.org/jira/browse/FOP-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757371#comment-17757371 ] Chris Bowditch commented on FOP-3143: - This isn't a bug! Its a requirement of PDF/A that all fonts are fully embedded. FOP allows either embedding mode you just need to configure full embedding when generating PDF/A. Please send questions to the mailing list rather than raising bugs in future. This will now be closed > PDF/A validation error > -- > > Key: FOP-3143 > URL: https://issues.apache.org/jira/browse/FOP-3143 > Project: FOP > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: zouari >Priority: Major > Attachments: error.zip > > > When the PDF/A documents generated by FOP *with the font > embedding-mode="subset"* are validated for PDF/A conformance, I get this > error: > "The following font CIDSet data is not consistent with embedded font program: > EA+ArialMT" > to test pdf validation I use: > https://avepdf.com/fr/pdfa-validation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FOP-3142) Fatal error when compiling large xsl templates
[
https://issues.apache.org/jira/browse/FOP-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch closed FOP-3142.
---
Resolution: Not A Bug
As mentioned in the previous comments, this is not a bug in FOP. We merely
stopped providing Xalan as part of the standard distribution and we now use the
one bundled with Java, or you can provide your own version if required
> Fatal error when compiling large xsl templates
> --
>
> Key: FOP-3142
> URL: https://issues.apache.org/jira/browse/FOP-3142
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Huy Ho
>Priority: Critical
>
> After we updated from FOP 2.6 to the latest FOP 2.8 version, our application
> is running into the following error when compiling our stylesheets (stack
> trace below). To get around this issue, we downloaded the latest xalan-j
> 2.7.3 library from [https://xalan.apache.org/xalan-j/index.html] and drop
> them in the fop/lib directory.
>
> {{java.lang.RuntimeException: XPATH_LIMIT}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseTopLevel(Parser.java:1165)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parseExpression(Parser.java:1112)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.VariableBase.parseContents(VariableBase.java:250)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Param.parseContents(Param.java:106)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Import.parseContents(Import.java:132)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:597)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:398)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:496)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:576)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:1018)}}
> {{ at
> java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:817)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:274)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
>
> {{ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an
> accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with
> an accumulated '10,001' operators that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.'}}
> {{[ERROR] FOP - Exception javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by
> 'FEATURE_SECURE_PROCESSING'.>org.apache.fop.apps.FOPException:
> javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{javax.xml.transform.TransformerConfigurationException: JAXP0801003: the
> compiler encountered XPath expressions with an accumulated '10,001' operators
> that exceeds the '10,000' limit set by 'FEATURE_SECURE_PROCESSING'.}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: javax.xml.transform.TransformerConfigurationException:
> JAXP0801003: the compiler encountered XPath expressions with an accumulated
[jira] [Commented] (FOP-3134) Long table footer overflows the page
[ https://issues.apache.org/jira/browse/FOP-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737695#comment-17737695 ] Chris Bowditch commented on FOP-3134: - XSL-FO dictates that table footers are repeated on every page. How is that possible when the footer is using 90% of the available space? I think this requirement is contradictory with the XSL-FO spec, which seems to imply/expect table footers will be small relative to the overall page height > Long table footer overflows the page > > > Key: FOP-3134 > URL: https://issues.apache.org/jira/browse/FOP-3134 > Project: FOP > Issue Type: Bug >Affects Versions: 2.5, 2.6, 2.8 >Reporter: Alexander Dyuzhev >Priority: Major > Attachments: image-2023-06-15-20-02-26-537.png, > image-2023-06-15-20-08-39-315.png, long_table_footer.fix.fo, > long_table_footer.fo, long_table_footer.pdf, long_table_footer_fix.pdf > > > I have a simple XSL-FO with the table with multi rows footer - > [^long_table_footer.fo] > The resulted PDF [^long_table_footer.pdf] is wrong: > - big empty space on the 1st page > - table footer doesn't fit to the 2nd page > !image-2023-06-15-20-02-26-537.png! > To fix it _visually_ I can move the long table footer into the separate table > [^long_table_footer.fix.fo], and the resulted PDF > [^long_table_footer_fix.pdf] looks as expected: > !image-2023-06-15-20-08-39-315.png! > BUT I have to generate the PDF/UA with the structure tags tree, and the table > should be one with footer. > The links to the issues: > * > [https://stackoverflow.com/questions/41625388/table-footer-doesnt-page-break-using-apache-fop] > * > [https://github.com/metanorma/metanorma-iso/issues/1001#issuecomment-1593341473] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3127) Allow XMP at PDF page level
[ https://issues.apache.org/jira/browse/FOP-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-3127: Issue Type: Improvement (was: Bug) > Allow XMP at PDF page level > --- > > Key: FOP-3127 > URL: https://issues.apache.org/jira/browse/FOP-3127 > Project: FOP > Issue Type: Improvement >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FOP-3100) openinig xls file whit web dependency
[ https://issues.apache.org/jira/browse/FOP-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3100. --- Resolution: Cannot Reproduce Closing as unable to reproduce based on Dave's feedback > openinig xls file whit web dependency > - > > Key: FOP-3100 > URL: https://issues.apache.org/jira/browse/FOP-3100 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: 2.7 > Environment: Kubuntu 22.04 > Netbeans 15 > Java 1.8.0_322 OpenJDK 64-Bit >Reporter: Martin Pejchar >Priority: Minor > Attachments: print-chybova_hlaseni.xsl > > > I was trying to modify XML2PDF example code to load custom xsl but loading > crashed on line > href="http://docbook.sourceforge.net/release/xsl-ns/current/fo/profile-docbook.xsl"/> > whit error > [Fatal Error] :-1:-1: Premature end of file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FOP-3122) the pdf does not continue the "outlines"
[ https://issues.apache.org/jira/browse/FOP-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3122. --- Resolution: Cannot Reproduce Insufficient information as per Dave's comment. Re-open if you can clarify the issue > the pdf does not continue the "outlines" > > > Key: FOP-3122 > URL: https://issues.apache.org/jira/browse/FOP-3122 > Project: FOP > Issue Type: Bug >Affects Versions: 2.8 >Reporter: zouari >Priority: Major > Attachments: bookmarks.pdf, outlines.png, result.pdf, test.fo > > > the document external-document contains the "outlines"but the final document > "result.pdf" does not contain the "outlines". > here is my FO file "test.fo" and the external document "bookmarks.pdf". > Can you help me please. > THANKS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699567#comment-17699567
]
Chris Bowditch commented on FOP-3098:
-
This has been committed in 2a73338d3424e9907b46a19f2288d61c9f885006
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: main
>
> Attachments: Post-FOP-3098-NPE-Bugfix.diff, patch.txt,
> patch_cached.txt, stacktrace.txt, x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698818#comment-17698818
]
Chris Bowditch commented on FOP-3098:
-
[~jeremias] long time no speak. Good to see you here :)
Thanks for the patch and Unit test
As others mentioned we recently moved FOP to Github, so you'll need to get
setup there if you plan on still working with FOP. Might be idea to get it
setup and commit this patch yourself. If you don't get the chance, I'll do it
later if I get time
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: main
>
> Attachments: Post-FOP-3098-NPE-Bugfix.diff, patch.txt,
> patch_cached.txt, stacktrace.txt, x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-3098:
Fix Version/s: trunk
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
> Attachments: Post-FOP-3098-NPE-Bugfix.diff, patch.txt,
> patch_cached.txt, stacktrace.txt, x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch resolved FOP-3098.
-
Resolution: Fixed
fix committed to main branch
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: Post-FOP-3098-NPE-Bugfix.diff, patch.txt,
> patch_cached.txt, stacktrace.txt, x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FOP-3098 started by Chris Bowditch.
---
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: patch.txt, patch_cached.txt, stacktrace.txt,
> x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch reassigned FOP-3098:
---
Assignee: Chris Bowditch
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: patch.txt, patch_cached.txt, stacktrace.txt,
> x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695752#comment-17695752
]
Chris Bowditch commented on FOP-3098:
-
Thanks for the submission Dave. Since you are adding a new file can you
complete the ICLA and send it to the Apache Secretary?
[https://www.apache.org/licenses/icla.pdf] I'll then get this committed. Thanks
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Priority: Major
> Attachments: patch.txt, patch_cached.txt, stacktrace.txt,
> x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FOP-3119) the external document is not identical
[ https://issues.apache.org/jira/browse/FOP-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3119. --- Resolution: Cannot Reproduce Insufficient information to replicate. Feel free to re-open if more information is provided > the external document is not identical > -- > > Key: FOP-3119 > URL: https://issues.apache.org/jira/browse/FOP-3119 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: zouari >Priority: Major > Attachments: new.JPG, new.pdf, original.JPG, test.fo > > > when i used fop 2.4 to create a pdf document,I noticed that the external > document is not identical. > the "AcroForm" dictionary is not the same. > you know why? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3098) [PATCH] Nullpointer Exception in LMiter.next depending on text
[
https://issues.apache.org/jira/browse/FOP-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-3098:
Summary: [PATCH] Nullpointer Exception in LMiter.next depending on text
(was: Nullpointer Exception in LMiter.next depending on text)
> [PATCH] Nullpointer Exception in LMiter.next depending on text
> --
>
> Key: FOP-3098
> URL: https://issues.apache.org/jira/browse/FOP-3098
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
> Environment: Windows 10
>Reporter: Michael Heitkamp
>Priority: Major
> Attachments: patch.txt, patch_cached.txt, stacktrace.txt,
> x-fop-error.xml, x-fop-error.xsl
>
>
> Doing a FOP translation with the given XSL and XML input files lead to a
> Nullpointer Exception.
> If the text block is shortened by one character ("dataX" -> "data") then the
> translation succeeds.
> If the text block is replaced by "lore ipsum" of the same length then the
> translation succeeds also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3077. --- Resolution: Not A Bug Closing as Not a bug, based on Simon's comment that this is a bug in the version of the font being used not in FOP itself > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_NotoSans-Regular.png, j_with_acute_NotoSansMono-Regular-1.png, > j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-2865) [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
[
https://issues.apache.org/jira/browse/FOP-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch resolved FOP-2865.
-
Fix Version/s: trunk
Resolution: Fixed
committed fix in revision 1901463
> [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
>
>
> Key: FOP-2865
> URL: https://issues.apache.org/jira/browse/FOP-2865
> Project: FOP
> Issue Type: Bug
>Reporter: Abdul Vazid
>Assignee: Chris Bowditch
>Priority: Major
> Labels: fop
> Fix For: trunk
>
> Attachments: FOP-2865.fo, FOP-2865.patch
>
>
> I am upgrading batik-1.7 to 1.11 and fop-0.94 to 2.2. I am using
> PDFTranscoder of fop to convert SVG to PDF in my application. stroke-opacity
> is applied to text in svg. Before upgrading pdf looks good and result is as
> expected with opacity. But after upgrading stroke-opacity is not being
> applied to text.
> *Below is the code used to convert svg to pdf:*
> {code:java}
> Transcoder transcoder = new PDFTranscoder();
> TranscoderInput input = new TranscoderInput(svgFile.toURI().toString());
> ByteArrayOutputStream outStream = new ByteArrayOutputStream();
> TranscoderOutput output = new TranscoderOutput(outStream);
> transcoder.transcode(input, output);{code}
>
> *SVG Used:*
> {noformat}
>
> http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink; height="418" viewBox="0,0
> 65416,45424" width="816" xml:space="preserve">
>
> .P{
> font-family:"Arial";
> font-weight:normal;
> font-size:247px;
> font-family:"Lucida Sans";
> font-style:normal;
> stroke:#000;
> stroke-width:16px;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:0.5px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:none;
> fill-opacity:0.0;
> fill-rule:evenodd;
> }
> .M{
> font-family:"Arial";
> font-weight:normal;
> font-size:282px;
> font-style:normal;
> stroke:#00F;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:2px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:#00F;
> fill-rule:evenodd;
> fill-opacity:1.0;
> }
> .dimmed{
> stroke-opacity:1.0;
> fill-opacity:0.0;
> }
> ]]>
>
>
>
> d="M7964,25320h5669m-5669,0v1905m0,-1401h5669m-5669,467h5669m-5669,467h5669m-5669,467h5669m-4968,-1401v1401m934,-1401v1401m785,-1401v1401m743,-1401v1401m1295,-1401v1401m1210,-1905v1905"/>
> CONN3
> Cav.
>
>
>
> {noformat}
> {{Stroke-opacity in "dimmed" class is not showing any effect on the text
> "CONN3" after upgrading batik and fop.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-2865) [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
[
https://issues.apache.org/jira/browse/FOP-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544371#comment-17544371
]
Chris Bowditch commented on FOP-2865:
-
The test case as cited doesn't make any sense as stroke-opacity: 1.0 is the
default. I can only observe the bug by changing stroke-opacity to 0.1
> [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
>
>
> Key: FOP-2865
> URL: https://issues.apache.org/jira/browse/FOP-2865
> Project: FOP
> Issue Type: Bug
>Reporter: Abdul Vazid
>Assignee: Chris Bowditch
>Priority: Major
> Labels: fop
> Attachments: FOP-2865.fo, FOP-2865.patch
>
>
> I am upgrading batik-1.7 to 1.11 and fop-0.94 to 2.2. I am using
> PDFTranscoder of fop to convert SVG to PDF in my application. stroke-opacity
> is applied to text in svg. Before upgrading pdf looks good and result is as
> expected with opacity. But after upgrading stroke-opacity is not being
> applied to text.
> *Below is the code used to convert svg to pdf:*
> {code:java}
> Transcoder transcoder = new PDFTranscoder();
> TranscoderInput input = new TranscoderInput(svgFile.toURI().toString());
> ByteArrayOutputStream outStream = new ByteArrayOutputStream();
> TranscoderOutput output = new TranscoderOutput(outStream);
> transcoder.transcode(input, output);{code}
>
> *SVG Used:*
> {noformat}
>
> http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink; height="418" viewBox="0,0
> 65416,45424" width="816" xml:space="preserve">
>
> .P{
> font-family:"Arial";
> font-weight:normal;
> font-size:247px;
> font-family:"Lucida Sans";
> font-style:normal;
> stroke:#000;
> stroke-width:16px;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:0.5px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:none;
> fill-opacity:0.0;
> fill-rule:evenodd;
> }
> .M{
> font-family:"Arial";
> font-weight:normal;
> font-size:282px;
> font-style:normal;
> stroke:#00F;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:2px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:#00F;
> fill-rule:evenodd;
> fill-opacity:1.0;
> }
> .dimmed{
> stroke-opacity:1.0;
> fill-opacity:0.0;
> }
> ]]>
>
>
>
> d="M7964,25320h5669m-5669,0v1905m0,-1401h5669m-5669,467h5669m-5669,467h5669m-5669,467h5669m-4968,-1401v1401m934,-1401v1401m785,-1401v1401m743,-1401v1401m1295,-1401v1401m1210,-1905v1905"/>
> CONN3
> Cav.
>
>
>
> {noformat}
> {{Stroke-opacity in "dimmed" class is not showing any effect on the text
> "CONN3" after upgrading batik and fop.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (FOP-2865) [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
[
https://issues.apache.org/jira/browse/FOP-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-2865:
Attachment: FOP-2865.patch
> [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
>
>
> Key: FOP-2865
> URL: https://issues.apache.org/jira/browse/FOP-2865
> Project: FOP
> Issue Type: Bug
>Reporter: Abdul Vazid
>Assignee: Chris Bowditch
>Priority: Major
> Labels: fop
> Attachments: FOP-2865.fo, FOP-2865.patch
>
>
> I am upgrading batik-1.7 to 1.11 and fop-0.94 to 2.2. I am using
> PDFTranscoder of fop to convert SVG to PDF in my application. stroke-opacity
> is applied to text in svg. Before upgrading pdf looks good and result is as
> expected with opacity. But after upgrading stroke-opacity is not being
> applied to text.
> *Below is the code used to convert svg to pdf:*
> {code:java}
> Transcoder transcoder = new PDFTranscoder();
> TranscoderInput input = new TranscoderInput(svgFile.toURI().toString());
> ByteArrayOutputStream outStream = new ByteArrayOutputStream();
> TranscoderOutput output = new TranscoderOutput(outStream);
> transcoder.transcode(input, output);{code}
>
> *SVG Used:*
> {noformat}
>
> http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink; height="418" viewBox="0,0
> 65416,45424" width="816" xml:space="preserve">
>
> .P{
> font-family:"Arial";
> font-weight:normal;
> font-size:247px;
> font-family:"Lucida Sans";
> font-style:normal;
> stroke:#000;
> stroke-width:16px;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:0.5px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:none;
> fill-opacity:0.0;
> fill-rule:evenodd;
> }
> .M{
> font-family:"Arial";
> font-weight:normal;
> font-size:282px;
> font-style:normal;
> stroke:#00F;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:2px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:#00F;
> fill-rule:evenodd;
> fill-opacity:1.0;
> }
> .dimmed{
> stroke-opacity:1.0;
> fill-opacity:0.0;
> }
> ]]>
>
>
>
> d="M7964,25320h5669m-5669,0v1905m0,-1401h5669m-5669,467h5669m-5669,467h5669m-5669,467h5669m-4968,-1401v1401m934,-1401v1401m785,-1401v1401m743,-1401v1401m1295,-1401v1401m1210,-1905v1905"/>
> CONN3
> Cav.
>
>
>
> {noformat}
> {{Stroke-opacity in "dimmed" class is not showing any effect on the text
> "CONN3" after upgrading batik and fop.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (FOP-2865) [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
[
https://issues.apache.org/jira/browse/FOP-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch reassigned FOP-2865:
---
Assignee: Chris Bowditch
> [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
>
>
> Key: FOP-2865
> URL: https://issues.apache.org/jira/browse/FOP-2865
> Project: FOP
> Issue Type: Bug
>Reporter: Abdul Vazid
>Assignee: Chris Bowditch
>Priority: Major
> Labels: fop
> Attachments: FOP-2865.fo, FOP-2865.patch
>
>
> I am upgrading batik-1.7 to 1.11 and fop-0.94 to 2.2. I am using
> PDFTranscoder of fop to convert SVG to PDF in my application. stroke-opacity
> is applied to text in svg. Before upgrading pdf looks good and result is as
> expected with opacity. But after upgrading stroke-opacity is not being
> applied to text.
> *Below is the code used to convert svg to pdf:*
> {code:java}
> Transcoder transcoder = new PDFTranscoder();
> TranscoderInput input = new TranscoderInput(svgFile.toURI().toString());
> ByteArrayOutputStream outStream = new ByteArrayOutputStream();
> TranscoderOutput output = new TranscoderOutput(outStream);
> transcoder.transcode(input, output);{code}
>
> *SVG Used:*
> {noformat}
>
> http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink; height="418" viewBox="0,0
> 65416,45424" width="816" xml:space="preserve">
>
> .P{
> font-family:"Arial";
> font-weight:normal;
> font-size:247px;
> font-family:"Lucida Sans";
> font-style:normal;
> stroke:#000;
> stroke-width:16px;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:0.5px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:none;
> fill-opacity:0.0;
> fill-rule:evenodd;
> }
> .M{
> font-family:"Arial";
> font-weight:normal;
> font-size:282px;
> font-style:normal;
> stroke:#00F;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:2px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:#00F;
> fill-rule:evenodd;
> fill-opacity:1.0;
> }
> .dimmed{
> stroke-opacity:1.0;
> fill-opacity:0.0;
> }
> ]]>
>
>
>
> d="M7964,25320h5669m-5669,0v1905m0,-1401h5669m-5669,467h5669m-5669,467h5669m-5669,467h5669m-4968,-1401v1401m934,-1401v1401m785,-1401v1401m743,-1401v1401m1295,-1401v1401m1210,-1905v1905"/>
> CONN3
> Cav.
>
>
>
> {noformat}
> {{Stroke-opacity in "dimmed" class is not showing any effect on the text
> "CONN3" after upgrading batik and fop.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (FOP-2865) [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
[
https://issues.apache.org/jira/browse/FOP-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-2865:
Attachment: FOP-2865.fo
> [PATCH] stroke-opacity is not honored on svg:text while conveting svg to pdf
>
>
> Key: FOP-2865
> URL: https://issues.apache.org/jira/browse/FOP-2865
> Project: FOP
> Issue Type: Bug
>Reporter: Abdul Vazid
>Assignee: Chris Bowditch
>Priority: Major
> Labels: fop
> Attachments: FOP-2865.fo, FOP-2865.patch
>
>
> I am upgrading batik-1.7 to 1.11 and fop-0.94 to 2.2. I am using
> PDFTranscoder of fop to convert SVG to PDF in my application. stroke-opacity
> is applied to text in svg. Before upgrading pdf looks good and result is as
> expected with opacity. But after upgrading stroke-opacity is not being
> applied to text.
> *Below is the code used to convert svg to pdf:*
> {code:java}
> Transcoder transcoder = new PDFTranscoder();
> TranscoderInput input = new TranscoderInput(svgFile.toURI().toString());
> ByteArrayOutputStream outStream = new ByteArrayOutputStream();
> TranscoderOutput output = new TranscoderOutput(outStream);
> transcoder.transcode(input, output);{code}
>
> *SVG Used:*
> {noformat}
>
> http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink; height="418" viewBox="0,0
> 65416,45424" width="816" xml:space="preserve">
>
> .P{
> font-family:"Arial";
> font-weight:normal;
> font-size:247px;
> font-family:"Lucida Sans";
> font-style:normal;
> stroke:#000;
> stroke-width:16px;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:0.5px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:none;
> fill-opacity:0.0;
> fill-rule:evenodd;
> }
> .M{
> font-family:"Arial";
> font-weight:normal;
> font-size:282px;
> font-style:normal;
> stroke:#00F;
> stroke-dasharray:none;
> stroke-linejoin:miter;
> stroke-miterlimit:10;
> stroke-width:2px;
> stroke-linecap:square;
> stroke-opacity:1.0;
> fill:#00F;
> fill-rule:evenodd;
> fill-opacity:1.0;
> }
> .dimmed{
> stroke-opacity:1.0;
> fill-opacity:0.0;
> }
> ]]>
>
>
>
> d="M7964,25320h5669m-5669,0v1905m0,-1401h5669m-5669,467h5669m-5669,467h5669m-5669,467h5669m-4968,-1401v1401m934,-1401v1401m785,-1401v1401m743,-1401v1401m1295,-1401v1401m1210,-1905v1905"/>
> CONN3
> Cav.
>
>
>
> {noformat}
> {{Stroke-opacity in "dimmed" class is not showing any effect on the text
> "CONN3" after upgrading batik and fop.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (FOP-3012) Using Various Fonts to Achieve Multiple Languages Sometimes Results in Errors
[ https://issues.apache.org/jira/browse/FOP-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-3012. --- Resolution: Duplicate Closing as a Duplicate of FOP-2977 > Using Various Fonts to Achieve Multiple Languages Sometimes Results in Errors > - > > Key: FOP-3012 > URL: https://issues.apache.org/jira/browse/FOP-3012 > Project: FOP > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Martin Furek >Priority: Major > > Reporting this bug based on: > [http://apache-fop.1065347.n5.nabble.com/Using-Various-Fonts-to-Achieve-Multiple-Languages-Sometimes-Results-in-Errors-td47985.html] > > Example: > [https://drive.google.com/file/d/1QUDI31mUmkqvSrSWdoCkI2taGYd8teu6/view?usp=sharing] > I am using multiple fonts SansSerif,NotoSans,NotoSansCJK,Symbola to > get Chinese, Greek and Emoji characters. I need to support multiple > languages with mixed text (latin in Chinese and other way around). I > never know beforehand where the text is. This works with multiple > fonts, but sometimes throws an error: > java.lang.ArrayIndexOutOfBoundsException: Index 13 out of bounds for length 13 > at > org.apache.fop.fonts.GlyphMapping.processWordMapping(GlyphMapping.java:172) > at org.apache.fop.fonts.GlyphMapping.doGlyphMapping(GlyphMapping.java:92) > at > org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:960) > at > org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:819) > at > org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:698) > at > org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:627) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:292) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223) > at > org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:148) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69) > at > org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252) > at > org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:675) > at > org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:179) > at > org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:159) > at > org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:385) > at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:113) > at > org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:143) > at > org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267) > at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:139) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:362) > at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190) > at > org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) > 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:485) > at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:293) > at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116) > at org.apache.fop.cli.Main.startFOP(Main.java:183) > at org.apache.fop.cli.Main.main(Main.java:214) -- This
[jira] [Commented] (FOP-3060) Line breaks differences
[ https://issues.apache.org/jira/browse/FOP-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518247#comment-17518247 ] Chris Bowditch commented on FOP-3060: - I think the bug reporter is expecting line breaking to follow first fit approach like most word processors, but FOP uses a total fit algorithm, so yes the line breaking will be different when the text of the paragraph or its alignment is altered. That is not a bug but by design > Line breaks differences > --- > > Key: FOP-3060 > URL: https://issues.apache.org/jira/browse/FOP-3060 > Project: FOP > Issue Type: Bug > Components: layout/unqualified >Affects Versions: 2.6 > Environment: OS: Windows , >Reporter: Maria >Priority: Major > Attachments: Test.fo > > > Hello, > There are differences in line breaks in pdf between small and large > paragraphs of same text. > Case 1: If the text in the paragraph is cut to three lines long, line breaks > are at one position but if the same text is left to ten or more lines, line > breaks for the same first three lines are not at the same position. > Case 2: Also if nine lines long text is cut to eight lines long text, there > is a difference in line breaks from line two onwards in comparison to the > original text. > The fo file used for this two test cases is attached. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FOP-3059) Open JDK 11 with FOP fail on transform to PDF
[ https://issues.apache.org/jira/browse/FOP-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513264#comment-17513264 ] Chris Bowditch commented on FOP-3059: - Do you have the full stack trace of the exception? Looks like the bug is with Saxon and not FOP. I use FOP with openJDK 11 without issues > Open JDK 11 with FOP fail on transform to PDF > - > > Key: FOP-3059 > URL: https://issues.apache.org/jira/browse/FOP-3059 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6 >Reporter: Yakir Goaron >Priority: Critical > > When using FOP with SAX factory on open JDK 11 there is an error when calling > the transform from java code. > The following error shows : > Class org.apache.fop.fo.FOTreeBuilder does not implement the requested > interface org.xml.sax.ContentHandler > Although the FOTreeBuilder implement the interface it seems that due too the > java version it is incompatible. > For now I have tried with FOP 2.4 and FOP 2.6 . -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FOP-2991) Table/Cell width is not adjusted properly on a page break when body width changes
[ https://issues.apache.org/jira/browse/FOP-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501380#comment-17501380 ] Chris Bowditch commented on FOP-2991: - Thanks [~jagruti.fr...@gmail.com] I agree, I have moved this bug to an Improvement instead > Table/Cell width is not adjusted properly on a page break when body width > changes > - > > Key: FOP-2991 > URL: https://issues.apache.org/jira/browse/FOP-2991 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Eugene >Priority: Major > Attachments: Expected-TableOnPageBreakWithChangingBodyWidth.png, > TableOnPageBreakWithChangingBodyWidth.pdf, > TableOnPageBreakWithChangingBodyWidth2.fo > > > Table & cells width should be adjusted per column-width ratio when table is > split between pages with varying body width. Sample FO with PDF generated and > expected output screenshot is attached. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FOP-2991) Table/Cell width is not adjusted properly on a page break when body width changes
[ https://issues.apache.org/jira/browse/FOP-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2991: Issue Type: Improvement (was: Bug) > Table/Cell width is not adjusted properly on a page break when body width > changes > - > > Key: FOP-2991 > URL: https://issues.apache.org/jira/browse/FOP-2991 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Eugene >Priority: Major > Attachments: Expected-TableOnPageBreakWithChangingBodyWidth.png, > TableOnPageBreakWithChangingBodyWidth.pdf, > TableOnPageBreakWithChangingBodyWidth2.fo > > > Table & cells width should be adjusted per column-width ratio when table is > split between pages with varying body width. Sample FO with PDF generated and > expected output screenshot is attached. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (FOP-2839) FOP Extensions: Named destination link not working
[
https://issues.apache.org/jira/browse/FOP-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472835#comment-17472835
]
Chris Bowditch edited comment on FOP-2839 at 1/11/22, 3:45 PM:
---
I have seen the same thing when using Acrobat Reader DC, but Chrome PDF Viewer
seems to work fine, so seems to be a quirk with Acrobat Reader
was (Author: cbowditch):
I have seen the same thing when using Acrobat Reader DC, bt Chrome PDF Viewer
seems to work fine, so seems to be a quirk with Acrobat Reader
> FOP Extensions: Named destination link not working
> --
>
> Key: FOP-2839
> URL: https://issues.apache.org/jira/browse/FOP-2839
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.2, 2.6
> Environment: Windows 10
>Reporter: Nadine Ausländer
>Priority: Major
> Attachments: sourceDoc.fo, targetDoc.fo
>
>
> h3. Summary
> Given is a link from Doc A to a named destination in Doc B. Since FOP 2.2 a
> fox:destination in Doc B does not work anymore as the link target in PDF
> output using Adobe Acrobat Reader DC. Same issue observed in FOP 2.3.
> h3. Observed behavior
> When following the link in Doc A, the first page of Doc B is displayed.
> h3. Expected behavior
> When following the link in Doc A, Doc B is opened at the named destination.
> h3. Test documents
> Test documents also attached.
> Doc A: sourceDoc.fo:
> {code:java}
>show-destination="new" text-decoration="underline"
> color="#0099D4"
> external-destination="url(targetDoc.pdf#dest=target)">
> Link to external PDF with anchor
>
> {code}
> Doc B: targetDoc.fo
> {code:java}
> Target
> Anchor
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (FOP-2839) FOP Extensions: Named destination link not working
[
https://issues.apache.org/jira/browse/FOP-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472835#comment-17472835
]
Chris Bowditch commented on FOP-2839:
-
I have seen the same thing when using Acrobat Reader DC, bt Chrome PDF Viewer
seems to work fine, so seems to be a quirk with Acrobat Reader
> FOP Extensions: Named destination link not working
> --
>
> Key: FOP-2839
> URL: https://issues.apache.org/jira/browse/FOP-2839
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.2, 2.6
> Environment: Windows 10
>Reporter: Nadine Ausländer
>Priority: Major
> Attachments: sourceDoc.fo, targetDoc.fo
>
>
> h3. Summary
> Given is a link from Doc A to a named destination in Doc B. Since FOP 2.2 a
> fox:destination in Doc B does not work anymore as the link target in PDF
> output using Adobe Acrobat Reader DC. Same issue observed in FOP 2.3.
> h3. Observed behavior
> When following the link in Doc A, the first page of Doc B is displayed.
> h3. Expected behavior
> When following the link in Doc A, Doc B is opened at the named destination.
> h3. Test documents
> Test documents also attached.
> Doc A: sourceDoc.fo:
> {code:java}
>show-destination="new" text-decoration="underline"
> color="#0099D4"
> external-destination="url(targetDoc.pdf#dest=target)">
> Link to external PDF with anchor
>
> {code}
> Doc B: targetDoc.fo
> {code:java}
> Target
> Anchor
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (FOP-3035) NPE on combination of ZWSP, NBSP and
[
https://issues.apache.org/jira/browse/FOP-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch reassigned FOP-3035:
---
Assignee: J Frank
> NPE on combination of ZWSP, NBSP and
>
>
> Key: FOP-3035
> URL: https://issues.apache.org/jira/browse/FOP-3035
> Project: FOP
> Issue Type: Bug
> Components: renderer/pdf
>Affects Versions: 2.6
> Environment: Linux SLES 11 running on Intel x86_64
>Reporter: Paul Katz
>Assignee: J Frank
>Priority: Minor
> Attachments: bad.fo, fop-config.xml, fop.log
>
>
> The following line in my XSL:FO reliably causes a NPE when generating a PDF:
>
> {code:java}
> x {code}
> Removing any single element of this line makes the NPE go away:
>
> * The outer
> * {{The Zero-Width Space}}
> * The inner
> * The Non-Breaking Space
> * The "x" text
> (My actual document has more content within the outer ; I just
> removed everything else to provide the minimum content needed to reproduce
> the NPE.)
> The NPE is reported as:
>
> {code:java}
> SEVERE: Exception
> org.apache.fop.apps.FOPException
> java.lang.NullPointerException
> at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)
> at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)
> at org.apache.fop.cli.Main.startFOP(Main.java:183)
> at org.apache.fop.cli.Main.main(Main.java:214)
> Caused by: java.lang.NullPointerException
> ... {code}
>
> The complete FOP output is attached as fop.log.
> The complete input XSL:F0 is attached as bad.fo. The line of interest is near
> the bottom of the file. I have placed a comment above it listing several
> variations of the line with each element removed one at a time. Any of those
> alternatives prevents the NPE from occurring.
> My command line is:
>
> {noformat}
> fop/fop-2.6/fop/fop -c WD/fop-config.xml -fo bad.fo bad.pdf 2>&1 | tee
> fop.log{noformat}
> My FOP config file is attached as fop-config.xml.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (FOP-1798) [PATCH] Empty fo:inline objects with id attribute generate blank line
[ https://issues.apache.org/jira/browse/FOP-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1798. --- Resolution: Won't Fix See previous comment from Jagruti. This isn't actually a bug. Other issue found by Andreas has unwanted side effects, so I'm not sure we should implement especially considering no one actually reported that > [PATCH] Empty fo:inline objects with id attribute generate blank line > - > > Key: FOP-1798 > URL: https://issues.apache.org/jira/browse/FOP-1798 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: 0.95 > Environment: Operating System: All > Platform: PC >Reporter: Dwayne B. > Attachments: h13-623-Exam-Dumps-2019.pdf, inline-test-cases.zip, > patch.diff > > > As per the summary, fo:inline objects with no content and an id attribute > (e.g. ) will render a blank space; this should not > occur. Please see the example test cases and the PDFs generated by Apache FOP > 0.95 that are in the attached zip file. > I am fairly certain this is related to the resolution of this bug: > https://issues.apache.org/bugzilla/show_bug.cgi?id=42748 and this revision: > http://svn.apache.org/viewvc?view=revision=591437 > Thanks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440560#comment-17440560
]
Chris Bowditch commented on FOP-2522:
-
I would add that you'll increase the chances of the patch being applied if you
also attach a test XSL-FO file that demos the issue
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440557#comment-17440557
]
Chris Bowditch commented on FOP-2522:
-
Sorry I've not had a chance to look at this recently
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (FOP-2899) Setting a background-color let border vanish
[ https://issues.apache.org/jira/browse/FOP-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2899. --- Resolution: Not A Bug > Setting a background-color let border vanish > > > Key: FOP-2899 > URL: https://issues.apache.org/jira/browse/FOP-2899 > Project: FOP > Issue Type: Bug > Components: fo/block >Affects Versions: 2.4 >Reporter: Svante Schubert >Assignee: J Frank >Priority: Major > Attachments: UBL-Invoice-2.0-Example_backgroundColor.fo, > UBL-Invoice-2.0-Example_backgroundColor.pdf, > UBL-Invoice-2.0-Example_backgroundColor_indent.fo, > UBL-Invoice-2.0-Example_noBackground.fo, > UBL-Invoice-2.0-Example_noBackground.pdf, > UBL-Invoice-2.0-Example_noBackground_indent.fo, output Border color > black.pdf, output- border color same color as that of background.pdf, > output_Border color Red.pdf, test.fo > > > As soon a background-color is being added to cells the cell border is > vanishing as it seems to use the same color as the background. > I have attached two versions of a document, one with and the other without > background colour as PDF and FO (indent and without indent). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-3004) Invalid TTC file causes NullPointerException
[
https://issues.apache.org/jira/browse/FOP-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302332#comment-17302332
]
Chris Bowditch commented on FOP-3004:
-
Thanks for the patch. I don't suppose you can share the broken TTC File? Or
name it so I can download it?
> Invalid TTC file causes NullPointerException
>
>
> Key: FOP-3004
> URL: https://issues.apache.org/jira/browse/FOP-3004
> Project: FOP
> Issue Type: Bug
> Components: font/opentype, font/unqualified
>Affects Versions: trunk
>Reporter: Kelly H Wilkerson
>Priority: Minor
> Attachments: ttcIssue.diff
>
>
> A broken TTC on a customer's Windows 10 machine caused a NPE.
> {code:java}
> org.apache.fop.fonts.truetype.OpenFont.getTTCnames(){code}
> returns null (after logging SEVERE: Not a TTC!) and then
> {code:java}
> org.apache.fop.fonts.autodetect.FontInfoFinder.find()
> {code}
> doesn't check the result before iterating on it. But a quick null check on
> ttcNames fixes the issue. (diff attached.)
> Here's the stack trace with the logging right before as well.
> {code:java}
> WARNING: Unable to load font file:
> file:/C:/Windows/servicing/LCU/Package_for_RollupFix~31bf3856ad364e35~amd64~~18362.1016.1.5/amd64_microsoft-windows-ecapp.appxmain_31bf3856ad364e35_10.0.18362.997_none_52b446c91de63187/r/ecmdl2.ttf.
> Reason: java.io.EOFException: Reached EOF, file size=52
> Mar 10, 2021 5:08:12 PM org.apache.fop.fonts.truetype.OpenFont getTTCnames
> SEVERE: Not a TTC!
> java.lang.NullPointerException: Cannot invoke "java.util.List.iterator()"
> because "ttcNames" is null
> at
> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:219)
> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
> at
> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
> 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:363)
> 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:184)
> at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:242)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2960. - Fix Version/s: trunk Resolution: Fixed Thanks for your contribution. This has been committed in revision 1884753 > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Fix For: trunk > > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOP-2960 started by Chris Bowditch. --- > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2960: --- Assignee: Chris Bowditch > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2983) [PATCH] Font auto-detection doesn't work
[ https://issues.apache.org/jira/browse/FOP-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254053#comment-17254053 ] Chris Bowditch commented on FOP-2983: - Can you provide more information on how to replicate the issue you describe. Preferrably attaching an FO file and fop.xconf file? > [PATCH] Font auto-detection doesn't work > > > Key: FOP-2983 > URL: https://issues.apache.org/jira/browse/FOP-2983 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.5, trunk > Environment: Apache Maven 3.6.0 > Java version: 1.8.0_181, vendor: Oracle Corporation > Default locale: ru_RU, platform encoding: Cp1251 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Sergey Gorbunov >Priority: Critical > Attachments: fonts-auto-detect.patch > > > When constructing a tree with a configuration, the node for auto-detection is > added to the wrong parent node. As a result, the flag remains with a false. > Detected when trying to convert SVG to PDF with Cyrillic characters. Since > the correct font was not detected automatically, incorrect characters were > displayed after conversion. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2985) SVG Images inherit font configuration from sibling objects.
[ https://issues.apache.org/jira/browse/FOP-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2985: Summary: SVG Images inherit font configuration from sibling objects. (was: [PATCH] SVG Images inherit font configuration from sibling objects.) > SVG Images inherit font configuration from sibling objects. > --- > > Key: FOP-2985 > URL: https://issues.apache.org/jira/browse/FOP-2985 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Juan >Priority: Minor > Attachments: SVG-letter-spacing.patch, input.fo, sample.svg > > > Given the sample [^input.fo] (adjust the path to sample.svg), the letter > spacing of an inline element in a previous block is being applied also to an > external-graphic element on a different block. > The letter spacing property in the inline element should not affect the > external-graphic in a different block. > Additionally, setting letter-spacing on the external-graphic or it's parent > block has no effect and the content still used the letter-spacing of the > previous inline text. > > The given patch [^SVG-letter-spacing.patch] does fix the issue with > letter-spacing, altough *it might need a more generic approach*. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2985) [PATCH] SVG Images inherit font configuration from sibling objects.
[ https://issues.apache.org/jira/browse/FOP-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254050#comment-17254050 ] Chris Bowditch commented on FOP-2985: - I don't think this is the right solution. As you mention its specific fix to PDF, and I don't think we should be calling beginText when rendering an image. We don't even know if the image is an SVG at the place where you inserted this code. I think letter spacing should be reset when ending the fo:inline with it set, and this should be done in AbstractRenderer or IFRenderer not in PDFPainter > [PATCH] SVG Images inherit font configuration from sibling objects. > --- > > Key: FOP-2985 > URL: https://issues.apache.org/jira/browse/FOP-2985 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Juan >Priority: Minor > Attachments: SVG-letter-spacing.patch, input.fo, sample.svg > > > Given the sample [^input.fo] (adjust the path to sample.svg), the letter > spacing of an inline element in a previous block is being applied also to an > external-graphic element on a different block. > The letter spacing property in the inline element should not affect the > external-graphic in a different block. > Additionally, setting letter-spacing on the external-graphic or it's parent > block has no effect and the content still used the letter-spacing of the > previous inline text. > > The given patch [^SVG-letter-spacing.patch] does fix the issue with > letter-spacing, altough *it might need a more generic approach*. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2497) XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2497: Summary: XML processor attempts to resolve URIs from internet when loading XSLT source (was: [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source) > XML processor attempts to resolve URIs from internet when loading XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FOP-2497) [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254016#comment-17254016 ] Chris Bowditch edited comment on FOP-2497 at 12/23/20, 10:34 AM: - Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue, i.e. the XML and XSLT source was (Author: cbowditch): Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue > [PATCH] XML processor attempts to resolve URIs from internet when loading > XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2497) [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254016#comment-17254016 ] Chris Bowditch commented on FOP-2497: - Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue > [PATCH] XML processor attempts to resolve URIs from internet when loading > XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2988) Commercial license of jai-core and jai-codec libraries
[ https://issues.apache.org/jira/browse/FOP-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2988. --- Resolution: Duplicate > Commercial license of jai-core and jai-codec libraries > -- > > Key: FOP-2988 > URL: https://issues.apache.org/jira/browse/FOP-2988 > Project: FOP > Issue Type: Wish >Affects Versions: 2.5, 2.4 >Reporter: Olga >Priority: Major > > Hi all, our product uses the fop library to generate pdfs. And we have an > issue with the commercial license of sun jai-core and jai-codec libraries. We > cannot distribute them with our product. > I found already the thread about the issue: > https://issues.apache.org/jira/browse/FOP-2889 > We are going to exclude these libs from the maven dependency, but we are > concerned about what kind of FOP functionality uses jai-core and jai-codec > libraries? What issues could we face? > Thanks, Olga. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2988) Commercial license of jai-core and jai-codec libraries
[ https://issues.apache.org/jira/browse/FOP-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252925#comment-17252925 ] Chris Bowditch commented on FOP-2988: - Why didn't you just ask your question on the mailing list or on the existing bug report? I will close this as duplicate. JAI is used to provide support for additional image types and without it you will not be able to use some images when generating PDF/PS/AFP from XSL-FO > Commercial license of jai-core and jai-codec libraries > -- > > Key: FOP-2988 > URL: https://issues.apache.org/jira/browse/FOP-2988 > Project: FOP > Issue Type: Wish >Affects Versions: 2.5, 2.4 >Reporter: Olga >Priority: Major > > Hi all, our product uses the fop library to generate pdfs. And we have an > issue with the commercial license of sun jai-core and jai-codec libraries. We > cannot distribute them with our product. > I found already the thread about the issue: > https://issues.apache.org/jira/browse/FOP-2889 > We are going to exclude these libs from the maven dependency, but we are > concerned about what kind of FOP functionality uses jai-core and jai-codec > libraries? What issues could we face? > Thanks, Olga. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2569) [PATCH] Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172119#comment-17172119 ] Chris Bowditch commented on FOP-2569: - I never applied the patch, so unless you applied the patch and rebuilt FOP thats expected > [PATCH] Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: FOP-2569.patch, hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2947) PDF fulltext is missing spaces and As
[ https://issues.apache.org/jira/browse/FOP-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150289#comment-17150289 ] Chris Bowditch commented on FOP-2947: - Great news that you resolved the issue. This is not a bug, and I think asking questions like this on fop-user rather than raising a bug is the best course of action. I will close this bug > PDF fulltext is missing spaces and As > - > > Key: FOP-2947 > URL: https://issues.apache.org/jira/browse/FOP-2947 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 1.0 > Environment: Windows 10 > Apache FOP 1.0 > Saxon (don't know which version) > Java (openjdk-13.0.1) >Reporter: Hannes Hartl >Priority: Major > Attachments: Full-Text-Example.txt, konventionen.pdf > > > Hi > we are converting XMLs to PDF. > We were using Frutiger-Font but now we have to switch to a variant of Adobe > Source Sans. Both fonts are TTFs and used as embeded. > Since we are using the new font, PDFs are created perfectly but the full text > of the PDF is missing spaces between words. > Additionally als big As are missing in the full text. > This leads to the problem that twe (and our customers) are no longer able to > search the PDF full text correctly. > Unfortunally the original developper of our converting environonment is no > longer working for the company. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2947) PDF fulltext is missing spaces and As
[ https://issues.apache.org/jira/browse/FOP-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2947. --- Resolution: Not A Bug > PDF fulltext is missing spaces and As > - > > Key: FOP-2947 > URL: https://issues.apache.org/jira/browse/FOP-2947 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 1.0 > Environment: Windows 10 > Apache FOP 1.0 > Saxon (don't know which version) > Java (openjdk-13.0.1) >Reporter: Hannes Hartl >Priority: Major > Attachments: Full-Text-Example.txt, konventionen.pdf > > > Hi > we are converting XMLs to PDF. > We were using Frutiger-Font but now we have to switch to a variant of Adobe > Source Sans. Both fonts are TTFs and used as embeded. > Since we are using the new font, PDFs are created perfectly but the full text > of the PDF is missing spaces between words. > Additionally als big As are missing in the full text. > This leads to the problem that twe (and our customers) are no longer able to > search the PDF full text correctly. > Unfortunally the original developper of our converting environonment is no > longer working for the company. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2569) [PATCH] Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135599#comment-17135599 ] Chris Bowditch commented on FOP-2569: - I've attached my patch. Unfortunately the unit tests are failing and so it needs more work. I think the reason they fail is they try to use the compiled files from OFFO. So it may be that we just need to recompile them, but unfortunately I have more pressing work that needs attention today > [PATCH] Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: FOP-2569.patch, hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2569) [PATCH] Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2569: Summary: [PATCH] Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) (was: Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)) > [PATCH] Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: FOP-2569.patch, hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2569: Attachment: FOP-2569.patch > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: FOP-2569.patch, hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134325#comment-17134325 ] Chris Bowditch commented on FOP-2569: - I think I managed to get this working. I generated a .hyp file anyway :) which I attached, but I don't think you can use it as you will need the new code. The hyp file is a serialized version of the Java object and I amended this by changing char[] to int[]. I need to do a bit more testing before I commit my changes > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2569: Attachment: hyph_de_DE.hyp > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: hyph_de_DE.fop, hyph_de_DE.hyp > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134250#comment-17134250 ] Chris Bowditch commented on FOP-2569: - Thanks for sharing the XML. Looking at the code I think its designed for a maximum number of hyphenation patterns of around 65535. This is backed up by the comments at the top of the class: Using java's char type as pointer (yes, I know pointer * it is a forbidden word in java) we can keep the size of the node * to be just 8 bytes (3 pointers and the data char). This gives * room for about 65000 nodes. In my tests the english patterns * took 7694 nodes and the german patterns 10055 nodes, * so I think we are safe. I'll have a go at changing the char[] to int[] to see if that resolves the issue > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > Attachments: hyph_de_DE.fop > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17129272#comment-17129272 ] Chris Bowditch commented on FOP-2569: - I download the Open Office extension you referenced and looked at the hyphenation file supplied. It's not in XML format as required by SerializeHyphPattern class. What process are you using to convert it? It would help if you could just attach the XML File you are working with. Thanks > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre >Priority: Major > Fix For: 1.1 > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2880) [PATCH] Hyphenated words are not searchable in readers (when accessibilty is turned on)
[
https://issues.apache.org/jira/browse/FOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116615#comment-17116615
]
Chris Bowditch commented on FOP-2880:
-
Submit a patch to correct glyphlist.xml and encoding.xml, and we'll review it
> [PATCH] Hyphenated words are not searchable in readers (when accessibilty is
> turned on)
> ---
>
> Key: FOP-2880
> URL: https://issues.apache.org/jira/browse/FOP-2880
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The hyphenated words are rendered by FOP using the hard hyphen character.
> This contradicts the PDF specification, where in section:
> 14.8.2.2.3 Incidental Artifacts
> clearly states that the SHY soft hyphen U+00AD character should be used.
> The effect is that the hyphenated words are not searchable, and the
> copy/paste feature includes also the hard hyphens, instead of removing them
> and joining the words pieces together.
> Here is a small patch that can be applied on the FOP core project in order to
> fix this - this is more like a proof of concept, the real fix would be to
> change the default hyphenation character * in the FOProppertyMapping and to
> change the font mappings: to remove the replacement of the SHY with the
> HYPHEN, see the org.apache.fop.fonts.CodePointMapping.encStandardEncoding,
> and org.apache.fop.fonts.CodePointMapping.encISOLatin1Encoding
> {code}
>0xad, 0x002D, // hyphen
>0xad, 0x00AD, // hyphen
> {code}
> The patch:
> {code}
> Index: src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> ===
> --- src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (revision 191037)
> +++ src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (working copy)
> @@ -15,7 +15,7 @@
> * limitations under the License.
> */
>
> -/* $Id$ */
> +/* $Id: CommonHyphenation.java 1610839 2014-07-15 20:25:58Z vhennebert $ */
>
> package org.apache.fop.fo.properties;
>
> @@ -184,6 +184,16 @@
> */
> public int getHyphIPD(org.apache.fop.fonts.Font font) {
> char hyphChar = getHyphChar(font);
> +
> +if (hyphChar == '\u00ad') {
> + // Bizarre fix, defining the SHY as default hyphenation character
> in the FOPropertyMapping, leads
> + // to hard hyphens not selectable in the PDF reader.
> + //
> + // Mapping also the hard hyphen makes the character selectable!
> + font.mapChar('\u002d');
> +}
> +
> +
> return font.getCharWidth(hyphChar);
> }
>
> Index: src/main/java/org/apache/fop/fo/FOPropertyMapping.java
> ===
> --- src/main/java/org/apache/fop/fo/FOPropertyMapping.java(revision
> 190759)
> +++ src/main/java/org/apache/fop/fo/FOPropertyMapping.java(working copy)
> @@ -1106,7 +1106,10 @@
> // hyphenation-character
> m = new CharacterProperty.Maker(PR_HYPHENATION_CHARACTER);
> m.setInherited(true);
> -m.setDefault("-");
> +//
> +// m.setDefault("-");
> +m.setDefault("\u00ad");
> +
> addPropertyMaker("hyphenation-character", m);
>
> // hyphenation-push-character-count
> Index: src/main/java/org/apache/fop/render/pdf/PDFPainter.java
> ===
> --- src/main/java/org/apache/fop/render/pdf/PDFPainter.java (revision
> 190759)
> +++ src/main/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
> @@ -420,7 +420,8 @@
> PDFStructElem structElem = (PDFStructElem)
> getContext().getStructureTreeElement();
> languageAvailabilityChecker.checkLanguageAvailability(text);
> MarkedContentInfo mci =
> logicalStructureHandler.addTextContentItem(structElem);
> -String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +//String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +String actualText = null;
> generator.endTextObject();
> generator.updateColor(state.getTextColor(), true, null);
> generator.beginTextObject(mci.tag, mci.mcid, actualText);
> @@ -490,6 +491,15 @@
> float glyphAdjust = 0;
> if (font.hasCodePoint(orgChar)) {
> ch = font.mapCodePoint(orgChar);
> + if (orgChar ==
> '\u00ad' && ch == '\u002d'){
> +
[jira] [Commented] (FOP-2937) [PATCH]Post PDF generation, Soft reference of PDFObject in PDFReference are not immediately garbage collected leading to excessive memory usage.
[ https://issues.apache.org/jira/browse/FOP-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110253#comment-17110253 ] Chris Bowditch commented on FOP-2937: - I think we need to keep these references until entire PDF is generated because bookmarks or other links might refer back to objects on the first page. So clearing them at page 2 onwards would prevent that. We also need to de-duplicate resources and clearing information about earlier pages could also lead to larger file size with duplicated resources. I am therefore closing this suggestion but feel free to disprove my hypothesis and re-open if you can > [PATCH]Post PDF generation, Soft reference of PDFObject in PDFReference are > not immediately garbage collected leading to excessive memory usage. > > > Key: FOP-2937 > URL: https://issues.apache.org/jira/browse/FOP-2937 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.3, 2.4 >Reporter: Piyush Khandelwal >Priority: Major > Attachments: PDFDictionary.patch, pdfreference.patch > > > PDFReference object holds a SoftReference of PDFObject (PDFPage, PDFLabel, > PDFName etc.). > If we generate a huge PDF ; *I tried with a PDF having around 150 thousand > pages with 12 GB of RAM;* lots of these references linger around waiting for > the garbage collector to collect them. > But GC wont collect them as long as JVM is able to recover enough memory > without throwing out of memory. > Here are few metadata from my testing for further understanding of the issue > - > Stats for generating 1 PDF - > *FO size:* 2.03GB > *Generated PDF No. of Pages:* Around 150 K > RAM: 12 GB > Peak memory that reached while generation - 11.3GB > Residual memory after forced GC: 9 GB > The FO mainly contains tabular data with each pages sequence having max of > 500 rows. > On analyzing the memory dump; found lots of reference for PDFPage, PDFName > etc. > *Question - * Is there any specific reason for using SoftReference in > PDFReference class instead of WeakReference. > Testing by changing SoftReference to WeakReference in PDFReference shows > following improvements without any issue in the generation whatsoever - > Stats for Generating 5 PDF in parallel - > *FO size:* 2.03GB > *Generated PDF No. of Pages:* Around 150 K > RAM: 12 GB > Peak memory that reached while generation - 4GB > Residual memory after forced GC: 300 MB > So, by changing SoftReference to WeakReference, I was able to generate 5 PDF > having 150K pages in parallel with max 4GB Ram; without any generation > issues. > You can clearly see the performance benefits of changing to WeakReference. > But as I dont understand the complete internal details of how FOP works, I > would like to understand if we can target this change and if not what is the > reason behind using SoftReference? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2937) [PATCH]Post PDF generation, Soft reference of PDFObject in PDFReference are not immediately garbage collected leading to excessive memory usage.
[ https://issues.apache.org/jira/browse/FOP-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2937. --- Resolution: Invalid > [PATCH]Post PDF generation, Soft reference of PDFObject in PDFReference are > not immediately garbage collected leading to excessive memory usage. > > > Key: FOP-2937 > URL: https://issues.apache.org/jira/browse/FOP-2937 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.3, 2.4 >Reporter: Piyush Khandelwal >Priority: Major > Attachments: PDFDictionary.patch, pdfreference.patch > > > PDFReference object holds a SoftReference of PDFObject (PDFPage, PDFLabel, > PDFName etc.). > If we generate a huge PDF ; *I tried with a PDF having around 150 thousand > pages with 12 GB of RAM;* lots of these references linger around waiting for > the garbage collector to collect them. > But GC wont collect them as long as JVM is able to recover enough memory > without throwing out of memory. > Here are few metadata from my testing for further understanding of the issue > - > Stats for generating 1 PDF - > *FO size:* 2.03GB > *Generated PDF No. of Pages:* Around 150 K > RAM: 12 GB > Peak memory that reached while generation - 11.3GB > Residual memory after forced GC: 9 GB > The FO mainly contains tabular data with each pages sequence having max of > 500 rows. > On analyzing the memory dump; found lots of reference for PDFPage, PDFName > etc. > *Question - * Is there any specific reason for using SoftReference in > PDFReference class instead of WeakReference. > Testing by changing SoftReference to WeakReference in PDFReference shows > following improvements without any issue in the generation whatsoever - > Stats for Generating 5 PDF in parallel - > *FO size:* 2.03GB > *Generated PDF No. of Pages:* Around 150 K > RAM: 12 GB > Peak memory that reached while generation - 4GB > Residual memory after forced GC: 300 MB > So, by changing SoftReference to WeakReference, I was able to generate 5 PDF > having 150K pages in parallel with max 4GB Ram; without any generation > issues. > You can clearly see the performance benefits of changing to WeakReference. > But as I dont understand the complete internal details of how FOP works, I > would like to understand if we can target this change and if not what is the > reason behind using SoftReference? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2936) [PATCH] Font-Family name is case sensitive.
[ https://issues.apache.org/jira/browse/FOP-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2936. --- Resolution: Duplicate > [PATCH] Font-Family name is case sensitive. > --- > > Key: FOP-2936 > URL: https://issues.apache.org/jira/browse/FOP-2936 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Sanjitha Srinivasan >Priority: Major > Attachments: case-sensitivity.patch > > > This patch attempts to fix the following defect - > https://issues.apache.org/jira/browse/FOP-2573 > FOP performs its font registration and lookup using a HashMap whose key is > the FontTriplet object - a string combination of the font family, font style > and font weight. Therefore, 'Courier' and 'courier' and 'COURIER' are treated > as different fonts. > The change made to address this was to convert all font family names to lower > case while creating the FontTriplet object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (FOP-2936) [PATCH] Font-Family name is case sensitive.
[ https://issues.apache.org/jira/browse/FOP-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reopened FOP-2936: - > [PATCH] Font-Family name is case sensitive. > --- > > Key: FOP-2936 > URL: https://issues.apache.org/jira/browse/FOP-2936 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Sanjitha Srinivasan >Priority: Major > Attachments: case-sensitivity.patch > > > This patch attempts to fix the following defect - > https://issues.apache.org/jira/browse/FOP-2573 > FOP performs its font registration and lookup using a HashMap whose key is > the FontTriplet object - a string combination of the font family, font style > and font weight. Therefore, 'Courier' and 'courier' and 'COURIER' are treated > as different fonts. > The change made to address this was to convert all font family names to lower > case while creating the FontTriplet object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2936) [PATCH] Font-Family name is case sensitive.
[ https://issues.apache.org/jira/browse/FOP-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2936. --- Resolution: Fixed > [PATCH] Font-Family name is case sensitive. > --- > > Key: FOP-2936 > URL: https://issues.apache.org/jira/browse/FOP-2936 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Sanjitha Srinivasan >Priority: Major > Attachments: case-sensitivity.patch > > > This patch attempts to fix the following defect - > https://issues.apache.org/jira/browse/FOP-2573 > FOP performs its font registration and lookup using a HashMap whose key is > the FontTriplet object - a string combination of the font family, font style > and font weight. Therefore, 'Courier' and 'courier' and 'COURIER' are treated > as different fonts. > The change made to address this was to convert all font family names to lower > case while creating the FontTriplet object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2573) [PATCH] Font-Family attribute is case-sensitive
[ https://issues.apache.org/jira/browse/FOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2573: Summary: [PATCH] Font-Family attribute is case-sensitive (was: Font-Family attribute is case-sensitive) > [PATCH] Font-Family attribute is case-sensitive > --- > > Key: FOP-2573 > URL: https://issues.apache.org/jira/browse/FOP-2573 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0, 2.1 > Environment: Window 7 x64, Java build 1.8.0_72-b15 >Reporter: Đorđe Zeljić >Priority: Major > Attachments: case-sensitivity.patch > > > I have simple FO file that contains block with font-family attribute (It's > very simple version of my huge FO file where I found the issue). > The attribute contains font name (eg. consolas). > When I try to render PDF I see the warn message: > WARNING: Font "consolas,normal,400" not found. Substituting with > "any,normal,400". > The test FO file is rendered fine in FOP 1.1 version, but not in 2.0 and 2.1 > versions. > I'm not sure if this is the bug, or it was in 1.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2573) [PATCH] Font-Family attribute is case-sensitive
[ https://issues.apache.org/jira/browse/FOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2573: Attachment: case-sensitivity.patch > [PATCH] Font-Family attribute is case-sensitive > --- > > Key: FOP-2573 > URL: https://issues.apache.org/jira/browse/FOP-2573 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0, 2.1 > Environment: Window 7 x64, Java build 1.8.0_72-b15 >Reporter: Đorđe Zeljić >Priority: Major > Attachments: case-sensitivity.patch > > > I have simple FO file that contains block with font-family attribute (It's > very simple version of my huge FO file where I found the issue). > The attribute contains font name (eg. consolas). > When I try to render PDF I see the warn message: > WARNING: Font "consolas,normal,400" not found. Substituting with > "any,normal,400". > The test FO file is rendered fine in FOP 1.1 version, but not in 2.0 and 2.1 > versions. > I'm not sure if this is the bug, or it was in 1.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2936) [PATCH] Font-Family name is case sensitive.
[ https://issues.apache.org/jira/browse/FOP-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106153#comment-17106153 ] Chris Bowditch commented on FOP-2936: - Thanks for the patch, but in future can you attach it to the bug to which it relates i.e. FOP-2573, and not open a new bug. I will do that for you on this occasion, and close this as a duplicate > [PATCH] Font-Family name is case sensitive. > --- > > Key: FOP-2936 > URL: https://issues.apache.org/jira/browse/FOP-2936 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Sanjitha Srinivasan >Priority: Major > Attachments: case-sensitivity.patch > > > This patch attempts to fix the following defect - > https://issues.apache.org/jira/browse/FOP-2573 > FOP performs its font registration and lookup using a HashMap whose key is > the FontTriplet object - a string combination of the font family, font style > and font weight. Therefore, 'Courier' and 'courier' and 'COURIER' are treated > as different fonts. > The change made to address this was to convert all font family names to lower > case while creating the FontTriplet object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1648) [PATCH]internal named destinations
[ https://issues.apache.org/jira/browse/FOP-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17104621#comment-17104621 ] Chris Bowditch commented on FOP-1648: - Subversion: Committed revision 1877589. > [PATCH]internal named destinations > -- > > Key: FOP-1648 > URL: https://issues.apache.org/jira/browse/FOP-1648 > Project: FOP > Issue Type: Improvement > Components: renderer/pdf >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: michaelrichardson89 >Assignee: Chris Bowditch > Labels: PatchAvailable > Attachments: b46980.diff, fop-1648.patch, > internal_named_destinations.diff > > > [PATCH] > I was experiencing an issue where svg graphics would enterpret links of the > format: > > as external web-links opening up a web browser. > I have now fixed this issue (given in the attached patch) so that links in > the above format now properly go to an internal named destinations. > The named destination must be specified with the tag: > > I hope this is helpfull. > -Michael -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FOP-1648) [PATCH]internal named destinations
[ https://issues.apache.org/jira/browse/FOP-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-1648. - Fix Version/s: trunk Resolution: Fixed > [PATCH]internal named destinations > -- > > Key: FOP-1648 > URL: https://issues.apache.org/jira/browse/FOP-1648 > Project: FOP > Issue Type: Improvement > Components: renderer/pdf >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: michaelrichardson89 >Assignee: Chris Bowditch > Labels: PatchAvailable > Fix For: trunk > > Attachments: b46980.diff, fop-1648.patch, > internal_named_destinations.diff > > > [PATCH] > I was experiencing an issue where svg graphics would enterpret links of the > format: > > as external web-links opening up a web browser. > I have now fixed this issue (given in the attached patch) so that links in > the above format now properly go to an internal named destinations. > The named destination must be specified with the tag: > > I hope this is helpfull. > -Michael -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FOP-1648) [PATCH]internal named destinations
[ https://issues.apache.org/jira/browse/FOP-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-1648: --- Assignee: Chris Bowditch (was: Matthias Reischenbacher) > [PATCH]internal named destinations > -- > > Key: FOP-1648 > URL: https://issues.apache.org/jira/browse/FOP-1648 > Project: FOP > Issue Type: Improvement > Components: renderer/pdf >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: michaelrichardson89 >Assignee: Chris Bowditch > Labels: PatchAvailable > Attachments: b46980.diff, fop-1648.patch, > internal_named_destinations.diff > > > [PATCH] > I was experiencing an issue where svg graphics would enterpret links of the > format: > > as external web-links opening up a web browser. > I have now fixed this issue (given in the attached patch) so that links in > the above format now properly go to an internal named destinations. > The named destination must be specified with the tag: > > I hope this is helpfull. > -Michael -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2930) performance problem in pdf generation
[ https://issues.apache.org/jira/browse/FOP-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084051#comment-17084051 ] Chris Bowditch commented on FOP-2930: - I also don't approve of the proposed solution. I'd guess there is some image processing needed to convert images to format required by PDF and thats why it takes a long time to generate the PDF File. I think we should confirm before closing this bug > performance problem in pdf generation > - > > Key: FOP-2930 > URL: https://issues.apache.org/jira/browse/FOP-2930 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4 >Reporter: zouari >Priority: Major > Fix For: 2.4 > > Attachments: PDFFactory.patch, test1.if, test1.pdf > > > I have an ".if" file which contains external document. > this file contains 50,000 pages. > I tried to convert it to pdf but this task took a long time > we analyze this performance problem, I find for each external page, an object > "PDFResources". > PDFResources objects processing slows down pdf file generation. > solution: > create a global "PDFResources" object for all the pages. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-2917) Superscript / sub script shifted to the next character
[ https://issues.apache.org/jira/browse/FOP-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2917. --- Resolution: Cannot Reproduce Closing this until an XSL-FO File is provided. Please re-open when you attach the XSL-FO File. There's nothing we can do without that > Superscript / sub script shifted to the next character > -- > > Key: FOP-2917 > URL: https://issues.apache.org/jira/browse/FOP-2917 > Project: FOP > Issue Type: Bug >Reporter: Fung Cheung >Priority: Critical > > Hello, > > We are experiencing a weird issue where text with superscripts/ subscripts > sometimes are changed in the FOP PDF output. > E.g. > input text: Gestión > output text: Gestíon > input text: años > output text: ãnos > > With the same input, the output is always the same. However this doesn't > happen to all superscripts. I am not able to find a pattern of what input > would trigger the incorrect output. > > Please help, thanks! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2921) Diactrics misplaced in fop generated PDF
[ https://issues.apache.org/jira/browse/FOP-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062467#comment-17062467 ] Chris Bowditch commented on FOP-2921: - Can you please attach an XSL-FO FIle and fop.xconf (for font configuration) that replicates the issue. Can you tell which language that is, because we don't support diacritics for every language, see: [https://xmlgraphics.apache.org/fop/trunk/complexscripts.html#supported_scripts] > Diactrics misplaced in fop generated PDF > > > Key: FOP-2921 > URL: https://issues.apache.org/jira/browse/FOP-2921 > Project: FOP > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Harish Rayasam >Priority: Critical > Labels: pdf > > We are using fop 2.3 to generate PDF output. > It misplaces diactrics in a weird manner. > Input String: Responsável pela análise e controlo dos indicadores de gestão > String in generated PDF: Responśavel pela ańalise e controlo dos indicadores > de gest̃ao > > We tried with different fonts like DejavuSans, Symbola, Arial > None of them seem to solve the issue. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FOP-2921) Diactrics misplaced in fop generated PDF
[ https://issues.apache.org/jira/browse/FOP-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062467#comment-17062467 ] Chris Bowditch edited comment on FOP-2921 at 3/19/20, 11:21 AM: Can you please attach an XSL-FO FIle and fop.xconf (for font configuration) that replicates the issue. Can you tell me which language that is, because we don't support diacritics for every language, see: [https://xmlgraphics.apache.org/fop/trunk/complexscripts.html#supported_scripts] was (Author: cbowditch): Can you please attach an XSL-FO FIle and fop.xconf (for font configuration) that replicates the issue. Can you tell which language that is, because we don't support diacritics for every language, see: [https://xmlgraphics.apache.org/fop/trunk/complexscripts.html#supported_scripts] > Diactrics misplaced in fop generated PDF > > > Key: FOP-2921 > URL: https://issues.apache.org/jira/browse/FOP-2921 > Project: FOP > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Harish Rayasam >Priority: Critical > Labels: pdf > > We are using fop 2.3 to generate PDF output. > It misplaces diactrics in a weird manner. > Input String: Responsável pela análise e controlo dos indicadores de gestão > String in generated PDF: Responśavel pela ańalise e controlo dos indicadores > de gest̃ao > > We tried with different fonts like DejavuSans, Symbola, Arial > None of them seem to solve the issue. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1487) vertical-align or baseline-shift In table-cells carries across entire row
[ https://issues.apache.org/jira/browse/FOP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062458#comment-17062458 ] Chris Bowditch commented on FOP-1487: - Hi Abigael, anyone can contribute to an Apache Project. If you submit large patches that add new files we may ask you to complete an ICLA before we apply them > vertical-align or baseline-shift In table-cells carries across entire row > - > > Key: FOP-1487 > URL: https://issues.apache.org/jira/browse/FOP-1487 > Project: FOP > Issue Type: Bug > Components: renderer/rtf >Affects Versions: 0.94 > Environment: Operating System: other > Platform: Other >Reporter: Peter Ryan > Attachments: superscript.fo > > > adding a baseline shift to "super" in a fo:inline element within a table cell > causes all subsequent cells in the row to retain the baseline shift. > Please see attached fo document for example that demonstrates the problem. > This problem does not exist for PDF. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2920) [PATCH] Surrogate pair edge-case causes java.lang.ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/FOP-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-2920:
Summary: [PATCH] Surrogate pair edge-case causes
java.lang.ArrayIndexOutOfBoundsException (was: Surrogate pair edge-case causes
java.lang.ArrayIndexOutOfBoundsException)
> [PATCH] Surrogate pair edge-case causes
> java.lang.ArrayIndexOutOfBoundsException
>
>
> Key: FOP-2920
> URL: https://issues.apache.org/jira/browse/FOP-2920
> Project: FOP
> Issue Type: Bug
> Components: renderer/pdf
>Affects Versions: trunk
> Environment: macOS Mojave
> java version "1.8.0_192-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
>Reporter: Kelly H Wilkerson
>Priority: Minor
> Attachments: TwitterColorEmoji-SVGinOT.ttf, diff.txt, fail.xml,
> twe_template.fo, twe_userconfig.xml
>
>
> fop-core/src/main/java/org/apache/fop/pdf/PDFToUnicodeCMap.java
> writeBFCharEntries runs through the codepoint entries in sections of 100 at a
> time. It looks like there's an edge case here where the last entry in the
> section is a surrogate pair.
>
> Here's my steps to reproduce from the latest trunk:
> {{java -cp
> fop/target/fop-2.5.0-SNAPSHOT.jar:fop/lib/commons-logging-1.0.4.jar:fop/lib/commons-io-1.3.1.jar:fop/lib/xmlgraphics-commons-svn-trunk.jar
> org.apache.fop.fonts.apps.TTFReader TwitterColorEmoji-SVGinOT.ttf twe.xml}}
> {{java -cp
> fop/target/fop-2.5.0-SNAPSHOT.jar:fop/lib/commons-logging-1.0.4.jar:fop/lib/commons-io-1.3.1.jar:fop/lib/xmlgraphics-commons-svn-trunk.jar:fop/lib/batik-all-1.11.0-SNAPSHOT.jar
> org.apache.fop.cli.Main -c twe_userconfig.xml -xsl twe_template.fo -xml
> fail.xml -pdf fail.pdf}}
>
> Here's the temporary way I resolved it for my own build:
>
> index ee773dcec..37c21803e 100644
> --- a/fop-core/src/main/java/org/apache/fop/pdf/PDFToUnicodeCMap.java
> +++ b/fop-core/src/main/java/org/apache/fop/pdf/PDFToUnicodeCMap.java
> @@ -128,6 +128,18 @@ public class PDFToUnicodeCMap extends PDFCMap {
> while (partOfRange(charArray, charIndex)) {
> charIndex++;
> }
> /*
> * If this entry is going to overflow the entriesThisSection
> * array, then don't use it. This happens if there are
> * non-pair entries in the table mixed with pair entries.
> */
> if (Character.codePointAt(charArray, charIndex) > 0x
> && i+1 >= entriesThisSection) {
> entriesThisSection--;
> break;
> }
> writer.write("<" + padCharIndex(charIndex) + "> ");
> if (Character.codePointAt(charArray, charIndex) > 0x) {
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FOP-1196) [PATCH] GSoC: floats implementation
[
https://issues.apache.org/jira/browse/FOP-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056772#comment-17056772
]
Chris Bowditch commented on FOP-1196:
-
No one has implemented support for top floats, only side floats has been
implemented so far
> [PATCH] GSoC: floats implementation
> ---
>
> Key: FOP-1196
> URL: https://issues.apache.org/jira/browse/FOP-1196
> Project: FOP
> Issue Type: Improvement
> Components: layout/unqualified
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Vincent Hennebert
>Priority: Major
> Labels: PatchAvailable
> Attachments: patch.diff, patch2.diff, patchBeforeFloats-2.diff,
> patchBeforeFloats.diff, patchDisabledTestcases.diff, patchTestcases.diff
>
>
> This patch isn't really meant to be applied... Rather to be reviewed by
> interested parties to check if I'm not wrong. Changelog:
> * javadocs for the Knuth line- and page-breaking algorithms. Some items are
> marked with double question marks because I haven't found out yet what is
> their
> purpose. I will probably find eventually, but if anybody has immediate hints
> they will be welcome.
> * some methods have been marked deprecated because AFAICT they are not called
> anywhere. If this is agreed I'll remove them in my next patch
> * bugfix? In the last for loop of the method
> layoutmgr.PageBreakingAlgorithm.noBreakBetween I think the exit condition
> should
> be a strict comparison ('<' instead of '<='). Confirmation?
> * the javadoc comments for some methods have been removed because they will
> inherit them from their super-class
> * some checkstyle fixes
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FOP-2889) Missing maven artifacts: jai-core and jai-codec
[
https://issues.apache.org/jira/browse/FOP-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030508#comment-17030508
]
Chris Bowditch commented on FOP-2889:
-
Sorry if I'm being a little slow but I don't understand your point. We aren't
distributing the libraries, we are using them as a build dependency off
Redhat's server. If Redhat didn't want you to use them at all then why are they
publicly available on their nexus server?
> Missing maven artifacts: jai-core and jai-codec
> ---
>
> Key: FOP-2889
> URL: https://issues.apache.org/jira/browse/FOP-2889
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Jörg Weske
>Priority: Major
>
> +*Problem:*+ When trying to include FOP 2.4 in a Java Maven project, the
> following artifacts cannot be found through maven-central:
> {noformat}
>
> javax.media
> jai-core
> 1.1.3
>
>
> com.sun.media
> jai-codec
> 1.1.3
> {noformat}
> As a result, building the project is impossible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FOP-2903) Do not delete files on invocation with syntax errors in command line
[
https://issues.apache.org/jira/browse/FOP-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015878#comment-17015878
]
Chris Bowditch commented on FOP-2903:
-
Please attach sample files to replicate the issue or it will be closed as
unable to replicate
> Do not delete files on invocation with syntax errors in command line
>
>
> Key: FOP-2903
> URL: https://issues.apache.org/jira/browse/FOP-2903
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.3
> Environment: Linux RHEL 7, FOP installed from source
>Reporter: Mathias Weiersmueller
>Priority: Trivial
>
> When invoking FOP from the command line with an error, fop deletes files. I
> expect FOP to touch nothing upon an error.
> Example:
> {{fop -xml ./my.xml my.xsl -pdf result.pdf}}
> above command throws as expected an error because the -xsl flag is missing in
> front of the XSL file name:
> Jan 15, 2020 8:56:03 AM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: you can only set one output method
> But the file my.xsl is gone (deleted) afterwards. The file should not get
> deleted upon an error in the command line.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FOP-1789) java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor
[ https://issues.apache.org/jira/browse/FOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1789: Summary: java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor (was: [PATCH] java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor) > java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor > --- > > Key: FOP-1789 > URL: https://issues.apache.org/jira/browse/FOP-1789 > Project: FOP > Issue Type: Bug > Components: foreign/svg >Affects Versions: 0.95, 2.4 > Environment: Operating System: All > Platform: All >Reporter: Yannick Majoros >Assignee: Chris Bowditch > Attachments: fop.patch > > > While starting fop without batik jar, this error is shown in the logs: > Error while initializing the Batik SVG extensions > java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor >at > org.apache.fop.fo.extensions.svg.SVGElementMapping.initialize(SVGElementMapping.java:80) > > (+long stack trace) > This is a warning, but is confusing some developers of my team. A quick check > on the web shows many people are confused with this. > This is not consistent with what other extensions do. > If the only consequence is that batik is disabled, the complete stack trace > should not be shown. A warning is enough, and debug info with complete stack > trace should be made available. > This quick patch fixes that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1789) [PATCH] java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor
[ https://issues.apache.org/jira/browse/FOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014402#comment-17014402 ] Chris Bowditch commented on FOP-1789: - Unfortunately, this patch doesn't resolve the problem in the latest FOP version. I get the following exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/batik/bridge/UserAgent at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.getDeclaredConstructor(Class.java:2178) at org.apache.xmlgraphics.util.Service.providers(Service.java:85) at org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry.discoverClasspathImplementations(ImageImplRegistry.java:117) at org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry.(ImageImplRegistry.java:81) at org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry.(ImageImplRegistry.java:89) at org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry.(ImageImplRegistry.java:73) at org.apache.xmlgraphics.image.loader.ImageManager.(ImageManager.java:64) at org.apache.fop.apps.FopFactoryBuilder$FopFactoryConfigImpl.(FopFactoryBuilder.java:380) at org.apache.fop.apps.FopFactoryBuilder.(FopFactoryBuilder.java:89) at org.apache.fop.apps.FopFactoryBuilder.(FopFactoryBuilder.java:80) at org.apache.fop.apps.FopFactoryBuilder.(FopFactoryBuilder.java:70) at org.apache.fop.cli.CommandLineOptions.setUserConfig(CommandLineOptions.java:1018) at org.apache.fop.cli.CommandLineOptions.parse(CommandLineOptions.java:173) > [PATCH] java.lang.NoClassDefFoundError: > org/apache/batik/util/XMLResourceDescriptor > --- > > Key: FOP-1789 > URL: https://issues.apache.org/jira/browse/FOP-1789 > Project: FOP > Issue Type: Bug > Components: foreign/svg >Affects Versions: 0.95, 2.4 > Environment: Operating System: All > Platform: All >Reporter: Yannick Majoros >Assignee: Chris Bowditch > Attachments: fop.patch > > > While starting fop without batik jar, this error is shown in the logs: > Error while initializing the Batik SVG extensions > java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor >at > org.apache.fop.fo.extensions.svg.SVGElementMapping.initialize(SVGElementMapping.java:80) > > (+long stack trace) > This is a warning, but is confusing some developers of my team. A quick check > on the web shows many people are confused with this. > This is not consistent with what other extensions do. > If the only consequence is that batik is disabled, the complete stack trace > should not be shown. A warning is enough, and debug info with complete stack > trace should be made available. > This quick patch fixes that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1789) [PATCH] java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor
[ https://issues.apache.org/jira/browse/FOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1789: Affects Version/s: 2.4 > [PATCH] java.lang.NoClassDefFoundError: > org/apache/batik/util/XMLResourceDescriptor > --- > > Key: FOP-1789 > URL: https://issues.apache.org/jira/browse/FOP-1789 > Project: FOP > Issue Type: Bug > Components: foreign/svg >Affects Versions: 0.95, 2.4 > Environment: Operating System: All > Platform: All >Reporter: Yannick Majoros >Assignee: Chris Bowditch > Attachments: fop.patch > > > While starting fop without batik jar, this error is shown in the logs: > Error while initializing the Batik SVG extensions > java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor >at > org.apache.fop.fo.extensions.svg.SVGElementMapping.initialize(SVGElementMapping.java:80) > > (+long stack trace) > This is a warning, but is confusing some developers of my team. A quick check > on the web shows many people are confused with this. > This is not consistent with what other extensions do. > If the only consequence is that batik is disabled, the complete stack trace > should not be shown. A warning is enough, and debug info with complete stack > trace should be made available. > This quick patch fixes that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FOP-1789) [PATCH] java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor
[ https://issues.apache.org/jira/browse/FOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-1789: --- Assignee: Chris Bowditch > [PATCH] java.lang.NoClassDefFoundError: > org/apache/batik/util/XMLResourceDescriptor > --- > > Key: FOP-1789 > URL: https://issues.apache.org/jira/browse/FOP-1789 > Project: FOP > Issue Type: Bug > Components: foreign/svg >Affects Versions: 0.95 > Environment: Operating System: All > Platform: All >Reporter: Yannick Majoros >Assignee: Chris Bowditch > Attachments: fop.patch > > > While starting fop without batik jar, this error is shown in the logs: > Error while initializing the Batik SVG extensions > java.lang.NoClassDefFoundError: org/apache/batik/util/XMLResourceDescriptor >at > org.apache.fop.fo.extensions.svg.SVGElementMapping.initialize(SVGElementMapping.java:80) > > (+long stack trace) > This is a warning, but is confusing some developers of my team. A quick check > on the web shows many people are confused with this. > This is not consistent with what other extensions do. > If the only consequence is that batik is disabled, the complete stack trace > should not be shown. A warning is enough, and debug info with complete stack > trace should be made available. > This quick patch fixes that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2146) Wrong FontCache-Directory used for not existing userHome in FontCache.getDefaultCacheFile() (Bug 47786 was not fixed correctly)
[
https://issues.apache.org/jira/browse/FOP-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014388#comment-17014388
]
Chris Bowditch commented on FOP-2146:
-
I know this is an old bug, but I'm wondering what situation can user.home
environment variable be unset? If that only on a specific operating system?
> Wrong FontCache-Directory used for not existing userHome in
> FontCache.getDefaultCacheFile() (Bug 47786 was not fixed correctly)
> ---
>
> Key: FOP-2146
> URL: https://issues.apache.org/jira/browse/FOP-2146
> Project: FOP
> Issue Type: Bug
> Components: font/unqualified
>Affects Versions: 1.1
> Environment: Operating System: All
> Platform: All
>Reporter: mg
>
> Method getDefaultCacheFile() returns an invalid file name if the user has no
> home directory set. In that case the name of the fop user directory
> (FOP_USER_DIR!) is returned and not the name of the cache file
> (DEFAULT_CACHE_FILENAME).
> Wrong Code:
> public static File getDefaultCacheFile(boolean forWriting) {
> File userHome = getUserHome();
> if (userHome != null) {
> File fopUserDir = new File(userHome, FOP_USER_DIR);
> if (forWriting) {
> boolean writable = fopUserDir.canWrite();
> if (!fopUserDir.exists()) {
> writable = fopUserDir.mkdir();
> }
> if (!writable) {
> userHome = getTempDirectory();
> fopUserDir = new File(userHome, FOP_USER_DIR);
> fopUserDir.mkdir();
> }
> }
> return new File(fopUserDir, DEFAULT_CACHE_FILENAME);
> }
> return new File(FOP_USER_DIR);
> }
> If getUserHome() does not return a directory the default name must be
> returned (and not the name of the directory):
> return new File(DEFAULT_CACHE_FILENAME);
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FOP-2146) Wrong FontCache-Directory used for not existing userHome in FontCache.getDefaultCacheFile() (Bug 47786 was not fixed correctly)
[
https://issues.apache.org/jira/browse/FOP-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch updated FOP-2146:
Attachment: (was: 62-193-Exam-Dumps-2019.pdf)
> Wrong FontCache-Directory used for not existing userHome in
> FontCache.getDefaultCacheFile() (Bug 47786 was not fixed correctly)
> ---
>
> Key: FOP-2146
> URL: https://issues.apache.org/jira/browse/FOP-2146
> Project: FOP
> Issue Type: Bug
> Components: font/unqualified
>Affects Versions: 1.1
> Environment: Operating System: All
> Platform: All
>Reporter: mg
>
> Method getDefaultCacheFile() returns an invalid file name if the user has no
> home directory set. In that case the name of the fop user directory
> (FOP_USER_DIR!) is returned and not the name of the cache file
> (DEFAULT_CACHE_FILENAME).
> Wrong Code:
> public static File getDefaultCacheFile(boolean forWriting) {
> File userHome = getUserHome();
> if (userHome != null) {
> File fopUserDir = new File(userHome, FOP_USER_DIR);
> if (forWriting) {
> boolean writable = fopUserDir.canWrite();
> if (!fopUserDir.exists()) {
> writable = fopUserDir.mkdir();
> }
> if (!writable) {
> userHome = getTempDirectory();
> fopUserDir = new File(userHome, FOP_USER_DIR);
> fopUserDir.mkdir();
> }
> }
> return new File(fopUserDir, DEFAULT_CACHE_FILENAME);
> }
> return new File(FOP_USER_DIR);
> }
> If getUserHome() does not return a directory the default name must be
> returned (and not the name of the directory):
> return new File(DEFAULT_CACHE_FILENAME);
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1802. --- Resolution: Cannot Reproduce > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010528#comment-17010528 ] Chris Bowditch commented on FOP-1802: - Thanks for the patch, but I have no means to replicate the issue. Also, we no longer use AWT Fonts for rendering Postscript. Instead we try to identify a font registered in the fop.xconf file with same name, style, etc. Since this is now 10 years old, I'm going to close it, but if you can provide a test case for the latest FOP version please do re-open > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1581) Improve border painting in collapsing border model
[ https://issues.apache.org/jira/browse/FOP-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1581: Attachment: (was: az-900-Exam-Dumps-2019.pdf) > Improve border painting in collapsing border model > -- > > Key: FOP-1581 > URL: https://issues.apache.org/jira/browse/FOP-1581 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: border-painting.fo > > > See attached file: the corners adjacent to the cell without borders aren't > fully painted, which makes the result not very nice. > It would be a nice to have if the borders were fully painted, like in the > separate border model (second table). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010525#comment-17010525 ] Chris Bowditch commented on FOP-1690: - Testing this in the latest trunk, this bug now appears to be resolved as I get the expected output without any error > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1690. --- Resolution: Cannot Reproduce > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1690: Attachment: (was: h13-623-Exam-Dumps-2019.pdf) > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1690) int overflow with large font size values
[ https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1690: Attachment: (was: h13-623-Exam-Dumps-2019.pdf) > int overflow with large font size values > > > Key: FOP-1690 > URL: https://issues.apache.org/jira/browse/FOP-1690 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Jeremias Maerki > Attachments: svg-text.fo > > > A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points. > No problem. Switch to SVG and define a viewBox with relatively high values and > you can quickly end up with a font size of 11'000 (units not points). It > happened to me when I ran an SVG that was produced by the SVG document handler > in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate > system in SVG. No SVG editor/viewer has a problem with that. > So, the problem is, for example, the generated Helvetica class' getWidth(int > i, > int size) method which returns an int. Multiply a number in the 1000 range > with > the font size that has been multiplied by 1000 (pt -> mpt conversion for > normal > FO). > 950 * (1000 * 11000) = 1045000 (0x26EDE5880) > That result is bigger than a 32-bit int. > For comparison, the usual case in FO: > 950 * (1000 * 11) = 1045 (0x9F7450) > I've locally added long variants of the problematic methods (getWidth() -> > getWidthLong()) to see if this really solves the problem and it does indeed. > Just replacing int with long everywhere is not a good idea because of > backwards-compatibility. We know that some people are using these classes > outside of FOP. To me, the additional long variants look like the cleanest > solution, but maybe someone has a better solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1802) [PATCH] NativeTextHandler ignores AWT Font AffineTransform
[ https://issues.apache.org/jira/browse/FOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1802: Attachment: (was: mb2-717-Exam-Dumps-NewYear-2019.pdf) > [PATCH] NativeTextHandler ignores AWT Font AffineTransform > -- > > Key: FOP-1802 > URL: https://issues.apache.org/jira/browse/FOP-1802 > Project: FOP > Issue Type: Bug > Components: renderer/ps >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Julien Aymé > Attachments: NativeTextHandler.diff, NativeTextHandler.diff > > > The NativeTextHandler class ignores the AffineTransform of the AWT Font, and > the generated Postscript document is incorrect. > I suggest that the NativeTextHandler adds a transformation matrix > corresponding to the font's AffineTransform if it is not the Identity matrix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-1606) [PATCH] Incorrect border when using number-columns-spanned in RTF
[ https://issues.apache.org/jira/browse/FOP-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009871#comment-17009871 ] Chris Bowditch commented on FOP-1606: - Thanks for the patch, fix committed in revision: 1872447 Notes; the fix is quite specific, for example it doesn't cover the use case for number-rows-spanned and border-bottom is specified on the table. I also won't work if border-collapse is changed from its default value. However, I don't think the RTF output channel in general supports that yet > [PATCH] Incorrect border when using number-columns-spanned in RTF > - > > Key: FOP-1606 > URL: https://issues.apache.org/jira/browse/FOP-1606 > Project: FOP > Issue Type: Bug > Components: renderer/rtf >Affects Versions: 0.95 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Max Aster >Assignee: Chris Bowditch > Labels: PatchAvailable > Attachments: TableCellBorderFix.txt, tableSpan.fo, > tableSpan_Current.rtf, tableSpan_Fixed.rtf > > > The right border of the table is not created if the last cell in a table row > is using number-columns-spanned. See attached RTF File -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FOP-1606) [PATCH] Incorrect border when using number-columns-spanned in RTF
[ https://issues.apache.org/jira/browse/FOP-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-1606. --- Fix Version/s: trunk Resolution: Fixed > [PATCH] Incorrect border when using number-columns-spanned in RTF > - > > Key: FOP-1606 > URL: https://issues.apache.org/jira/browse/FOP-1606 > Project: FOP > Issue Type: Bug > Components: renderer/rtf >Affects Versions: 0.95 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Max Aster >Assignee: Chris Bowditch > Labels: PatchAvailable > Fix For: trunk > > Attachments: TableCellBorderFix.txt, tableSpan.fo, > tableSpan_Current.rtf, tableSpan_Fixed.rtf > > > The right border of the table is not created if the last cell in a table row > is using number-columns-spanned. See attached RTF File -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (FOP-1606) [PATCH] Incorrect border when using number-columns-spanned in RTF
[ https://issues.apache.org/jira/browse/FOP-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOP-1606 started by Chris Bowditch. --- > [PATCH] Incorrect border when using number-columns-spanned in RTF > - > > Key: FOP-1606 > URL: https://issues.apache.org/jira/browse/FOP-1606 > Project: FOP > Issue Type: Bug > Components: renderer/rtf >Affects Versions: 0.95 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Max Aster >Assignee: Chris Bowditch > Labels: PatchAvailable > Attachments: TableCellBorderFix.txt, tableSpan.fo, > tableSpan_Current.rtf, tableSpan_Fixed.rtf > > > The right border of the table is not created if the last cell in a table row > is using number-columns-spanned. See attached RTF File -- This message was sent by Atlassian Jira (v8.3.4#803005)
