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, <bugzi...@apache.org> wrote:

> https://issues.apache.org/bugzilla/show_bug.cgi?id=51639
>
> --- Comment #5 from Aleksey Hlyavich <alexey.hlyav...@duallab.com>
> 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.
>

Reply via email to