Bug 46813 - [PATCH] block margin as percentage problem on 1st block in block-container
Summary: [PATCH] block margin as percentage problem on 1st block in block-container
Status: NEW
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.95
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL: http://markmail.org/thread/aczg2mzdpk...
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2009-03-06 03:29 UTC by John Escott
Modified: 2012-04-11 03:20 UTC (History)
0 users



Attachments
fo file illustrating the problem (1.11 KB, text/plain)
2009-03-06 03:31 UTC, John Escott
Details
Patch that fixes problem (1.72 KB, application/octet-stream)
2009-09-25 17:46 UTC, Jonathan Levinson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Escott 2009-03-06 03:29:33 UTC
Setting a block margin-right to a percentage on the first block in a block-container is not honoured. The effect is as though the right margin is zero.

The attached fo contains a block-container containing 3 blocks, the first and third of which have margin-right="40%". Viewing the pdf produced shows that the first block receives a right margin of 0, whereas the third has the correct right margin.

This effect happens with 0.95 but not 0.93
Comment 1 John Escott 2009-03-06 03:31:35 UTC
Created attachment 23347 [details]
fo file illustrating the problem
Comment 2 Jonathan Levinson 2009-09-25 17:46:34 UTC
Created attachment 24314 [details]
Patch that fixes problem

Attached is a patch that fixes problem which occurs when containing-block contains block which contains block whose right-margin is a percentage width.

I ran JUNIT tests and all passed successfully.

I'm new to FOP community and to Layout Manager and I have confidence that someone more senior on FOP community will review my fix.

Let id=1 be the containing block (not a block container but the containing block!) and let id=2 be the block whose right-margin is a percentage.  The problem was that when the endIndent was calculated in BlockLayoutManager in method initialize, the ipd for id=1 had not yet been set up and was zero in its various manifestations.  Percent * 0 = 0.

There could be a deeper problem (like the Knuth Elements being processed in the wrong order), which my fix masks, however my fix did resolve this particular issue and still passed all JUNIT tests, so it is worth posting.

My fix is an instance of the "RECALCULATE" design pattern (my own coinage).  If you sometimes get the calculation wrong the first time, unconditionally do it again when it is needed and more information is available.  In this case, if you sometimes get the calculation wrong in initialize, unconditionally recalculate when you get the next Knuth Element, which is responsible for updating the content ipd with over-constrained adjust.
Comment 3 Glenn Adams 2012-04-07 01:41:46 UTC
resetting P2 open bugs to P3 pending further review
Comment 4 Glenn Adams 2012-04-11 03:20:57 UTC
increase priority for bugs with a patch