[jira] [Resolved] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2960. - Fix Version/s: trunk Resolution: Fixed Thanks for your contribution. This has been committed in revision 1884753 > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Fix For: trunk > > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2854) CreationDate in PDF metadata breaks reproducible builds
[
https://issues.apache.org/jira/browse/FOP-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254077#comment-17254077
]
Bernhard M. Wiedemann commented on FOP-2854:
Made at patch for CreationDate at
[https://github.com/apache/xmlgraphics-fop/pull/65]
However, I also found that our build-compare tool only showed the first diff,
so there are indeed more details to get right.
{{ DAPS 84.87.20180228.827b030
(https://opensuse.gith}}{{ub.io/daps) using openSUSE XSL Stylesheets 2.0.17
(based on DocBook XSL Styleshe}}{{ets 1.79.2)}}
{{- 2020-12-23T06:19:20Z}}
{{+ 2036-01-25T19:35:53Z}}
{{- /ID [
]}}
{{+ /ID [
]}}
{{-/BaseFont /EC+DejaVuSansMono}}
{{+/BaseFont /EC+DejaVuSansMono-Bold}}
> CreationDate in PDF metadata breaks reproducible builds
> ---
>
> Key: FOP-2854
> URL: https://issues.apache.org/jira/browse/FOP-2854
> Project: FOP
> Issue Type: Improvement
> Components: renderer/pdf
>Affects Versions: 2.3
> Environment: Debian GNU/Linux
>Reporter: Filippo Rusconi
>Priority: Major
>
> Greetings,
> I would like to report that the CreationDate value that is set in the PDF
> file changes at each run. This is problematic because that makes it
> impossible to run FOP in the context of reproducible builds (see
> https://wiki.debian.org/ReproducibleBuilds).
> Would it be possible to create an option to set that date value manually or
> some equivalent solution to this problem ?
> Thank you so much for your work on FOP !
> Regards,
> Filippo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOP-2960 started by Chris Bowditch. --- > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[ https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2960: --- Assignee: Chris Bowditch > [PATCH] Soft-Hyphen on Hyphenated words. > > > Key: FOP-2960 > URL: https://issues.apache.org/jira/browse/FOP-2960 > Project: FOP > Issue Type: Bug > Components: layout/line >Affects Versions: 1.1 >Reporter: Juan >Assignee: Chris Bowditch >Priority: Minor > Labels: hyphenation, soft-hyphen > Attachments: fix-soft-hyphens-on-hyphenated-words.patch > > > When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break > line at the position given by the higher level word hyphenation, ignoring the > pre-hyphenation made by applying soft-hyphens. > > About the patch: > Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to > FOP-2466 by disabling the higher level hyphenation when a word contains a > soft-hyphen. > Note that at this part of the code, the original word has been already > divided into 2 words by the soft-hyphen, to workaround this, we look at > current and previous Glyphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2983) [PATCH] Font auto-detection doesn't work
[ https://issues.apache.org/jira/browse/FOP-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254053#comment-17254053 ] Chris Bowditch commented on FOP-2983: - Can you provide more information on how to replicate the issue you describe. Preferrably attaching an FO file and fop.xconf file? > [PATCH] Font auto-detection doesn't work > > > Key: FOP-2983 > URL: https://issues.apache.org/jira/browse/FOP-2983 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.5, trunk > Environment: Apache Maven 3.6.0 > Java version: 1.8.0_181, vendor: Oracle Corporation > Default locale: ru_RU, platform encoding: Cp1251 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Sergey Gorbunov >Priority: Critical > Attachments: fonts-auto-detect.patch > > > When constructing a tree with a configuration, the node for auto-detection is > added to the wrong parent node. As a result, the flag remains with a false. > Detected when trying to convert SVG to PDF with Cyrillic characters. Since > the correct font was not detected automatically, incorrect characters were > displayed after conversion. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2985) SVG Images inherit font configuration from sibling objects.
[ https://issues.apache.org/jira/browse/FOP-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2985: Summary: SVG Images inherit font configuration from sibling objects. (was: [PATCH] SVG Images inherit font configuration from sibling objects.) > SVG Images inherit font configuration from sibling objects. > --- > > Key: FOP-2985 > URL: https://issues.apache.org/jira/browse/FOP-2985 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Juan >Priority: Minor > Attachments: SVG-letter-spacing.patch, input.fo, sample.svg > > > Given the sample [^input.fo] (adjust the path to sample.svg), the letter > spacing of an inline element in a previous block is being applied also to an > external-graphic element on a different block. > The letter spacing property in the inline element should not affect the > external-graphic in a different block. > Additionally, setting letter-spacing on the external-graphic or it's parent > block has no effect and the content still used the letter-spacing of the > previous inline text. > > The given patch [^SVG-letter-spacing.patch] does fix the issue with > letter-spacing, altough *it might need a more generic approach*. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2985) [PATCH] SVG Images inherit font configuration from sibling objects.
[ https://issues.apache.org/jira/browse/FOP-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254050#comment-17254050 ] Chris Bowditch commented on FOP-2985: - I don't think this is the right solution. As you mention its specific fix to PDF, and I don't think we should be calling beginText when rendering an image. We don't even know if the image is an SVG at the place where you inserted this code. I think letter spacing should be reset when ending the fo:inline with it set, and this should be done in AbstractRenderer or IFRenderer not in PDFPainter > [PATCH] SVG Images inherit font configuration from sibling objects. > --- > > Key: FOP-2985 > URL: https://issues.apache.org/jira/browse/FOP-2985 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Juan >Priority: Minor > Attachments: SVG-letter-spacing.patch, input.fo, sample.svg > > > Given the sample [^input.fo] (adjust the path to sample.svg), the letter > spacing of an inline element in a previous block is being applied also to an > external-graphic element on a different block. > The letter spacing property in the inline element should not affect the > external-graphic in a different block. > Additionally, setting letter-spacing on the external-graphic or it's parent > block has no effect and the content still used the letter-spacing of the > previous inline text. > > The given patch [^SVG-letter-spacing.patch] does fix the issue with > letter-spacing, altough *it might need a more generic approach*. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2497) XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2497: Summary: XML processor attempts to resolve URIs from internet when loading XSLT source (was: [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source) > XML processor attempts to resolve URIs from internet when loading XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FOP-2497) [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254016#comment-17254016 ] Chris Bowditch edited comment on FOP-2497 at 12/23/20, 10:34 AM: - Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue, i.e. the XML and XSLT source was (Author: cbowditch): Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue > [PATCH] XML processor attempts to resolve URIs from internet when loading > XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2497) [PATCH] XML processor attempts to resolve URIs from internet when loading XSLT source
[ https://issues.apache.org/jira/browse/FOP-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254016#comment-17254016 ] Chris Bowditch commented on FOP-2497: - Please attach your suggested change as a patch file, not a link to github. Also, please describe what inputs you gave to FOP to observe the issue > [PATCH] XML processor attempts to resolve URIs from internet when loading > XSLT source > - > > Key: FOP-2497 > URL: https://issues.apache.org/jira/browse/FOP-2497 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, 2.0 >Reporter: Dan Allen >Priority: Minor > > The XSL processor attempts to reach out to the internet to resolve URIs in > XSLT source files. This is not the expected behavior. This happens because > the URIResolver is not registered on the TransformerFactory when it creates a > Transformer instance for a given XSLT source. > The fix assigns the URIResolver to the TransformerFactory (which then gets > assigned to any Transformer created from that factory) rather than on the > Transformer. This change allows the processor to resolve URIs in the XSLT > source when the source is being loaded. > This patch also registers the InputHandler as an ErrorListener for the > TransformerFactory so that any errors that occur while loading the XSLT are > logged consistently. > The patch is available at the following URL: > https://github.com/apache/fop/pull/1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
