[jira] [Comment Edited] (FOP-2364) Keep-with-next integer value: Illegal value for breakClass: 75
[
https://issues.apache.org/jira/browse/FOP-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295232#comment-15295232
]
Andreas L. Delmelle edited comment on FOP-2364 at 5/21/16 8:09 PM:
---
I quickly checked the code, and this comment is entirely to the point. I
suspect the explanation is that at some point, some dev started mixing the
concepts of "enum values for the {{break-*}} properties" on the one hand and
"break classes" on the other. The latter is internal to FOP, so one could argue
that, architecturally, it is actually improper to use the same symbolic
literals, defined in {{org.apache.fop.fo.Constants}}, for something that is
strictly internal to the {{org.apache.fop.layoutmgr}} package. For that matter,
I am not sure what the rationale was for putting that {{BreakUtil}} class in
the _general_ utilities package. I cannot immediately imagine where that would
be useful outside of the layout context, but maybe that's just me...
Now, the result is that a literal EN_LINE, which represents the enum value
"line" -- and note: cannot even be used as a value in said {{break-*}}
properties; it is meant for the more exotic, float-related
{{intrusion-displace}} property (see:
http://www.w3.org/TR/xsl/#intrusion-displace ) -- is being used, in the FOP
layout code, to represent a "break class" that I would guess to have the
highest priority...?
EDIT - ... or better, a "keep class" with the lowest priority; see
{{org.apache.fop.layoutmgr.Keep}}.
A "break class" is roughly the result in the layout code of merging the
different {{break-\*}} *and* {{keep-\*}} properties at different levels. Since
there is a specific {{keep-with-next.within-line}} property that is implicitly
set via the shorthand, that now translates into a "break class" of EN_LINE...
Pretty sure the {{.within-line}} component is not officially supported, though
(read: not included in the test cases). The general workaround given on
fop-users@ is usually to avoid using the shorthand for specifying keeps, and
mostly useful to avoid accidentally setting {{keep-together.within-line}} to
"always". Perhaps worth a try to check here whether explicitly setting only the
{{.within-page}} and/or {{.within-column}} to the integer value would avoid the
issue.
was (Author: adelmelle):
I quickly checked the code, and this comment is entirely to the point. I
suspect the explanation is that at some point, some dev started mixing the
concepts of "enum values for the {{break-*}} properties" on the one hand and
"break classes" on the other. The latter is internal to FOP, so one could argue
that, architecturally, it is actually improper to use the same symbolic
literals, defined in {{org.apache.fop.fo.Constants}}, for something that is
strictly internal to the {{org.apache.fop.layoutmgr}} package. For that matter,
I am not sure what the rationale was for putting that {{BreakUtil}} class in
the _general_ utilities package. I cannot immediately imagine where that would
be useful outside of the layout context, but maybe that's just me...
Now, the result is that a literal EN_LINE, which represents the enum value
"line" -- and note: cannot even be used as a value in said {{break-*}}
properties; it is meant for the more exotic, float-related
{{intrusion-displace}} property (see:
http://www.w3.org/TR/xsl/#intrusion-displace ) -- is being used, in the FOP
layout code, to represent a "break class" that I would guess to have the
highest priority...?
A "break class" is roughly the result in the layout code of merging the
different {{break-\*}} *and* {{keep-\*}} properties at different levels. Since
there is a specific {{keep-with-next.within-line}} property that is implicitly
set via the shorthand, that now translates into a "break class" of EN_LINE...
Pretty sure the {{.within-line}} component is not officially supported, though
(read: not included in the test cases). The general workaround given on
fop-users@ is usually to avoid using the shorthand for specifying keeps, and
mostly useful to avoid accidentally setting {{keep-together.within-line}} to
"always". Perhaps worth a try to check here whether explicitly setting only the
{{.within-page}} and/or {{.within-column}} to the integer value would avoid the
issue.
> Keep-with-next integer value: Illegal value for breakClass: 75
> --
>
> Key: FOP-2364
> URL: https://issues.apache.org/jira/browse/FOP-2364
> Project: FOP
> Issue Type: Bug
> Components: layout/unqualified
>Affects Versions: trunk
>Reporter: Matthias Reischenbacher
> Attachments: illegal_break_class_75.xml
>
>
> The attached sample FO file causes an IllegalArgumentException: Illegal value
> for breakClass: 75.
> It seems to be related to the integer value within
[jira] [Commented] (FOP-2364) Keep-with-next integer value: Illegal value for breakClass: 75
[
https://issues.apache.org/jira/browse/FOP-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295232#comment-15295232
]
Andreas L. Delmelle commented on FOP-2364:
--
I quickly checked the code, and this comment is entirely to the point. I
suspect the explanation is that at some point, some dev started mixing the
concepts of "enum values for the {{break-*}} properties" on the one hand and
"break classes" on the other. The latter is internal to FOP, so one could argue
that, architecturally, it is actually improper to use the same symbolic
literals, defined in {{org.apache.fop.fo.Constants}}, for something that is
strictly internal to the {{org.apache.fop.layoutmgr}} package. For that matter,
I am not sure what the rationale was for putting that {{BreakUtil}} class in
the _general_ utilities package. I cannot immediately imagine where that would
be useful outside of the layout context, but maybe that's just me...
Now, the result is that a literal EN_LINE, which represents the enum value
"line" -- and note: cannot even be used as a value in said {{break-*}}
properties; it is meant for the more exotic, float-related
{{intrusion-displace}} property (see:
http://www.w3.org/TR/xsl/#intrusion-displace ) -- is being used, in the FOP
layout code, to represent a "break class" that I would guess to have the
highest priority...?
A "break class" is roughly the result in the layout code of merging the
different {{break-\*}} *and* {{keep-\*}} properties at different levels. Since
there is a specific {{keep-with-next.within-line}} property that is implicitly
set via the shorthand, that now translates into a "break class" of EN_LINE...
Pretty sure the {{.within-line}} component is not officially supported, though
(read: not included in the test cases). The general workaround given on
fop-users@ is usually to avoid using the shorthand for specifying keeps, and
mostly useful to avoid accidentally setting {{keep-together.within-line}} to
"always". Perhaps worth a try to check here whether explicitly setting only the
{{.within-page}} and/or {{.within-column}} to the integer value would avoid the
issue.
> Keep-with-next integer value: Illegal value for breakClass: 75
> --
>
> Key: FOP-2364
> URL: https://issues.apache.org/jira/browse/FOP-2364
> Project: FOP
> Issue Type: Bug
> Components: layout/unqualified
>Affects Versions: trunk
>Reporter: Matthias Reischenbacher
> Attachments: illegal_break_class_75.xml
>
>
> The attached sample FO file causes an IllegalArgumentException: Illegal value
> for breakClass: 75.
> It seems to be related to the integer value within the keep-with-next
> property.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2525: - Comment: was deleted (was: Yes, very likely the exact same issue, since GlyphPositioningTable is a subclass of GlyphTable. Are you at liberty to try the attached patch, and apply it locally to confirm that this fixes the issue on your end? So far, apart from David, we have not received any confirmation that the patch really resolves it...) > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > Attachments: FOP-2525.patch > > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191040#comment-15191040 ] Andreas L. Delmelle commented on FOP-2525: -- Yes, very likely the exact same issue, since GlyphPositioningTable is a subclass of GlyphTable. Are you at liberty to try the attached patch, and apply it locally to confirm that this fixes the issue on your end? So far, apart from David, we have not received any confirmation that the patch really resolves it... > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > Attachments: FOP-2525.patch > > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191039#comment-15191039 ] Andreas L. Delmelle commented on FOP-2525: -- Yes, very likely the exact same issue, since GlyphPositioningTable is a subclass of GlyphTable. Are you at liberty to try the attached patch, and apply it locally to confirm that this fixes the issue on your end? So far, apart from David, we have not received any confirmation that the patch really resolves it... > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > Attachments: FOP-2525.patch > > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2590) Text wrapping not working, when there is an ampersand (&) in the text
[ https://issues.apache.org/jira/browse/FOP-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190913#comment-15190913 ] Andreas L. Delmelle commented on FOP-2590: -- Yep, plenty of examples. To name a few: quotes, apostrophes, exclamation marks, question marks, commas... although with commas, I assume it does allow a break after, if the preceding character is a letter (?) To find all of them, or check if a specific codepoint belongs to that class, check ftp://ftp.unicode.org/Public/UNIDATA/LineBreak.txt and look for '# Po' > Text wrapping not working, when there is an ampersand (&) in the text > - > > Key: FOP-2590 > URL: https://issues.apache.org/jira/browse/FOP-2590 > Project: FOP > Issue Type: Bug >Reporter: Murthy > Attachments: screenshot.png > > > Hi, > I have the below 2 Texts and the one with the ampersand (&) is not wrapping > the text within the block, and the one which has the text without it is > wrapping, > With ampersand (&): > > Task: Task added without spaces for testing 31090 and sepertaed by commas > from now one > 11,12,13,14,15,16,11,11,11,11,11,11,11,11,11,11,16dfdfd > Wihtout ampersand > > Task: Task added without spaces for testing 31090 and sepertaed by commas > from now one > 11ac,12ac,13ac,14ac,15ac,16ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,16dfdfd > Using FOP 1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2590) Text wrapping not working, when there is an ampersand (&) in the text
[ https://issues.apache.org/jira/browse/FOP-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle resolved FOP-2590. -- Resolution: Not A Bug No bug, but intended behaviour, as far as I know. An ampersand belongs to a class of characters (PO - Postfix Numeric) that prohibits breaks in Unicode UAX#14 line breaking rules (especially so when preceded or followed by digits or letters). One way to work around that would be to insert ZWSP before and/or after the ampersands to allow line breaks. > Text wrapping not working, when there is an ampersand (&) in the text > - > > Key: FOP-2590 > URL: https://issues.apache.org/jira/browse/FOP-2590 > Project: FOP > Issue Type: Bug >Reporter: Murthy > Attachments: screenshot.png > > > Hi, > I have the below 2 Texts and the one with the ampersand (&) is not wrapping > the text within the block, and the one which has the text without it is > wrapping, > With ampersand (&): > > Task: Task added without spaces for testing 31090 and sepertaed by commas > from now one > 11,12,13,14,15,16,11,11,11,11,11,11,11,11,11,11,16dfdfd > Wihtout ampersand > > Task: Task added without spaces for testing 31090 and sepertaed by commas > from now one > 11ac,12ac,13ac,14ac,15ac,16ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,11ac,16dfdfd > Using FOP 1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2578) Add support for the background shorthand property
[
https://issues.apache.org/jira/browse/FOP-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153216#comment-15153216
]
Andreas L. Delmelle edited comment on FOP-2578 at 2/18/16 10:16 PM:
Actually, I don't think it is that difficult to add, given that, apart from
background-attachment, all the other base or shorthand properties are already
implemented. Not sure why it was never done. Perhaps simply because there was
not enough demand, and priorities and such...
For someone looking at taking a crack at this, the existing pair
{{o.a.f.fo.properties.FontShorthandParser}} and
{{o.a.f.fo.properties.FontShorthandProperty}} can serve to get some idea on how
to implement such shorthands.
The only part I am a bit uncertain about is the fact that this is actually a
'shorthand shorthand' if you will (i.e. background-position is in itself
already a shorthand). Not sure how much complexity that would add.
EDIT - Just caught the remark about FOP-1423... That one would have to be fixed
first, obviously.
Just my 2 cents...
was (Author: adelmelle):
Actually, I don't think it is that difficult to add, given that, apart from
background-attachment, all the other base or shorthand properties are already
implemented. Not sure why it was never done. Perhaps simply because there was
not enough demand, and priorities and such...
For someone looking at taking a crack at this, the existing pair
{{o.a.f.fo.properties.FontShorthandParser}} and
{{o.a.f.fo.properties.FontShorthandProperty}} can serve to get some idea on how
to implement such shorthands.
The only part I am a bit uncertain about is the fact that this is actually a
'shorthand shorthand' if you will (i.e. background-position is in itself
already a shorthand). Not sure how much complexity that would add.
Just my 2 cents...
> Add support for the background shorthand property
> -
>
> Key: FOP-2578
> URL: https://issues.apache.org/jira/browse/FOP-2578
> Project: FOP
> Issue Type: Improvement
> Components: fo/unqualified
>Affects Versions: 2.1
>Reporter: Vincent Massol
>
> The following input doesn't display any image in the PDF generated by FOP:
> {code}
> background="url(http://semiticsoft.com/resources/front_end/images/Icon-Globe-Small.gif;)
> no-repeat right center">
>role="html:p">helloworld
>
>
> {code}
> While the following does:
> {code}
> background-image="url(http://semiticsoft.com/resources/front_end/images/Icon-Globe-Small.gif;)"
> background-repeat="no-repeat" background-position="right center">
>role="html:p">helloworld
>
>
> {code}
> It would be nice if the "background" shortcut property could be supported:
> https://www.w3.org/wiki/CSS/Properties/background
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2578) Add support for the background shorthand property
[
https://issues.apache.org/jira/browse/FOP-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153216#comment-15153216
]
Andreas L. Delmelle commented on FOP-2578:
--
Actually, I don't think it is that difficult to add, given that, apart from
background-attachment, all the other base or shorthand properties are already
implemented. Not sure why it was never done. Perhaps simply because there was
not enough demand, and priorities and such...
For someone looking at taking a crack at this, the existing pair
{{o.a.f.fo.properties.FontShorthandParser}} and
{{o.a.f.fo.properties.FontShorthandProperty}} can serve to get some idea on how
to implement such shorthands.
The only part I am a bit uncertain about is the fact that this is actually a
'shorthand shorthand' if you will (i.e. background-position is in itself
already a shorthand). Not sure how much complexity that would add.
Just my 2 cents...
> Add support for the background shorthand property
> -
>
> Key: FOP-2578
> URL: https://issues.apache.org/jira/browse/FOP-2578
> Project: FOP
> Issue Type: Improvement
> Components: fo/unqualified
>Affects Versions: 2.1
>Reporter: Vincent Massol
>
> The following input doesn't display any image in the PDF generated by FOP:
> {code}
> background="url(http://semiticsoft.com/resources/front_end/images/Icon-Globe-Small.gif;)
> no-repeat right center">
>role="html:p">helloworld
>
>
> {code}
> While the following does:
> {code}
> background-image="url(http://semiticsoft.com/resources/front_end/images/Icon-Globe-Small.gif;)"
> background-repeat="no-repeat" background-position="right center">
>role="html:p">helloworld
>
>
> {code}
> It would be nice if the "background" shortcut property could be supported:
> https://www.w3.org/wiki/CSS/Properties/background
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FOP-2461) NullPointerException in ListItemLayoutManager since Temp_BasicSideFloat Merge
[ https://issues.apache.org/jira/browse/FOP-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle resolved FOP-2461. -- Resolution: Fixed Fix Version/s: 2.1 > NullPointerException in ListItemLayoutManager since Temp_BasicSideFloat Merge > - > > Key: FOP-2461 > URL: https://issues.apache.org/jira/browse/FOP-2461 > Project: FOP > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk >Reporter: Matthias Reischenbacher > Fix For: 2.1 > > Attachments: fop-2461-test-case.xml, listNPE.patch > > > The attached fo test cases causes a NullPointerException inside > ListItemLayoutManager. This is the stack trace: > java.lang.NullPointerException > at > org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405) > at > org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) > at > org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) > at > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) > at > org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:191) > at > org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:120) > at > org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:63) > at > org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:270) > at > org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:212) > at > org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:273) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223) > at > org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:148) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116) > at > org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69) > at > org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252) > at > org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643) > at > org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178) > at > org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158) > at > org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384) > at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112) > at > org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:135) > at > org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267) > at > org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360) > at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190) > at > org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) > 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 >
[jira] [Updated] (FOP-2577) Improve semantics of layout "auxiliary" Position
[ https://issues.apache.org/jira/browse/FOP-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2577: - Attachment: listNPE.patch Re-attaching the patch submitted by Thanasis Giannimaras in FOP-2461 here, as a starting point. > Improve semantics of layout "auxiliary" Position > > > Key: FOP-2577 > URL: https://issues.apache.org/jira/browse/FOP-2577 > Project: FOP > Issue Type: Improvement > Components: layout/unqualified >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Labels: patch > Attachments: listNPE.patch > > > Creating this issue as a follow-up to FOP-2461, which itself is resolved with > a quick workaround as of FOP 2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2577) Improve semantics of layout "auxiliary" Position
Andreas L. Delmelle created FOP-2577: Summary: Improve semantics of layout "auxiliary" Position Key: FOP-2577 URL: https://issues.apache.org/jira/browse/FOP-2577 Project: FOP Issue Type: Improvement Components: layout/unqualified Reporter: Andreas L. Delmelle Assignee: Andreas L. Delmelle Priority: Minor Creating this issue as a follow-up to FOP-2461, which itself is resolved with a quick workaround as of FOP 2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2402: - Attachment: (was: FOP-2402.fo) > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.pdf, bad.fo, bad.pdf, footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146232#comment-15146232 ] Andreas L. Delmelle commented on FOP-2402: -- Some further musings on this issue: Seems like the best option would be to do some minor refactoring of the list layout code (in ListItemLayoutManager). I am currently thinking of, as a first step, introducing a ListItemStepper, to stress the analogy between lists and tables -- there already is a TableStepper --, then see if this triggers new insights into potential simplifications of the code. That new class can hold some of the logic that is currently in getCombinedKnuthElementsForListItem() and getNextStep(), in an attempt to make the former method a bit easier to grasp. It will definitely be tricky to get it all right, though. The case as presented here is rather simple, since the label is empty. This should normally yield the same output as a two-column table, with a zero-width first column. In most cases, the label will consist of a single part, which will still not add too much complexity. The main focus will be the multi-part body content. The point where it gets really interesting is where a list is really used as a two-column table. If both label and body have multiple parts _and_ those parts have stretchable spaces with different widths, we somehow need to generate one or more "combined" glue elements that have the appropriate effect when the layout algorithm is run over it...? I can imagine that this may be one of the reasons why the table layout code currently simply converts all stretchable glues into non-stretchable ones ( ? ) > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.fo, FOP-2402.pdf, bad.fo, bad.pdf, > footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 7:16 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-before discarded -- and all following boxes are 17pt (= 12pt + 5pt). The list has no glues, i.e. from the point of view of the algorithm there is nothing to stretch/shrink at the given page-break position, and it is all-or-nothing. In case the list is not nested, the page-breaking algorithm gets to see the full set of elements produced by the list, which has the spaces neatly represented by glue elements, which allows the algorithm to play with stretch/shrink at each break position. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.fo, FOP-2402.pdf, bad.fo, bad.pdf, > footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. --
[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 6:50 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.fo, FOP-2402.pdf, bad.fo, bad.pdf, > footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 7:38 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-before discarded -- and all following boxes are 17pt (= 12pt + 5pt). The list has no glues, i.e. from the point of view of the algorithm there is nothing to stretch/shrink at the given page-break position, and it is all-or-nothing. In case the list is not nested, the page-breaking algorithm gets to see the full set of elements produced by the list, which has the spaces neatly represented by glue elements, which allows the algorithm to play with stretch/shrink at each break position. EDIT 3 - So, the actual root cause of the problem is that a sequence of glue-box produced by a nested LM is merged into a single box. If we can avoid that from happening, it should be solved. The table layout code seems to handle this slightly better, as in: it does not merge glue-box sequences into a single box, but there I noticed that the glues are somehow returned as non-stretchable, which would result in a tiny amount of space between the last list item on the first page and the footnotes. Only in case of a plain block parent is the result as expected (no matter how many levels are nested), because the block LM always returns the sequence it receives from its child LM, with only minimal additions in case the block has borders or spaces set. It does not combine anything. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-before discarded --
[jira] [Commented] (FOP-2574) Right alignment doesn't work correctly
[
https://issues.apache.org/jira/browse/FOP-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143843#comment-15143843
]
Andreas L. Delmelle commented on FOP-2574:
--
I assume, by "wrapper", you refer to the inner block, and yes, I admit it does
not automatically take care of the case where you have lines of varying width,
where some are larger and others do fit.
As to your question, the answer is: it depends... :)
If that is the appropriate thing to do, then yes, but it is definitely not
always that way. While a fo:block-container is _similar to_ a div, it is not
really the same.
Simple example of where the behaviour differs is the "margin-left", or the
XSL-FO correlate "start-indent".
Without actually rendering, try to take a stab at what the following should
look like:
{code:language=xml}
{code}
Now, try to render it with FOP to see if that matches your expectation...
However unexpected the result, be sure that we double-checked this with the
XSL-FO WG, and the result produced by FOP is exactly as intended. All other FO
processors at that time rendered it more as expected, but were actually
non-compliant in their implementation.
As to this particular case, it is possible that FOP 2.1 is wrong, but this
seems like a question for the XSL-FO WG rather than something we just want to
copy from existing HTML renderers.
> Right alignment doesn't work correctly
> --
>
> Key: FOP-2574
> URL: https://issues.apache.org/jira/browse/FOP-2574
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: Window 7 x64, Java build 1.8.0_72-b15
>Reporter: Đorđe Zeljić
>
> Simple .fo example at
> https://gist.github.com/zeljic/d83ecee965ce89b79c2e
> doesn't work the same in 1.1 and (2.0 or 2.1) versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2574) Right alignment doesn't work correctly
[
https://issues.apache.org/jira/browse/FOP-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143505#comment-15143505
]
Andreas L. Delmelle commented on FOP-2574:
--
Seems like somehow, I cannot edit my own reply, so to amend my previous answer:
the nested fo:block-container is actually not even needed, and you can just do:
{code:language=xml}
AAA
Lorem ipsum oposum!
{code}
> Right alignment doesn't work correctly
> --
>
> Key: FOP-2574
> URL: https://issues.apache.org/jira/browse/FOP-2574
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: Window 7 x64, Java build 1.8.0_72-b15
>Reporter: Đorđe Zeljić
>
> Simple .fo example at
> https://gist.github.com/zeljic/d83ecee965ce89b79c2e
> doesn't work the same in 1.1 and (2.0 or 2.1) versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2574) Right alignment doesn't work correctly
[
https://issues.apache.org/jira/browse/FOP-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143488#comment-15143488
]
Andreas L. Delmelle commented on FOP-2574:
--
*scratches head*
After looking at the sample rendered in HTML, I must admit that that does looks
a bit unexpected...
Still, all browsers I tried, rendered it exactly the same way. The CSS spec --
and by extension also XSL-FO -- does state that the alignment is not with
respect to the viewport, though, so not sure if that means we are implementing
it wrongly ( ? )
That said, suppose one adds one line above that just contains the string 'AAA',
you would end up with a right-aligned first line and a second line that
_appears_ to be left-aligned ( ? )
Example in HTML:
{code:language=html}
AAALorem ipsum
oposum!
{code}
If that is the intended rendering, it can be obtained via FOP by means of a
nested fo:block-container. Note that "text-align" is an inherited property, so
can be set at the level of the outer fo:block-container, and then overridden on
an inner fo:block-container.
Example rendering similarly in XSL-FO:
{code:language=xml}
AAA
Lorem ipsum
oposum!
{code}
> Right alignment doesn't work correctly
> --
>
> Key: FOP-2574
> URL: https://issues.apache.org/jira/browse/FOP-2574
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: Window 7 x64, Java build 1.8.0_72-b15
>Reporter: Đorđe Zeljić
>
> Simple .fo example at
> https://gist.github.com/zeljic/d83ecee965ce89b79c2e
> doesn't work the same in 1.1 and (2.0 or 2.1) versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2402: - Attachment: FOP-2402.pdf Just a bit of further info: As far as I can see, the assessment in the previous comment is roughly correct. It is definitely related to the stretchable spaces, and it seems indeed like the breaks are calculated using the minimum or optimum, while the maximum is eventually used, which then leads to the overlap. Replacing the stretchable spaces with fixed ones also avoids the bug from manifesting. Either the last footnote is shifted to the next page (when using the maximum), or everything fits nicely (using the minimum or optimum values). See also attached for a more reduced sample, which already shows the bug manifesting, but you admittedly do need a good pair of eyes to see it, as it seems to be a matter of a couple of pt there. Added background-colors for additional clarity. Looking carefully, two things struck me: * the yellow background of the footnote overlaps a tiny bit with the red of the last list item. * on the second page, the blue background, which corresponds to the spacing, is slightly less than it is on the first, even though there would be more than enough room there to use the maximum value. Looking at the area tree XML reveals that, indeed, for the first page the maximum value of 6pt for the space-before is used, while it is the optimum value of 5pt on the second page... > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.pdf, bad.fo, bad.pdf, footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2402: - Attachment: (was: FOP-2402.pdf) > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.pdf, bad.fo, bad.pdf, footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15137145#comment-15137145 ] Andreas L. Delmelle commented on FOP-2525: -- Thanks for tracing it this far, and the suggested patch! Still, I am curious why/whether this would truly solve the memory leak as reported. I can see how this would lead to a reduced number of instances that would have been considered unequal before the patch, but have you been able to ascertain that those instances are now properly collected (i.e. the OOM is not just postponed)? Or would the explanation be that the GC relies on the hashCode() and equals() methods to determine which instances can and should be collected? Any idea? > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2574) Right alignment doesn't work correctly
[ https://issues.apache.org/jira/browse/FOP-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle closed FOP-2574. Resolution: Invalid As far as I can tell, this is not a bug. The behaviour in 1.1 was actually a regression, as it did work correctly in 1.0. This was fixed in 2.0, see also FOP-2177. > Right alignment doesn't work correctly > -- > > Key: FOP-2574 > URL: https://issues.apache.org/jira/browse/FOP-2574 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0, 2.1 > Environment: Window 7 x64, Java build 1.8.0_72-b15 >Reporter: Đorđe Zeljić > > Simple .fo example at > https://gist.github.com/zeljic/d83ecee965ce89b79c2e > doesn't work the same in 1.1 and (2.0 or 2.1) versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[
https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15137742#comment-15137742
]
Andreas L. Delmelle commented on FOP-2525:
--
Thanks for the clarification. Makes a lot of sense now. I personally am no
expert in that particular part of the FOP code either, but if GlyphTable is
used as -- or better: if I interpret the code correctly, _indirectly used in_
-- a key in a Map, then it should indeed have proper {{equals()}} and
{{hashCode()}} implementations.
The {{ScriptProcessor.AssembledLookupsKey.equals()}} method performs a check on
whether one GlyphTable equals another, so if the implementation is absent, the
default implementation from {{java.lang.Object}} is used, which only considers
x and y equal if they are truly identical (i.e. {{x == y}})...
As to the static and unbounded characteristic, it remains to be investigated
whether this is really the most appropriate solution here...
For now, I will see about getting those two methods committed to the trunk, so
at least this particular problem is resolved.
Thanks again for your efforts!
> Memory leak present when using Truetype Collection (.ttc)
> -
>
> Key: FOP-2525
> URL: https://issues.apache.org/jira/browse/FOP-2525
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: At least Mac and Linux, both Oracle VM and OpenJDK
>Reporter: Jeremy Smith
>Priority: Minor
>
> When a TrueType Collection file is used to specify custom fonts, and a
> long-running FopFactory is used to create FOP instances to process many FO
> input documents, millions of
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances
> get created which are never collected. Thus the heap continues to grow,
> leading to eventual GC thrashing or crash.
> When the same fonts are used, but extracted from the TTC file, the issue does
> not occur, and the instances of those classes are collected normally.
> The issue can be seen by repeatedly processing a document with a config.xml
> which specifies fonts inside of a Truetype Collection file. Attaching
> VisualVM to such a process will show continuous heap growth and millions of
> aforementioned instances whose numbers never decrease.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2525: - Attachment: FOP-2525.patch Patch to FOP trunk, following David's suggestion. hashCode() aligned with the implementations already used elsewhere in FOP's codebase. It would be great if the OP (Jeremy) could also independently verify and confirm that this fixes the issue on his end, prior to committing. Unless anyone objects, I will commit this change by the end of the week. > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > Attachments: FOP-2525.patch > > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2402: - Attachment: FOP-2402.pdf I may have some good news... On my end, it renders as in attach. The only potential issue I still see is that the superscript footnote label on the second page is clipped, but that is due to the "line-height-shift-adjustment" specified on the root. If you remove that, then the result looks slightly better. Now, the reason this appears 'fixed' on my end, is because I locally have the changes for proper orphans and widows handling incorporated in my local copy. Can you try to apply the patch attached to FOP-1488 to confirm? Note - Just confirmed that this would still pose a problem if the user forces widows and orphans to 1, which would trigger the behaviour of current trunk. For the case as attached, default values of 2 for each of the properties should be respected, which FOP 2.1 does not yet properly implement. Also note that just removing the "line-height-shift-adjustment" appears to trigger another bug, where some content is dropped, i.e. the second page appears blank...? > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.pdf, bad.fo, bad.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138004#comment-15138004 ] Andreas L. Delmelle commented on FOP-2402: -- Indeed, I neglected to try that, but as you point out, copying the last list-item -- just once is already enough -- will trigger the bug with default widows/orphans of 2. Will be looking closer into this as soon as I find the time. > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.pdf, bad.fo, bad.pdf, footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2573) Font-Family attribute is case-sensitive
[ https://issues.apache.org/jira/browse/FOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2573: - Affects Version/s: 2.1 > Font-Family attribute is case-sensitive > --- > > Key: FOP-2573 > URL: https://issues.apache.org/jira/browse/FOP-2573 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0, 2.1 > Environment: Window 7 x64, Java build 1.8.0_72-b15 >Reporter: Đorđe Zeljić > > I have simple FO file that contains block with font-family attribute (It's > very simple version of my huge FO file where I found the issue). > The attribute contains font name (eg. consolas). > When I try to render PDF I see the warn message: > WARNING: Font "consolas,normal,400" not found. Substituting with > "any,normal,400". > The test FO file is rendered fine in FOP 1.1 version, but not in 2.0 and 2.1 > versions. > I'm not sure if this is the bug, or it was in 1.1 version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2573) Font-Family attribute is case-sensitive
[ https://issues.apache.org/jira/browse/FOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136228#comment-15136228 ] Andreas L. Delmelle commented on FOP-2573: -- At first glance, this would indeed be a bug in 2.0. While I did not find it explicitly mentioned that the "font-family" attribute should or should not be case-sensitive, looking at an example in the CSS2 specification[*] referenced by XSL-FO, a value "new century schoolbook" is used, which seems to hint that it should indeed be treated in a case-insensitive manner... ? [*] http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-family > Font-Family attribute is case-sensitive > --- > > Key: FOP-2573 > URL: https://issues.apache.org/jira/browse/FOP-2573 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: Window 7 x64, Java build 1.8.0_72-b15 >Reporter: Đorđe Zeljić > > I have simple FO file that contains block with font-family attribute (It's > very simple version of my huge FO file where I found the issue). > The attribute contains font name (eg. consolas). > When I try to render PDF I see the warn message: > WARNING: Font "consolas,normal,400" not found. Substituting with > "any,normal,400". > The test FO file is rendered fine in FOP 1.1 version, but not in 2.0 and 2.1 > versions. > I'm not sure if this is the bug, or it was in 1.1 version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2573) Font-Family attribute is case-sensitive
[
https://issues.apache.org/jira/browse/FOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136228#comment-15136228
]
Andreas L. Delmelle edited comment on FOP-2573 at 2/7/16 12:30 PM:
---
At first glance, this would indeed be a bug in 2.0. While I did not find it
explicitly mentioned that the "font-family" attribute should or should not be
case-sensitive, looking at an example in the CSS2 specification[*] referenced
by XSL-FO, a value "new century schoolbook" is used, which seems to hint that
it should indeed be treated in a case-insensitive manner... ?
[*] http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-family
EDIT - As a workaround, awaiting a proper fix, if it is only for a few fonts,
one could add a substitutions section to the config file as follows:
{code:language=xml}
{code}
see also: http://xmlgraphics.apache.org/fop/2.1/fonts.html#font_substitution
was (Author: adelmelle):
At first glance, this would indeed be a bug in 2.0. While I did not find it
explicitly mentioned that the "font-family" attribute should or should not be
case-sensitive, looking at an example in the CSS2 specification[*] referenced
by XSL-FO, a value "new century schoolbook" is used, which seems to hint that
it should indeed be treated in a case-insensitive manner... ?
[*] http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-family
> Font-Family attribute is case-sensitive
> ---
>
> Key: FOP-2573
> URL: https://issues.apache.org/jira/browse/FOP-2573
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Window 7 x64, Java build 1.8.0_72-b15
>Reporter: Đorđe Zeljić
>
> I have simple FO file that contains block with font-family attribute (It's
> very simple version of my huge FO file where I found the issue).
> The attribute contains font name (eg. consolas).
> When I try to render PDF I see the warn message:
> WARNING: Font "consolas,normal,400" not found. Substituting with
> "any,normal,400".
> The test FO file is rendered fine in FOP 1.1 version, but not in 2.0 and 2.1
> versions.
> I'm not sure if this is the bug, or it was in 1.1 version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136235#comment-15136235 ] Andreas L. Delmelle commented on FOP-2525: -- Interesting... So, we know that the leakage does not occur in case of standalone TTF files, but only in TTC. Since you have already done the VisualVM profiling, any chance you can tell us to which root class(es) those uncollected references are attached? That info would be of immense help in tracing and possibly resolving this. Thanks in advance! > Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2557) Adobe Reader report corrupt embedded font
[ https://issues.apache.org/jira/browse/FOP-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075156#comment-15075156 ] Andreas L. Delmelle commented on FOP-2557: -- Just a quick check - Before sending fop-devs on a "wild goose chase": Are you absolutely certain this is really a FOP issue, and not related to the issues reported with the font itself? (see github - "Issues" tab, which has one that mentions "Adobe Reader fails to extract Noto Sans CJK from a PDF") > Adobe Reader report corrupt embedded font > -- > > Key: FOP-2557 > URL: https://issues.apache.org/jira/browse/FOP-2557 > Project: FOP > Issue Type: Bug > Components: fo/block >Affects Versions: trunk > Environment: Mac OSX 10.10, JDK 1.8 >Reporter: chunlinyao > Attachments: fop.xconf, test_fail.xml, test_fail2.xml, test_good.xml > > > When use NotoSansCJKSc regular font, If I don't include any number the > embedded subset is corrupt. > How to repeat > 1. Get FOP from trunk@1720811 > 2. Get Font from > https://github.com/googlei18n/noto-cjk/blob/40d9f5b179a59a06b98373c76bdc3e2119e4e6b2/NotoSansCJKsc-Regular.otf > 3. Use my config file and transform my fo files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2551) CSS Box-sizing extension
[ https://issues.apache.org/jira/browse/FOP-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062861#comment-15062861 ] Andreas L. Delmelle commented on FOP-2551: -- Looks like a neat addition. Will look into the patch in more detail soon, but first minor remark: can you remove the tabs from the test cases, and replace with spaces? We are generally allergic to tabs, is all... Relics from a distant past, when printers were basically still but automated typewriters. :) > CSS Box-sizing extension > > > Key: FOP-2551 > URL: https://issues.apache.org/jira/browse/FOP-2551 > Project: FOP > Issue Type: New Feature > Components: fo/block >Affects Versions: trunk >Reporter: Seifeddine Dridi >Priority: Minor > Fix For: trunk > > Attachments: block-container_fox-box-sizing.patch > > > I implemented an extension (fox:box-sizing) which provides the same > functionality as the CSS attribute box-sizing. > Attribute box-sizing can take two values: > * content-box: paddings and borders will enlarge the initial box' width and > height (this is the default behavior). > * border-box: the box' size is maintained even in the presence of paddings > and borders. > Currently fox:box-sizing can only be used with block-containers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[ https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045377#comment-15045377 ] Andreas L. Delmelle commented on FOP-2549: -- I think so, especially in this case, given that it is the final stop _and_ has the exact same color. Reading the SVG spec on gradients, there is an example mentioned with two stops having the same offset, but it is not the last one and it has a different color, so in that case, the result would be wrong if we just skip it entirely. I have not yet tried how FOP currently processes that sample, though... > [PATCH] SVGs with radial gradiant causes PDF display error > -- > > Key: FOP-2549 > URL: https://issues.apache.org/jira/browse/FOP-2549 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Matthias Reischenbacher > Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, > fop-2549-test-case_wrong.pdf, fop-2549.patch > > > A radial gradiant isn't processed correctly by FOP. E.g. the following > gradiant: > cx="51159.898" >cy="57300" >r="5279.6602" >fx="51159.898" >fy="57300" >id="id0" >gradientUnits="userSpaceOnUse"> >id="stop28" >style="stop-color:#fefefe;stop-opacity:1" >offset="0" /> >id="stop30" >style="stop-color:#cdcece;stop-opacity:1" >offset="0.58823502" /> >id="stop32" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> >id="stop34" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> > > is only outputted with one "Bound" entry in the PDF color function (instead > of two). > When opening the PDF with Adobe Acrobat the SVG is only partially displayed > and an error message pops up after clicking on the image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[
https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043435#comment-15043435
]
Andreas L. Delmelle edited comment on FOP-2549 at 12/6/15 10:27 PM:
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
EDIT2 - To answer my own question: Yes, absolutely! :) Currently,
{{o.a.fop.pdf.PDFFunction}} somehow has to import functionality from the
{{o.a.fop.render.gradient}} classes, in order to construct a Type 3 Stitching
function, which seems wrong on so many levels... :( Seems like a perfect
opportunity to improve the code here.
EDIT3 - Oops! Overlooked that this is shared code between the PDF and
PostScript renderers... More thinking required.
was (Author: adelmelle):
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
EDIT2 - To answer my own question: Yes, absolutely! :) Currently,
{{o.a.fop.pdf.PDFFunction}} somehow has to import functionality from the
{{o.a.fop.render.gradient}} classes, in order to construct a Type 3 Stitching
function, which seems wrong on so many levels... :( Seems like a perfect
opportunity to improve the code here.
> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg,
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>
[jira] [Comment Edited] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[
https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043435#comment-15043435
]
Andreas L. Delmelle edited comment on FOP-2549 at 12/6/15 10:25 PM:
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
EDIT2 - To answer my own question: Yes, absolutely! :) Currently,
{{o.a.fop.pdf.PDFFunction}} somehow has to import functionality from the
{{o.a.fop.render.gradient}} classes, in order to construct a Type 3 Stitching
function, which seems wrong on so many levels... :( Seems like a perfect
opportunity to improve the code here.
was (Author: adelmelle):
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg,
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>
> is only outputted with one "Bound" entry in the PDF color function (instead
>
[jira] [Comment Edited] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[
https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043435#comment-15043435
]
Andreas L. Delmelle edited comment on FOP-2549 at 12/6/15 10:14 PM:
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
was (Author: adelmelle):
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
I may be the case that something is just going wrong with the processing of the
last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
> [PATCH] SVGs with radial gradiant causes PDF display error
> --
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg,
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following
> gradiant:
> cx="51159.898"
>cy="57300"
>r="5279.6602"
>fx="51159.898"
>fy="57300"
>id="id0"
>gradientUnits="userSpaceOnUse">
>id="stop28"
>style="stop-color:#fefefe;stop-opacity:1"
>offset="0" />
>id="stop30"
>style="stop-color:#cdcece;stop-opacity:1"
>offset="0.58823502" />
>id="stop32"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>id="stop34"
>style="stop-color:#9d9e9e;stop-opacity:1"
>offset="1" />
>
> is only outputted with one "Bound" entry in the PDF color function (instead
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed
> and an error message pops up after clicking on the image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[ https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044188#comment-15044188 ] Andreas L. Delmelle edited comment on FOP-2549 at 12/6/15 11:06 PM: Back on topic for this particular issue: the confusion stems -- I think -- from the fact that the gradient in the SVG has two stops with the same offset (= 1). Somehow -- vague as I am not quite there yet -- this triggers the generation of a stitching function with 3 functions where one would expect 2. Very likely, that is what throws off the eventual rendering of the PDF in Acrobat Reader. If you comment out or remove the unnecessary second stops in the SVG, the sample renders as intended. Now, I still think this is a bug, but solving it by just adding the extra value in the Bounds array would not be appropriate. We just need to fix the code so that this case of two stops with the same offset does not trigger the generation an extra subfunction (which then makes the Functions array one element too long). was (Author: adelmelle): Back on topic for this particular issue: the confusion stems -- I think -- from the fact that the gradient in the SVG has two stops with the same offset (= 1). Somehow -- vague as I am not quite there yet -- this triggers the generation of a stitching function where with 3 functions where one would expect 2. Very likely, that is what throws off the eventual rendering of the PDF in Acrobat Reader. If you comment out or remove the unnecessary second stops in the SVG, the sample renders as intended. Now, I still think this is a bug, but solving it by just adding the extra value in the Bounds array would not be appropriate. We just need to fix the code so that this case of two stops with the same offset does not trigger the generation an extra subfunction (which then makes the Functions array one element too long). > [PATCH] SVGs with radial gradiant causes PDF display error > -- > > Key: FOP-2549 > URL: https://issues.apache.org/jira/browse/FOP-2549 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Matthias Reischenbacher > Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, > fop-2549-test-case_wrong.pdf, fop-2549.patch > > > A radial gradiant isn't processed correctly by FOP. E.g. the following > gradiant: > cx="51159.898" >cy="57300" >r="5279.6602" >fx="51159.898" >fy="57300" >id="id0" >gradientUnits="userSpaceOnUse"> >id="stop28" >style="stop-color:#fefefe;stop-opacity:1" >offset="0" /> >id="stop30" >style="stop-color:#cdcece;stop-opacity:1" >offset="0.58823502" /> >id="stop32" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> >id="stop34" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> > > is only outputted with one "Bound" entry in the PDF color function (instead > of two). > When opening the PDF with Adobe Acrobat the SVG is only partially displayed > and an error message pops up after clicking on the image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2549) [PATCH] SVGs with radial gradiant causes PDF display error
[ https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043435#comment-15043435 ] Andreas L. Delmelle commented on FOP-2549: -- Also not an expert here, but at any rate, from what I can tell, the problem seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an extra interval, where there should not really be any. Additionally, whether that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the output resolution (I think) ? If the precision is increased, you may eventually end up with a percentage that is low enough so that it does not produce a noticeable difference on any currently available printer/output medium. So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3 Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5 and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds array of 1 element [0.5]. The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the second subdomain from 0.5 (inclusive) to 1 (*inclusive*). I may be the case that something is just going wrong with the processing of the last subdomain, for which the PDF spec clearly states that it is the only interval that is supposed to be fully closed, on both the left and the right. All other subdomains are half-open, closed on the left but open on the right. > [PATCH] SVGs with radial gradiant causes PDF display error > -- > > Key: FOP-2549 > URL: https://issues.apache.org/jira/browse/FOP-2549 > Project: FOP > Issue Type: Bug > Components: image/svg >Reporter: Matthias Reischenbacher > Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg, > fop-2549-test-case_wrong.pdf, fop-2549.patch > > > A radial gradiant isn't processed correctly by FOP. E.g. the following > gradiant: > cx="51159.898" >cy="57300" >r="5279.6602" >fx="51159.898" >fy="57300" >id="id0" >gradientUnits="userSpaceOnUse"> >id="stop28" >style="stop-color:#fefefe;stop-opacity:1" >offset="0" /> >id="stop30" >style="stop-color:#cdcece;stop-opacity:1" >offset="0.58823502" /> >id="stop32" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> >id="stop34" >style="stop-color:#9d9e9e;stop-opacity:1" >offset="1" /> > > is only outputted with one "Bound" entry in the PDF color function (instead > of two). > When opening the PDF with Adobe Acrobat the SVG is only partially displayed > and an error message pops up after clicking on the image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030873#comment-15030873 ] Andreas L. Delmelle commented on FOP-2540: -- EDIT - Note that the Macintosh/Roman cmap is currently processed as if it were a "symbol" cmap. This still needs to be revisited, I think. I have only done it that way now, since otherwise, the Macintosh/Roman cmap in the "Symbol" font would be processed before the Unicode/Unicode 2.0 cmap (i.e. the former appears before the latter in the font file), which would then leave the actual symbol codepoints unmapped... :( > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030875#comment-15030875 ] Andreas L. Delmelle commented on FOP-2540: -- Thinking some more about the current state of "codepoint-to-glyph" mappings, and IIUC, the 1-1 correspondence that is currently enforced by the code would be insufficient for a number of cases, i.e. not only the extra roman-to-symbol mappings that are supported by Windows and Mac Symbol fonts. I am thinking that, more generally, there may be cases where a font simply does not have a glyph for a certain codepoint, but wants to map that codepoint to another glyph. Example would be different types of dashes or spaces. A non-breaking space could theoretically be mapped to the very same 'glyph' (representing an empty space, obviously) as a regular space. An em-dash could be mapped to a regular minus sign. Things like that... This would not be supported by the current code, if I catch correctly, since as soon as an "eight-bit-glyph" is mapped once, it cannot be mapped again. In the other direction, it would likely be very rare situations. I cannot immediately think of use cases for mapping a single codepoint to more than one glyph...? > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: FOP-2540.patch Another update to the patch: added support for "Segmented Coverage" format subtables, as well as Macintosh/Roman cmaps with "Byte Encoding" format subtables > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: (was: FOP-2540.patch) > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: test_osx_fonts_after_1.log, test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle closed FOP-2539. Resolution: Cannot Reproduce See previous comment - no file attached ==> closing the issue > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: (was: FOP-2540.patch) > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: test_osx_fonts_after_1.log, test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: (was: FOP_2540.patch) > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: test_osx_fonts_after_1.log, test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: FOP-2540.patch Extended patch, containing the earlier mentioned potential improvement, i.e. basic refactoring to move logic related to the CMAP into a new class OFCMap. > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: FOP-2540.patch Updated patch. As I was browsing through the OpenFont class, started doing some more code cleanups, i.e. removal of unnecessary (un)boxing, simplification of if-statements, for-loops converted to foreach, etc. One particular absurdity worth mentioning is probably the private method unicodeToWinAnsi(). As far as I can tell, since that method gets passed a single int, and searches a char array for a matching value, it could never ever return an array with more than one element, so removed that overhead and made it return a single int instead... Not sure why it was equipped to build up a List of Integers, where a simple int would do. > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030292#comment-15030292 ] Andreas L. Delmelle edited comment on FOP-2540 at 11/27/15 11:01 PM: - Extended patch, containing the earlier mentioned potential improvement, i.e. basic refactoring to move logic related to the CMAP into a new class OFCMap. EDIT - Note that this is just a start. Currently, the whole fonts package seems to be designed as if a CMAP is always a collection of segments. Dead giveaway is the fact that the class CMapSegment is actually in the main package, and referenced in several other classes as well. This does not necessarily seem to be true, however, as far as I can see... For example, there is the simple "Byte Encoding" subtable format, where the concept of "segments" strictly speaking does not apply. It seems as if the only supported format (= "Segment to Delta" subtable) was taken to be "the" one and only CMAP format...? :/ At first glance, it would take quite some more refactoring to get that adjusted/corrected across the entire package. was (Author: adelmelle): Extended patch, containing the earlier mentioned potential improvement, i.e. basic refactoring to move logic related to the CMAP into a new class OFCMap. > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2455) [Patch] Duplicated AFP resource objects
[ https://issues.apache.org/jira/browse/FOP-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029103#comment-15029103 ] Andreas L. Delmelle edited comment on FOP-2455 at 11/26/15 9:28 PM: OK, done. Completely missed that the patch attached to the most recent mail was different... Sorry. So, to make sure I understand correctly, the additional identity check is just to cover the case where both operands are null, right? (Obviously, in case they are truly one and the same instance, this change will even perform slightly better...) EDIT - Note, just asking since, if this is not the reason, then maybe it is because one of the component fields does not have a proper implementation for equals, where it reverts to the default Object.equals() implementation, which produces unexpected results (?) was (Author: adelmelle): OK, done. Completely missed that the patch attached to the most recent mail was different... Sorry. So, to make sure I understand correctly, the additional identity check is just to cover the case where both operands are null, right? (Obviously, in case they are truly one and the same instance, this change will even perform slightly better...) > [Patch] Duplicated AFP resource objects > --- > > Key: FOP-2455 > URL: https://issues.apache.org/jira/browse/FOP-2455 > Project: FOP > Issue Type: Bug > Components: renderer/afp >Affects Versions: trunk >Reporter: Seifeddine Dridi > Labels: patch > Fix For: trunk > > Attachments: CZARN00, T1001252, fop.xconf, patch-updated.diff, > patch.diff, test-fixed.afp, test.afp, test.fo > > > When generating AFP documents, font resource objects are written as many > times as the number of formatting objects in which they were used. > This regression was introduced after a commit made Glenn Adams to fix > FindBugs warnings (revision 1616590). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2455) [Patch] Duplicated AFP resource objects
[ https://issues.apache.org/jira/browse/FOP-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle resolved FOP-2455. -- Resolution: Fixed Fixed in trunk - see http://svn.apache.org/viewvc?rev=1716732=rev Thanks for the patch, and apologies for the rather long delay... :( > [Patch] Duplicated AFP resource objects > --- > > Key: FOP-2455 > URL: https://issues.apache.org/jira/browse/FOP-2455 > Project: FOP > Issue Type: Bug > Components: renderer/afp >Affects Versions: trunk >Reporter: Seifeddine Dridi > Labels: patch > Fix For: trunk > > Attachments: CZARN00, T1001252, fop.xconf, patch.diff, > test-fixed.afp, test.afp, test.fo > > > When generating AFP documents, font resource objects are written as many > times as the number of formatting objects in which they were used. > This regression was introduced after a commit made Glenn Adams to fix > FindBugs warnings (revision 1616590). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2455) [Patch] Duplicated AFP resource objects
[ https://issues.apache.org/jira/browse/FOP-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029103#comment-15029103 ] Andreas L. Delmelle commented on FOP-2455: -- OK, done. Completely missed that the patch attached to the most recent mail was different... Sorry. So, to make sure I understand correctly, the additional identity check is just to cover the case where both operands are null, right? (Obviously, in case they are truly one and the same instance, this change will even perform slightly better...) > [Patch] Duplicated AFP resource objects > --- > > Key: FOP-2455 > URL: https://issues.apache.org/jira/browse/FOP-2455 > Project: FOP > Issue Type: Bug > Components: renderer/afp >Affects Versions: trunk >Reporter: Seifeddine Dridi > Labels: patch > Fix For: trunk > > Attachments: CZARN00, T1001252, fop.xconf, patch-updated.diff, > patch.diff, test-fixed.afp, test.afp, test.fo > > > When generating AFP documents, font resource objects are written as many > times as the number of formatting objects in which they were used. > This regression was introduced after a commit made Glenn Adams to fix > FindBugs warnings (revision 1616590). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2540: - Attachment: FOP_2540.patch test_osx_fonts_before.log test_osx_fonts_after_1.log Attached small patch + log outputs to demonstrate that number of 'unusable' font file warnings goes down from 111 to 64. Core of the change is really at line 37 in the patch. For the remainder: * replaced some 'magic numbers' with more descriptive symbolic literals, and already added a few more for as of yet unsupported formats (based on OTF documentation available at Microsoft) * added generics to OFMtxEntry.unicodeIndex and related getter * removed some unnecessary (un)boxing. > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP_2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15020999#comment-15020999 ] Andreas L. Delmelle edited comment on FOP-2540 at 11/22/15 1:41 PM: Attached small patch + log outputs to demonstrate that number of 'unusable' font file warnings goes down from 111 to 64. Core of the change is really at line 37 in the patch. For the remainder: * replaced some 'magic numbers' with more descriptive symbolic literals, and already added a few more for as of yet unsupported formats (based on OTF documentation available at Microsoft) * added generics to OFMtxEntry.unicodeIndex and related getter * removed some unnecessary (un)boxing. Potential improvement: perhaps we should add a class OFCmap, to extricate the logic from the main OpenFont class, which would likely make it easier/cleaner to extend the functionality in the future... was (Author: adelmelle): Attached small patch + log outputs to demonstrate that number of 'unusable' font file warnings goes down from 111 to 64. Core of the change is really at line 37 in the patch. For the remainder: * replaced some 'magic numbers' with more descriptive symbolic literals, and already added a few more for as of yet unsupported formats (based on OTF documentation available at Microsoft) * added generics to OFMtxEntry.unicodeIndex and related getter * removed some unnecessary (un)boxing. > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP_2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021005#comment-15021005 ] Andreas L. Delmelle commented on FOP-2539: -- FYI - Repeat of request to attach a minimal FO file demonstrating the issue. If no such attachment is added by next Friday, I will close this one, assuming that it was indeed an encoding issue. > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2540) Enhance TTF/OTF support beyond Windows
Andreas L. Delmelle created FOP-2540: Summary: Enhance TTF/OTF support beyond Windows Key: FOP-2540 URL: https://issues.apache.org/jira/browse/FOP-2540 Project: FOP Issue Type: Improvement Components: font/opentype Affects Versions: 2.0 Environment: OS X Reporter: Andreas L. Delmelle Assignee: Andreas L. Delmelle Priority: Minor Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, or 1, i.e. Macintosh. This makes quite some system fonts bundled with OS X supposedly unusable. The solution is fairly trivial (patch proposal will be attached shortly), provided the cmap table format in the font is already supported. FOP currently only has support for cmap format 4 (segment to delta mapping), but this seems to suffice for most of the Unicode cmaps as well. See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009211#comment-15009211 ] Andreas L. Delmelle commented on FOP-2539: -- Please attach a minimal FO file that reproduces the issue on your end for further analysis. The most usual suspect, based on the description, would be an encoding issue. That is: the actual encoding of the symbol characters in the XML FO file does not correspond to the one that is specified (= UTF-8, if not explicitly set). We cannot see whether that is the case here if you just copy-paste a fragment into the issue Description. > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009834#comment-15009834 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 11:41 PM: - Having a go at adding support for the Macintosh/Roman table -- which is fairly straightforward, since it is a simple 1-1 mapping -- I noticed that the situation there is very similar to the Windows/Symbol one, only there the codepoints for regular latin alphabet are _directly_ mapped to the symbol glyphs, i.e. without going via the 'private use area'. So, regular latin characters are also not supported in the Apple OTF implementation of the Symbol font. There are no glyphs "A", "b", etc. in that font. Since the code currently processes the Windows/Symbol mapping _only_ if there is no Windows/Unicode mapping available, that bit of code really does not do anything if the TTF contains both. Even if we were to process both mappings, then the one that happens to be processed first will take precedence, i.e. the code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 to glyph 'α', but not both, as is the case in both Windows and OS X when you type text in a text editor or word processor. To get back on topic for this particular issue: I still very much suspect this to be an encoding issue in the source file, maybe as the result of either copy-pasting text or reading from a stream with the default platform encoding. Notice that the user mentions both Windows and Unix as affected; if the default encoding on both platforms does not match, this is typically the result -- rule of thumb: *always* specify an explicit encoding when setting up Input/OutputStreamReaders/Writers. One could argue that Java makes it far too easy for novices to make mistakes here, leading to issues that can be a real pain to trace to their origin... ;) was (Author: adelmelle): Having a go at adding support for the Macintosh/Roman table -- which is fairly straightforward, since it is a simple 1-1 mapping -- I noticed that the situation there is very similar to the Windows/Symbol one, only there the codepoints for regular latin alphabet are _directly_ mapped to the symbol glyphs, i.e. without going via the 'private use area'. So, regular latin characters are also not supported in the Apple OTF implementation of the Symbol font. There are no glyphs "A", "b", etc. in that font. Since the code currently processes the Windows/Symbol mapping _only_ if there is no Windows/Unicode mapping available, that bit of code really does not do anything if the TTF contains both. Even if we were to process both mappings, then the one that happens to be processed first will take precedence, i.e. the code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 to glyph 'α', but not both, as is the case in both Windows and OS X when you type text in a text editor or word processor. To get back on topic for this particular issue: I still very much suspect this to be an encoding issue in the source file, maybe as the result of either copy-pasting text or reading from a stream with the default platform encoding. Notice that the user mentions both Windows and Unix as affected; if the default encoding on both platforms does not match, this is typically the result -- rule of thumb: *always* specify an explicit encoding when setting up Input/OutputStreamReaders. One could argue that Java makes it far too easy for novices to make mistakes here, leading to issues that can be a real pain to trace to their origin... ;) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009834#comment-15009834 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 11:33 PM: - Having a go at adding support for the Macintosh/Roman table -- which is fairly straightforward, since it is a simple 1-1 mapping -- I noticed that the situation there is very similar to the Windows/Symbol one, only there the codepoints for regular latin alphabet are _directly_ mapped to the symbol glyphs, i.e. without going via the 'private use area'. So, regular latin characters are also not supported in the Apple OTF implementation of the Symbol font. There are no glyphs "A", "b", etc. in that font. Since the code currently processes the Windows/Symbol mapping _only_ if there is no Windows/Unicode mapping available, that bit of code really does not do anything if the TTF contains both. Even if we were to process both mappings, then the one that happens to be processed first will take precedence, i.e. the code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 to glyph 'α', but not both, as is the case in both Windows and OS X when you type text in a text editor or word processor. To get back on topic for this particular issue: I still very much suspect this to be an encoding issue in the source file, maybe as the result of either copy-pasting text or reading from a stream with the default platform encoding. Notice that the user mentions both Windows and Unix as affected; if the default encoding on both platforms does not match, this is typically the result -- rule of thumb: *always* specify an explicit encoding when setting up Input/OutputStreamReaders. One could argue that Java makes it far too easy for novices to make mistakes here, leading to issues that can be a real pain to trace to their origin... ;) was (Author: adelmelle): Having a go at adding support for the Macintosh/Roman table --which is fairly straightforward, since it is a simple 1-1 mapping-- I noticed that the situation there is very similar to the Windows/Symbol one, only there the codepoints for regular latin alphabet are _directly_ mapped to the symbol glyphs, i.e. without going via the 'private use area'. So, regular latin characters are also not supported in the Apple OTF implementation of the Symbol font. There are no glyphs "A", "b", etc. in that font. Since the code currently processes the Windows/Symbol mapping _only_ if there is no Windows/Unicode mapping available, that bit of code really does not do anything if the TTF contains both. Even if we were to process both mappings, then the one that happens to be processed first will take precedence, i.e. the code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 to glyph 'α', but not both, as is the case in both Windows and OS X when you type text in a text editor or word processor. To get back on topic for this particular issue: I still very much suspect this to be an encoding issue in the source file, maybe as the result of either copy-pasting text or reading from a stream with the default platform encoding. Notice that the user mentions both Windows and Unix as affected; if the default encoding on both platforms does not match, this is typically the result -- rule of thumb: *always* specify an explicit encoding when setting up Input/OutputStreamReaders. One could argue that Java makes it far too easy for novices to make mistakes here, leading to issues that can be a real pain to trace to their origin... ;) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009834#comment-15009834 ] Andreas L. Delmelle commented on FOP-2539: -- Having a go at adding support for the Macintosh/Roman table --which is fairly straightforward, since it is a simple 1-1 mapping-- I noticed that the situation there is very similar to the Windows/Symbol one, only there the codepoints for regular latin alphabet are _directly_ mapped to the symbol glyphs, i.e. without going via the 'private use area'. So, regular latin characters are also not supported in the Apple OTF implementation of the Symbol font. There are no glyphs "A", "b", etc. in that font. Since the code currently processes the Windows/Symbol mapping _only_ if there is no Windows/Unicode mapping available, that bit of code really does not do anything if the TTF contains both. Even if we were to process both mappings, then the one that happens to be processed first will take precedence, i.e. the code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 to glyph 'α', but not both, as is the case in both Windows and OS X when you type text in a text editor or word processor. To get back on topic for this particular issue: I still very much suspect this to be an encoding issue in the source file, maybe as the result of either copy-pasting text or reading from a stream with the default platform encoding. Notice that the user mentions both Windows and Unix as affected; if the default encoding on both platforms does not match, this is typically the result -- rule of thumb: *always* specify an explicit encoding when setting up Input/OutputStreamReaders. One could argue that Java makes it far too easy for novices to make mistakes here, leading to issues that can be a real pain to trace to their origin... ;) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009459#comment-15009459 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 9:00 PM: Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? EDIT - The Arial.ttf that comes with OS X _does_ work apparently, and would render the first sample with proper baseline alignment between the regular latin characters and the greek symbols. was (Author: adelmelle): Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009397#comment-15009397 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 8:03 PM: See attached FO for an example that works without requiring any TTF embedding. I almost forgot that FOP does support font-selection... :) EDIT - Just noticed: Baseline alignment seems to be a bit off, though... :( Perhaps expected, not sure. I would have to dig deeper to say for sure. was (Author: adelmelle): See attached FO for an example that works without requiring any TTF embedding. I almost forgot that FOP does support font-selection... :) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2539: - Attachment: symbol_test.fo See attached FO for an example that works without requiring any TTF embedding. I almost forgot that FOP does support font-selection... :) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009437#comment-15009437 ] Andreas L. Delmelle commented on FOP-2539: -- BTW - Noticed the user specified FOP 1.0 as the version... Were the changes referred to in the earlier comment applied before or after that release? > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009347#comment-15009347 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 7:49 PM: Interesting... I was thinking along the lines that, provided the font supports it, there are 'standard' Unicode codepoints for the specific characters mentioned here, i.e. GREEK SMALL LETTER ALPHA - U+03B1 (α) GREEK SMALL LETTER BETA - U+03B2 (β) GREEK SMALL LETTER GAMMA - U+03B3 (γ) etc. Must admit that I have not verified if those codepoints are supported by the Base14 Symbol font, though. If so, no need for mapping to any 'private use area' codepoints. Just make sure those symbols are encoded properly...? EDIT - Just confirmed that those codepoints are properly supported by the Base14 Symbol font, i.e. no font embedding would be needed (?) That said, characters 'A', 'b' etc. are NOT supported by the Base14 Symbol font, so would need to be put in an fo:wrapper to set a different font. Maybe that would not be necessary with the TTF variant, not sure... What I think may be happening here, is that the characters are encoded not as UTF-8 and not referenced via entities, but the parser takes them to be such, if the user is either not specifying the encoding explicitly or is using a boiler plate '' That would lead to strange looking characters, since the bytes would be interpreted incorrectly. No way to tell without looking at the actual FO file in a hex editor... was (Author: adelmelle): Interesting... I was thinking along the lines that, provided the font supports it, there are 'standard' Unicode codepoints for the specific characters mentioned here, i.e. GREEK SMALL LETTER ALPHA - U+03B1 (α) GREEK SMALL LETTER BETA - U+03B2 (β) GREEK SMALL LETTER GAMMA - U+03B3 (γ) etc. Must admit that I have not verified if those codepoints are supported by the Base14 Symbol font, though. If so, no need for mapping to any 'private use area' codepoints. Just make sure those symbols are encoded properly...? > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009459#comment-15009459 ] Andreas L. Delmelle commented on FOP-2539: -- Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009347#comment-15009347 ] Andreas L. Delmelle commented on FOP-2539: -- Interesting... I was thinking along the lines that, provided the font supports it, there are 'standard' Unicode codepoints for the specific characters mentioned here, i.e. GREEK SMALL LETTER ALPHA - U+03B1 (α) GREEK SMALL LETTER BETA - U+03B2 (β) GREEK SMALL LETTER GAMMA - U+03B3 (γ) etc. Must admit that I have not verified if those codepoints are supported by the Base14 Symbol font, though. If so, no need for mapping to any 'private use area' codepoints. Just make sure those symbols are encoded properly...? > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2539: - Attachment: symbol_test_2.fo This sample file does render as intended, so baseline alignment seems to only work properly in case we don't rely on font-selection, i.e. by splitting into two fo:inlines, and specifying the font-family on each individually. Could be a genuine bug... > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009459#comment-15009459 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 9:43 PM: Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? EDIT - The Arial.ttf that comes with OS X _does_ work apparently, and would render the first sample with proper baseline alignment between the regular latin characters and the greek symbols. EDIT 2 - Was a bit in an adventurous mood, so decided to debug the code to try and find out why the Symbol.ttf throws that error. Apparently, it fails at OpenFont.readCMAP, lines 426 and following. There are two CMAP tables in the file, but one yields Platform ID = 0 and Encoding ID = 3, the other has Platform ID = 1 and Encoding ID = 0. Hence, neither cmapUniOffset nor symbolMapOffset is set on lines 419, resp. 422. This in turn causes FOP to assume there is no CMAP table available, which causes the error. Now, checking the OpenType documentation, it seems that our implementation would only process the Windows variants (Platform ID = 3), and not the Unicode (Platform ID = 0) nor the Macintosh (Platform ID = 1)... Shame that so many developers only know MS Windows and do not test their code on different platforms... :) was (Author: adelmelle): Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? EDIT - The Arial.ttf that comes with OS X _does_ work apparently, and would render the first sample with proper baseline alignment between the regular latin characters and the greek symbols. > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying properly and they are not human > readable format > fop.xconf:- > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2539) Apache PDF issue with Symbol.ttf
[ https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009459#comment-15009459 ] Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 10:05 PM: - Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? EDIT - The Arial.ttf that comes with OS X _does_ work apparently, and would render the first sample with proper baseline alignment between the regular latin characters and the greek symbols. EDIT 2 - Was a bit in an adventurous mood, so decided to debug the code to try and find out why the Symbol.ttf throws that error. Apparently, it fails at OpenFont.readCMAP, lines 426 and following. There are two CMAP tables in the file, but one yields Platform ID = 0 and Encoding ID = 3, the other has Platform ID = 1 and Encoding ID = 0. Hence, neither cmapUniOffset nor symbolMapOffset is set on lines 419, resp. 422. This in turn causes FOP to assume there is no CMAP table available, which causes the error. Now, checking the OpenType documentation, it seems that our implementation would only process the Windows variants (Platform ID = 3), and not the Unicode (Platform ID = 0) nor the Macintosh (Platform ID = 1)... Shame that so many developers only know MS Windows and do not test their code on different platforms... :) EDIT - Finally, just a heads up: the CMAP table with Platform ID = 0 and Encoding ID = 3 is properly processed if I alter the check on line 418. Result is then similar to using the Base14 font, i.e. no support for regular latin characters. The Macintosh/Roman table yields an error. Apparently, that table format is not yet supported by FOP's implementation. Very likely, if support for that is added, that would then also render the latin characters properly... was (Author: adelmelle): Was trying to check what the behavior was when the TTF was used, but unfortunately, the Symbol.ttf file that comes with OS X cannot be processed: WARNING: Unable to load font file: file:/System/Library/Fonts/Symbol.ttf. Reason: java.io.IOException: The font does not have a Unicode cmap table: file:/System/Library/Fonts/Symbol.ttf Happens with quite a lot of TTFs and TTCs on OS X. Not an expert, so not sure what is wrong about those files that makes FOP's font library not able to process it. I mean: I obviously get that it cannot find a Unicode cmap table, but would have to familiarize myself with the format to know whether that is really an issue with the file, or whether it just points to a deficiency in FOP's font lib... ? EDIT - The Arial.ttf that comes with OS X _does_ work apparently, and would render the first sample with proper baseline alignment between the regular latin characters and the greek symbols. EDIT 2 - Was a bit in an adventurous mood, so decided to debug the code to try and find out why the Symbol.ttf throws that error. Apparently, it fails at OpenFont.readCMAP, lines 426 and following. There are two CMAP tables in the file, but one yields Platform ID = 0 and Encoding ID = 3, the other has Platform ID = 1 and Encoding ID = 0. Hence, neither cmapUniOffset nor symbolMapOffset is set on lines 419, resp. 422. This in turn causes FOP to assume there is no CMAP table available, which causes the error. Now, checking the OpenType documentation, it seems that our implementation would only process the Windows variants (Platform ID = 3), and not the Unicode (Platform ID = 0) nor the Macintosh (Platform ID = 1)... Shame that so many developers only know MS Windows and do not test their code on different platforms... :) > Apache PDF issue with Symbol.ttf > > > Key: FOP-2539 > URL: https://issues.apache.org/jira/browse/FOP-2539 > Project: FOP > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windox, unix >Reporter: Sushmitha > Attachments: symbol_test.fo, symbol_test_2.fo > > > I have Symbol.ttf, configured the same in config file. Symbol font is not > applying properly. > Please find the below details > FOP version - 1.0 > OS - Unix, Windows > XSL-FO desc: > > Abcdefgh α β γ > > Result - the charcters are not displaying
[jira] [Updated] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-1444: - Attachment: FOP-1444-original.pdf FOP-1444-original_after.pdf * FOP-1444-original.pdf is the result of rendering the original FO attachment with current FOP trunk (basically 2.0), which already looks quite a lot better than the originally attached PDF. * FOP-1444-original_after.pdf is the result of rendering the same FO after a very minor update in TextLM, looking slightly better even, but still not entirely without issues. The lines with 'glitch' in them still appear a bit 'off' with respect to the others. Cause of that still remains to be determined PDF table of contents generated with incorrect page number alignments - Key: FOP-1444 URL: https://issues.apache.org/jira/browse/FOP-1444 Project: FOP Issue Type: Bug Components: renderer/pdf Affects Versions: 0.94, trunk Environment: Operating System: Windows XP Platform: PC Reporter: David H. Gutteridge Attachments: FOP-1444-original.pdf, FOP-1444-original_after.pdf, FOP_TOC_Bug_Test-dbk1.78-nospc.pdf, FOP_TOC_Bug_Test-dbk1.78.0-nospc.fo, FOP_TOC_Bug_Test-dbk1.78.0.fo, FOP_TOC_Bug_Test-dbk1.78.pdf, FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf, toc.fo, toc.pdf It seems there's a threshold where FOP does not align page number references correctly when generating tables of contents in PDF documents. I see that you have a reference to this in your FAQ (question 3.10), but it says The most recent FOP releases should have this problem fixed, I'm seeing this problem with 0.94. (I have a sample FO document I will attach, looks like the initial bug reporting interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2461) NullPointerException in ListItemLayoutManager since Temp_BasicSideFloat Merge
[ https://issues.apache.org/jira/browse/FOP-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14623505#comment-14623505 ] Andreas L. Delmelle commented on FOP-2461: -- Lazy workaround committed as a preliminary fix -- see http://svn.apache.org/r1690396 Keeping the issue open for now, as I still feel adding the extra not-null check is not robust enough... At least, if we were to do a point / fix release, this would no longer be a blocker for people to upgrade. NullPointerException in ListItemLayoutManager since Temp_BasicSideFloat Merge - Key: FOP-2461 URL: https://issues.apache.org/jira/browse/FOP-2461 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Reporter: Matthias Reischenbacher Attachments: fop-2461-test-case.xml The attached fo test cases causes a NullPointerException inside ListItemLayoutManager. This is the stack trace: java.lang.NullPointerException at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405) at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) at org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) at org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:191) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:120) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:63) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:270) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:212) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:273) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:148) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:135) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) 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
[jira] [Resolved] (FOP-2496) fop2.0 crashes if docbook note is last inside a listitem or a step. No bug in fop1.1
[ https://issues.apache.org/jira/browse/FOP-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle resolved FOP-2496. -- Resolution: Duplicate fop2.0 crashes if docbook note is last inside a listitem or a step. No bug in fop1.1 -- Key: FOP-2496 URL: https://issues.apache.org/jira/browse/FOP-2496 Project: FOP Issue Type: Bug Components: renderer/pdf Affects Versions: 2.0 Reporter: Lennart Johansson Attachments: note-problem-fop2.0-listitem-crash.fo, note-problem-fop2.0-listitem-workaround-patched.fo, note-problem-fop2.0-step-crash.fo, note-problem-fop2.0-step-workaround-patched.fo fop2.0 crashes if docbook note is last inside a listitem or a step. No bug in fop1.1 This works in fop1.1 and it is good docbook syntax and should not be a problem. A workaround, that also shows the problem, is to insert an empty para between /note and /listitem), or directly in the .fo file, insert an extra fo:block/fo.block. We are now forced to use this workaround in the building scripts - not nice! Appended: - note-problem-fop2.0-listitem-crash.fo = Small example .fo file with a note last in a listitem - note-problem-fop2.0-listitem-workaround-patched.fo = Workaround-patched .fo file (listitem) - note-problem-fop2.0-step-crash.fo = Small example .fo file with a note last in a step - note-problem-fop2.0-step-workaround-patched.fo = Workaround-patched .fo file (step) The fop CRASH log is below: INFO: Rendered page #1. INFO: Rendered page #2. Jul 8, 2015 8:18:06 PM org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:186) at org.apache.fop.cli.Main.main(Main.java:217) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405) at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289) at org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) 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
[jira] [Commented] (FOP-2495) Embedding: missing migration documentation from FOP 1.x
[ https://issues.apache.org/jira/browse/FOP-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620754#comment-14620754 ] Andreas L. Delmelle commented on FOP-2495: -- I definitely do not mean to be a pain here -- I fully understand the frustrations -- but can we please distinguish between: a) the core issue that was reported, which was related to missing migration documentation: comments related to that belong here b) other issues: comments should be deleted here, and moved to other, separate JIRA entries Right now, all the comments put together no longer form a coherent discussion about the core issue. This in turn does not really invite developers to even try to resolve it -- TLDR, stuff like that... That would be a shame, since I consider the point to be very valuable: significant API changes simply *MUST NOT* be released without proper documentation. Embedding: missing migration documentation from FOP 1.x --- Key: FOP-2495 URL: https://issues.apache.org/jira/browse/FOP-2495 Project: FOP Issue Type: Bug Components: documentation Affects Versions: 2.0 Environment: WIndows, Java 8, FOP 1.0 Reporter: MH Priority: Blocker Labels: documentation Because of bug FOP-2177 we couldn't upgrade form FOP 1.0 to FOP 1.1. FOP 2.0 has solved this bug (tested with standalone FOP scripts). Now we would like to upgrade our Java code from FOP 1.0 to FOP 2.0. The Upgrading page (https://xmlgraphics.apache.org/fop/2.0/upgrading.html) says You should encounter very few issues in upgrading from FOP 1.0, except as noted in the following: The truth is completely different: starting by replacing fop.jar, our code gets dozens of compiler errors! Many methods are simply gone: FopFactory.newInstance() FoUserAgent.setBaseURL(String); FopFactory.getFontManager().setFontBaseURL(String) FopFactory.setURIResolver(URIResolver); etc. The javadocs from 1.1 to 2.0 simple changed - no deprecated methods, no hints how to replace old methods. The FOP 2.0 embedding page (https://xmlgraphics.apache.org/fop/2.0/embedding.html) just shows simple examples to start from the ground. I can't find any migration help how to replace old code. E.g. how can I set the font base? FopFactory.getFontManager().setFontBaseURL(String) is gone and I can't find any equivalent code for FOP 2.0! This is a major bug in FOP 2.0 as API changes are not documented to upgrade from FOP 1.x Java API to FOP 2.0! Now I just can search and try and experiment if I get our old code somehow running with all those undocumented API changes. Can you please state a migration documentation for all methods (method signatures) that don't exist anymore? We can't start coding all over again from scratch. Thank you very much! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Attachment: (was: FOP-2469_20150618.patch) [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, 2015-06-09-LM-to-LC-refactoring-update.patch, FOP-2469_20150621.patch, FOP2469-auto-table-layout.xml, resize-all-but-static-spanned-columns.xml, resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Attachment: FOP-2469_20150621.patch New patch, with some further minor changes here and there, and the three additional test cases added to the layout engine test suite. Removed the isAutoLayout() method from AbstractBaseLM and LayoutManager, and made the implementations package private in TableLM and TableCellLM. I experimented with having the default implementation in AbstractBaseLM return false, which ultimately produces the exact same output, so I was left wondering what purpose the isAutoLayout() calls in BlockStackingLM and LineLM have other than avoiding some warning messages in the log, which seems to be the only difference ( ? ) That could also be avoided by passing the LayoutContext to the updateContentArea...() method, which is what I did instead. [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, 2015-06-09-LM-to-LC-refactoring-update.patch, FOP-2469_20150621.patch, FOP2469-auto-table-layout.xml, resize-all-but-static-spanned-columns.xml, resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Attachment: (was: LayoutContext_Tweak.diff) [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, 2015-06-09-LM-to-LC-refactoring-update.patch, FOP-2469_20150618.patch, FOP2469-auto-table-layout.xml, resize-all-but-static-spanned-columns.xml, resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Attachment: FOP-2469_20150618.patch Added new version of the patch. No real invasive changes, so far, just minor cleanups -- also some unrelated changes in the same classes, sorry ;) -- and integration of the LayoutContext tweak. Also added the initially added test case to the layout engine test suite. More detailed checks section still TBD, but currently, just adding the test already fails the build on the mentioned assertion error. [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, 2015-06-09-LM-to-LC-refactoring-update.patch, FOP-2469_20150618.patch, FOP2469-auto-table-layout.xml, LayoutContext_Tweak.diff, resize-all-but-static-spanned-columns.xml, resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14590434#comment-14590434
]
Andreas L. Delmelle commented on FOP-2469:
--
Nice read, thanks! :) Should be more than enough to be able to locate it.
In the meantime, interesting observation - Try running the first example
(FOP2469...xml) against a fresh trunk, with the latest patch applied, and
enable assertions.
On my end, this fails with:
{code}
Caused by: java.lang.AssertionError
at
org.apache.fop.layoutmgr.table.TableLayoutManager.setPossibleWidths(TableLayoutManager.java:647)
at
org.apache.fop.layoutmgr.table.ColumnSetup.redistribute(ColumnSetup.java:469)
...
{code}
Without assertions enabled, it comes through nicely, so no problem there. Just
seems like that method is called while it is -- or at least, it _was_ at some
point in your thought process ;) -- not expected ( ? )
Could be a consequence of the LM-to-LC refactoring.
[PATCH] auto table layout
-
Key: FOP-2469
URL: https://issues.apache.org/jira/browse/FOP-2469
Project: FOP
Issue Type: Bug
Components: layout/unqualified
Affects Versions: trunk
Environment: Windows 7, JDK 7
Reporter: Gregor Berg
Assignee: Andreas L. Delmelle
Fix For: trunk
Attachments: 2015-05-13-auto-table-layout.patch,
2015-05-27-LM-to-LC-refactoring.patch,
2015-06-09-LM-to-LC-refactoring-update.patch, FOP2469-auto-table-layout.xml,
LayoutContext_Tweak.diff, resize-all-but-static-spanned-columns.xml,
resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml
Hi,
this is a patch which enables table-layout=auto. It is quite robust, it can
not only handle linebreaks and pagebreaks, but it also copes with auto tables
in fixed tables in auto tables.
Essentially, it is the patch of issue FOP-2450 adapted to the trunk version
of FOP.
Best regards,
Gregor
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582223#comment-14582223
]
Andreas L. Delmelle commented on FOP-2469:
--
I finally had a much closer look at the patch yesterday and today, attempting
to merge it into my local branch -- so far, so good, although the test file did
throw an Exception at one point. This is likely related to changes I have on my
end, so no worries there, but...
Looking at the stack trace, I have run into another minor thing that bothered
me slightly, design-wise: more imports from the o.a.f.layoutmgr package in the
o.a.f.fo.flow package. That said, there were already some there... References
the other way around bother me less, somehow. Perhaps more a matter of personal
taste.
As a resolution (for me, at least), I have moved the body of that method
getNextKEFromPrimary() into the
TableContentLayoutManager.determineWidthOfPrimaryGridUnit(), since it is the
only place where it is called from, and I do not immediately see anything in
said method that cannot be handled within the context of the layoutmgr package
( ? )
Perhaps that whole PGU class should move to the LM side, but that is a
different story -- and a lot more work, so not right now... ;)
OK, at least that stack trace looks a bit -- prettier. All calls in
o.a.f.layoutmgr...
{code}
java.lang.IllegalArgumentException: min (27840) opt (27180)
at org.apache.fop.traits.MinOptMax.getInstance(MinOptMax.java:59)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.setBaseLength( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineWidthOfPrimary(
)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateOverTableRows( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineAutoLayoutWidths(
)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements( )
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
...
{code}
Now, on with the hunt for the cause of that Exception! :)
[PATCH] auto table layout
-
Key: FOP-2469
URL: https://issues.apache.org/jira/browse/FOP-2469
Project: FOP
Issue Type: Bug
Components: layout/unqualified
Affects Versions: trunk
Environment: Windows 7, JDK 7
Reporter: Gregor Berg
Assignee: Andreas L. Delmelle
Fix For: trunk
Attachments: 2015-05-13-auto-table-layout.patch,
2015-05-27-LM-to-LC-refactoring.patch,
2015-06-09-LM-to-LC-refactoring-update.patch, FOP2469-auto-table-layout.xml,
LayoutContext_Tweak.diff
Hi,
this is a patch which enables table-layout=auto. It is quite robust, it can
not only handle linebreaks and pagebreaks, but it also copes with auto tables
in fixed tables in auto tables.
Essentially, it is the patch of issue FOP-2450 adapted to the trunk version
of FOP.
Best regards,
Gregor
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FOP-2469) [PATCH] auto table layout
[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582223#comment-14582223
]
Andreas L. Delmelle edited comment on FOP-2469 at 6/11/15 6:52 PM:
---
I finally had a much closer look at the patch yesterday and today, attempting
to merge it into my local branch -- so far, so good, although the test file did
throw an Exception at one point. This is likely related to changes I have on my
end, so no worries there, but...
Looking at the stack trace, I have run into another minor thing that bothered
me slightly, design-wise: more imports from the o.a.f.layoutmgr package in the
o.a.f.fo.flow package. That said, there were already some there... References
the other way around bother me less, somehow. Perhaps more a matter of personal
taste.
As a resolution (for me, at least), I have moved the body of that method
getNextKEFromPrimary() into the
TableContentLayoutManager.determineWidthOfPrimaryGridUnit(), since it is the
only place where it is called from, and I do not immediately see anything in
said method that cannot be handled within the context of the layoutmgr package
( ? )
Perhaps that whole PGU class should move to the LM side, but that is a
different story -- and a lot more work, so not right now... ;)
OK, at least that stack trace looks a bit -- prettier. All calls in
o.a.f.layoutmgr...
{code}
java.lang.IllegalArgumentException: min (27840) opt (27180)
at org.apache.fop.traits.MinOptMax.getInstance(MinOptMax.java:59)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.setBaseLength( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineWidthOfPrimary(
)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateOverTableRows( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineAutoLayoutWidths(
)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements( )
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
...
{code}
Now, on with the hunt for the cause of that Exception! :)
EDIT - Actually, it may be something worth looking into on your end as well.
The block of code where the Exception is thrown seems to assert that ipd will
always be larger than minIPD ( ? )
See below, line 3.
{code:language=java|title=TableContentLayoutManager.getBaseLength()}
if (index == n - 1) {// a primary without col-span 1
if ((availableSpanWidth ipd) || (length.getMin() minIPD)) { // cell
needs more space
assert (ipd minIPD);
MinOptMax possibleWidths =
MinOptMax.getInstance(
Math.max(length.getMin(), minIPD),
Math.max(length.getOpt(), ipd),
Math.max(length.getMax(), ipd)
);
return length == this.baseLength.put(key, possibleWidths);
{code}
was (Author: adelmelle):
I finally had a much closer look at the patch yesterday and today, attempting
to merge it into my local branch -- so far, so good, although the test file did
throw an Exception at one point. This is likely related to changes I have on my
end, so no worries there, but...
Looking at the stack trace, I have run into another minor thing that bothered
me slightly, design-wise: more imports from the o.a.f.layoutmgr package in the
o.a.f.fo.flow package. That said, there were already some there... References
the other way around bother me less, somehow. Perhaps more a matter of personal
taste.
As a resolution (for me, at least), I have moved the body of that method
getNextKEFromPrimary() into the
TableContentLayoutManager.determineWidthOfPrimaryGridUnit(), since it is the
only place where it is called from, and I do not immediately see anything in
said method that cannot be handled within the context of the layoutmgr package
( ? )
Perhaps that whole PGU class should move to the LM side, but that is a
different story -- and a lot more work, so not right now... ;)
OK, at least that stack trace looks a bit -- prettier. All calls in
o.a.f.layoutmgr...
{code}
java.lang.IllegalArgumentException: min (27840) opt (27180)
at org.apache.fop.traits.MinOptMax.getInstance(MinOptMax.java:59)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.setBaseLength( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineWidthOfPrimary(
)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateOverTableRows( )
at
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Attachment: LayoutContext_Tweak.diff Good stuff, so far... Added a small patch for you to play with as well. Had an idea for improvement of handling the propagation of the related flags to child contexts. It should normally work on your end as is, too, since I kept the same method names. Only changes are that: a) the flags have now been aligned with the flag mechanism already present b) the offspringOf() method uses a more generic propagateFlagsFrom() to extend on the already propagated treatAsArtifact() Not included yet: The latter would allow replacing the newInstance() calls that are followed by setting both flags with offspringOff() calls. The cases where we do still need the explicit setter are those where we *don't* want the flag value propagated to the child context. [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, 2015-06-09-LM-to-LC-refactoring-update.patch, FOP2469-auto-table-layout.xml, LayoutContext_Tweak.diff Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575949#comment-14575949 ] Andreas L. Delmelle commented on FOP-2469: -- Investigating a bit further the creation and usage of the LayoutContext, I am beginning to think that all usages of LC.newInstance() are actually candidates for a switch to copyOf() or offspringOf(). The former would copy the whole parent context, all flags and settings included, which may be undesirable in some cases, but is likely to be what one would expect from a child context anyway. The latter currently copies only one single flag, but could easily be extended to serve other purposes as well. At least, it seems it was intended to be an in-between of newInstance() and copyOf(). The explicit LC init calls (copyPendingMarks(), setRefIPD()...) in the various LMs still remain, but would then override the inherited settings. The settings that are not explicitly set or unset by the LM can then be assumed to be propagated, which is exactly the behaviour we are looking for. [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2478) Incorrect position of block-container with fixed absolute-position
[ https://issues.apache.org/jira/browse/FOP-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575859#comment-14575859 ] Andreas L. Delmelle commented on FOP-2478: -- I am inclined to accept this as a bug. Reading the XSL 1.1 Rec - 7.6.1, absolute positioning is handled via top/bottom/left/right properties, specifying offsets with respect to the nearest ancestor reference area. A bit further down, in the restrictions for paged media, it is stated that the areas generated by absolute-positioned objects become descendants of the page, etc. I would take that to mean that the offsets are with respect to the page-reference-area, not the region-reference-area, which seems to be what FOP is doing. Incorrect position of block-container with fixed absolute-position -- Key: FOP-2478 URL: https://issues.apache.org/jira/browse/FOP-2478 Project: FOP Issue Type: Bug Affects Versions: 1.1, trunk, 2.0 Reporter: Jan Tošovský Attachments: block-container-fop.pdf, block-container-xep.pdf, block-container.fo In the attached example there is specified a distance of 180 mm between the bottom edge of block-container and bottom edge of the page. However, in FOP output this distance is different, bigger. Like both top and bottom margins (2x15 mm) would be added to this dimension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2478) Incorrect position of block-container with fixed absolute-position
[ https://issues.apache.org/jira/browse/FOP-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2478: - Affects Version/s: 2.0 Incorrect position of block-container with fixed absolute-position -- Key: FOP-2478 URL: https://issues.apache.org/jira/browse/FOP-2478 Project: FOP Issue Type: Bug Affects Versions: 1.1, trunk, 2.0 Reporter: Jan Tošovský Attachments: block-container-fop.pdf, block-container-xep.pdf, block-container.fo In the attached example there is specified a distance of 180 mm between the bottom edge of block-container and bottom edge of the page. However, in FOP output this distance is different, bigger. Like both top and bottom margins (2x15 mm) would be added to this dimension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574810#comment-14574810
]
Andreas L. Delmelle commented on FOP-2060:
--
FWIW -- I agree with that line of thinking.
The original issue, as reported, concerns a successive break-after and
break-before. The diagnosis at that time was: there is an extra sequence of one
empty box that serves no purpose or should not be there. Correct, but instead
of removing it, the better solution would probably have been to prevent it from
getting added to begin with.
Investigate BlockLM.getNextKE(), which for the outer block in the initial
example in the description is called 5 times. Each time means it is called by
FlowLM, so implies a return to the PageBreaker... The layout engine processes
all bits in between two forced breaks, if you will, so the solution is to avoid
that empty bit, erroneously assumed to be 'in between' the break-after of the
second and break-before of the third block, from being processed and triggering
a return to the PageBreaker.
Given the following sample (= the initial example, but with ids):
{code:language=xml}
fo:block id=outer
fo:block id=inner-onepage 1/fo:block
fo:block id=inner-two break-before=page break-after=pagepage
2/fo:block
fo:block id=inner-three break-before=page break-after=pagepage
3/fo:block
fo:block id=inner-fourpage 4/fo:block
/fo:block
{code}
The following sequence of BlockLM.getNextKE() calls is the result:
{code}
1. id=outer
2. id=inner-one
3. id=inner-two
4. id=outer (re-entry after break-before)
5. id=inner-two
6. id=outer (re-entry after break-after)
7. id=inner-three
8. id=outer (re-entry after break-before)
9. id=inner-three
10. id=inner-four
{code}
The appropriate solution would be to avoid at least call 8. from ever occurring.
adjoining blocks with break-before=page break-after=page cause extra
empty page
---
Key: FOP-2060
URL: https://issues.apache.org/jira/browse/FOP-2060
Project: FOP
Issue Type: Bug
Components: layout/unqualified
Affects Versions: trunk
Environment: Operating System: All
Platform: All
Reporter: Luis Bernardo
Fix For: trunk
Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf
This causes five pages instead of four:
fo:block
fo:blockpage 1/fo:block
fo:block break-before=page break-after=pagepage 2/fo:block
fo:block break-before=page break-after=pagepage 3/fo:block
fo:blockpage 4/fo:block
/fo:block
The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574810#comment-14574810
]
Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 4:54 PM:
--
FWIW -- I agree with that line of thinking.
The original issue, as reported, concerns a successive break-after and
break-before. The diagnosis at that time was: there is an extra sequence of one
empty box that serves no purpose or should not be there. Correct, but instead
of removing it, the better solution would probably have been to prevent it from
getting added to begin with.
Investigate BlockLM.getNextKE(), which for the outer block in the initial
example in the description is called 5 times. Each time means it is called by
FlowLM, so implies a return to the PageBreaker... The layout engine processes
all bits in between two forced breaks, if you will, so the solution is to avoid
that empty bit, erroneously assumed to be 'in between' the break-after of the
second and break-before of the third block, from being processed and triggering
a return to the PageBreaker.
Given the following sample (= the initial example, but with ids):
{code:language=xml}
fo:block id=outer
fo:block id=inner-onepage 1/fo:block
fo:block id=inner-two break-before=page break-after=pagepage
2/fo:block
fo:block id=inner-three break-before=page break-after=pagepage
3/fo:block
fo:block id=inner-fourpage 4/fo:block
/fo:block
{code}
The following sequence of BlockLM.getNextKE() calls is the result:
{code}
1. id=outer
2. id=inner-one
3. id=inner-two
4. id=outer (re-entry after break-before)
5. id=inner-two
6. id=outer (re-entry after break-after)
7. id=inner-three
8. id=outer (re-entry after break-before)
9. id=inner-three
10. id=outer (re-entry after break-after)
11. id=inner-four
{code}
The appropriate solution would be to avoid at least call 8. from ever occurring.
was (Author: adelmelle):
FWIW -- I agree with that line of thinking.
The original issue, as reported, concerns a successive break-after and
break-before. The diagnosis at that time was: there is an extra sequence of one
empty box that serves no purpose or should not be there. Correct, but instead
of removing it, the better solution would probably have been to prevent it from
getting added to begin with.
Investigate BlockLM.getNextKE(), which for the outer block in the initial
example in the description is called 5 times. Each time means it is called by
FlowLM, so implies a return to the PageBreaker... The layout engine processes
all bits in between two forced breaks, if you will, so the solution is to avoid
that empty bit, erroneously assumed to be 'in between' the break-after of the
second and break-before of the third block, from being processed and triggering
a return to the PageBreaker.
Given the following sample (= the initial example, but with ids):
{code:language=xml}
fo:block id=outer
fo:block id=inner-onepage 1/fo:block
fo:block id=inner-two break-before=page break-after=pagepage
2/fo:block
fo:block id=inner-three break-before=page break-after=pagepage
3/fo:block
fo:block id=inner-fourpage 4/fo:block
/fo:block
{code}
The following sequence of BlockLM.getNextKE() calls is the result:
{code}
1. id=outer
2. id=inner-one
3. id=inner-two
4. id=outer (re-entry after break-before)
5. id=inner-two
6. id=outer (re-entry after break-after)
7. id=inner-three
8. id=outer (re-entry after break-before)
9. id=inner-three
10. id=inner-four
{code}
The appropriate solution would be to avoid at least call 8. from ever occurring.
adjoining blocks with break-before=page break-after=page cause extra
empty page
---
Key: FOP-2060
URL: https://issues.apache.org/jira/browse/FOP-2060
Project: FOP
Issue Type: Bug
Components: layout/unqualified
Affects Versions: trunk
Environment: Operating System: All
Platform: All
Reporter: Luis Bernardo
Fix For: trunk
Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf
This causes five pages instead of four:
fo:block
fo:blockpage 1/fo:block
fo:block break-before=page break-after=pagepage 2/fo:block
fo:block break-before=page break-after=pagepage 3/fo:block
fo:blockpage 4/fo:block
/fo:block
The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574810#comment-14574810
]
Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 4:54 PM:
--
FWIW -- I agree with that line of thinking.
The original issue, as reported, concerns a successive break-after and
break-before. The diagnosis at that time was: there is an extra sequence of one
empty box that serves no purpose or should not be there. Correct, but instead
of removing it, the better solution would probably have been to prevent it from
getting added to begin with.
Investigate BlockLM.getNextKE(), which for the outer block in the initial
example in the description is called 5 times. Each time means it is called by
FlowLM, so implies a return to the PageBreaker... The layout engine processes
all bits in between two forced breaks, if you will, so the solution is to avoid
that empty bit, erroneously assumed to be 'in between' the break-after of the
second and break-before of the third block, from being processed and triggering
a return to the PageBreaker.
Given the following sample (= the initial example, but with ids):
{code:language=xml}
fo:block id=outer
fo:block id=inner-onepage 1/fo:block
fo:block id=inner-two break-before=page break-after=pagepage
2/fo:block
fo:block id=inner-three break-before=page break-after=pagepage
3/fo:block
fo:block id=inner-fourpage 4/fo:block
/fo:block
{code}
The following sequence of BlockLM.getNextKE() calls is the result:
{code}
1. id=outer
2. id=inner-one
3. id=inner-two
4. id=outer (re-entry after break-before)
5. id=inner-two
6. id=outer (re-entry after break-after)
7. id=inner-three
8. id=outer (re-entry after break-before)
9. id=inner-three
10. id=outer (re-entry after break-after)
11. id=inner-four
{code}
The appropriate solution would be to avoid at least call 8. from ever occurring.
was (Author: adelmelle):
FWIW -- I agree with that line of thinking.
The original issue, as reported, concerns a successive break-after and
break-before. The diagnosis at that time was: there is an extra sequence of one
empty box that serves no purpose or should not be there. Correct, but instead
of removing it, the better solution would probably have been to prevent it from
getting added to begin with.
Investigate BlockLM.getNextKE(), which for the outer block in the initial
example in the description is called 5 times. Each time means it is called by
FlowLM, so implies a return to the PageBreaker... The layout engine processes
all bits in between two forced breaks, if you will, so the solution is to avoid
that empty bit, erroneously assumed to be 'in between' the break-after of the
second and break-before of the third block, from being processed and triggering
a return to the PageBreaker.
Given the following sample (= the initial example, but with ids):
{code:language=xml}
fo:block id=outer
fo:block id=inner-onepage 1/fo:block
fo:block id=inner-two break-before=page break-after=pagepage
2/fo:block
fo:block id=inner-three break-before=page break-after=pagepage
3/fo:block
fo:block id=inner-fourpage 4/fo:block
/fo:block
{code}
The following sequence of BlockLM.getNextKE() calls is the result:
{code}
1. id=outer
2. id=inner-one
3. id=inner-two
4. id=outer (re-entry after break-before)
5. id=inner-two
6. id=outer (re-entry after break-after)
7. id=inner-three
8. id=outer (re-entry after break-before)
9. id=inner-three
10. id=outer (re-entry after break-after)
11. id=inner-four
{code}
The appropriate solution would be to avoid at least call 8. from ever occurring.
adjoining blocks with break-before=page break-after=page cause extra
empty page
---
Key: FOP-2060
URL: https://issues.apache.org/jira/browse/FOP-2060
Project: FOP
Issue Type: Bug
Components: layout/unqualified
Affects Versions: trunk
Environment: Operating System: All
Platform: All
Reporter: Luis Bernardo
Fix For: trunk
Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf
This causes five pages instead of four:
fo:block
fo:blockpage 1/fo:block
fo:block break-before=page break-after=pagepage 2/fo:block
fo:block break-before=page break-after=pagepage 3/fo:block
fo:blockpage 4/fo:block
/fo:block
The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575267#comment-14575267 ] Andreas L. Delmelle commented on FOP-2060: -- Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575267#comment-14575267 ] Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 9:53 PM: -- Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? EDIT - Looking a bit closer at the usage of newInstance() vs. copyOf() shows 19 vs. 6... Makes one wonder whether it is really required and such a good idea to disperse all that LC init logic across the different LMs. Definitely needs a closer look. was (Author: adelmelle): Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575394#comment-14575394 ] Andreas L. Delmelle commented on FOP-2060: -- There is indeed nothing about generating an empty area before jumping to the next page in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really empty. It does have content, namely one empty normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single empty normal block area would always end up on its own page, and that page would not be empty. Perhaps _that_ was a bit unclear before. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575346#comment-14575346 ] Andreas L. Delmelle commented on FOP-2060: -- Hmm, I think the expectation of 3 is correct. The empty middle block still generates one normal block area, which happens to have no descendant line areas. That block area shifts to the next page due to the specified break-before. The next block's first area then, cannot be the first area on that same page. So, in order to satisfy that second break-before, there *has* to be an empty second page. It is definitely not the same situation that is mentioned in the bug at w3.org, since that seems to concern cases of nesting. Now, if the empty block had both break-before and break-after specified, then the next block's break-before would be suppressed. In that case, there should not be 2 empty pages. I would say that, yes, the fix stands as in 'fixes the original issue'. It just had an unintended side effect that was not covered by the layout engine tests, so nothing that could have alerted anyone. No harm done. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before=page break-after=page cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575394#comment-14575394 ] Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 11:53 PM: --- There is indeed nothing about generating an empty area before jumping to the next page in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really empty. It does have content, namely one empty normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single empty normal block area would always end up on its own page, and that page would not be empty. Perhaps _that_ was a bit unclear before. EDIT - It all makes perfect sense once you factor in borders and/or padding. It's not because they are zero that the holder, the area is not there... If they are non-zero, the fact that the page is not really empty just becomes more visible. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. was (Author: adelmelle): There is indeed nothing about generating an empty area before jumping to the next page in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really empty. It does have content, namely one empty normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single empty normal block area would always end up on its own page, and that page would not be empty. Perhaps _that_ was a bit unclear before. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. adjoining blocks with break-before=page break-after=page cause extra empty page --- Key: FOP-2060 URL: https://issues.apache.org/jira/browse/FOP-2060 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Luis Bernardo Fix For: trunk Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf This causes five pages instead of four: fo:block fo:blockpage 1/fo:block fo:block break-before=page break-after=pagepage 2/fo:block fo:block break-before=page break-after=pagepage 3/fo:block fo:blockpage 4/fo:block /fo:block The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571715#comment-14571715 ] Andreas L. Delmelle commented on FOP-2469: -- Started looking into both patches, and I must say that at first glance, I do like the LC approach more, in spite of the increased effort... I am definitely going to have a closer look into how that LC initialization can be streamlined. If that triggers even more invasive refactoring somewhere else, _so mote it be_. ;) I also have a few ideas on the TODOs you have, concerning folding the getMinIPD() into the element collection loop. Since I am working in a local sandbox on refactoring KnuthSequence, I wonder whether that folding could go even deeper...? getMinIPD() could be considered a function of the element list (sequence) returned by each childLM. If the minimum width required for the largest ListElement in the sequence is updated automatically with each added (relevant) element, regardless of which LM is building it, then calling said function on a completed sequence would again become a constant time operation. That is, instead of requiring an additional iteration over the sequence, or maybe a painful integration of this logic into the various getNextKE() implementations. More to follow, probably in the weekend. Stay tuned... [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2479) java.lang.NullPointerException in ListItemLayoutManager
[
https://issues.apache.org/jira/browse/FOP-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas L. Delmelle resolved FOP-2479.
--
Resolution: Duplicate
java.lang.NullPointerException in ListItemLayoutManager
---
Key: FOP-2479
URL: https://issues.apache.org/jira/browse/FOP-2479
Project: FOP
Issue Type: Bug
Components: fo/block
Affects Versions: 2.0
Reporter: Radu Coravu
Fix For: 2.0
Original Estimate: 3h
Remaining Estimate: 3h
My XSL-FO file is very large and complex, but I can attach it if you want to
reproduce the issue:
{code}
[fop] [ERROR] Anttask - Error rendering fo file:
C:\Users\radu_coravu\Documents\userguide-private\DITA\temp\pdf\oxygen_dita_temp\topic.fo
org.apache.fop.apps.FOPException
[fop] java.lang.NullPointerExceptionorg.apache.fop.apps.FOPException
[fop] java.lang.NullPointerException
[fop] at
org.apache.fop.tools.anttasks.FOPTaskStarter.renderInputHandler(Fop.java:653)
[fop] at
org.apache.fop.tools.anttasks.FOPTaskStarter.render(Fop.java:672)
[fop] at
org.apache.fop.tools.anttasks.FOPTaskStarter.run(Fop.java:533)
[fop] at org.apache.fop.tools.anttasks.Fop.execute(Fop.java:367)
[fop] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[fop] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[fop] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
[fop] at java.lang.reflect.Method.invoke(Unknown Source)
[fop] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[fop] at org.apache.tools.ant.Task.perform(Task.java:348)
[fop] at org.apache.tools.ant.Target.execute(Target.java:435)
[fop] at org.apache.tools.ant.Target.performTasks(Target.java:456)
[fop] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
[fop] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[fop] at
org.apache.tools.ant.Project.executeTargets(Project.java:1248)
[fop] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:440)
[fop] at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
[fop] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[fop] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[fop] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
[fop] at java.lang.reflect.Method.invoke(Unknown Source)
[fop] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[fop] at org.apache.tools.ant.Task.perform(Task.java:348)
[fop] at org.apache.tools.ant.Target.execute(Target.java:435)
[fop] at org.apache.tools.ant.Target.performTasks(Target.java:456)
[fop] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
[fop] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[fop] at
org.apache.tools.ant.Project.executeTargets(Project.java:1248)
[fop] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:440)
[fop] at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
[fop] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[fop] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[fop] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
[fop] at java.lang.reflect.Method.invoke(Unknown Source)
[fop] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[fop] at org.apache.tools.ant.Task.perform(Task.java:348)
[fop] at org.apache.tools.ant.Target.execute(Target.java:435)
[fop] at org.apache.tools.ant.Target.performTasks(Target.java:456)
[fop] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
[fop] at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
[fop] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[fop] at
org.apache.tools.ant.Project.executeTargets(Project.java:1248)
[fop] at org.apache.tools.ant.Main.runBuild(Main.java:851)
[fop] at org.apache.tools.ant.Main.startAnt(Main.java:235)
[fop] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
[fop] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
[fop] Caused by: org.apache.fop.apps.FOPException
[fop] java.lang.NullPointerException
[fop] at
[jira] [Assigned] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle reassigned FOP-2469: Assignee: Andreas L. Delmelle [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Comment: was deleted (was: Side-note - Reading that (rather old) Wiki page again, with Jeremias' brain-dump (his words, not mine ;)), it just so happens that in my local sandbox, I am currently toying with that split in line-layout he is referring to. The problem Jeremias mentions has led to an implementation for changing page IPD that is actually suboptimal. No complaints on those who did the implementation, mind you. It is actually quite a feat that that someone managed to implement it in the first place. R-E-S-P-E-C-T! :) However, as a result, if you have a page-sequence with alternating page-masters with different margins, then (assuming no forced breaks) due to the fact that line-breaking is not really interrupted, the process will go roughly as: - perform line-breaking for all 40 pages - start page-breaking, and notice that available IPD changes after the first page - throw away every computed break after that first page, and restart from the second - perform line-breaking for 39 pages - start page-breaking, and notice that available IPD changes after the second page - throw away ... and restart from the third page - perform line-breaking for 38 pages etc. Now, the LayoutContext _does_ have the stack limit in BP direction available, so at least, it _should_ be possible for the LineLM to determine that after a certain number of line-breaks, there will inevitably be a page-break... If at that point, we could make the engine behave as if there was a forced break or something like that, then it could suspend, switch to page-breaking context, compute that one page-break, obtain the dimensions for the next page, and resume. I have always found it peculiar that the stackLimitBP is available, but is never really taken advantage of.) [PATCH] auto table layout - Key: FOP-2469 URL: https://issues.apache.org/jira/browse/FOP-2469 Project: FOP Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Windows 7, JDK 7 Reporter: Gregor Berg Assignee: Andreas L. Delmelle Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml Hi, this is a patch which enables table-layout=auto. It is quite robust, it can not only handle linebreaks and pagebreaks, but it also copes with auto tables in fixed tables in auto tables. Essentially, it is the patch of issue FOP-2450 adapted to the trunk version of FOP. Best regards, Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FOP-1488) [PATCH] orphans/widows not respected in some cases
[ https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle reassigned FOP-1488: Assignee: Andreas L. Delmelle [PATCH] orphans/widows not respected in some cases -- Key: FOP-1488 URL: https://issues.apache.org/jira/browse/FOP-1488 Project: FOP Issue Type: Bug Components: unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Andrew McFarland Assignee: Andreas L. Delmelle Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328_test.patch, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, widow.fo When I process the following fo, I get a PDF with a one-line widow at the start of the second page, even though widows for that fo:block is set to 4. ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:block widows=4 linefeed-treatment=preserve line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line /fo:block /fo:flow /fo:page-sequence /fo:root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2276) currentFObj is not updated if Throwable is thrown
[ https://issues.apache.org/jira/browse/FOP-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2276: - Attachment: FOP-2276.patch Attached a small patch proposal. Problem is, I currently do not immediately have an idea how to test whether this would really solve the issue... I would have to create a test case that somehow simulates this behaviour, i.e. forced throwing of a SAXException and attempt to continue processing. If anyone has ideas, even if very vague, feel free to speak up. currentFObj is not updated if Throwable is thrown - Key: FOP-2276 URL: https://issues.apache.org/jira/browse/FOP-2276 Project: FOP Issue Type: Bug Components: fo/unqualified Affects Versions: 1.1 Reporter: Daniel Dracott Assignee: Andreas L. Delmelle Attachments: FOP-2276.patch If an exception is thrown during org.apache.fop.fo.FOTreeBuilder.MainFOHandler.endElement(String, String, String), then the line currentFObj = currentFObj.getParent(); does not get executed. If the SAX event source decides to store the exception and continue, then subsequent endElement calls can generate SAXExceptions of the form: Caused by: org.xml.sax.SAXException: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. root (http://www.w3.org/1999/XSL/Format) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:338) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:181) ... Some implementations of javax.xml.transform.Transformer that we have used will attempt to perform further endElement calls in this way and the SAXException can hide the original Throwable, making diagnosis of problems difficult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
