Bug 44393 - Wrong fo.Constant values used for break class
Summary: Wrong fo.Constant values used for break class
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: trunk
Hardware: Other other
: P2 normal
Target Milestone: ---
Assignee: fop-dev
Depends on:
Reported: 2008-02-11 10:21 UTC by Vincent Hennebert
Modified: 2012-04-30 00:17 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Hennebert 2008-02-11 10:21:54 UTC
In fo.layoutmgr.PageBreaker references are made to Constants.EN_ALL or
Constants.EN_NONE whereas the only authorized values for break classes are
As a consequence the region-body_column-count_bug37468 testcase no longer passes
due to the latest changes in the table code.
Comment 1 Jeremias Maerki 2008-02-12 00:30:12 UTC
This is not a question if these values are "authorized". Of course, EN_ALL and
EN_NONE are illegal on the break-before/after properties but if we choose to use
them internally, it's our choice. The comments where these are used should make
clear why they are there. Span changes are break conditions for FOP and need to
be handled accordingly. Your change caused something else which doesn't have
anything to do with EN_ALL/EN_NONE. You switched from a (perhaps somewhat
suboptimal) -1 value to generating EN_AUTO for normal breaks in table layout
which caused the PageBreaker to react wrongly. I've added the necessary check to
handle the new case, too.

Comment 2 Vincent Hennebert 2008-02-12 02:22:40 UTC
Still, I understand your point but there is an inconsistent use of constants
IMO. There seems to be a confusion between the break class (auto, column,
page...) and the next part where the content should start (any, none (??),
column, page...).

The handleBreakTrait method expects a break class for its breakVal parameter
(according to its javadoc) and actually treats it as a "nextSequenceStartsOn"
value. In AbstractBreaker.getNextBlockList en_auto doesn't appear in the switch
block for the break class, so there is likely to be a problem in certain situations.

Re-opening the bug as a remainder that this area may need to be revised, and I
don't have time to look into it now.
Comment 3 Jeremias Maerki 2008-02-12 02:49:51 UTC
When a span change happens, the code will never run through
AbstractBreaker.getNextBlockList()'s forced break check. The switch statement
will only ever get enum constants from the break properties. FlowLM handles span
changes much earlier.


I still don't see a problem.
Comment 4 Glenn Adams 2012-04-01 19:27:17 UTC
due to lack of further action
Comment 5 Glenn Adams 2012-04-30 00:14:38 UTC
batch transition resolved+wontfix to closed+wontfix
Comment 6 Glenn Adams 2012-04-30 00:17:06 UTC
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen