xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas L. Delmelle (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FOP-2364) Keep-with-next integer value: Illegal value for breakClass: 75
Date Sat, 21 May 2016 20:10:12 GMT

    [ https://issues.apache.org/jira/browse/FOP-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 the keep-with-next property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message