Bug 44393

Summary: Wrong fo.Constant values used for break class
Product: Fop - Now in Jira Reporter: Vincent Hennebert <vhennebert>
Component: page-master/layoutAssignee: fop-dev
Status: CLOSED WONTFIX    
Severity: normal    
Priority: P2    
Version: trunk   
Target Milestone: ---   
Hardware: Other   
OS: other   

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
EN_AUTO, EN_COLUMN, EN_PAGE, EN_EVEN_PAGE and EN_ODD_PAGE.
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.

http://svn.apache.org/viewvc?rev=620723&view=rev
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.

http://svn.apache.org/viewvc?rev=620750&view=rev

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