https://issues.apache.org/bugzilla/show_bug.cgi?id=51639
--- Comment #4 from Glenn Adams <[email protected]> 2011-10-06 00:35:39 UTC --- (In reply to comment #2) > Hi Vincent, > > Thank you very much for explanation. I offer a solution of this problem: > > Height of each line is computed in > LineLayoutManager.makeLineBreakPosition(...) > by choosing the largest value from all > KnuthInlineBox.alignmentContent.lineHeight values belonging to current line. > If > we add attribute alignmentContent to class KnuthGlue we'll have the > possibility > to assign glue elements line height and then possibility to choose the largest > value of line height from both all KnuthInlineBox.alignmentContent.lineHeight > and all KnuthGlue.alignmentContent.lineHeight values belonging to current > line. > > Can you proove that it is the idea FOP needs? If it is I'll start > implementation of this. > > Kind Regards, > Alexey i would not agree with this approach; the correct approach is to use one of the following Unicode space characters: U+2001 EM QUAD U+2003 EM SPACE the EM QUAD is 1 'em' high and 1'em' wide; while the EM SPACE is 1 'em' wide these would generate Knuth boxes (not glue) of the desired width and height, and scale to the font size so as to affect line height; if there is any modification to FOP to resolve this issue, then it should be to have FOP synthesize at least these (and perhaps a few other) 'spacing' space characters in case the selected font does not contain a mapping for them; since these 'spacing' space characters generate inline boxes, they are treated just like any other character; as such they are *not* treated as whitespace for the purpose of collapsing, glue behavior, etc regards, glenn -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
