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.