TableLayout/KnuthElementsForTables

2005-04-09 Thread Simon Pepping
Jeremias,

I read your TableLayout/KnuthElementsForTables wiki page with
interest. Luca's algorithm is a fine algorithm.

I do have a problem with your last example. Half of the border-after
of the table-header is counted twice, once in the row heights and once
in the header itself. All heights before the page break except the
second one are 2 units too high, and those after the page break are 4
units too high when I compare them with your drawings of the table.

I believe it is better to omit half of the border-after
of the table-header and half of the border-before of the table-footer
from the row height. Then I get the following calculations:

Header is 5 + 8 = 13
Footer is 8 + 5 = 13

row1: 15 + (2/2) = (16,16,16)
row2: 20 + (2/2) = (21,21,21)
row group (37,37,37)

Step 1:
stepw= 10
maxRemainingHeight = 37
addedBoxHeight = 0
penalty = 10 + 37 - 37 = 10
effPenalty: w = 10 (space for block1) + 13 (header) + 4 (border-after-header) + 
4 (border-before-footer) + 13 (footer)
box = 10 - 0 - 10 = 0

Step 2:
stepw = 15
maxRemaningHeight = 20
addedBoxHeight = 0
penalty = 15 + 20 - 37 = -2
offPenalty: w = -2 (calc penalty) + 13 + 4 + 4 + 13
box = 15 - 0 - (-2) = 17

Step 3:
stepw = 10 + 10 = 20
maxRemainingHeight = 20
addedBoxHeight = 17
penalty = 20 + 20 - 37 = 3
effPenalty: w = 3 (calc penalty) + 13 + 4 + 4 + 13
box = 20 - 17 - 3 = 0

Step 4:
stepw = 10 + 10 + 10 = 30
maxRemaningHeight = 20
addedBoxHeight = 17
penalty = 30 + 20 - 37 = 13
effPenalty: w = 14 (calc penalty) + 13 + 4 + 4 + 13
box = 30 - 17 - 13 = 0

Step 5:
stepw = 15 + 2 + 20 = 37
maxRemainingHeight = 0
addedBoxHeight = 17
penalty = 37 + 0 - 37 = 0 (last step, omit penalty)
box = 37 - 17 - 0 = 20

box(0)
penalty(10) - 10/37
box(17)
penalty(-2) - 15/20
box(0)
penalty(3)  - 20/20
box(0)
penalty(13) - 30/20
box(20)
- 37

box(0)
penalty(44) //incl. header and footer - 44/71
box(17)
penalty(32) //incl. header and footer - 49/54
box(0)
penalty(37) //incl. header and footer - 54/54
box(0)
penalty(47) //incl. header and footer - 64/54
box(20)
box(17) //header
box(17) //footer
  - 71

You see I can avoid the subtraction of 2 for the second page break,
which makes the calculation more regular. I do get a negative
penalty. I do not believe that that is a problem, less so because it
is added to the penalty for the header/footer/borders. It expresses
the fact that for this page break the table is shorter than without
page break, due to the merger of the row border with the header and
footer borders.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



DO NOT REPLY [Bug 1180] - Problem with monospaced font

2005-04-09 Thread bugzilla
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=1180.
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=1180





--- Additional Comments From [EMAIL PROTECTED]  2005-04-09 18:56 ---
Let's celebrate the 4th anniversary of this bug in style.

To cite a famous physicist (C.Pauli, I believe):
This is not right, it is not even wrong.

Well, I just removed (locally) the fudge factor for 'whitespace' and it works 
fine.

What the original thinking behind the original kludge was beats me.

Do you want to have half a chance of seeing the same output on different
output devices?  Remove the kludge!
Do you want to be able to predict the size of some text based on font metrics
without going through FOP to find out?  Remove the kludge!

You don't _like_ _some_ spacing of a given Font? Where exactly does that bother
you? Only in AWT? In Word? In PDF?
Well, I've got news for you: Find yourself a font you like better!

Whoever commited that code should be relieved of his privileges.

-- 
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.