[jira] [Commented] (FOP-2569) [PATCH] Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)

2020-08-06 Thread Chris Bowditch (Jira)


[ 
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

2020-07-02 Thread Chris Bowditch (Jira)


[ 
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

2020-07-02 Thread Chris Bowditch (Jira)


 [ 
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)

2020-06-15 Thread Chris Bowditch (Jira)


[ 
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)

2020-06-15 Thread Chris Bowditch (Jira)


 [ 
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)

2020-06-15 Thread Chris Bowditch (Jira)


 [ 
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)

2020-06-12 Thread Chris Bowditch (Jira)


[ 
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)

2020-06-12 Thread Chris Bowditch (Jira)


 [ 
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)

2020-06-12 Thread Chris Bowditch (Jira)


[ 
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)

2020-06-09 Thread Chris Bowditch (Jira)


[ 
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)

2020-05-26 Thread Chris Bowditch (Jira)


[ 
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.

2020-05-18 Thread Chris Bowditch (Jira)


[ 
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.

2020-05-18 Thread Chris Bowditch (Jira)


 [ 
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.

2020-05-15 Thread Chris Bowditch (Jira)


 [ 
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.

2020-05-15 Thread Chris Bowditch (Jira)


 [ 
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.

2020-05-13 Thread Chris Bowditch (Jira)


 [ 
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

2020-05-13 Thread Chris Bowditch (Jira)


 [ 
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

2020-05-13 Thread Chris Bowditch (Jira)


 [ 
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.

2020-05-13 Thread Chris Bowditch (Jira)


[ 
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

2020-05-11 Thread Chris Bowditch (Jira)


[ 
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

2020-05-11 Thread Chris Bowditch (Jira)


 [ 
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

2020-05-11 Thread Chris Bowditch (Jira)


 [ 
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

2020-04-15 Thread Chris Bowditch (Jira)


[ 
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

2020-03-19 Thread Chris Bowditch (Jira)


 [ 
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

2020-03-19 Thread Chris Bowditch (Jira)


[ 
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

2020-03-19 Thread Chris Bowditch (Jira)


[ 
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

2020-03-19 Thread Chris Bowditch (Jira)


[ 
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

2020-03-19 Thread Chris Bowditch (Jira)


 [ 
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

2020-03-11 Thread Chris Bowditch (Jira)


[ 
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

2020-02-05 Thread Chris Bowditch (Jira)


[ 
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

2020-01-15 Thread Chris Bowditch (Jira)


[ 
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

2020-01-13 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-13 Thread Chris Bowditch (Jira)


[ 
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

2020-01-13 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-13 Thread Chris Bowditch (Jira)


 [ 
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)

2020-01-13 Thread Chris Bowditch (Jira)


[ 
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)

2020-01-13 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


[ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


[ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-08 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-07 Thread Chris Bowditch (Jira)


[ 
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

2020-01-07 Thread Chris Bowditch (Jira)


 [ 
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

2020-01-07 Thread Chris Bowditch (Jira)


 [ 
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)


[jira] [Assigned] (FOP-1606) [PATCH] Incorrect border when using number-columns-spanned in RTF

2020-01-07 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-1606:
---

Assignee: 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)


[jira] [Commented] (FOP-701) large list-item-label bleeds into following block

2020-01-07 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009763#comment-17009763
 ] 

Chris Bowditch commented on FOP-701:


Please can you attach an XSL-FO file that demos the problem? I'm not sure if 
the PDF attached more recently is relevant or not, at least I couldn't see an 
example of the problem described and with 16 years between the bug been opened 
and the file attached I suspect not.

Since this bug is now 17 years old and 0.20.5 is no longer supported I am going 
to close this, but feel free to re-open if you can attach an XSL-FO File that 
demos the issue

> large list-item-label bleeds into following block
> -
>
> Key: FOP-701
> URL: https://issues.apache.org/jira/browse/FOP-701
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>Affects Versions: 0.20.5
> Environment: Operating System: other
> Platform: Other
> URL: http://www.soggytrousers.net/repository/messed-up-list-block.pdf
>Reporter: lizzy barham
> Attachments: h12-223-Exam-Dumps-2019.pdf
>
>
> Hi,
> I was making a list somewhat like a definition list and the list-item-label is
> rather large. Unfortunatly its large height was not taken into account and
> showed up over the following block.
> Thanks! Great work btw.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (FOP-701) large list-item-label bleeds into following block

2020-01-07 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-701.
--
Resolution: Incomplete

> large list-item-label bleeds into following block
> -
>
> Key: FOP-701
> URL: https://issues.apache.org/jira/browse/FOP-701
> Project: FOP
>  Issue Type: Bug
>  Components: layout/unqualified
>Affects Versions: 0.20.5
> Environment: Operating System: other
> Platform: Other
> URL: http://www.soggytrousers.net/repository/messed-up-list-block.pdf
>Reporter: lizzy barham
> Attachments: h12-223-Exam-Dumps-2019.pdf
>
>
> Hi,
> I was making a list somewhat like a definition list and the list-item-label is
> rather large. Unfortunatly its large height was not taken into account and
> showed up over the following block.
> Thanks! Great work btw.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-1278) PNG missing for RTF output

2020-01-07 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009725#comment-17009725
 ] 

Chris Bowditch commented on FOP-1278:
-

I don't think the bug can be closed. The NPE no longer occurs, but the PNG 
appears to be a format unexpected by the RTFHandler

> PNG missing for RTF output
> --
>
> Key: FOP-1278
> URL: https://issues.apache.org/jira/browse/FOP-1278
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/rtf
>Affects Versions: trunk
> Environment: Operating System: other
> Platform: Other
>Reporter: Chris Bowditch
> Attachments: moon.png, test.fo
>
>
> Attached PNG causes a NPE when rendering to RTF. Submitted by Dominic Brugger 
> (brugger.at.puzzle.ch) Stack trace below:
> SEVERE: Error while handling an external-graphic: null
> java.lang.NullPointerException
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:920)
> at org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:215)
> at org.apache.fop.image.AbstractFopImage.loadDefaultOriginalData
> (AbstractFopImage.java:223)
> at org.apache.fop.image.ImageIOImage.loadOriginalData
> (ImageIOImage.java:217)
> at org.apache.fop.image.AbstractFopImage.load
> (AbstractFopImage.java:174)
> at org.apache.fop.render.rtf.RTFHandler.image(RTFHandler.java:1131)
> at org.apache.fop.render.rtf.RTFHandler.invokeDeferredEvent
> (RTFHandler.java:1492)
> at org.apache.fop.render.rtf.RTFHandler.recurseFONode
> (RTFHandler.java:1616)
> at org.apache.fop.render.rtf.RTFHandler.recurseFONode
> (RTFHandler.java:1687)
> at org.apache.fop.render.rtf.RTFHandler.recurseFONode
> (RTFHandler.java:1687)
> at org.apache.fop.render.rtf.RTFHandler.recurseFONode
> (RTFHandler.java:1639)
> at org.apache.fop.render.rtf.RTFHandler.endPageSequence
> (RTFHandler.java:



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2627) [PATCH] Allow relative paths to font files/directories

2020-01-07 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009614#comment-17009614
 ] 

Chris Bowditch commented on FOP-2627:
-

I don't like the suggested implementation. It uses File objects to access files 
locally, which is bad practice for services running in cloud environments

> [PATCH] Allow relative paths to font files/directories
> --
>
> Key: FOP-2627
> URL: https://issues.apache.org/jira/browse/FOP-2627
> Project: FOP
>  Issue Type: Improvement
>  Components: font/unqualified
>Affects Versions: 2.1
>Reporter: Agneta Walterscheidt
>Priority: Minor
>  Labels: patch
> Attachments: relative-paths.patch
>
>
> [PATCH]
> I have implemented support for *relative* paths to Font files and Font 
> directories in FOP configuration files. This makes it easier to ship a 
> default font configuration with an application. I have verified that all 
> tests that ran successfully before still run successfully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2892) [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected

2020-01-06 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008916#comment-17008916
 ] 

Chris Bowditch commented on FOP-2892:
-

Thanks for spotting the issue

 

fixed in At revision: 1872384

> [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() 
> does not find elements as expected
> --
>
> Key: FOP-2892
> URL: https://issues.apache.org/jira/browse/FOP-2892
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
>Reporter: Dan Caprioara
>Assignee: Chris Bowditch
>Priority: Major
>
> Starting with FOP 2.4 the avalon framework is not used anymore. 
> Instead, a {{Configuration}} implementation has been added to the FOP: 
> {{org.apache.fop.configuration.DefaultConfiguration}}
> The problem is that the {{getChild(String)}} method uses 
> {{getElementsByTagName}} that returns all matching elements in document 
> order, at any level. The old avalon implementation iterated only through the 
> direct children. This creates some bugs.
> Consider the following configuration:
> {code:xml}
> 
>   
>   
> 
>
> 
>   
> 
>   
>   
>   
>   
> 
>  font-weight='400'/>
>   
>  
>   
> 
> {code}
> The code from the {{FontManagerConfigurator}} 
> {code}
> DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts", 
> false);
> {code}
> now gets the first {{fonts}} element, the one containing the autodetect, 
> instead of getting the direct {{fonts}} element, the one containing the 
> substitutions.
> The patch that solves this is:
> {code}
> Index: DefaultConfiguration.java
> ===
> --- DefaultConfiguration.java (revision 195722)
> +++ DefaultConfiguration.java (working copy)
> @@ -108,7 +108,7 @@
>  
>  @Override
>  public Configuration getChild(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
>  if (n.getNodeName().equals(key)) {
> @@ -133,13 +133,17 @@
>  
>  @Override
>  public Configuration[] getChildren(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> -Configuration[] result = new Configuration[nl.getLength()];
> +ArrayList result = new ArrayList<>(1);
> +
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
> -result[i] = new DefaultConfiguration((Element) n);
> +if (n.getNodeName().equals(key)) {
> +  result.add(new DefaultConfiguration((Element) n));
> +}
>  }
> -return result;
> +
> +return result.toArray(new Configuration[0]);
>  }
>  
>  @Override
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (FOP-2892) [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected

2020-01-06 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch resolved FOP-2892.
-
Fix Version/s: trunk
   Resolution: Fixed

> [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() 
> does not find elements as expected
> --
>
> Key: FOP-2892
> URL: https://issues.apache.org/jira/browse/FOP-2892
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
>Reporter: Dan Caprioara
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
>
> Starting with FOP 2.4 the avalon framework is not used anymore. 
> Instead, a {{Configuration}} implementation has been added to the FOP: 
> {{org.apache.fop.configuration.DefaultConfiguration}}
> The problem is that the {{getChild(String)}} method uses 
> {{getElementsByTagName}} that returns all matching elements in document 
> order, at any level. The old avalon implementation iterated only through the 
> direct children. This creates some bugs.
> Consider the following configuration:
> {code:xml}
> 
>   
>   
> 
>
> 
>   
> 
>   
>   
>   
>   
> 
>  font-weight='400'/>
>   
>  
>   
> 
> {code}
> The code from the {{FontManagerConfigurator}} 
> {code}
> DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts", 
> false);
> {code}
> now gets the first {{fonts}} element, the one containing the autodetect, 
> instead of getting the direct {{fonts}} element, the one containing the 
> substitutions.
> The patch that solves this is:
> {code}
> Index: DefaultConfiguration.java
> ===
> --- DefaultConfiguration.java (revision 195722)
> +++ DefaultConfiguration.java (working copy)
> @@ -108,7 +108,7 @@
>  
>  @Override
>  public Configuration getChild(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
>  if (n.getNodeName().equals(key)) {
> @@ -133,13 +133,17 @@
>  
>  @Override
>  public Configuration[] getChildren(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> -Configuration[] result = new Configuration[nl.getLength()];
> +ArrayList result = new ArrayList<>(1);
> +
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
> -result[i] = new DefaultConfiguration((Element) n);
> +if (n.getNodeName().equals(key)) {
> +  result.add(new DefaultConfiguration((Element) n));
> +}
>  }
> -return result;
> +
> +return result.toArray(new Configuration[0]);
>  }
>  
>  @Override
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (FOP-2892) [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected

2020-01-06 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-2892:
---

Assignee: Chris Bowditch

> [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() 
> does not find elements as expected
> --
>
> Key: FOP-2892
> URL: https://issues.apache.org/jira/browse/FOP-2892
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
>Reporter: Dan Caprioara
>Assignee: Chris Bowditch
>Priority: Major
>
> Starting with FOP 2.4 the avalon framework is not used anymore. 
> Instead, a {{Configuration}} implementation has been added to the FOP: 
> {{org.apache.fop.configuration.DefaultConfiguration}}
> The problem is that the {{getChild(String)}} method uses 
> {{getElementsByTagName}} that returns all matching elements in document 
> order, at any level. The old avalon implementation iterated only through the 
> direct children. This creates some bugs.
> Consider the following configuration:
> {code:xml}
> 
>   
>   
> 
>
> 
>   
> 
>   
>   
>   
>   
> 
>  font-weight='400'/>
>   
>  
>   
> 
> {code}
> The code from the {{FontManagerConfigurator}} 
> {code}
> DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts", 
> false);
> {code}
> now gets the first {{fonts}} element, the one containing the autodetect, 
> instead of getting the direct {{fonts}} element, the one containing the 
> substitutions.
> The patch that solves this is:
> {code}
> Index: DefaultConfiguration.java
> ===
> --- DefaultConfiguration.java (revision 195722)
> +++ DefaultConfiguration.java (working copy)
> @@ -108,7 +108,7 @@
>  
>  @Override
>  public Configuration getChild(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
>  if (n.getNodeName().equals(key)) {
> @@ -133,13 +133,17 @@
>  
>  @Override
>  public Configuration[] getChildren(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> -Configuration[] result = new Configuration[nl.getLength()];
> +ArrayList result = new ArrayList<>(1);
> +
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
> -result[i] = new DefaultConfiguration((Element) n);
> +if (n.getNodeName().equals(key)) {
> +  result.add(new DefaultConfiguration((Element) n));
> +}
>  }
> -return result;
> +
> +return result.toArray(new Configuration[0]);
>  }
>  
>  @Override
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work started] (FOP-2892) [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected

2020-01-06 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FOP-2892 started by Chris Bowditch.
---
> [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() 
> does not find elements as expected
> --
>
> Key: FOP-2892
> URL: https://issues.apache.org/jira/browse/FOP-2892
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
>Reporter: Dan Caprioara
>Assignee: Chris Bowditch
>Priority: Major
>
> Starting with FOP 2.4 the avalon framework is not used anymore. 
> Instead, a {{Configuration}} implementation has been added to the FOP: 
> {{org.apache.fop.configuration.DefaultConfiguration}}
> The problem is that the {{getChild(String)}} method uses 
> {{getElementsByTagName}} that returns all matching elements in document 
> order, at any level. The old avalon implementation iterated only through the 
> direct children. This creates some bugs.
> Consider the following configuration:
> {code:xml}
> 
>   
>   
> 
>
> 
>   
> 
>   
>   
>   
>   
> 
>  font-weight='400'/>
>   
>  
>   
> 
> {code}
> The code from the {{FontManagerConfigurator}} 
> {code}
> DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts", 
> false);
> {code}
> now gets the first {{fonts}} element, the one containing the autodetect, 
> instead of getting the direct {{fonts}} element, the one containing the 
> substitutions.
> The patch that solves this is:
> {code}
> Index: DefaultConfiguration.java
> ===
> --- DefaultConfiguration.java (revision 195722)
> +++ DefaultConfiguration.java (working copy)
> @@ -108,7 +108,7 @@
>  
>  @Override
>  public Configuration getChild(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
>  if (n.getNodeName().equals(key)) {
> @@ -133,13 +133,17 @@
>  
>  @Override
>  public Configuration[] getChildren(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> -Configuration[] result = new Configuration[nl.getLength()];
> +ArrayList result = new ArrayList<>(1);
> +
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
> -result[i] = new DefaultConfiguration((Element) n);
> +if (n.getNodeName().equals(key)) {
> +  result.add(new DefaultConfiguration((Element) n));
> +}
>  }
> -return result;
> +
> +return result.toArray(new Configuration[0]);
>  }
>  
>  @Override
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (FOP-2011) FOP always uses the same prefix for embeded font

2020-01-06 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2011.
---
Resolution: Won't Fix

I'm closing a won't fix. As discussed above if you have a requirement to post 
process PDF or Postscript files generated by FOP then fully embedding the font 
makes this possible without having to deal with subset fonts and their random 
names

> FOP always uses the same prefix for embeded font
> 
>
> Key: FOP-2011
> URL: https://issues.apache.org/jira/browse/FOP-2011
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: PC
>Reporter: quamis
>
> After having some problems with ghostscript while trying to concatenate PDF 
> files generated by FOP, we went to the conclusion that FOP generates the 
> embedded fonts prefix by always using the same sequence.
> @see http://bugs.ghostscript.com/show_bug.cgi?id=692795 for the initial bug 
> report
> According to Ken Sharp from ghostscript, the embedded font should have an 
> unique name, non-repeatable across multiple generations. I couldn't find this 
> in the PDF specs, but i kinda lost myself trying to find anything in there, 
> so this is not really relevant.
> Basically, it seems that FOP always generates the embedded font prefix by 
> using EA, EB, EC etc sequentially when it should generate unique 
> prefixes.
> Because it generates the same prefix, gs(and the PDF viewer) cannot display 
> the required fonts. I cannot contribute a patch as i have 0 knowledge of 
> java, but i think that the prefix should be based on the current 
> timestamp+the current index(easiest), or be based on the currently embedded 
> font glyphs, this should be more accurate, but any method will do for now. 
> It should be able to disable this through the command line to allow automatic 
> unit-tests that tests binary files to not fail because of always having 
> something different in otherwise identical files.
> I have font-embeding enabled, according to 
> http://xmlgraphics.apache.org/fop/trunk/fonts.html#embedding , and it only 
> embeds used glyphs. Same thing happens though if i embed the whole font 
> (using encoding-mode).
> I have located the culprit in java\org\apache\fop\pdf\PDFFactory.java in 
> function createSubsetFontPrefix(), but as mentioned i'm unable to provide a 
> patch.
> I have found this as a related issue. 
> http://osdir.com/ml/fop-users-xmlgraphics.apache.org/2009-04/msg00127.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (FOP-2892) [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected

2019-12-13 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2892:

Summary: [PATCH] Font substitutions not working: the 
DefaultConfiguration.getChild() does not find elements as expected  (was: Font 
substitutions not working: the DefaultConfiguration.getChild() does not find 
elements as expected)

> [PATCH] Font substitutions not working: the DefaultConfiguration.getChild() 
> does not find elements as expected
> --
>
> Key: FOP-2892
> URL: https://issues.apache.org/jira/browse/FOP-2892
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
>Reporter: Dan Caprioara
>Priority: Major
>
> Starting with FOP 2.4 the avalon framework is not used anymore. 
> Instead, a {{Configuration}} implementation has been added to the FOP: 
> {{org.apache.fop.configuration.DefaultConfiguration}}
> The problem is that the {{getChild(String)}} method uses 
> {{getElementsByTagName}} that returns all matching elements in document 
> order, at any level. The old avalon implementation iterated only through the 
> direct children. This creates some bugs.
> Consider the following configuration:
> {code:xml}
> 
>   
>   
> 
>
> 
>   
> 
>   
>   
>   
>   
> 
>  font-weight='400'/>
>   
>  
>   
> 
> {code}
> The code from the {{FontManagerConfigurator}} 
> {code}
> DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts", 
> false);
> {code}
> now gets the first {{fonts}} element, the one containing the autodetect, 
> instead of getting the direct {{fonts}} element, the one containing the 
> substitutions.
> The patch that solves this is:
> {code}
> Index: DefaultConfiguration.java
> ===
> --- DefaultConfiguration.java (revision 195722)
> +++ DefaultConfiguration.java (working copy)
> @@ -108,7 +108,7 @@
>  
>  @Override
>  public Configuration getChild(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
>  if (n.getNodeName().equals(key)) {
> @@ -133,13 +133,17 @@
>  
>  @Override
>  public Configuration[] getChildren(String key) {
> -NodeList nl = element.getElementsByTagName(key);
> -Configuration[] result = new Configuration[nl.getLength()];
> +ArrayList result = new ArrayList<>(1);
> +
> +NodeList nl = element.getChildNodes();
>  for (int i = 0; i < nl.getLength(); ++i) {
>  Node n = nl.item(i);
> -result[i] = new DefaultConfiguration((Element) n);
> +if (n.getNodeName().equals(key)) {
> +  result.add(new DefaultConfiguration((Element) n));
> +}
>  }
> -return result;
> +
> +return result.toArray(new Configuration[0]);
>  }
>  
>  @Override
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2890) fo:change-bar problem with AT format

2019-12-12 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16994836#comment-16994836
 ] 

Chris Bowditch commented on FOP-2890:
-

AT is way more complex than IF, which was designed to be simple. I am surprised 
you think it is the other way round. As I mentioned AT is considered legacy and 
shouldn't be relied on

> fo:change-bar problem with AT format
> 
>
> Key: FOP-2890
> URL: https://issues.apache.org/jira/browse/FOP-2890
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
> Environment: Tested on Windows 8/10 and Mac OSX 10.15
>Reporter: Michele baravalle
>Priority: Major
> Fix For: 2.4
>
> Attachments: testChangeBar.fo
>
>
>  
>   
>  Good morning, 
>  I would like to report the following problem.
> Add fo:change-bar on any fo file and make PDF with fop: it work well. Then 
> make AT format with the same fo file and then make PDF from the generated AT 
> file: output is wrong (change bar and text are overlapped and moved)
> Regards
> Used commands:
>  * PDF (work well): fop testChangeBar.fo -pdf ok.pdf
>  * AT + PDF (wrong): fop testChangeBar.fo -at test.at
>  and then 
>  fop -atin test.at -pdf wrong.pdf



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2890) fo:change-bar problem with AT format

2019-12-12 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16994813#comment-16994813
 ] 

Chris Bowditch commented on FOP-2890:
-

I'm not sure it makes sense to fix a bug in AT. That is a legacy format 
superceded by IF XML. Have you tried Change Bars with IF XML?

> fo:change-bar problem with AT format
> 
>
> Key: FOP-2890
> URL: https://issues.apache.org/jira/browse/FOP-2890
> Project: FOP
>  Issue Type: Bug
>  Components: unqualified
>Affects Versions: 2.4
> Environment: Tested on Windows 8/10 and Mac OSX 10.15
>Reporter: Michele baravalle
>Priority: Major
> Fix For: 2.4
>
> Attachments: testChangeBar.fo
>
>
>  
>   
>  Good morning, 
>  I would like to report the following problem.
> Add fo:change-bar on any fo file and make PDF with fop: it work well. Then 
> make AT format with the same fo file and then make PDF from the generated AT 
> file: output is wrong (change bar and text are overlapped and moved)
> Regards
> Used commands:
>  * PDF (work well): fop testChangeBar.fo -pdf ok.pdf
>  * AT + PDF (wrong): fop testChangeBar.fo -at test.at
>  and then 
>  fop -atin test.at -pdf wrong.pdf



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2888) Byte array different each time I generate a PDF

2019-12-02 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985917#comment-16985917
 ] 

Chris Bowditch commented on FOP-2888:
-

The fact that you can't unit test is not a bug. This is just a question about 
how to compare PDFs. I suggest asking on fop-user mailing list for ideas. I am 
closing this bug

> Byte array different each time I generate a PDF
> ---
>
> Key: FOP-2888
> URL: https://issues.apache.org/jira/browse/FOP-2888
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>Affects Versions: 2.1
>Reporter: Victor Balta
>Priority: Major
>
> I have been using the FopFactory & FOUserAgent to render a PDF from an xsl & 
> xml. This is working correctly however I'm running into an issue when writing 
> my unit test.
> I save the output PDF and in my unit test I am doing a render and then doing 
> a byte[] compare. What I noticed is that the byte array is different each 
> time I do a render.
> When I compare the PDF's I am not able to see anything visually different. 
> Does anyone know why it is changing each render? 
> I tried setting the FOUserAgent creation date, but it still shows differences 
> each render



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (FOP-2888) Byte array different each time I generate a PDF

2019-12-02 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2888.
---
Resolution: Not A Bug

> Byte array different each time I generate a PDF
> ---
>
> Key: FOP-2888
> URL: https://issues.apache.org/jira/browse/FOP-2888
> Project: FOP
>  Issue Type: Bug
>  Components: renderer/pdf
>Affects Versions: 2.1
>Reporter: Victor Balta
>Priority: Major
>
> I have been using the FopFactory & FOUserAgent to render a PDF from an xsl & 
> xml. This is working correctly however I'm running into an issue when writing 
> my unit test.
> I save the output PDF and in my unit test I am doing a render and then doing 
> a byte[] compare. What I noticed is that the byte array is different each 
> time I do a render.
> When I compare the PDF's I am not able to see anything visually different. 
> Does anyone know why it is changing each render? 
> I tried setting the FOUserAgent creation date, but it still shows differences 
> each render



--
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)

2019-10-22 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956890#comment-16956890
 ] 

Chris Bowditch commented on FOP-2880:
-

The patch seems like a hack to me. I know you describe it as a prototype, but 
why not just fix CodePointMapping? This is generated code from glyphlist.xml 
file. This is based on a very old Adobe Glyphlist.txt file, and SoftHyphen 
appear absent from glyphlist.xml, with 0x00AD being mapped instead to hyphen. 
But softhyphen is correctly defined in the latest Adobe Glyphlist.txt. So 
updating glyphlist.xml and possibly encoding.xml to resolve this seems like the 
way to resolve this properly

> [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();
>

[jira] [Closed] (FOP-2884) Rendering emoji doesn't work

2019-09-26 Thread Chris Bowditch (Jira)


 [ 
https://issues.apache.org/jira/browse/FOP-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2884.
---
Resolution: Not A Bug

Not a bug as explained by Simon in the previous comment

> Rendering emoji doesn't work
> 
>
> Key: FOP-2884
> URL: https://issues.apache.org/jira/browse/FOP-2884
> Project: FOP
>  Issue Type: Bug
>  Components: font/unqualified
>Affects Versions: 2.3
> Environment: oracle-jdk-11, ubuntu Linux
>Reporter: Andreas Joseph Krogh
>Priority: Major
> Attachments: pdf_with_smiley_test.pdf
>
>
> The following code (in Scala, but it's easy enough to understand for 
> Java-devs) renders the smiley-emoji  as '#'-character.
>  
> {code:java}
> import java.io.ByteArrayInputStream
> import java.nio.file.{Files, Paths, StandardOpenOption}
> import javax.xml.transform.sax.SAXResult
> import javax.xml.transform.stream.StreamSource
> import javax.xml.transform.{Result, Transformer, TransformerFactory}
> import org.apache.fop.apps.{Fop, FopFactoryBuilder}
> import org.apache.xmlgraphics.util.MimeConstants
> import org.testng.annotations.Test
> class PdfWithSmileyTest {
>@Test
>def generatePdfWithSmileyTets(): Unit = {
>   val xml =
>  """
>|http://www.w3.org/1999/XSL/Format;>
>|
>||  margin-right="17mm"
>|  margin-left="17mm"
>|  margin-bottom="0cm"
>|  margin-top="14mm"
>|  page-width="29.1cm"
>|  page-height="21cm"
>|  master-name="document">
>|background-color="#ff"/>
>|background-color="#ff"/>
>|background-color="#ff"/>
>|
>|
>|
>|
>|Hi  smile!
>|
>|
>|
>|""".stripMargin
>   val tmpFilePath = Paths.get("/tmp/pdf_with_smiley_test.pdf")
>   val out = Files.newOutputStream(tmpFilePath, 
> StandardOpenOption.TRUNCATE_EXISTING)
>   val fopFactory = new 
> FopFactoryBuilder(getClass.getResource("/").toURI).build
>   val agent = fopFactory.newFOUserAgent()
>   val fop: Fop = fopFactory.newFop(MimeConstants.MIME_PDF, agent, out)
>   val transformer: Transformer = 
> TransformerFactory.newInstance.newTransformer
>   val res: Result = new SAXResult(fop.getDefaultHandler)
>   val source = new StreamSource(new ByteArrayInputStream(xml.getBytes()))
>   transformer.transform(source, res)
>}
> }
> {code}
> The output in the PDF is "Hi # smile!" instead of "Hi  smile!"
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2882) Allow PDFFormXObject to improve performance

2019-09-25 Thread Chris Bowditch (Jira)


[ 
https://issues.apache.org/jira/browse/FOP-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937814#comment-16937814
 ] 

Chris Bowditch commented on FOP-2882:
-

Is there an associated documentation change for this? I can't see one in the 
SVN commit

> Allow PDFFormXObject to improve performance
> ---
>
> Key: FOP-2882
> URL: https://issues.apache.org/jira/browse/FOP-2882
> Project: FOP
>  Issue Type: Bug
>Reporter: simon steiner
>Assignee: simon steiner
>Priority: Major
> Attachments: fop.xconf, in.pdf, test.fo
>
>
> PDF with large content stream has poor performance
>  
> fop test.fo -c fop.xconf out.pdf
> should take a few seconds



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FOP-2854) CreationDate in PDF metadata breaks reproducible builds

2019-07-22 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890198#comment-16890198
 ] 

Chris Bowditch commented on FOP-2854:
-

I don't see how fixing the create date to the Unix Epoch will help you compare 
linux distros either. As I mentioned above if you regenerate a PDF File, 
internal IDs could change as well as the date. So an alternative means of 
comparing PDFs within Linux distros is needed. Or perhaps a PDF should be 
treated as static when rebuilding the Linux distro

> CreationDate in PDF metadata breaks reproducible builds
> ---
>
> Key: FOP-2854
> URL: https://issues.apache.org/jira/browse/FOP-2854
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: 2.3
> Environment: Debian GNU/Linux
>Reporter: Filippo Rusconi
>Priority: Major
>
> Greetings,
> I would like to report that the CreationDate value that is set in the PDF 
> file changes at each run. This is problematic because that makes it 
> impossible to run FOP in the context of reproducible builds (see 
> https://wiki.debian.org/ReproducibleBuilds).
> Would it be possible to create an option to set that date value manually or 
> some equivalent solution to this problem ?
> Thank you so much for your work on FOP !
> Regards,
> Filippo



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-04 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch resolved FOP-2624.
-
Resolution: Fixed

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-04 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855851#comment-16855851
 ] 

Chris Bowditch commented on FOP-2624:
-

committed fix in Revision: 1860626

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-04 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2624:

Fix Version/s: trunk

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-04 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-2624:
---

Assignee: Chris Bowditch

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-04 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855792#comment-16855792
 ] 

Chris Bowditch commented on FOP-2624:
-

I've worked out this bug is caused by changes for FOP-1918. I have a potential 
fix for it

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Priority: Major
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell

2019-06-03 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854683#comment-16854683
 ] 

Chris Bowditch commented on FOP-2624:
-

[~vinodsankar] FOP is open source and so bugs are fixed by volunteers. Feel 
free to jump in and help

When running your FO File I am getting a lot of validation errors like:

 

org.apache.fop.fo.ValidationException: Invalid property encountered on 
"fo:list-block": list-style-type (See position 142:119)

 

I will have a go at fixing them, but to save time and avoid further delays 
provide clean XSL-FO up front is the effective way to get a resolution

> FO to RTF conversion adds unnecessary \cell after 
> ... when it is nested inside any table cell
> 
>
> Key: FOP-2624
> URL: https://issues.apache.org/jira/browse/FOP-2624
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: jaydeep V
>Priority: Major
> Attachments: FO.xml, HTML.html, RTF.rtf
>
>
> I am trying to convert from FO to RTF here, The version of FOP i am using is 
> 1.1
> let say below is my FO
> ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> •
> 
>  
>  test data
> 
>  
> ...(similarly many list items)..
> 
> ..(some more fo:block div data)..
> 
> 
> 
> 
> here immediately after the  RTF is addind '\cell', Because of 
> that even though there is some data after list block RTF treats it as end of 
> table cell. 
> so Rest of the data after list block won't be visible in RTF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (FOP-2857) [PATCH] FontCache.toDirectory() and FontCache.getDefaultCacheFile() not working correctly

2019-04-11 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2857:

Summary: [PATCH] FontCache.toDirectory() and 
FontCache.getDefaultCacheFile() not working correctly  (was: 
FontCache.toDirectory() and FontCache.getDefaultCacheFile() work not correct)

> [PATCH] FontCache.toDirectory() and FontCache.getDefaultCacheFile() not 
> working correctly
> -
>
> Key: FOP-2857
> URL: https://issues.apache.org/jira/browse/FOP-2857
> Project: FOP
>  Issue Type: Bug
>  Components: font/unqualified
>Affects Versions: 2.3
>Reporter: Vera Straube
>Priority: Critical
> Attachments: FontCache.java.patch, FontCache.java.patch2
>
>
> The function getDefaultCacheFile() of the class FontCache should work like 
> this:
> [1] case:   select user_dir
> -> user_dir:'C:\Users\strv'
> -> temp_dir:'C:\Users\strv\AppData\Local\Temp\'
> -> cache_file:  'C:\Users\strv\.fop\fop-fonts.cache'
> [2] case:   select temp_dir
> -> user_dir:''
> -> temp_dir:'C:\Users\strv\AppData\Local\Temp\'
> -> cache_file:  'C:\Users\strv\AppData\Local\Temp\.fop\fop-fonts.cache'
> [3] case:   select curr_dir
> -> user_dir:''
> -> temp_dir:''
> -> cache_file:  'fop-fonts.cache'
> Actually it works uncorrectly like this:
> [1] case:   select user_dir
> -> user_dir:'C:\Users\strv'
> -> temp_dir:'C:\Users\strv\AppData\Local\Temp\'
> -> cache_file:  'C:\Users\strv\.fop\fop-fonts.cache'
> [2] case:   select temp_dir
> -> user_dir:''
> -> temp_dir:'C:\Users\strv\AppData\Local\Temp\'
> -> cache_file:  '.fop'  --> wrong behavior !!!
> [3] case:   select curr_dir
> -> user_dir:''
> -> temp_dir:''
> -> cache_file:  '.fop'  --> wrong behavior !!!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-29 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804783#comment-16804783
 ] 

Chris Bowditch edited comment on FOP-2514 at 3/29/19 10:25 AM:
---

It's been a while since I did any hyphenation work. The cause of the unit test 
failure was just a config issue on my end. My bad.  So this fix is not 
committed in revision 1856528. Thanks for the patch


was (Author: cbowditch):
It's been a while since I did any hyphenation wotk. The cause of the unit test 
failure was just a config issue on my end. My bad.  SO this fix is not 
committed in revision 1856528. Thanks for the patch

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-29 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804783#comment-16804783
 ] 

Chris Bowditch commented on FOP-2514:
-

It's been a while since I did any hyphenation wotk. The cause of the unit test 
failure was just a config issue on my end. My bad.  SO this fix is not 
committed in revision 1856528. Thanks for the patch

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-29 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2514.
---
   Resolution: Fixed
Fix Version/s: trunk

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2854) CreationDate in PDF metadata breaks reproducible builds

2019-03-28 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804002#comment-16804002
 ] 

Chris Bowditch commented on FOP-2854:
-

Most people overcome this issue by loading the PDF using a library such as 
PDFBox and comparing the parts of the PDF they care about

It's not only dates that change by object reference IDs and other data 
structures within the PDF. I don't think this enhancement request is feasible 
nor within scope of FOP, whose responsibility it is generate valid PDF, not 
solve upstream problems in relation to comparison

> CreationDate in PDF metadata breaks reproducible builds
> ---
>
> Key: FOP-2854
> URL: https://issues.apache.org/jira/browse/FOP-2854
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: 2.3
> Environment: Debian GNU/Linux
>Reporter: Filippo Rusconi
>Priority: Major
>
> Greetings,
> I would like to report that the CreationDate value that is set in the PDF 
> file changes at each run. This is problematic because that makes it 
> impossible to run FOP in the context of reproducible builds (see 
> https://wiki.debian.org/ReproducibleBuilds).
> Would it be possible to create an option to set that date value manually or 
> some equivalent solution to this problem ?
> Thank you so much for your work on FOP !
> Regards,
> Filippo



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (FOP-2854) CreationDate in PDF metadata breaks reproducible builds

2019-03-28 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2854.
---
Resolution: Won't Fix

> CreationDate in PDF metadata breaks reproducible builds
> ---
>
> Key: FOP-2854
> URL: https://issues.apache.org/jira/browse/FOP-2854
> Project: FOP
>  Issue Type: Improvement
>  Components: renderer/pdf
>Affects Versions: 2.3
> Environment: Debian GNU/Linux
>Reporter: Filippo Rusconi
>Priority: Major
>
> Greetings,
> I would like to report that the CreationDate value that is set in the PDF 
> file changes at each run. This is problematic because that makes it 
> impossible to run FOP in the context of reproducible builds (see 
> https://wiki.debian.org/ReproducibleBuilds).
> Would it be possible to create an option to set that date value manually or 
> some equivalent solution to this problem ?
> Thank you so much for your work on FOP !
> Regards,
> Filippo



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803046#comment-16803046
 ] 

Chris Bowditch commented on FOP-2514:
-

I still can't commit your change. Looks like it breaks a unit test:

[junit] Testcase: runTest[6](org.apache.fop.intermediate.IFTestCase):
FAILED
 [junit] Expected XPath expression to evaluate to 'true', but got '' (XPath:
/descendant::if:text[1]/@hyphenated)
 [junit] junit.framework.AssertionFailedError: Expected XPath expression to e
valuate to 'true', but got '' (XPath: /descendant::if:text[1]/@hyphenated)
 [junit] at org.apache.fop.layoutengine.EvalCheck.doCheck(EvalCheck.java:
86)
 [junit] at org.apache.fop.layoutengine.EvalCheck.check(EvalCheck.java:65
)

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802983#comment-16802983
 ] 

Chris Bowditch commented on FOP-2514:
-

On second thought, I had a go at inheriting CharacterProperty from 
OptionalCharacterProperty. It only saves 2 member variable declarations and the 
definition of getObject() and causes a number of problems. So I'm happy to 
accept the patch as-is

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FOP-2514 started by Chris Bowditch.
---
> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-2514:
---

Assignee: Chris Bowditch

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work stopped] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FOP-2514 stopped by Chris Bowditch.
---
> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-2514:
---

Assignee: (was: Chris Bowditch)

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802885#comment-16802885
 ] 

Chris Bowditch commented on FOP-2514:
-

I've confirmed the fix works. However, I don't like the fact a lot of the code 
in CharacterProperty has been copied into the new class 
OptionalCharacterProperty. I'd prefer it if OptionalCharacterProperty extended 
CharacterProperty to reduce code duplication

Ideally the patch should include a unit test as well, but I can overlook that 
if you can fix the inheritance of OptionalCharacterProperty

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2514:

Attachment: hyphen.fo

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FOP-2514 started by Chris Bowditch.
---
> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (FOP-2514) [PATCH] Empty hyphenation-character leads to "String index out of range: 0"

2019-03-27 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch reassigned FOP-2514:
---

Assignee: Chris Bowditch

> [PATCH] Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Assignee: Chris Bowditch
>Priority: Major
> Attachments: hyphen.fo, issue-2514.patch
>
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2514) Empty hyphenation-character leads to "String index out of range: 0"

2019-02-28 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780428#comment-16780428
 ] 

Chris Bowditch commented on FOP-2514:
-

Thanks for developing a fix for the issue. However, the process for submitting 
patches is to attached a SVN diff file, see: 
[https://xmlgraphics.apache.org/fop/dev/#patches]

> Empty hyphenation-character leads to "String index out of range: 0"
> ---
>
> Key: FOP-2514
> URL: https://issues.apache.org/jira/browse/FOP-2514
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
>
> If you set hyphenation-character to the empty value, then you get the error 
> message "String index out of range: 0".
> If there is no hyphenation-character set, there should simply nothing be used.
> This is useful in cases where you want hyphenation but no hyphenation 
> character like in program listings or similar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2522) Soft hyphens in front of some characters are transformed to hyphen-minus

2019-02-28 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780427#comment-16780427
 ] 

Chris Bowditch commented on FOP-2522:
-

Thanks for developing a fix for the issue. However, the process for submitting 
patches is to attached a SVN diff file, see: 
https://xmlgraphics.apache.org/fop/dev/#patches

> 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
>
> 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
(v7.6.3#76005)


[jira] [Commented] (FOP-2515) Use default value for keep-with-next if inherit and parent has no explicit value

2019-02-28 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780429#comment-16780429
 ] 

Chris Bowditch commented on FOP-2515:
-

Thanks for developing a fix for the issue. However, the process for submitting 
patches is to attach a SVN diff file, see: 
[https://xmlgraphics.apache.org/fop/dev/#patches]

> Use default value for keep-with-next if inherit and parent has no explicit 
> value
> 
>
> Key: FOP-2515
> URL: https://issues.apache.org/jira/browse/FOP-2515
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
>
> If I have keep-with-next="inherit" on a fo:block, but no explicit value on 
> the parent FO, FOP tells me this with {{keep-with-next="inherit" on fo:block, 
> but no explicit value found on the parent FO.}}.
> I'd expect that inherit just inherits what is used on the parent, no matter 
> whether this is explicitly set or not.
> So if the parent is using the default value, the one that inherits should 
> simply also use the default value and not output anyhting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2834) Patch for support to launch fop command from the MSYS2/MINGW bash on Windows

2019-01-10 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739228#comment-16739228
 ] 

Chris Bowditch commented on FOP-2834:
-

I've re-classified this as an improvement as it was never intended for FOP's 
scripts to support MSYS2 out of the box

> Patch for support to launch fop command from the MSYS2/MINGW bash on Windows
> 
>
> Key: FOP-2834
> URL: https://issues.apache.org/jira/browse/FOP-2834
> Project: FOP
>  Issue Type: Improvement
>  Components: unqualified
>Affects Versions: 2.3
> Environment: Windows 7/10 with MSYS2 (www.msys2.org)
>Reporter: Gerrit Albrecht
>Priority: Minor
>  Labels: FOP, MSYS
> Fix For: 2.3
>
> Attachments: fop-2.3-msys2.patch
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> When using the fop 2.3 binary download with a MSYS2 shell, the fop command in 
> the main directory fails because it does not know anything about MSYS2. Same 
> problem exists after running fop from a MINGW32/64 bash. The fop.bat worked 
> out of the box but would need cmd.exe.
> The patch (for fop 1.0) is from here: 
> [https://gist.github.com/lammermann/1307565]
> My patch enables MSYS2 too (MSYS2 uses different uname's for its shells) and 
> targets version 2.3.
> To test it you need a JAVA_HOME env variable which leads to a JRE (tested 
> with jre1.8.0_192) and you have to add $JAVA_HOME/bin and fop-2.3/fop to the 
> PATH variable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (FOP-2834) Patch for support to launch fop command from the MSYS2/MINGW bash on Windows

2019-01-10 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2834:

Issue Type: Improvement  (was: Bug)

> Patch for support to launch fop command from the MSYS2/MINGW bash on Windows
> 
>
> Key: FOP-2834
> URL: https://issues.apache.org/jira/browse/FOP-2834
> Project: FOP
>  Issue Type: Improvement
>  Components: unqualified
>Affects Versions: 2.3
> Environment: Windows 7/10 with MSYS2 (www.msys2.org)
>Reporter: Gerrit Albrecht
>Priority: Minor
>  Labels: FOP, MSYS
> Fix For: 2.3
>
> Attachments: fop-2.3-msys2.patch
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> When using the fop 2.3 binary download with a MSYS2 shell, the fop command in 
> the main directory fails because it does not know anything about MSYS2. Same 
> problem exists after running fop from a MINGW32/64 bash. The fop.bat worked 
> out of the box but would need cmd.exe.
> The patch (for fop 1.0) is from here: 
> [https://gist.github.com/lammermann/1307565]
> My patch enables MSYS2 too (MSYS2 uses different uname's for its shells) and 
> targets version 2.3.
> To test it you need a JAVA_HOME env variable which leads to a JRE (tested 
> with jre1.8.0_192) and you have to add $JAVA_HOME/bin and fop-2.3/fop to the 
> PATH variable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2826) PDF/A validation error: CIDset in subset font is incomplete

2018-11-28 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701926#comment-16701926
 ] 

Chris Bowditch commented on FOP-2826:
-

FOP provides subset option because PDF/A is not on by default. PDF/A is just 
another option. It seems that PDF/A and subset options are incompatible with 
each other

> PDF/A validation error: CIDset in subset font is incomplete
> ---
>
> Key: FOP-2826
> URL: https://issues.apache.org/jira/browse/FOP-2826
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Radek Bidlo
>Priority: Major
> Attachments: samples.zip
>
>
> When the PDF/A documents generated by FOP *with the font 
> embedding-mode="subset"* are validated for PDF/A conformance by validators 
> based on Adobe Preflight, these validators report the following error:
> *CIDset in subset font is incomplete*
> More precisely, the attached samples are the PDF/A-1b documents, but the same 
> issue occurs also for other PDF/A variants.
> This issue occurs also in PDF/A documents generated from previous versions of 
> FOP.
> Please see the attached [^samples.zip], where you can find:
> - TTF fonts used for the samples
> - FOP configuration files with both the full and subset embedding mode
> - sample FO input file for FOP
> - resulting PDF/A documents subset.pdf (of which validation reports the 
> error) and full.pdf (which is without errors)
> This issue complicates the document processing, where the PDF/A conformance 
> validation is performed and the no error result is expected to allow further 
> processing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2826) PDF/A validation error: CIDset in subset font is incomplete

2018-11-20 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693322#comment-16693322
 ] 

Chris Bowditch commented on FOP-2826:
-

I don't see this as a bug. You ask FOP to create a subset font, but PDF/A 
requires the complete font. That's why you get the error validating in PDF/A. 
The solution is to embed the entire font instead of subset. The workaround 
mentioned by Simon is the solution not workaround. How else can this be solved?

> PDF/A validation error: CIDset in subset font is incomplete
> ---
>
> Key: FOP-2826
> URL: https://issues.apache.org/jira/browse/FOP-2826
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Radek Bidlo
>Priority: Major
> Attachments: samples.zip
>
>
> When the PDF/A documents generated by FOP *with the font 
> embedding-mode="subset"* are validated for PDF/A conformance by validators 
> based on Adobe Preflight, these validators report the following error:
> *CIDset in subset font is incomplete*
> More precisely, the attached samples are the PDF/A-1b documents, but the same 
> issue occurs also for other PDF/A variants.
> This issue occurs also in PDF/A documents generated from previous versions of 
> FOP.
> Please see the attached [^samples.zip], where you can find:
> - TTF fonts used for the samples
> - FOP configuration files with both the full and subset embedding mode
> - sample FO input file for FOP
> - resulting PDF/A documents subset.pdf (of which validation reports the 
> error) and full.pdf (which is without errors)
> This issue complicates the document processing, where the PDF/A conformance 
> validation is performed and the no error result is expected to allow further 
> processing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (FOP-2826) PDF/A validation error: CIDset in subset font is incomplete

2018-11-20 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch closed FOP-2826.
---
Resolution: Not A Bug

> PDF/A validation error: CIDset in subset font is incomplete
> ---
>
> Key: FOP-2826
> URL: https://issues.apache.org/jira/browse/FOP-2826
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Radek Bidlo
>Priority: Major
> Attachments: samples.zip
>
>
> When the PDF/A documents generated by FOP *with the font 
> embedding-mode="subset"* are validated for PDF/A conformance by validators 
> based on Adobe Preflight, these validators report the following error:
> *CIDset in subset font is incomplete*
> More precisely, the attached samples are the PDF/A-1b documents, but the same 
> issue occurs also for other PDF/A variants.
> This issue occurs also in PDF/A documents generated from previous versions of 
> FOP.
> Please see the attached [^samples.zip], where you can find:
> - TTF fonts used for the samples
> - FOP configuration files with both the full and subset embedding mode
> - sample FO input file for FOP
> - resulting PDF/A documents subset.pdf (of which validation reports the 
> error) and full.pdf (which is without errors)
> This issue complicates the document processing, where the PDF/A conformance 
> validation is performed and the no error result is expected to allow further 
> processing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (FOP-2820) [PATCH] Top/Bottom borders and padding of block containers are repeated after the page break

2018-10-15 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649881#comment-16649881
 ] 

Chris Bowditch commented on FOP-2820:
-

I'm not sure this is a bug. A block-container has a different purpose to an 
fo:block. Did you check the specification?

> [PATCH] Top/Bottom borders and padding of block containers are repeated after 
> the page break
> 
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
>  Issue Type: Bug
>  Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml, 
> fo-block-container.png, fo-block.png, fop.patch
>
>
> There is a big difference between a block and a block-container regarding the 
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
>  !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the 
> text, chck the borders):
>  !fo-block-container.png!
> If you have a longer text in the block container and it spans on several 
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (FOP-2820) [PATCH] Top/Bottom borders and padding of block containers are repeated after the page break

2018-10-15 Thread Chris Bowditch (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Bowditch updated FOP-2820:

Summary: [PATCH] Top/Bottom borders and padding of block containers are 
repeated after the page break  (was: Top/Bottom borders and padding of block 
containers are repeated after the page break)

> [PATCH] Top/Bottom borders and padding of block containers are repeated after 
> the page break
> 
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
>  Issue Type: Bug
>  Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml, 
> fo-block-container.png, fo-block.png, fop.patch
>
>
> There is a big difference between a block and a block-container regarding the 
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
>  !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the 
> text, chck the borders):
>  !fo-block-container.png!
> If you have a longer text in the block container and it spans on several 
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (FOP-2810) [PATCH] Incomplete implementation of the simulate-style flag

2018-09-03 Thread Chris Bowditch (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602187#comment-16602187
 ] 

Chris Bowditch edited comment on FOP-2810 at 9/3/18 3:05 PM:
-

I have managed to replicate this using a document with a mixture of Western and 
Arabic scripts, but unfortunately its a confidential XSL-FO, so I can't share 
it here. 


was (Author: cbowditch):
I have managed to replicate this using a document with a mixture of Western and 
Arabic scripts, but unfortunately its a confidential XSL-FO, so I can't share 
it here. I also noticed a side issue; The Simulated font styles are reported as 
missing when they shouldn't be cos we are simulating them!

> [PATCH] Incomplete implementation of the simulate-style flag
> 
>
> Key: FOP-2810
> URL: https://issues.apache.org/jira/browse/FOP-2810
> Project: FOP
>  Issue Type: Bug
>  Components: font/unqualified
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Assignee: Chris Bowditch
>Priority: Major
> Fix For: trunk
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The CustomFont.getSimulateStyle() is used only in:
> {code:java}
> org.apache.fop.render.pdf.PDFPainter.drawTextWithDX(int, int, String, 
> FontTriplet, int, int, int[])
> {code}
> But not in:
> {code:java}
> org.apache.fop.render.pdf.PDFPainter.drawTextWithDP(int, int, String, 
> FontTriplet, int, int, int[][])
> {code}
> As a result some of the font styling is not applied.
> Modifying the above method with the following patch seem to fix the problem:
> {code:java}
> ...
>boolean simulateStyle = tf instanceof CustomFont && ((CustomFont) 
> tf).getSimulateStyle();
> 
> // PATCH START 
> // Taken from #drawTextWithDX method
> double shear = 0;
>   
> if (simulateStyle) {
> //Adding this breaks the PDF: generator.add("q\n")
> if (triplet.getWeight() == 700) {
> generator.add("2 Tr 0.31543 w\n");
> }
> if (triplet.getStyle().equals("italic")) {
> shear = 0.333;
> }
> }
> // PATCH END
> tu.writeTextMatrix(new AffineTransform(1, 0, shear, -1, x / 
> 1000f, y / 1000f));
> tu.updateTf(fk, fsPoints, true);
>generator.updateCharacterSpacing(letterSpacing / 1000f);
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


  1   2   3   >