https://issues.apache.org/bugzilla/show_bug.cgi?id=51639

--- Comment #4 from Glenn Adams <gl...@skynav.com> 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.

Reply via email to