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

--- Comment #6 from Glenn Adams <gl...@skynav.com> 2011-10-06 10:45:45 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (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
> 
> Hi Glenn,
> 
> I could't understand your idea why adding alignmentContent attribute to glue
> elements can break the processing of 'spacing' space characters. We just have
> the aim to store information about line-height in inline elements, that 
> contain
> spaces only, I mean U+0020. In this case inline boxes are not generated, and 
> we
> would like to have possibility to get line height from glue element. In case 
> of
> other 'spacing' space characters logic would stay as it was, because glue
> elements would have absolutely identical alignmentContent attribute as box
> elements in one fo:inline.
> 
> I explained my point. Could you explain yours?
> 
> Kind regards,
> Alexey

i am disagreeing with you that glue should have a height;

what you are trying to do is to assign a height to whitespace characters tha
map to glue; the correct way to do that is to use a character that maps to a
knuth box, not knuth glue; and the way you do that is using EM QUAD or EN QUAD
characters;

glue should have *NO* height, as that is fundamental change to the Knuth
algorithm, so, no thank you - please use EM|EN QUAD

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