You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2005/09/12 23:49:07 UTC

DO NOT REPLY [Bug 36625] New: - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36625>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36625

           Summary: Percentage IPD incorrect in side regions
           Product: Fop
           Version: 1.0dev
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: page-master/layout
        AssignedTo: fop-dev@xmlgraphics.apache.org
        ReportedBy: yvalot@gmail.com


Warning: attached patch is completely empirical. Which is why this issue doesn't
have [PATCH] in the title...

There is a bug for percentage resolution in side regions :
Specifying 100% as inline-progression-dimension on a block-container, or a table
(useful to layout information in a header/footer) does not give the proper
result : the result has an IPD of zero (maybe even less).

The origin of the problem is rather simple to explain : the getBaseLength method
asks the base length for the percentage to the BlockContainerLayoutManager,
which in turn asks its parent LayoutManager, StaticContentLayoutManager, its
contentAreaIPD, via getContentAreaIPD. Problem is, this value is not initialized.

The problem does not occur within the flow: the parent layout manager, in this
case, is the FlowLayoutManager ; the getContentAreaIPD of this LM gets the
colWidth of its current span, and that information is initialized.

I tried an empirical solution, adding setContentAreaIPD(context.getRefIPD()); to 
org.apache.fop.layoutmgr.StaticContentLayoutManager.StaticContentBreaker.getNextKnuthElements.
This gives the correct result in my sample case, of course ; but my knowledge of
the layout is far too minimal to know whether this is wise and accurate or
stupid and buggy� Even if the solution were correct, other areas of the code
might need similar modifications.

Attached are :
- A testcase and before/after PDF results
- A one line empirical patch

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.