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