[jira] [Comment Edited] (FOP-2364) Keep-with-next integer value: Illegal value for breakClass: 75

2016-05-21 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-05-21 Thread Andreas L. Delmelle (JIRA)

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

2016-03-11 Thread Andreas L. Delmelle (JIRA)

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

2016-03-11 Thread Andreas L. Delmelle (JIRA)

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

2016-03-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-03-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-03-10 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-18 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-18 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-15 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-15 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-15 Thread Andreas L. Delmelle (JIRA)
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

2016-02-13 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-13 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-12 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-12 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-12 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-09 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-09 Thread Andreas L. Delmelle (JIRA)

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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-08 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-07 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2016-02-07 Thread Andreas L. Delmelle (JIRA)

[ 
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

2016-02-07 Thread Andreas L. Delmelle (JIRA)

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

2016-02-07 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-30 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-07 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-12-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-29 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-29 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-28 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-28 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-27 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-26 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-26 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-26 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-22 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-22 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-22 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-18 Thread Andreas L. Delmelle (JIRA)
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-11-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-07-24 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-07-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-07-09 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-07-09 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-21 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-21 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-19 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-18 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-17 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-11 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-10 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-06 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-06 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-05 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-03 Thread Andreas L. Delmelle (JIRA)

[ 
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

2015-06-03 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-05-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-05-27 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-05-26 Thread Andreas L. Delmelle (JIRA)

 [ 
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

2015-05-26 Thread Andreas L. Delmelle (JIRA)

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


  1   2   >