i am disagreeing with you that glue should have a height; what you are trying to do is to assign a heigh to space characters that have a definite width and height; the correct way to do that is to use a character that maps to a knuth box, not a 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 On Thu, Oct 6, 2011 at 5:06 PM, <[email protected]> wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 > > --- Comment #5 from Aleksey Hlyavich <[email protected]> > 2011-10-06 09:06:20 UTC --- > (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 > > -- > Configure bugmail: > https://issues.apache.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. >
