[jira] [Assigned] (FOP-3089) Corrupt font display in iOS when using PDF-Images with merge-fonts=true
[
https://issues.apache.org/jira/browse/FOP-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3089:
--
Assignee: Simon Steiner
> Corrupt font display in iOS when using PDF-Images with merge-fonts=true
> ---
>
> Key: FOP-3089
> URL: https://issues.apache.org/jira/browse/FOP-3089
> Project: FOP
> Issue Type: Bug
> Environment: Both Windows and Linux (CentOS)
>Reporter: Mark Gibson
>Assignee: Simon Steiner
>Priority: Major
> Attachments: CorrupPdfViewComparison.png, fop-mergefonts.xml,
> fop.xml, image1.pdf, pdf-images-mergefonts.pdf, pdf-images.fo, pdf-images.pdf
>
>
> Using PDF-Images to inject a PDF as an image (fo:external-graphic). When
> setting merge-fonts=true in fop config, there are visual issues with the
> fonts in the embedded image when viewing the rendered PDF on in-browser
> viewers on iOS.
> All tests have been carried out using FOP 2.7. When merge-fonts=false, the
> PDF displays fine in all known browsers.
> Tested viewing on latest iPadOS 15.6, and iOS 15.6, latest browser versions
> for Safari, Chrome, and DuckDuckGo.
> Viewing the rendered PDF on windows browsers, the PDF displays fine.
> Ironically, when viewing the PDF on the Adobe Acrobat app for iOS, it
> displays fine. Apologies, I don't have access to Linux to test browsers
> there.
> I've attached some files for reproduction:
> * *{{pdf-images.fo}}*
> * *{{image1.pdf}}* - image being embedded
> * *{{fop.xml}}* - fop config with merge-fonts=false
> * *{{fop-mergefonts.xml}}* - fop config with merge-fonts=true
> * *{{pdf-images.pdf}}* - PDF rendered with merge-fonts=false
> * *{{pdf-images-mergefonts.pdf}}* - PDF rendered with merge-fonts=true
> I also attached a screenshot of the two PDFs as viewed on an iOS device.
> Fonts (calibri.ttf, calibrib.ttf) can be provided on request.
> Commands to render the two PDFs are as follows:
> * {{…/fop.bat -fo pdf-images.fo -c fop.xml -pdf pdf-images.pdf}}
> * {{…/fop.bat -fo pdf-images.fo -c fop-mergefonts.xml -pdf
> pdf-images-mergefonts.pdf}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580767#comment-17580767
]
Simon Steiner edited comment on FOP-3088 at 8/17/22 12:37 PM:
--
Can you reference
+--- org.apache.xmlgraphics:fop-util:2.6
+--- org.apache.xmlgraphics:fop-events:2.6
\--- org.apache.xmlgraphics:fop-core:2.6
instead of the parent, as the parent is designed for cmd line use outside of mvn
was (Author: ssteiner1):
Can you reference
+--- org.apache.xmlgraphics:fop-util:2.6
+--- org.apache.xmlgraphics:fop-events:2.6
\--- org.apache.xmlgraphics:fop-core:2.6
instead of the parent, as the parent is designed for cmd line use standalone
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3088:
--
Assignee: (was: Simon Steiner)
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580767#comment-17580767
]
Simon Steiner commented on FOP-3088:
Can you reference
+--- org.apache.xmlgraphics:fop-util:2.6
+--- org.apache.xmlgraphics:fop-events:2.6
\--- org.apache.xmlgraphics:fop-core:2.6
instead of the parent, as the parent is designed for cmd line use standalone
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner updated FOP-3088:
---
Fix Version/s: (was: trunk)
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (FOP-3088) Jar packaging duplicates classes on classpath
[ https://issues.apache.org/jira/browse/FOP-3088 ]
Simon Steiner deleted comment on FOP-3088:
was (Author: ssteiner1):
http://svn.apache.org/viewvc?view=revision=1903486
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reopened FOP-3088:
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
> Fix For: trunk
>
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3088.
Fix Version/s: trunk
Resolution: Fixed
http://svn.apache.org/viewvc?view=revision=1903486
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
> Fix For: trunk
>
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FOP-3088) Jar packaging duplicates classes on classpath
[
https://issues.apache.org/jira/browse/FOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3088:
--
Assignee: Simon Steiner
> Jar packaging duplicates classes on classpath
> -
>
> Key: FOP-3088
> URL: https://issues.apache.org/jira/browse/FOP-3088
> Project: FOP
> Issue Type: Bug
>Reporter: Skip de Groot
>Assignee: Simon Steiner
>Priority: Major
>
> I have a gradle project where we import apache fop with the following:
> {code:java}
> implementation("org.apache.xmlgraphics:fop:2.6") {code}
> Which results in the following dependencies being loaded on the classpath (I
> have removed the sub dependencies for simplicity)
> {code:java}
> org.apache.xmlgraphics:fop -> 2.6
> +--- org.apache.xmlgraphics:fop-util:2.6
> +--- org.apache.xmlgraphics:fop-events:2.6
> \--- org.apache.xmlgraphics:fop-core:2.6 {code}
> So far so good and everything works most of the time. I suspect any maven
> project would import in the same way.
> However, most classes are duplicated in fop-2.6.jar and their respective sub
> module. For instance, the org.apache.fop.apps.FOUserAgent class is packaged
> both in fop and fop-core.
> All classes from the fop-events module in org.apache.fop.events package are
> also duplicated, but not from the org.apache.fop.tools package from the
> fop-events module (For instance org.apache.fop.tools.EventProducerCollector),
> making this also inconsistent somehow.
> Luckily both implementations seem the same but it is bad practice to have
> duplicate classes on the classpath, and package sizes are also doubled.
>
> Depending on the implementation choice I would either expect a fatty jar with
> all the classes packaged which does not import anything or an somewhat empty
> root fop jar with all classes imported by the sub modules. As it stands now
> it seems to be a combination of both and not a completely consistant one
> either.
> Which one is the prefered solution of this project?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-2987) Allow FOP to set Batik blockExternalResources flag
[ https://issues.apache.org/jira/browse/FOP-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580294#comment-17580294 ] Simon Steiner commented on FOP-2987: Maybe better for batik to enable DefaultExternalResourceSecurity by default > Allow FOP to set Batik blockExternalResources flag > -- > > Key: FOP-2987 > URL: https://issues.apache.org/jira/browse/FOP-2987 > Project: FOP > Issue Type: New Feature > Components: image/svg >Reporter: Graham Hadden >Priority: Critical > > Batik 1.13+ has a flag blockExternalResources to allow blocking of external > resources in the xlink:href of SVGs (see > https://issues.apache.org/jira/browse/BATIK-1276). > However, there doesn't seem to be any way to set this flag within FOP which > leaves the original SSRF security vulnerability open. > We would like to request that a new feature is added to FOP such that it's > possible to set the Batik blockExternalResources flag via config. > Thank you. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3077. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1903233 > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute-deja.pdf, fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_DejaVuLGCSerif.pdf, j_with_acute_NotoSans-Regular.png, > j_with_acute_NotoSansMono-Regular-1.png, j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3077: -- Assignee: Simon Steiner > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute-deja.pdf, fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_DejaVuLGCSerif.pdf, j_with_acute_NotoSans-Regular.png, > j_with_acute_NotoSansMono-Regular-1.png, j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3086) allow override of http://apache.org/xml/features/disallow-doctype-decl
[ https://issues.apache.org/jira/browse/FOP-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573665#comment-17573665 ] Simon Steiner commented on FOP-3086: What about calling fop by using https://xmlgraphics.apache.org/fop/trunk/embedding.html > allow override of http://apache.org/xml/features/disallow-doctype-decl > -- > > Key: FOP-3086 > URL: https://issues.apache.org/jira/browse/FOP-3086 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Greg Janée >Priority: Blocker > > In org.apache.fop.cli.InputHandler.getXMLReader, there is a call that is > hard-coded to set SAX feature > [http://apache.org/xml/features/disallow-doctype-decl] to true. This breaks > existing implementations (such as mine) that process libraries of templates > that contain DOCTYPE declarations. While I'm sure there was a reason for > this change (security against rogue DOCTYPE contents I'm guessing), the risk > doesn't apply for implementations that are processing internally-maintained > templates and that are not processing templates coming in from the wild. The > request is to make this setting overrideable to false by some kind of FOP > configuration parameter or environment variable. As it is, this completely > breaks FOP for my installation, and the only way I've been able to continue > to run is to monkey-patch the JAR file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3083. Resolution: Not A Problem > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3085) Remove Xalan
[ https://issues.apache.org/jira/browse/FOP-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3085: --- Description: See BATIK-1329 "The Apache Xalan Java project is dormant and in the process of being retired. No future releases of Apache Xalan Java to address this issue are expected." was:See BATIK-1329 > Remove Xalan > > > Key: FOP-3085 > URL: https://issues.apache.org/jira/browse/FOP-3085 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > > See BATIK-1329 > "The Apache Xalan Java project is dormant and in the process of being > retired. No future releases of Apache Xalan Java to address this issue are > expected." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3085) Remove Xalan
[ https://issues.apache.org/jira/browse/FOP-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3085. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1903024 > Remove Xalan > > > Key: FOP-3085 > URL: https://issues.apache.org/jira/browse/FOP-3085 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > > See BATIK-1329 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (FOP-3069) Empty results in infinite loop when strict-validation is set to false
[
https://issues.apache.org/jira/browse/FOP-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reopened FOP-3069:
> Empty results in infinite loop when strict-validation is set
> to false
> -
>
> Key: FOP-3069
> URL: https://issues.apache.org/jira/browse/FOP-3069
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.6, 2.7
>Reporter: Michael Kainzbauer
>Priority: Major
>
> +_Since Apache FOP 1.1 (not reproducible in 1.0)_+
> When disabling strict-validation, ApacheFOP will loop infinitely when a
> is empty, e.g.:
> As a result in class
> {color:#57d9a3}org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(LayoutContext
> context, int alignment);{color}
> (line 111)
> is called infinitely.
> Yes, the XML-FO is incorrect and not according to the standard, but this is
> an issue that can cause real trouble when the given conditions are met.
> Turning on strict-validation will result in an error with a clear and
> understandable error message:
> {quote}{color:#57d9a3}{{Error on line 26 column 29 }}{color}
> {color:#57d9a3}{{ SXCH0003 org.apache.fop.fo.ValidationException:
> "fo:table-body" is missing child}}{color}
> {color:#57d9a3}{{ elements. Required content model: marker*
> (table-row+|table-cell+) (Siehe Position 26:29).}}{color}
> {color:#57d9a3}{{ Caused by org.apache.fop.fo.ValidationException:
> null:26:29: "fo:table-body" is missing}}{color}
> {color:#57d9a3}{{ child elements. Required content model: marker*
> (table-row+|table-cell+) (See position 26:29)}}{color}
> {quote}
> Example XML-FO:
> {quote}{{{color:#57d9a3}{color}}}
> {{{color:#57d9a3} xmlns:fo="http://www.w3.org/1999/XSL/Format;>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} page-width="210mm" page-height="297mm">{color}}}
> {{{color:#57d9a3} margin-right="5mm" margin-top="10mm"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-before"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-after"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} master-reference="A4-main" page-position="any"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3}{color}}}
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-3085) Remove Xalan
[ https://issues.apache.org/jira/browse/FOP-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3085: --- Description: See BATIK-1329 > Remove Xalan > > > Key: FOP-3085 > URL: https://issues.apache.org/jira/browse/FOP-3085 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > > See BATIK-1329 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FOP-3085) Remove Xalan
Simon Steiner created FOP-3085: -- Summary: Remove Xalan Key: FOP-3085 URL: https://issues.apache.org/jira/browse/FOP-3085 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-2845) File leak to background-image
[
https://issues.apache.org/jira/browse/FOP-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569885#comment-17569885
]
Simon Steiner commented on FOP-2845:
What about setting:
-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true
> File leak to background-image
> -
>
> Key: FOP-2845
> URL: https://issues.apache.org/jira/browse/FOP-2845
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Björn Kautler
>Assignee: Matthias Reischenbacher
>Priority: Major
>
> I use FOP from within my Gradle build to produce documentation PDFs.
> So the VM usually is not closed, but the Gradle Daemon that executes the
> build stays alive.
> I built some PDF and then tried to delete the folder as it was just a test,
> but one file was still locked by the Gradle process, so FOP seems to leak
> that file resource.
> It was the {{draft.png}} that is set as {{background-image}} in this snippet.
> Also interesting, this page master was not even used, so it is even more
> suspicious why the file was opened for reading at all, but that it stays
> locked is pretty unnice.
> {code:xml}
> margin-bottom="0cm" margin-top="0cm" page-height="297mm" page-width="210mm"
> master-name="my-titlepage-first-draft">
> column-gap="12pt"
> margin-top="0cm"
> margin-bottom="0cm"
>
> background-image="url(../../common/images/decorative/draft.png)"
> background-attachment="fixed"
> background-repeat="no-repeat"
> background-position-horizontal="center"
> background-position-vertical="center"/>
> region-name="xsl-region-before-first"/>
> region-name="xsl-region-after-first"/>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[
https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569878#comment-17569878
]
Simon Steiner commented on FOP-3083:
for linux to test:
{code:java}
@Test
public void x() throws Exception {
try {
FopFactoryBuilder fopFactoryBuilder = new FopFactoryBuilder(new
File(".").toURI());
fopFactoryBuilder.setStrictFOValidation(true);
fopFactoryBuilder.setStrictUserConfigValidation(true);
FopFactory fopFactory = fopFactoryBuilder.build();
try (ByteArrayOutputStream stream = new ByteArrayOutputStream()) {
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, stream);
TransformerFactory transformerFactory =
TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
Source src = new StreamSource(new File("test.fo"));
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(src, res);
}
}
finally {
Assert.assertTrue(isFileClosed(new File("example.jpg")));
}
}
private boolean isFileClosed(File file) throws Exception {
Process plsof = new ProcessBuilder(new String[]{"lsof", "|", "grep",
file.getAbsolutePath()}).start();
BufferedReader reader = new BufferedReader(new
InputStreamReader(plsof.getInputStream()));
String line;
while((line=reader.readLine())!=null) {
if(line.contains(file.getAbsolutePath())) {
reader.close();
plsof.destroy();
return false;
}
}
reader.close();
plsof.destroy();
return true;
}
{code}
> Referenced JPG image is not closed when TransformerException is thrown by
> transform()
> -
>
> Key: FOP-3083
> URL: https://issues.apache.org/jira/browse/FOP-3083
> Project: FOP
> Issue Type: Bug
> Components: renderer/pdf
>Affects Versions: 2.7
> Environment: jdk-17.0.3.7-hotspot (Microsoft)
>Reporter: Paul Sharp
>Priority: Major
> Attachments: Code snippet.txt, example.jpg, xsl-fo.xml
>
>
> We are trying to implement a workflow where the FO file and the images
> referenced within, are stored in a temporary directory which we can clear
> down once complete.
> When we disable strict FO validation, the approach works fine.
> However, when strict FO validation is enabled, a TransformerException is
> thrown (as expected for a poor FO). But it appears to keep the image file
> open until the JVM is shut down.
> I have checked through previous Jira entries and tried many other suggestions
> (clearing the image cache etc.) but we cannot seem to get the file closed.
> The attached example code snippet illustrates the behaviour. We would expect
> the example.jpg file to be deleted after processing.
> I hope I've provided enough here. Let me know if more detail is required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569876#comment-17569876 ] Simon Steiner commented on FOP-3083: What about setting: -Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Assignee: Simon Steiner >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3083: -- Assignee: (was: Simon Steiner) > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FOP-3083) Referenced JPG image is not closed when TransformerException is thrown by transform()
[ https://issues.apache.org/jira/browse/FOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3083: -- Assignee: Simon Steiner > Referenced JPG image is not closed when TransformerException is thrown by > transform() > - > > Key: FOP-3083 > URL: https://issues.apache.org/jira/browse/FOP-3083 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.7 > Environment: jdk-17.0.3.7-hotspot (Microsoft) >Reporter: Paul Sharp >Assignee: Simon Steiner >Priority: Major > Attachments: Code snippet.txt, example.jpg, xsl-fo.xml > > > We are trying to implement a workflow where the FO file and the images > referenced within, are stored in a temporary directory which we can clear > down once complete. > When we disable strict FO validation, the approach works fine. > However, when strict FO validation is enabled, a TransformerException is > thrown (as expected for a poor FO). But it appears to keep the image file > open until the JVM is shut down. > I have checked through previous Jira entries and tried many other suggestions > (clearing the image cache etc.) but we cannot seem to get the file closed. > The attached example code snippet illustrates the behaviour. We would expect > the example.jpg file to be deleted after processing. > I hope I've provided enough here. Let me know if more detail is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569630#comment-17569630 ] Simon Steiner commented on FOP-3084: in the FO you can use your own protocol, xyz://path/my.jpg ? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569630#comment-17569630 ] Simon Steiner edited comment on FOP-3084 at 7/21/22 6:16 PM: - in the external-graphic src you can use your own protocol, xyz://path/my.jpg ? was (Author: ssteiner1): in the FO you can use your own protocol, xyz://path/my.jpg ? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-2459) how to merge two afp files into a single afp file with single DOCUMENT tag
[ https://issues.apache.org/jira/browse/FOP-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-2459. Resolution: Not A Problem > how to merge two afp files into a single afp file with single DOCUMENT tag > -- > > Key: FOP-2459 > URL: https://issues.apache.org/jira/browse/FOP-2459 > Project: FOP > Issue Type: Test > Components: fo/block, fo/page, renderer/afp >Affects Versions: 1.1 > Environment: FOP,Java,AFP Files >Reporter: Dhiraj >Priority: Major > Labels: test > Original Estimate: 48h > Remaining Estimate: 48h > > how to merge two afp files into a single afp file with single DOCUMENT tag, i > mean like this > DOCUMENT > BDT > Named group > BPG > EPG > EDT. > i am merging two afp files, its merged into a single afp file but problem is > i am getting two Documents Tag. > i am looking for some idea about merge and thanks is advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3069) Empty results in infinite loop when strict-validation is set to false
[
https://issues.apache.org/jira/browse/FOP-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3069.
Resolution: Cannot Reproduce
> Empty results in infinite loop when strict-validation is set
> to false
> -
>
> Key: FOP-3069
> URL: https://issues.apache.org/jira/browse/FOP-3069
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.6, 2.7
>Reporter: Michael Kainzbauer
>Priority: Major
>
> +_Since Apache FOP 1.1 (not reproducible in 1.0)_+
> When disabling strict-validation, ApacheFOP will loop infinitely when a
> is empty, e.g.:
> As a result in class
> {color:#57d9a3}org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(LayoutContext
> context, int alignment);{color}
> (line 111)
> is called infinitely.
> Yes, the XML-FO is incorrect and not according to the standard, but this is
> an issue that can cause real trouble when the given conditions are met.
> Turning on strict-validation will result in an error with a clear and
> understandable error message:
> {quote}{color:#57d9a3}{{Error on line 26 column 29 }}{color}
> {color:#57d9a3}{{ SXCH0003 org.apache.fop.fo.ValidationException:
> "fo:table-body" is missing child}}{color}
> {color:#57d9a3}{{ elements. Required content model: marker*
> (table-row+|table-cell+) (Siehe Position 26:29).}}{color}
> {color:#57d9a3}{{ Caused by org.apache.fop.fo.ValidationException:
> null:26:29: "fo:table-body" is missing}}{color}
> {color:#57d9a3}{{ child elements. Required content model: marker*
> (table-row+|table-cell+) (See position 26:29)}}{color}
> {quote}
> Example XML-FO:
> {quote}{{{color:#57d9a3}{color}}}
> {{{color:#57d9a3} xmlns:fo="http://www.w3.org/1999/XSL/Format;>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} page-width="210mm" page-height="297mm">{color}}}
> {{{color:#57d9a3} margin-right="5mm" margin-top="10mm"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-before"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-after"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} master-reference="A4-main" page-position="any"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3}{color}}}
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3069) Empty results in infinite loop when strict-validation is set to false
[
https://issues.apache.org/jira/browse/FOP-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569401#comment-17569401
]
Simon Steiner commented on FOP-3069:
on trunk i get
java.lang.IndexOutOfBoundsException: Index: -1, Size: 0
> Empty results in infinite loop when strict-validation is set
> to false
> -
>
> Key: FOP-3069
> URL: https://issues.apache.org/jira/browse/FOP-3069
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.6, 2.7
>Reporter: Michael Kainzbauer
>Priority: Major
>
> +_Since Apache FOP 1.1 (not reproducible in 1.0)_+
> When disabling strict-validation, ApacheFOP will loop infinitely when a
> is empty, e.g.:
> As a result in class
> {color:#57d9a3}org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(LayoutContext
> context, int alignment);{color}
> (line 111)
> is called infinitely.
> Yes, the XML-FO is incorrect and not according to the standard, but this is
> an issue that can cause real trouble when the given conditions are met.
> Turning on strict-validation will result in an error with a clear and
> understandable error message:
> {quote}{color:#57d9a3}{{Error on line 26 column 29 }}{color}
> {color:#57d9a3}{{ SXCH0003 org.apache.fop.fo.ValidationException:
> "fo:table-body" is missing child}}{color}
> {color:#57d9a3}{{ elements. Required content model: marker*
> (table-row+|table-cell+) (Siehe Position 26:29).}}{color}
> {color:#57d9a3}{{ Caused by org.apache.fop.fo.ValidationException:
> null:26:29: "fo:table-body" is missing}}{color}
> {color:#57d9a3}{{ child elements. Required content model: marker*
> (table-row+|table-cell+) (See position 26:29)}}{color}
> {quote}
> Example XML-FO:
> {quote}{{{color:#57d9a3}{color}}}
> {{{color:#57d9a3} xmlns:fo="http://www.w3.org/1999/XSL/Format;>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} page-width="210mm" page-height="297mm">{color}}}
> {{{color:#57d9a3} margin-right="5mm" margin-top="10mm"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-before"/>{color}}}
> {{{color:#57d9a3} region-name="main-reg-after"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} master-reference="A4-main" page-position="any"/>{color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3} {color}}}
> {{{color:#57d9a3}{color}}}
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569388#comment-17569388 ] Simon Steiner commented on FOP-3084: You could get the uri from a threadlocal object? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569336#comment-17569336 ] Simon Steiner commented on FOP-3084: cant you implement a custom resource resolver and switch the baseuri used in that? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3082) NPE when using a link in a span with accessibility
[ https://issues.apache.org/jira/browse/FOP-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3082. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1902716 > NPE when using a link in a span with accessibility > -- > > Key: FOP-3082 > URL: https://issues.apache.org/jira/browse/FOP-3082 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: fop.xconf, test3.fo > > > fop test3.fo -if application/pdf out.if -c fop.xconf > fop -ifin out.if -c fop.xconf out.pdf > No error should occur > java.lang.NullPointerException > at java.util.HashMap.putMapEntries(HashMap.java:501) > at java.util.HashMap.putAll(HashMap.java:785) > at org.apache.fop.area.PageViewport.replace(PageViewport.java:287) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3082) NPE when using a link in a span with accessibility
[ https://issues.apache.org/jira/browse/FOP-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3082: --- Attachment: fop.xconf > NPE when using a link in a span with accessibility > -- > > Key: FOP-3082 > URL: https://issues.apache.org/jira/browse/FOP-3082 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: fop.xconf, test3.fo > > > fop test3.fo -if application/pdf out.if -c fop.xconf > fop -ifin out.if -c fop.xconf out.pdf > No error should occur > java.lang.NullPointerException > at java.util.HashMap.putMapEntries(HashMap.java:501) > at java.util.HashMap.putAll(HashMap.java:785) > at org.apache.fop.area.PageViewport.replace(PageViewport.java:287) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3082) NPE when using a link in a span with accessibility
[ https://issues.apache.org/jira/browse/FOP-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3082: --- Description: fop test3.fo -if application/pdf out.if -c fop.xconf fop -ifin out.if -c fop.xconf out.pdf No error should occur java.lang.NullPointerException at java.util.HashMap.putMapEntries(HashMap.java:501) at java.util.HashMap.putAll(HashMap.java:785) at org.apache.fop.area.PageViewport.replace(PageViewport.java:287) was: fop test3.fo -if application/pdf out.if -c fop.xconf fop -ifin out.if -c fop.xconf out.pdf No error should occur > NPE when using a link in a span with accessibility > -- > > Key: FOP-3082 > URL: https://issues.apache.org/jira/browse/FOP-3082 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: fop.xconf, test3.fo > > > fop test3.fo -if application/pdf out.if -c fop.xconf > fop -ifin out.if -c fop.xconf out.pdf > No error should occur > java.lang.NullPointerException > at java.util.HashMap.putMapEntries(HashMap.java:501) > at java.util.HashMap.putAll(HashMap.java:785) > at org.apache.fop.area.PageViewport.replace(PageViewport.java:287) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3082) NPE when using a link in a span with accessibility
[ https://issues.apache.org/jira/browse/FOP-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3082: --- Description: fop test3.fo -if application/pdf out.if -c fop.xconf fop -ifin out.if -c fop.xconf out.pdf No error should occur > NPE when using a link in a span with accessibility > -- > > Key: FOP-3082 > URL: https://issues.apache.org/jira/browse/FOP-3082 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: fop.xconf, test3.fo > > > fop test3.fo -if application/pdf out.if -c fop.xconf > fop -ifin out.if -c fop.xconf out.pdf > No error should occur -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FOP-3082) NPE when using a link in a span with accessibility
Simon Steiner created FOP-3082: -- Summary: NPE when using a link in a span with accessibility Key: FOP-3082 URL: https://issues.apache.org/jira/browse/FOP-3082 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner Attachments: test3.fo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3082) NPE when using a link in a span with accessibility
[ https://issues.apache.org/jira/browse/FOP-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3082: --- Attachment: test3.fo > NPE when using a link in a span with accessibility > -- > > Key: FOP-3082 > URL: https://issues.apache.org/jira/browse/FOP-3082 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: test3.fo > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FOP-3081) Text duplicated when using linefeed-treatment=preserve and changing page width
[ https://issues.apache.org/jira/browse/FOP-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3081. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1902677 > Text duplicated when using linefeed-treatment=preserve and changing page width > -- > > Key: FOP-3081 > URL: https://issues.apache.org/jira/browse/FOP-3081 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: test.fo > > > fop test.fo out.pdf > Text should not be duplicated in the output -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3081) Text duplicated when using linefeed-treatment=preserve and changing page width
[ https://issues.apache.org/jira/browse/FOP-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3081: --- Attachment: test.fo > Text duplicated when using linefeed-treatment=preserve and changing page width > -- > > Key: FOP-3081 > URL: https://issues.apache.org/jira/browse/FOP-3081 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: test.fo > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3081) Text duplicated when using linefeed-treatment=preserve and changing page width
[ https://issues.apache.org/jira/browse/FOP-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3081: --- Description: fop test.fo out.pdf Text should not be duplicated in the output > Text duplicated when using linefeed-treatment=preserve and changing page width > -- > > Key: FOP-3081 > URL: https://issues.apache.org/jira/browse/FOP-3081 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: test.fo > > > fop test.fo out.pdf > Text should not be duplicated in the output -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FOP-3081) Text duplicated when using linefeed-treatment=preserve and changing page width
Simon Steiner created FOP-3081: -- Summary: Text duplicated when using linefeed-treatment=preserve and changing page width Key: FOP-3081 URL: https://issues.apache.org/jira/browse/FOP-3081 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner Attachments: test.fo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
Title: Message Title Simon Steiner commented on FOP-3079 Re: Fonts are Not getting rendered in FOP-2.6 while genrating PDF Maybe you have 2 different common io jars in your classpath? Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
Title: Message Title Simon Steiner deleted a comment on FOP-3079 Re: Fonts are Not getting rendered in FOP-2.6 while genrating PDF Did you try to configure the fonts as i suggested above Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
Title: Message Title Simon Steiner commented on FOP-3079 Re: Fonts are Not getting rendered in FOP-2.6 while genrating PDF Try passing file instead of uri into FopFactory.newInstance Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
Title: Message Title Simon Steiner commented on FOP-3079 Re: Fonts are Not getting rendered in FOP-2.6 while genrating PDF Did you try to configure the fonts as i suggested above Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17559126#comment-17559126 ] Simon Steiner commented on FOP-3079: If you see this sort of message WARNING: Font "Arial Narrow,normal,700" not found. Substituting with "any,normal,700". You can configure the font in the fop.xconf > Fonts are Not getting rendered in FOP-2.6 while genrating PDF > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype, renderer/pdf >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > Attachments: ConmfiguraionFile.xml, XSLTOPDF.java > > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > On windows trying XSL to PDF Conversion with Apache FOP-2.6. > > Tried with following Changes in configuration file : > 1 . Adding Directory for Font Location > C:\Windows\Fonts > 2. Adding font triplet in Configuraion File > embedding-mode="subset"> > > > 3. Adding font triplet in Configuraion File with URL path : > > > > 4. MOved fonts file (.ttf ) to same location as of Configuration file > > But still Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17559122#comment-17559122 ] Simon Steiner commented on FOP-3079: Maybe try adding each font you want manually: > Fonts are Not getting rendered in FOP-2.6 while genrating PDF > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype, renderer/pdf >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > > > > > > embedding-mode="subset"> > weight="700" /> > > > > Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6 while genrating PDF
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17559117#comment-17559117 ] Simon Steiner commented on FOP-3079: How come you mix windows and mac paths: > Fonts are Not getting rendered in FOP-2.6 while genrating PDF > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype, renderer/pdf >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > > > > > > embedding-mode="subset"> > weight="700" /> > > > > Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3076) Nullpointer with ZUGFeRD XMP MetaData
[
https://issues.apache.org/jira/browse/FOP-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3076.
Resolution: Duplicate
> Nullpointer with ZUGFeRD XMP MetaData
> -
>
> Key: FOP-3076
> URL: https://issues.apache.org/jira/browse/FOP-3076
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
>Reporter: Gregor Müller
>Assignee: Simon Steiner
>Priority: Major
> Attachments: zugferd-1.fo, zugferd.fo
>
>
> ZUGFeRD allows to add invoice meta data in XML form to pdf documents. Adding
> the file as attachment works really well. However the ZUGFeRD Standard also
> requires to add XMP Metadata. When doing that a NullPointerException occurs.
>
> I am running the command:
> fop -r -fo zugferd.fo -pdf zugferd.pdf
> {{Juni 10, 2022 7:09:35 PM org.apache.fop.cli.Main startFOP}}
> {{SEVERE: Exception}}
> {{org.apache.fop.apps.FOPException: java.lang.NullPointerException}}
> {{java.lang.NullPointerException}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: java.lang.NullPointerException}}
> {{ at
> org.apache.xmlgraphics.xmp.XMPHandler.endElement(XMPHandler.java:291)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:207)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:204)}}
> {{ at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:312)}}
> {{ at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:203)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)}}
> {{ at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:293)}}
> {{ ... 3 more}}
>
>
> The bug might also be caused in org.apache.xmlgraphics.xmp.XMPHandler
> The line before the null pointer stated
> {{assert getCurrentProperties() != null : "no current property";}}
>
> {{The FO File is also attached to this report.}}
>
>
> {{}}
> {{http://www.w3.org/1999/XSL/Format;>}}
> {{}}
> {{ page-height="297mm" margin-top="0mm"}}
> {{margin-bottom="0mm" margin-left="0mm" margin-right="0mm">}}
> {{ margin-right="15mm"/>}}
> {{}}
> {{}}
> {{}}
> {{http://www.w3.org/1999/02/22-rdf-syntax-ns#;>}}
> {{ xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/"}}
> {{xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#"}}
> {{xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#; rdf:about="">}}
> {{}}
> {{}}
> {{}}
> {{Factur-X PDFA Extension Schema}}
> {{urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#}}
> {{}}
> {{fx}}
> {{}}
> {{}}
> {{}}
> {{DocumentFileName}}
> {{Text}}
> {{external}}
> {{name of the embedded XML invoice file}}
> {{}}
> {{}}
> {{}}
> {{DocumentType}}
> {{Text}}
> {{external}}
> {{INVOICE}}
> {{}}
> {{}}
> {{Version}}
> {{Text}}
> {{external}}
> {{The actual version of the Factur-X XML schema}}
> {{}}
> {{}}
> {{}}
> {{ConformanceLevel}}
> {{Text}}
> {{external}}
> {{The conformance level of the embedded Factur-X
> data}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{ xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#" rdf:about=""}}
> {{fx:ConformanceLevel="EN 16931" fx:DocumentFileName="factur-x.xml"
> fx:DocumentType="INVOICE"}}
> {{fx:Version="1.0"/>}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{Hello ZUGFeRD}}
> {{}}
> {{}}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (FOP-3076) Nullpointer with ZUGFeRD XMP MetaData
[
https://issues.apache.org/jira/browse/FOP-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3076:
--
Assignee: Simon Steiner
> Nullpointer with ZUGFeRD XMP MetaData
> -
>
> Key: FOP-3076
> URL: https://issues.apache.org/jira/browse/FOP-3076
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
>Reporter: Gregor Müller
>Assignee: Simon Steiner
>Priority: Major
> Attachments: zugferd-1.fo, zugferd.fo
>
>
> ZUGFeRD allows to add invoice meta data in XML form to pdf documents. Adding
> the file as attachment works really well. However the ZUGFeRD Standard also
> requires to add XMP Metadata. When doing that a NullPointerException occurs.
>
> I am running the command:
> fop -r -fo zugferd.fo -pdf zugferd.pdf
> {{Juni 10, 2022 7:09:35 PM org.apache.fop.cli.Main startFOP}}
> {{SEVERE: Exception}}
> {{org.apache.fop.apps.FOPException: java.lang.NullPointerException}}
> {{java.lang.NullPointerException}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: java.lang.NullPointerException}}
> {{ at
> org.apache.xmlgraphics.xmp.XMPHandler.endElement(XMPHandler.java:291)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:207)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:204)}}
> {{ at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:312)}}
> {{ at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:203)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)}}
> {{ at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:293)}}
> {{ ... 3 more}}
>
>
> The bug might also be caused in org.apache.xmlgraphics.xmp.XMPHandler
> The line before the null pointer stated
> {{assert getCurrentProperties() != null : "no current property";}}
>
> {{The FO File is also attached to this report.}}
>
>
> {{}}
> {{http://www.w3.org/1999/XSL/Format;>}}
> {{}}
> {{ page-height="297mm" margin-top="0mm"}}
> {{margin-bottom="0mm" margin-left="0mm" margin-right="0mm">}}
> {{ margin-right="15mm"/>}}
> {{}}
> {{}}
> {{}}
> {{http://www.w3.org/1999/02/22-rdf-syntax-ns#;>}}
> {{ xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/"}}
> {{xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#"}}
> {{xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#; rdf:about="">}}
> {{}}
> {{}}
> {{}}
> {{Factur-X PDFA Extension Schema}}
> {{urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#}}
> {{}}
> {{fx}}
> {{}}
> {{}}
> {{}}
> {{DocumentFileName}}
> {{Text}}
> {{external}}
> {{name of the embedded XML invoice file}}
> {{}}
> {{}}
> {{}}
> {{DocumentType}}
> {{Text}}
> {{external}}
> {{INVOICE}}
> {{}}
> {{}}
> {{Version}}
> {{Text}}
> {{external}}
> {{The actual version of the Factur-X XML schema}}
> {{}}
> {{}}
> {{}}
> {{ConformanceLevel}}
> {{Text}}
> {{external}}
> {{The conformance level of the embedded Factur-X
> data}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{ xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#" rdf:about=""}}
> {{fx:ConformanceLevel="EN 16931" fx:DocumentFileName="factur-x.xml"
> fx:DocumentType="INVOICE"}}
> {{fx:Version="1.0"/>}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{Hello ZUGFeRD}}
> {{}}
> {{}}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
[
https://issues.apache.org/jira/browse/FOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-2897.
Fix Version/s: trunk
Resolution: Fixed
http://svn.apache.org/viewvc?view=revision=1902203
> Out of memory when loading fonts on Mac - instead it should report font too
> large and continue
> --
>
> Key: FOP-2897
> URL: https://issues.apache.org/jira/browse/FOP-2897
> Project: FOP
> Issue Type: Bug
>Reporter: Dan Caprioara
>Assignee: Simon Steiner
>Priority: Major
> Fix For: trunk
>
>
> The FontInfoFinder class collects all the fonts from the system. On Mac there
> are huge font files containing icons. This makes FOP break with
> OutOfMemoryError.
> Probably it should show an warning and throw an IOException instead of OOM
> (IOException does not break the entire processing, just skips the current
> font loading, in this way next fonts can be loaded).
> There are two places in the FontInfoFinder class where the OOM should be
> catched:
> {code:java}
> try {
>TTFFile ttf = new TTFFile(false, false);
>FontFileReader reader = new FontFileReader(in);
>ttcNames = ttf.getTTCnames(reader);
> } catch (OutOfMemoryError oom) {
>handleOOM(fontURI);
> }
> {code}
> {code:java}
> try {
>OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
> EmbeddingMode.AUTO,
> EncodingMode.AUTO, useKerning, useAdvanced,
> resourceResolver, false, false);
>customFont = ttfLoader.getFont();
>if (this.eventListener != null) {
> customFont.setEventListener(this.eventListener);
>}
> } catch(OutOfMemoryError e) {
>handleOOM(fontURI);
> }
> {code}
> And the handling:
> {code:java}
> private void handleOOM(URI fontURI) throws IOException {
> String sizeMsg = "";
> if ("file".equals(fontURI.getScheme())) {
> sizeMsg = "The font file size was: " + new
> File(fontURI).length() + " bytes";
> }
> throw new IOException(
> "Font is too large. " + sizeMsg);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
[
https://issues.apache.org/jira/browse/FOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-2897:
--
Assignee: Simon Steiner
> Out of memory when loading fonts on Mac - instead it should report font too
> large and continue
> --
>
> Key: FOP-2897
> URL: https://issues.apache.org/jira/browse/FOP-2897
> Project: FOP
> Issue Type: Bug
>Reporter: Dan Caprioara
>Assignee: Simon Steiner
>Priority: Major
>
> The FontInfoFinder class collects all the fonts from the system. On Mac there
> are huge font files containing icons. This makes FOP break with
> OutOfMemoryError.
> Probably it should show an warning and throw an IOException instead of OOM
> (IOException does not break the entire processing, just skips the current
> font loading, in this way next fonts can be loaded).
> There are two places in the FontInfoFinder class where the OOM should be
> catched:
> {code:java}
> try {
>TTFFile ttf = new TTFFile(false, false);
>FontFileReader reader = new FontFileReader(in);
>ttcNames = ttf.getTTCnames(reader);
> } catch (OutOfMemoryError oom) {
>handleOOM(fontURI);
> }
> {code}
> {code:java}
> try {
>OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
> EmbeddingMode.AUTO,
> EncodingMode.AUTO, useKerning, useAdvanced,
> resourceResolver, false, false);
>customFont = ttfLoader.getFont();
>if (this.eventListener != null) {
> customFont.setEventListener(this.eventListener);
>}
> } catch(OutOfMemoryError e) {
>handleOOM(fontURI);
> }
> {code}
> And the handling:
> {code:java}
> private void handleOOM(URI fontURI) throws IOException {
> String sizeMsg = "";
> if ("file".equals(fontURI.getScheme())) {
> sizeMsg = "The font file size was: " + new
> File(fontURI).length() + " bytes";
> }
> throw new IOException(
> "Font is too large. " + sizeMsg);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557994#comment-17557994 ] Simon Steiner commented on FOP-3079: i mean for GTSuperDisplayLight > Fonts are Not getting rendered in FOP-2.6 > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > > > > > > embedding-mode="subset"> > weight="700" /> > > > > Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3076) Nullpointer with ZUGFeRD XMP MetaData
[
https://issues.apache.org/jira/browse/FOP-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557992#comment-17557992
]
Simon Steiner commented on FOP-3076:
there is a example on https://xmlgraphics.apache.org/fop/trunk/metadata.html
> Nullpointer with ZUGFeRD XMP MetaData
> -
>
> Key: FOP-3076
> URL: https://issues.apache.org/jira/browse/FOP-3076
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.7
>Reporter: Gregor Müller
>Priority: Major
> Attachments: zugferd.fo
>
>
> ZUGFeRD allows to add invoice meta data in XML form to pdf documents. Adding
> the file as attachment works really well. However the ZUGFeRD Standard also
> requires to add XMP Metadata. When doing that a NullPointerException occurs.
>
> I am running the command:
> fop -r -fo zugferd.fo -pdf zugferd.pdf
> {{Juni 10, 2022 7:09:35 PM org.apache.fop.cli.Main startFOP}}
> {{SEVERE: Exception}}
> {{org.apache.fop.apps.FOPException: java.lang.NullPointerException}}
> {{java.lang.NullPointerException}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:296)}}
> {{ at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:116)}}
> {{ at org.apache.fop.cli.Main.startFOP(Main.java:183)}}
> {{ at org.apache.fop.cli.Main.main(Main.java:214)}}
> {{Caused by: java.lang.NullPointerException}}
> {{ at
> org.apache.xmlgraphics.xmp.XMPHandler.endElement(XMPHandler.java:291)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:207)}}
> {{ at org.apache.fop.fo.FOTreeBuilder$3.run(FOTreeBuilder.java:204)}}
> {{ at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:312)}}
> {{ at
> org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:203)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)}}
> {{ at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)}}
> {{ at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)}}
> {{ at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)}}
> {{ at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)}}
> {{ at
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)}}
> {{ at
> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:293)}}
> {{ ... 3 more}}
>
>
> The bug might also be caused in org.apache.xmlgraphics.xmp.XMPHandler
> The line before the null pointer stated
> {{assert getCurrentProperties() != null : "no current property";}}
>
> {{The FO File is also attached to this report.}}
>
>
> {{}}
> {{http://www.w3.org/1999/XSL/Format;>}}
> {{}}
> {{ page-height="297mm" margin-top="0mm"}}
> {{margin-bottom="0mm" margin-left="0mm" margin-right="0mm">}}
> {{ margin-right="15mm"/>}}
> {{}}
> {{}}
> {{}}
> {{http://www.w3.org/1999/02/22-rdf-syntax-ns#;>}}
> {{ xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/"}}
> {{xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#"}}
> {{xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#; rdf:about="">}}
> {{}}
> {{}}
> {{}}
> {{Factur-X PDFA Extension Schema}}
> {{urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#}}
> {{}}
> {{fx}}
> {{}}
> {{}}
> {{}}
> {{DocumentFileName}}
> {{Text}}
> {{external}}
> {{name of the embedded XML invoice file}}
> {{}}
> {{}}
> {{}}
> {{DocumentType}}
> {{Text}}
> {{external}}
> {{INVOICE}}
> {{}}
> {{}}
> {{Version}}
> {{Text}}
> {{external}}
> {{The actual version of the Factur-X XML schema}}
> {{}}
> {{}}
> {{}}
> {{ConformanceLevel}}
> {{Text}}
> {{external}}
> {{The conformance level of the embedded Factur-X
> data}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{ xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#" rdf:about=""}}
> {{fx:ConformanceLevel="EN 16931" fx:DocumentFileName="factur-x.xml"
> fx:DocumentType="INVOICE"}}
> {{fx:Version="1.0"/>}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{Hello ZUGFeRD}}
> {{}}
> {{}}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-3079) Fonts are Not getting rendered in FOP-2.6
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557989#comment-17557989 ] Simon Steiner commented on FOP-3079: you could try adding full path to font in fop.xconf > Fonts are Not getting rendered in FOP-2.6 > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > > > > > > embedding-mode="subset"> > weight="700" /> > > > > Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1774#comment-1774 ] Simon Steiner commented on FOP-3077: NotoSans-Regular.ttf version 2.0 is ok, version 2.007 has the issue > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_NotoSans-Regular.png, j_with_acute_NotoSansMono-Regular-1.png, > j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reopened FOP-3077: > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_NotoSans-Regular.png, j_with_acute_NotoSansMono-Regular-1.png, > j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
[
https://issues.apache.org/jira/browse/FOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555476#comment-17555476
]
Simon Steiner commented on FOP-2897:
Can you increase the Xmx to fop?
> Out of memory when loading fonts on Mac - instead it should report font too
> large and continue
> --
>
> Key: FOP-2897
> URL: https://issues.apache.org/jira/browse/FOP-2897
> Project: FOP
> Issue Type: Bug
>Reporter: Dan Caprioara
>Priority: Major
>
> The FontInfoFinder class collects all the fonts from the system. On Mac there
> are huge font files containing icons. This makes FOP break with
> OutOfMemoryError.
> Probably it should show an warning and throw an IOException instead of OOM
> (IOException does not break the entire processing, just skips the current
> font loading, in this way next fonts can be loaded).
> There are two places in the FontInfoFinder class where the OOM should be
> catched:
> {code:java}
> try {
>TTFFile ttf = new TTFFile(false, false);
>FontFileReader reader = new FontFileReader(in);
>ttcNames = ttf.getTTCnames(reader);
> } catch (OutOfMemoryError oom) {
>handleOOM(fontURI);
> }
> {code}
> {code:java}
> try {
>OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
> EmbeddingMode.AUTO,
> EncodingMode.AUTO, useKerning, useAdvanced,
> resourceResolver, false, false);
>customFont = ttfLoader.getFont();
>if (this.eventListener != null) {
> customFont.setEventListener(this.eventListener);
>}
> } catch(OutOfMemoryError e) {
>handleOOM(fontURI);
> }
> {code}
> And the handling:
> {code:java}
> private void handleOOM(URI fontURI) throws IOException {
> String sizeMsg = "";
> if ("file".equals(fontURI.getScheme())) {
> sizeMsg = "The font file size was: " + new
> File(fontURI).length() + " bytes";
> }
> throw new IOException(
> "Font is too large. " + sizeMsg);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-2459) how to merge two afp files into a single afp file with single DOCUMENT tag
[ https://issues.apache.org/jira/browse/FOP-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555474#comment-17555474 ] Simon Steiner commented on FOP-2459: what about fop test.fo -if application/x-afp out.if fop test2.fo -if application/x-afp out2.if merge the 2 output files together then fop -ifin merged.if -afp out.afp > how to merge two afp files into a single afp file with single DOCUMENT tag > -- > > Key: FOP-2459 > URL: https://issues.apache.org/jira/browse/FOP-2459 > Project: FOP > Issue Type: Test > Components: fo/block, fo/page, renderer/afp >Affects Versions: 1.1 > Environment: FOP,Java,AFP Files >Reporter: Dhiraj >Priority: Major > Labels: test > Original Estimate: 48h > Remaining Estimate: 48h > > how to merge two afp files into a single afp file with single DOCUMENT tag, i > mean like this > DOCUMENT > BDT > Named group > BPG > EPG > EDT. > i am merging two afp files, its merged into a single afp file but problem is > i am getting two Documents Tag. > i am looking for some idea about merge and thanks is advance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3079) Fonts are Not getting rendered in FOP-2.6
[ https://issues.apache.org/jira/browse/FOP-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3079: --- Fix Version/s: (was: 2.6) > Fonts are Not getting rendered in FOP-2.6 > - > > Key: FOP-3079 > URL: https://issues.apache.org/jira/browse/FOP-3079 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.6 >Reporter: Ashish Sharma >Priority: Blocker > > Fonts which Are Auto detected in FOP-2.4 is not Working in FOP-2.6 . > > > > > > embedding-mode="subset"> > weight="700" /> > > > > Throws This Error: > > WARNING: Font "Arial Narrow,normal,700" not found. Substituting with > "any,normal,700". > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > WARNING: Font "GTSuperDisplayLight,normal,700" not found. Substituting with > "any,normal,700". -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3078) [PATCH] Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3078: --- Summary: [PATCH] Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON (was: Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON) > [PATCH] Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: > !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3078. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1901980 > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: > !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3077: --- Description: In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT the letter "j" should be substituted by dotless j and then combined with the accent. The substitution is not carried out. For font Noto Sans Regular Result with FOP: !image-2022-06-11-12-04-55-468.png! Result with HarfBuzz: !j_with_acute_NotoSans-Regular.png! The same error occurs with font Noto Sans Mono Regular. FOP: !image-2022-06-11-12-07-43-295.png! HarfBuzz: !j_with_acute_NotoSansMono-Regular-1.png! See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] For reference I added a list of all characters and sequences of DIN SPEC 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . was: In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT the letter "j" should be substituted by dotless j and then combined with the accent. The substitution is not carried out. For font Noto Sans Regular Result with FOP: !image-2022-06-11-12-04-55-468.png! Result with HarfBuzz: !j_with_acute_NotoSans-Regular.png! The same error occurs with font Noto Sans Mono Regular. FOP: !image-2022-06-11-12-07-43-295.png! HarfBuzz: !j_with_acute_NotoSansMono-Regular-1.png! See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] For reference I added a list of all characters and sequences of DIN SPEC 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_NotoSans-Regular.png, j_with_acute_NotoSansMono-Regular-1.png, > j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: > !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: > !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: > !image-2022-06-11-12-07-43-295.png! > HarfBuzz: > !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3078: --- Fix Version/s: (was: trunk) > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: > !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078 ] Simon Steiner deleted comment on FOP-3078: was (Author: ssteiner1): http://svn.apache.org/viewvc?view=revision=1901965 > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: > !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3078: --- Description: In the sequences 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING MACRON; S̛̄; and 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING MACRON; s̛̄; the MACRON has a wrong position for font Noto Sans Mono Regular. Compare rendering with FOP: !image-2022-06-11-12-17-21-602.png! and with HarfBuzz hb-view: !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] Rendering with font Noto Sans Regular is correct. For reference I added the letters of DIN SPEC 91379: [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] was: In the sequences 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING MACRON; S̛̄; and 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING MACRON; s̛̄; the MACRON has a wrong position for font Noto Sans Mono Regular. Compare rendering with FOP: !image-2022-06-11-12-17-21-602.png! and with HarfBuzz hb-view: !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] Rendering with font Noto Sans Regular is correct. For reference I added the letters of DIN SPEC 91379: [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: > !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reopened FOP-3078: > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3078. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1901965 > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FOP-3078) Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON
[ https://issues.apache.org/jira/browse/FOP-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3078: -- Assignee: Simon Steiner > Wrong position of macron in S WITH COMBINING HORN AND COMBINING MACRON > -- > > Key: FOP-3078 > URL: https://issues.apache.org/jira/browse/FOP-3078 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Attachments: > S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png, > fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, fop-s-horn-macron.fo, > fop-s-horn-macron.fo.pdf, fop.conf, image-2022-06-11-12-17-21-602.png > > > In the sequences > 0053 031B 0304; LATIN CAPITAL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; S̛̄; > and > 0073 031B 0304; LATIN SMALL LETTER S WITH COMBINING HORN AND COMBINING > MACRON; s̛̄; > the MACRON has a wrong position for font Noto Sans Mono Regular. > Compare rendering with FOP: !image-2022-06-11-12-17-21-602.png! > and with HarfBuzz hb-view: > !S_WITH_COMBINING_HORN_AND_COMBINING_MACRON_NotoSansMono-Regular.png! > See also: [^fop-s-horn-macron.fo], [^fop-s-horn-macron.fo.pdf] > Rendering with font Noto Sans Regular is correct. > For reference I added the letters of DIN SPEC 91379: > [^fop-din-spec-91379.fo], [^fop-din-spec-91379.fo.pdf] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3077) Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT
[ https://issues.apache.org/jira/browse/FOP-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3077. Resolution: Cannot Reproduce works on trunk > Wrong rendering of LATIN SMALL LETTER J WITH COMBINING ACUTE ACCENT > --- > > Key: FOP-3077 > URL: https://issues.apache.org/jira/browse/FOP-3077 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: Volker Kunert >Priority: Major > Attachments: fop-din-spec-91379.fo, fop-din-spec-91379.fo.pdf, > fop-j-acute.fo, fop-j-acute.fo.pdf, fop.conf, > image-2022-06-11-12-04-55-468.png, image-2022-06-11-12-07-43-295.png, > j_with_acute_NotoSans-Regular.png, j_with_acute_NotoSansMono-Regular-1.png, > j_with_acute_NotoSansMono-Regular.png > > > In the glyph layout process for LATIN SMALL LETTER J WITH COMBINING ACUTE > ACCENT > the letter "j" should be substituted by dotless j and then combined with the > accent. > The substitution is not carried out. > For font Noto Sans Regular > Result with FOP: !image-2022-06-11-12-04-55-468.png! > Result with HarfBuzz: !j_with_acute_NotoSans-Regular.png! > The same error occurs with font Noto Sans Mono Regular. > FOP: !image-2022-06-11-12-07-43-295.png! > HarfBuzz: !j_with_acute_NotoSansMono-Regular-1.png! > See also [^fop-j-acute.fo] and [^fop-j-acute.fo.pdf] > For reference I added a list of all characters and sequences of DIN SPEC > 91379, see [^fop-din-spec-91379.fo] and [^fop-din-spec-91379.fo.pdf] . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-2996) Arabic letters are not joined in generated PDF whatever I can try
[
https://issues.apache.org/jira/browse/FOP-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-2996.
Resolution: Not A Problem
> Arabic letters are not joined in generated PDF whatever I can try
> -
>
> Key: FOP-2996
> URL: https://issues.apache.org/jira/browse/FOP-2996
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.5, 2.6
> Environment: Any OS; any version of Java. However attached PDFs
> having been generated on Linux running 1.8.0_281.
>Reporter: Hussein Shafie
>Priority: Major
> Attachments: fop_arialuni.conf, fop_scheherazade.conf,
> fop_trado.conf, sample2_ar.fo, sample2_ar_FOP_arialuni.pdf,
> sample2_ar_FOP_scheherazade.pdf, sample2_ar_FOP_trado.pdf, sample2_ar_XEP.pdf
>
>
> Arabic letters _*are not joined*_ whatever in generated PDF I can try:
> specify language="ar", specify language="arab", specify writing-mode="rl-tb",
> use one of the fonts you officially support (with the corresponding
> configuration file).
> Sample Arabic file is: sample2_ar.fo
> Expected output is: sample2_ar_XEP.pdf
> Generating PDF using FOP v2.6 with font "Arial Unicode MS":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_arialuni.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_arialuni.pdf{code}
>
> Generating PDF using FOP v2.6 with font "Scheherazade New":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_scheherazade.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_scheherazade.pdf{code}
>
> Generating PDF using FOP v2.6 with font "Traditional Arabic":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_trado.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_trado.pdf
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-2996) Arabic letters are not joined in generated PDF whatever I can try
[
https://issues.apache.org/jira/browse/FOP-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555028#comment-17555028
]
Simon Steiner commented on FOP-2996:
You can open the font in fontforge, font info, lookups, gsub, edit to see the
list of languages supported
> Arabic letters are not joined in generated PDF whatever I can try
> -
>
> Key: FOP-2996
> URL: https://issues.apache.org/jira/browse/FOP-2996
> Project: FOP
> Issue Type: Bug
> Components: fo/unqualified
>Affects Versions: 2.5, 2.6
> Environment: Any OS; any version of Java. However attached PDFs
> having been generated on Linux running 1.8.0_281.
>Reporter: Hussein Shafie
>Priority: Major
> Attachments: fop_arialuni.conf, fop_scheherazade.conf,
> fop_trado.conf, sample2_ar.fo, sample2_ar_FOP_arialuni.pdf,
> sample2_ar_FOP_scheherazade.pdf, sample2_ar_FOP_trado.pdf, sample2_ar_XEP.pdf
>
>
> Arabic letters _*are not joined*_ whatever in generated PDF I can try:
> specify language="ar", specify language="arab", specify writing-mode="rl-tb",
> use one of the fonts you officially support (with the corresponding
> configuration file).
> Sample Arabic file is: sample2_ar.fo
> Expected output is: sample2_ar_XEP.pdf
> Generating PDF using FOP v2.6 with font "Arial Unicode MS":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_arialuni.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_arialuni.pdf{code}
>
> Generating PDF using FOP v2.6 with font "Scheherazade New":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_scheherazade.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_scheherazade.pdf{code}
>
> Generating PDF using FOP v2.6 with font "Traditional Arabic":
>
> {code:java}
> $ /opt/fop-2.6/fop/fop -c ./fop_trado.conf -fo sample2_ar.fo -pdf
> sample2_ar_FOP_trado.pdf
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-3080) Allow to remove empty table elements from read out loud
[ https://issues.apache.org/jira/browse/FOP-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3080. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1901930 > Allow to remove empty table elements from read out loud > --- > > Key: FOP-3080 > URL: https://issues.apache.org/jira/browse/FOP-3080 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: fop.xconf, simple.fo > > > fop simple.fo -c fop.xconf out4.pdf > Open PDF with Adobe Acrobat, table header should not be listed in Tags menu -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3080) Allow to remove empty table elements from read out loud
[ https://issues.apache.org/jira/browse/FOP-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3080: --- Description: fop simple.fo -c fop.xconf out4.pdf Open PDF with Adobe Acrobat, table header should not be listed in Tags menu > Allow to remove empty table elements from read out loud > --- > > Key: FOP-3080 > URL: https://issues.apache.org/jira/browse/FOP-3080 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: fop.xconf, simple.fo > > > fop simple.fo -c fop.xconf out4.pdf > Open PDF with Adobe Acrobat, table header should not be listed in Tags menu -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3080) Allow to remove empty table elements from read out loud
[ https://issues.apache.org/jira/browse/FOP-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3080: --- Attachment: fop.xconf simple.fo > Allow to remove empty table elements from read out loud > --- > > Key: FOP-3080 > URL: https://issues.apache.org/jira/browse/FOP-3080 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: fop.xconf, simple.fo > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (FOP-3080) Allow to remove empty table elements from read out loud
Simon Steiner created FOP-3080: -- Summary: Allow to remove empty table elements from read out loud Key: FOP-3080 URL: https://issues.apache.org/jira/browse/FOP-3080 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3063) Overlapping diaresis and combining macron glyphs
[ https://issues.apache.org/jira/browse/FOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3063. Assignee: Simon Steiner Resolution: Duplicate Works on trunk after removing xml:lang="en" > Overlapping diaresis and combining macron glyphs > > > Key: FOP-3063 > URL: https://issues.apache.org/jira/browse/FOP-3063 > Project: FOP > Issue Type: Bug >Reporter: Alexander Dyuzhev >Assignee: Simon Steiner >Priority: Major > Attachments: combining_chars.fo.xml, fop.xconf, out.pdf, > pdf_rendering.PNG, test.fo, test_combining_char.pdf, word_rendering.PNG > > > I have a text encoded with special characters like diaeresis, umlaut with > combining character like 'combining macron'. For instance, sequence ǟ > In the PDF such sequence looks overlapped (see [^test_combining_char.pdf]): > !pdf_rendering.PNG! > In Word and HTML it render ok: > !word_rendering.PNG! > -macron placed over diaeresis. > Source xsl-fo: [^combining_chars.fo.xml] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FOP-3070) Remove example SVG file using external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner updated FOP-3070:
---
Summary: Remove example SVG file using external links (was: FOP fails to
render SVG files provided as external links)
> Remove example SVG file using external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
> Fix For: trunk
>
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-3070) FOP fails to render SVG files provided as external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3070.
Fix Version/s: trunk
Resolution: Fixed
http://svn.apache.org/viewvc?view=revision=1901801
> FOP fails to render SVG files provided as external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
> Fix For: trunk
>
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Reopened] (FOP-3070) FOP fails to render SVG files provided as external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reopened FOP-3070:
> FOP fails to render SVG files provided as external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-3062) AssertionError in GlyphPositioningTable$DeviceTable with SFArabic.ttf
[
https://issues.apache.org/jira/browse/FOP-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3062.
Fix Version/s: trunk
Resolution: Fixed
http://svn.apache.org/viewvc?view=revision=1901773
> AssertionError in GlyphPositioningTable$DeviceTable with SFArabic.ttf
> -
>
> Key: FOP-3062
> URL: https://issues.apache.org/jira/browse/FOP-3062
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.7
>Reporter: Richard Zowalla
>Assignee: Simon Steiner
>Priority: Major
> Fix For: trunk
>
> Attachments: SFArabic.ttf, image-2022-04-08-16-09-21-254.png,
> propagate_use_advanced.patch
>
>
> While working on a M1 Mac OS system:
>
> {code:java}
> Java version: 17.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault locale:
> de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3", arch: "aarch64", family: "mac"{code}
> I get the following AssertionError with a simple FOP config as follows:
> {code:java}
> http://www.w3.org/2001/XMLSchema-instance;
>
> xsi:noNamespaceSchemaLocation="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd?view=co;>
>
>
>
>
> null
>
>
>
> flate
> ascii-85
>
>
>
> /Users/abc/uploads/fonts
>
>
>
>
>
> /Users/abc/uploads/fonts
>
> {code}
> The font, which violates the assertion in DeviceTable is:
> *[file:/System/Library/Fonts/SFArabic.ttf*|file:///System/Library/Fonts/SFArabic.ttf*]
>
> *Stacktrace:*
> {code:java}
> java.lang.AssertionError at
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$DeviceTable.(GlyphPositioningTable.java:1774)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readPosDeviceTable(OTFAdvancedTypographicTableReader.java:1727)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readPosAnchor(OTFAdvancedTypographicTableReader.java:2051)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readMarkToLigaturePosTableFormat1(OTFAdvancedTypographicTableReader.java:2345)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readMarkToLigaturePosTable(OTFAdvancedTypographicTableReader.java:2371)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGPOSSubtable(OTFAdvancedTypographicTableReader.java:3122)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readLookupTable(OTFAdvancedTypographicTableReader.java:3191)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readLookupList(OTFAdvancedTypographicTableReader.java:3218)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readCommonLayoutTables(OTFAdvancedTypographicTableReader.java:3239)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGPOS(OTFAdvancedTypographicTableReader.java:3499)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readAll(OTFAdvancedTypographicTableReader.java:84)
> at
> org.apache.fop.fonts.truetype.OpenFont.handleCharacterSpacing(OpenFont.java:889)
> at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:861) at
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:119) at
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:103) at
> org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:126) at
> org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:110) at
> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:253)
> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) at
> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:105)
> at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) at
> org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
> at
> org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
> at
> org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
> at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) at
> org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
> at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) at
>
[jira] [Assigned] (FOP-3062) AssertionError in GlyphPositioningTable$DeviceTable with SFArabic.ttf
[
https://issues.apache.org/jira/browse/FOP-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3062:
--
Assignee: Simon Steiner
> AssertionError in GlyphPositioningTable$DeviceTable with SFArabic.ttf
> -
>
> Key: FOP-3062
> URL: https://issues.apache.org/jira/browse/FOP-3062
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.7
>Reporter: Richard Zowalla
>Assignee: Simon Steiner
>Priority: Major
> Attachments: SFArabic.ttf, image-2022-04-08-16-09-21-254.png,
> propagate_use_advanced.patch
>
>
> While working on a M1 Mac OS system:
>
> {code:java}
> Java version: 17.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault locale:
> de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "12.3", arch: "aarch64", family: "mac"{code}
> I get the following AssertionError with a simple FOP config as follows:
> {code:java}
> http://www.w3.org/2001/XMLSchema-instance;
>
> xsi:noNamespaceSchemaLocation="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd?view=co;>
>
>
>
>
> null
>
>
>
> flate
> ascii-85
>
>
>
> /Users/abc/uploads/fonts
>
>
>
>
>
> /Users/abc/uploads/fonts
>
> {code}
> The font, which violates the assertion in DeviceTable is:
> *[file:/System/Library/Fonts/SFArabic.ttf*|file:///System/Library/Fonts/SFArabic.ttf*]
>
> *Stacktrace:*
> {code:java}
> java.lang.AssertionError at
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$DeviceTable.(GlyphPositioningTable.java:1774)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readPosDeviceTable(OTFAdvancedTypographicTableReader.java:1727)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readPosAnchor(OTFAdvancedTypographicTableReader.java:2051)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readMarkToLigaturePosTableFormat1(OTFAdvancedTypographicTableReader.java:2345)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readMarkToLigaturePosTable(OTFAdvancedTypographicTableReader.java:2371)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGPOSSubtable(OTFAdvancedTypographicTableReader.java:3122)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readLookupTable(OTFAdvancedTypographicTableReader.java:3191)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readLookupList(OTFAdvancedTypographicTableReader.java:3218)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readCommonLayoutTables(OTFAdvancedTypographicTableReader.java:3239)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGPOS(OTFAdvancedTypographicTableReader.java:3499)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readAll(OTFAdvancedTypographicTableReader.java:84)
> at
> org.apache.fop.fonts.truetype.OpenFont.handleCharacterSpacing(OpenFont.java:889)
> at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:861) at
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:119) at
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:103) at
> org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:126) at
> org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:110) at
> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:253)
> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) at
> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:105)
> at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) at
> org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
> at
> org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
> at
> org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
> at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) at
> org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
> at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) at
> org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) at
> org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105) at
>
[jira] [Assigned] (FOP-2701) Some of the latin ligatures make text not searchable in PDF
[
https://issues.apache.org/jira/browse/FOP-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-2701:
--
Assignee: (was: J Frank)
> Some of the latin ligatures make text not searchable in PDF
> ---
>
> Key: FOP-2701
> URL: https://issues.apache.org/jira/browse/FOP-2701
> Project: FOP
> Issue Type: Bug
> Components: font/opentype
>Affects Versions: 2.1
> Environment: Windows 10, Calibri font.
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: 3-fonts-copy-paste-result.png, 3-fonts-fop.xconf,
> 3-fonts-latn-ligatures-FOP.fo, 3-fonts-latn-ligatures-FOP.pdf, Screenshot
> 2022-06-07 092013.png, fop.xconf, image-2022-05-31-15-50-26-058.png,
> image-2022-05-31-15-50-39-029.png, image-2022-05-31-15-52-01-435.png,
> image-2022-06-07-15-31-01-526.png, latn-ligatures-Antenna-House.pdf,
> latn-ligatures-FOP.pdf, out.pdf, test.fo
>
>
> This problem happens using the Calibri font, that is packed in the MS Office
> suite and Windows 10.
> I tested with the following text: {{file settings}}.
> The resulted PDF text contains ligatures: {{(fi)le se(tti)ngs}}
> Searching for {{file}} in Acrobat Reader results in the first word being
> selected. This is Ok. But searching for {{set}}, or {{settings}} gives no
> results.
> The same example, run with Antenna House works fine, you get results when
> searching for {{settings}}.
> Here is the complete FO file:
> {code:xml}
>
> http://www.w3.org/1999/XSL/Format;>
>
>
>
>
>
>
>
> file
> settings
>
>
>
> {code}
> Some considerations:
> # A workaround would be to reject all the substitutions that are not part of
> org.apache.fop.fonts.type1.AdobeStandardEncoding. This would leave the (fi)
> ligature, but reject the (tti) one. But this seems to work only for Calibri
> and not for Roboto!!
> # I think there might be some issues with the font embedding, and some
> substitution mapping data is lost. It is just a guess, I am not sure how PDF
> deals with substitutions.
> I know that setting in FO xml:lang to "en" disables the ligatures, but is not
> a solution for my project. I would appreciate any suggestions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-3070) FOP fails to render SVG files provided as external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner resolved FOP-3070.
Resolution: Won't Fix
> FOP fails to render SVG files provided as external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-3070) FOP fails to render SVG files provided as external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551079#comment-17551079
]
Simon Steiner commented on FOP-3070:
Batik is setting http://apache.org/xml/features/nonvalidating/load-external-dtd
to false for security reasons so these external files are blocked
> FOP fails to render SVG files provided as external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (FOP-3070) FOP fails to render SVG files provided as external links
[
https://issues.apache.org/jira/browse/FOP-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-3070:
--
Assignee: Simon Steiner
> FOP fails to render SVG files provided as external links
>
>
> Key: FOP-3070
> URL: https://issues.apache.org/jira/browse/FOP-3070
> Project: FOP
> Issue Type: Bug
> Components: foreign/svg, image/svg
>Affects Versions: 2.5, 2.2, 2.3, 2.4, 2.6, 2.7
> Environment: The file was processed using the fop CLI in both Ubuntu
> 20.04 (+ OpenJDK 11) and Windows 10 (+OpenJDK 18) with similar results.
>Reporter: Asitha
>Assignee: Simon Steiner
>Priority: Critical
>
> FOP fails to render SVG files provided as external links. The following error
> is returned where I ran the provided example file in examples/svg/external.fo
> {quote}SEVERE: SVG error: The file format is not supported. No ImagePreloader
> found for file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> file:/home/asitha/Downloads/fop-2.7/fop/examples/fo/svg/boxes.svg
> at
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
> at
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:127)
> at
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
> at
> org.apache.fop.svg.AbstractFOPImageElementBridge.createImageGraphicsNode(AbstractFOPImageElementBridge.java:78)
> {quote}
> Command:
> ./fop examples/fo/svg/external.fo temp.pdf
> The same command works without any issues in version 2.1, 2.0, and 1.1.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (FOP-3074) Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono
[ https://issues.apache.org/jira/browse/FOP-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3074. Fix Version/s: trunk Resolution: Fixed http://svn.apache.org/viewvc?view=revision=1901699 > Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono > - > > Key: FOP-3074 > URL: https://issues.apache.org/jira/browse/FOP-3074 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.7 >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Fix For: trunk > > Attachments: Main.java, fop-text.fo, fop-text.fo.pdf, fop.conf, > image-2022-06-06-12-10-16-338.png, image-2022-06-06-12-11-09-497.png, > khorn-notosansmono.png, khorn.patch > > > In the combination LATIN CAPITAL LETTER K WITH COMBINING HORN > the combining horm is positioned at the left side of the letter K instead of > the right side, with font Noto Sans Mono, see [^fop-text.fo.pdf] > !image-2022-06-06-12-10-16-338.png! > Compare with the rendering with HarfBuzz in !khorn-notosansmono.png! > This bug occurs also for the other combinations with COMBINING HORN in DIN > SPEC 91379. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FOP-2701) Some of the latin ligatures make text not searchable in PDF
[
https://issues.apache.org/jira/browse/FOP-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Steiner reassigned FOP-2701:
--
Assignee: J Frank
> Some of the latin ligatures make text not searchable in PDF
> ---
>
> Key: FOP-2701
> URL: https://issues.apache.org/jira/browse/FOP-2701
> Project: FOP
> Issue Type: Bug
> Components: font/opentype
>Affects Versions: 2.1
> Environment: Windows 10, Calibri font.
>Reporter: Dan Caprioara
>Assignee: J Frank
>Priority: Major
> Attachments: 3-fonts-copy-paste-result.png, 3-fonts-fop.xconf,
> 3-fonts-latn-ligatures-FOP.fo, 3-fonts-latn-ligatures-FOP.pdf, fop.xconf,
> image-2022-05-31-15-50-26-058.png, image-2022-05-31-15-50-39-029.png,
> image-2022-05-31-15-52-01-435.png, latn-ligatures-Antenna-House.pdf,
> latn-ligatures-FOP.pdf, out.pdf, test.fo
>
>
> This problem happens using the Calibri font, that is packed in the MS Office
> suite and Windows 10.
> I tested with the following text: {{file settings}}.
> The resulted PDF text contains ligatures: {{(fi)le se(tti)ngs}}
> Searching for {{file}} in Acrobat Reader results in the first word being
> selected. This is Ok. But searching for {{set}}, or {{settings}} gives no
> results.
> The same example, run with Antenna House works fine, you get results when
> searching for {{settings}}.
> Here is the complete FO file:
> {code:xml}
>
> http://www.w3.org/1999/XSL/Format;>
>
>
>
>
>
>
>
> file
> settings
>
>
>
> {code}
> Some considerations:
> # A workaround would be to reject all the substitutions that are not part of
> org.apache.fop.fonts.type1.AdobeStandardEncoding. This would leave the (fi)
> ligature, but reject the (tti) one. But this seems to work only for Calibri
> and not for Roboto!!
> # I think there might be some issues with the font embedding, and some
> substitution mapping data is lost. It is just a guess, I am not sure how PDF
> deals with substitutions.
> I know that setting in FO xml:lang to "en" disables the ligatures, but is not
> a solution for my project. I would appreciate any suggestions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (FOP-3074) Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono
[ https://issues.apache.org/jira/browse/FOP-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner reassigned FOP-3074: -- Assignee: Simon Steiner > Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono > - > > Key: FOP-3074 > URL: https://issues.apache.org/jira/browse/FOP-3074 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.7 >Reporter: Volker Kunert >Assignee: Simon Steiner >Priority: Major > Attachments: Main.java, fop-text.fo, fop-text.fo.pdf, fop.conf, > image-2022-06-06-12-10-16-338.png, image-2022-06-06-12-11-09-497.png, > khorn-notosansmono.png, khorn.patch > > > In the combination LATIN CAPITAL LETTER K WITH COMBINING HORN > the combining horm is positioned at the left side of the letter K instead of > the right side, with font Noto Sans Mono, see [^fop-text.fo.pdf] > !image-2022-06-06-12-10-16-338.png! > Compare with the rendering with HarfBuzz in !khorn-notosansmono.png! > This bug occurs also for the other combinations with COMBINING HORN in DIN > SPEC 91379. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (FOP-3074) Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono
[ https://issues.apache.org/jira/browse/FOP-3074 ] Simon Steiner deleted comment on FOP-3074: was (Author: ssteiner1): Can you try latest fop trunk to see if that helps > Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono > - > > Key: FOP-3074 > URL: https://issues.apache.org/jira/browse/FOP-3074 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.7 >Reporter: Volker Kunert >Priority: Major > Attachments: Main.java, fop-text.fo, fop-text.fo.pdf, fop.conf, > image-2022-06-06-12-10-16-338.png, image-2022-06-06-12-11-09-497.png, > khorn-notosansmono.png, khorn.patch > > > In the combination LATIN CAPITAL LETTER K WITH COMBINING HORN > the combining horm is positioned at the left side of the letter K instead of > the right side, with font Noto Sans Mono, see [^fop-text.fo.pdf] > !image-2022-06-06-12-10-16-338.png! > Compare with the rendering with HarfBuzz in !khorn-notosansmono.png! > This bug occurs also for the other combinations with COMBINING HORN in DIN > SPEC 91379. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3074) Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono
[ https://issues.apache.org/jira/browse/FOP-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550409#comment-17550409 ] Simon Steiner commented on FOP-3074: Can you try latest fop trunk to see if that helps > Wrong position of combining mark (COMBINING HORN) with Noto Sans Mono > - > > Key: FOP-3074 > URL: https://issues.apache.org/jira/browse/FOP-3074 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.7 >Reporter: Volker Kunert >Priority: Major > Attachments: Main.java, fop-text.fo, fop-text.fo.pdf, fop.conf, > image-2022-06-06-12-10-16-338.png, image-2022-06-06-12-11-09-497.png, > khorn-notosansmono.png, khorn.patch > > > In the combination LATIN CAPITAL LETTER K WITH COMBINING HORN > the combining horm is positioned at the left side of the letter K instead of > the right side, with font Noto Sans Mono, see [^fop-text.fo.pdf] > !image-2022-06-06-12-10-16-338.png! > Compare with the rendering with HarfBuzz in !khorn-notosansmono.png! > This bug occurs also for the other combinations with COMBINING HORN in DIN > SPEC 91379. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3065) Shifted combining chars
[ https://issues.apache.org/jira/browse/FOP-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546386#comment-17546386 ] Simon Steiner commented on FOP-3065: The font vendor may list the languages for example at: https://docs.microsoft.com/en-us/typography/font-list/cambria > Shifted combining chars > --- > > Key: FOP-3065 > URL: https://issues.apache.org/jira/browse/FOP-3065 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: fop.xconf, image-2022-04-26-08-56-51-840.png, > image-2022-04-29-11-53-00-968.png, image-2022-04-29-11-54-27-704.png, > image-2022-04-29-11-55-20-495.png, image-2022-04-30-13-54-09-030.png, > image-2022-04-30-13-54-23-021.png, image-2022-05-29-22-24-51-772.png, > shifted-1.pdf, shifted.fo-1.xml > > > Combining chars (above and below main char) render shifted. For instance: > n > N > f > F > > h > !image-2022-04-26-08-56-51-840.png! > > Combining char renders shifted to the left or right depends on the font. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3065) Shifted combining chars
[ https://issues.apache.org/jira/browse/FOP-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545958#comment-17545958 ] Simon Steiner commented on FOP-3065: You would need to use a font that supports the xml:lang you use > Shifted combining chars > --- > > Key: FOP-3065 > URL: https://issues.apache.org/jira/browse/FOP-3065 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: fop.xconf, image-2022-04-26-08-56-51-840.png, > image-2022-04-29-11-53-00-968.png, image-2022-04-29-11-54-27-704.png, > image-2022-04-29-11-55-20-495.png, image-2022-04-30-13-54-09-030.png, > image-2022-04-30-13-54-23-021.png, image-2022-05-29-22-24-51-772.png, > shifted-1.pdf, shifted.fo-1.xml > > > Combining chars (above and below main char) render shifted. For instance: > n > N > f > F > > h > !image-2022-04-26-08-56-51-840.png! > > Combining char renders shifted to the left or right depends on the font. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3065) Shifted combining chars
[ https://issues.apache.org/jira/browse/FOP-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544436#comment-17544436 ] Simon Steiner commented on FOP-3065: what about xml:lang="none" > Shifted combining chars > --- > > Key: FOP-3065 > URL: https://issues.apache.org/jira/browse/FOP-3065 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: fop.xconf, image-2022-04-26-08-56-51-840.png, > image-2022-04-29-11-53-00-968.png, image-2022-04-29-11-54-27-704.png, > image-2022-04-29-11-55-20-495.png, image-2022-04-30-13-54-09-030.png, > image-2022-04-30-13-54-23-021.png, image-2022-05-29-22-24-51-772.png, > shifted-1.pdf, shifted.fo-1.xml > > > Combining chars (above and below main char) render shifted. For instance: > n > N > f > F > > h > !image-2022-04-26-08-56-51-840.png! > > Combining char renders shifted to the left or right depends on the font. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3064) Wrong accent position in PDF
[ https://issues.apache.org/jira/browse/FOP-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544434#comment-17544434 ] Simon Steiner commented on FOP-3064: what about xml:lang="none" > Wrong accent position in PDF > > > Key: FOP-3064 > URL: https://issues.apache.org/jira/browse/FOP-3064 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: image-2022-04-25-15-28-24-248.png, > image-2022-04-25-15-30-05-741.png, image-2022-04-30-13-23-47-423.png, > image-2022-04-30-13-25-35-655.png, image-2022-04-30-13-26-21-967.png, > image-2022-05-24-14-05-20-676.png, image-2022-05-24-15-40-53-235.png, > image-2022-05-25-21-14-01-798.png, image-2022-05-25-21-16-15-935.png, > image-2022-05-25-21-44-30-254.png, image-2022-05-25-21-45-20-171.png, > image-2022-05-25-21-45-37-805.png, image-2022-05-26-11-51-51-538.png, > kafedra.fo.xml, kafedra.pdf > > > Combining Grave Accent character () encoded after letter `f` in the > source xsl-fo [^kafedra.fo.xml]: > kafedra > But accent character renders in PDF after letter 'a': > !image-2022-04-25-15-28-24-248.png! > In HTML and Word it renders ok: > !image-2022-04-25-15-30-05-741.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (FOP-3064) Wrong accent position in PDF
[ https://issues.apache.org/jira/browse/FOP-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544414#comment-17544414 ] Simon Steiner edited comment on FOP-3064 at 5/31/22 2:10 PM: - Can you remove xml:lang="en" No need for japanese was (Author: ssteiner1): Can you remove xml:lang="en" > Wrong accent position in PDF > > > Key: FOP-3064 > URL: https://issues.apache.org/jira/browse/FOP-3064 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: image-2022-04-25-15-28-24-248.png, > image-2022-04-25-15-30-05-741.png, image-2022-04-30-13-23-47-423.png, > image-2022-04-30-13-25-35-655.png, image-2022-04-30-13-26-21-967.png, > image-2022-05-24-14-05-20-676.png, image-2022-05-24-15-40-53-235.png, > image-2022-05-25-21-14-01-798.png, image-2022-05-25-21-16-15-935.png, > image-2022-05-25-21-44-30-254.png, image-2022-05-25-21-45-20-171.png, > image-2022-05-25-21-45-37-805.png, image-2022-05-26-11-51-51-538.png, > kafedra.fo.xml, kafedra.pdf > > > Combining Grave Accent character () encoded after letter `f` in the > source xsl-fo [^kafedra.fo.xml]: > kafedra > But accent character renders in PDF after letter 'a': > !image-2022-04-25-15-28-24-248.png! > In HTML and Word it renders ok: > !image-2022-04-25-15-30-05-741.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (FOP-3064) Wrong accent position in PDF
[ https://issues.apache.org/jira/browse/FOP-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544414#comment-17544414 ] Simon Steiner edited comment on FOP-3064 at 5/31/22 2:10 PM: - Can you remove xml:lang="en" No need for other changes was (Author: ssteiner1): Can you remove xml:lang="en" No need for japanese > Wrong accent position in PDF > > > Key: FOP-3064 > URL: https://issues.apache.org/jira/browse/FOP-3064 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: image-2022-04-25-15-28-24-248.png, > image-2022-04-25-15-30-05-741.png, image-2022-04-30-13-23-47-423.png, > image-2022-04-30-13-25-35-655.png, image-2022-04-30-13-26-21-967.png, > image-2022-05-24-14-05-20-676.png, image-2022-05-24-15-40-53-235.png, > image-2022-05-25-21-14-01-798.png, image-2022-05-25-21-16-15-935.png, > image-2022-05-25-21-44-30-254.png, image-2022-05-25-21-45-20-171.png, > image-2022-05-25-21-45-37-805.png, image-2022-05-26-11-51-51-538.png, > kafedra.fo.xml, kafedra.pdf > > > Combining Grave Accent character () encoded after letter `f` in the > source xsl-fo [^kafedra.fo.xml]: > kafedra > But accent character renders in PDF after letter 'a': > !image-2022-04-25-15-28-24-248.png! > In HTML and Word it renders ok: > !image-2022-04-25-15-30-05-741.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FOP-3064) Wrong accent position in PDF
[ https://issues.apache.org/jira/browse/FOP-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3064. Resolution: Not A Problem > Wrong accent position in PDF > > > Key: FOP-3064 > URL: https://issues.apache.org/jira/browse/FOP-3064 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: image-2022-04-25-15-28-24-248.png, > image-2022-04-25-15-30-05-741.png, image-2022-04-30-13-23-47-423.png, > image-2022-04-30-13-25-35-655.png, image-2022-04-30-13-26-21-967.png, > image-2022-05-24-14-05-20-676.png, image-2022-05-24-15-40-53-235.png, > image-2022-05-25-21-14-01-798.png, image-2022-05-25-21-16-15-935.png, > image-2022-05-25-21-44-30-254.png, image-2022-05-25-21-45-20-171.png, > image-2022-05-25-21-45-37-805.png, image-2022-05-26-11-51-51-538.png, > kafedra.fo.xml, kafedra.pdf > > > Combining Grave Accent character () encoded after letter `f` in the > source xsl-fo [^kafedra.fo.xml]: > kafedra > But accent character renders in PDF after letter 'a': > !image-2022-04-25-15-28-24-248.png! > In HTML and Word it renders ok: > !image-2022-04-25-15-30-05-741.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FOP-3064) Wrong accent position in PDF
[ https://issues.apache.org/jira/browse/FOP-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544414#comment-17544414 ] Simon Steiner commented on FOP-3064: Can you remove xml:lang="en" > Wrong accent position in PDF > > > Key: FOP-3064 > URL: https://issues.apache.org/jira/browse/FOP-3064 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: image-2022-04-25-15-28-24-248.png, > image-2022-04-25-15-30-05-741.png, image-2022-04-30-13-23-47-423.png, > image-2022-04-30-13-25-35-655.png, image-2022-04-30-13-26-21-967.png, > image-2022-05-24-14-05-20-676.png, image-2022-05-24-15-40-53-235.png, > image-2022-05-25-21-14-01-798.png, image-2022-05-25-21-16-15-935.png, > image-2022-05-25-21-44-30-254.png, image-2022-05-25-21-45-20-171.png, > image-2022-05-25-21-45-37-805.png, image-2022-05-26-11-51-51-538.png, > kafedra.fo.xml, kafedra.pdf > > > Combining Grave Accent character () encoded after letter `f` in the > source xsl-fo [^kafedra.fo.xml]: > kafedra > But accent character renders in PDF after letter 'a': > !image-2022-04-25-15-28-24-248.png! > In HTML and Word it renders ok: > !image-2022-04-25-15-30-05-741.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (FOP-3065) Shifted combining chars
[ https://issues.apache.org/jira/browse/FOP-3065 ] Simon Steiner deleted comment on FOP-3065: was (Author: ssteiner1): You may need to use one of the supported fonts: https://xmlgraphics.apache.org/fop/trunk/complexscripts.html#supported_fonts > Shifted combining chars > --- > > Key: FOP-3065 > URL: https://issues.apache.org/jira/browse/FOP-3065 > Project: FOP > Issue Type: Bug >Affects Versions: 2.4, 2.6, 2.7 >Reporter: Alexander Dyuzhev >Priority: Critical > Attachments: fop.xconf, image-2022-04-26-08-56-51-840.png, > image-2022-04-29-11-53-00-968.png, image-2022-04-29-11-54-27-704.png, > image-2022-04-29-11-55-20-495.png, image-2022-04-30-13-54-09-030.png, > image-2022-04-30-13-54-23-021.png, image-2022-05-29-22-24-51-772.png, > shifted-1.pdf, shifted.fo-1.xml > > > Combining chars (above and below main char) render shifted. For instance: > n > N > f > F > > h > !image-2022-04-26-08-56-51-840.png! > > Combining char renders shifted to the left or right depends on the font. -- This message was sent by Atlassian Jira (v8.20.7#820007)
