Bug 51639

Thanks for your bug report. I believe the attached FO file is rendered in accordance with the XSL-FO Recommendation.

The line-height property specified on an fo:inline element has an effect only if the line-stacking-strategy on the parent fo:block has been set to 'line-height', which is not the case here.

FOP does not support that strategy, but even if it did, the result would probably not be what you expect as the second fo:inline would not generate any area. Indeed, it is ending a line and since its white-space-treatment property has been left to the default value, the white space it contains will be discarded.

To achieve the desired effect you probably want to play with the font-size property on the fo:inline elements, but a quick test shows that the size of the second inline will be taken into account only if it contains non-white space glyphs. Even a non-breakable space doesn't work.

I think this is a bug, so I'm leaving this issue open and re-phrased accordingly.

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

(In reply to comment #2)

Hi Alexey,

I'm not too familiar with inline-level layout but, yes, its does indeed seem like what we want is to get the height of KnuthGlue instances in addition to KnuthInlineBox. I suppose AlignmentContext instances would be passed the same way as for KnuthInlineBox.

There may be undesirable side effects I can't think of right now. Obviously this would have to be made only for KnuthGlue instances that are actually derived from white space characters.

HTH,
Vincent

(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

(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

(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

Created attachment 27711 [details]
Example .fo and .pdf files.

(In reply to comment #6)
> (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

I've understood your position and tried to use space characters you've advised for my aims and got a result, that is attached.

Both U+2001 EM QUAD and U+2003 EM SPACE are mapped to aux.box element, which has attribute alignmentContent = null. Furthermore lot's of well-known text editors such as MS Word or Adobe Indesign let the customer set font size and line height to simple spaces and set them in pdf like U+0020.

But if you still disagree with me I offer to modify FOP in the following way: if fo:inline contains spaces only then zero width box element should be added to the sequence. What can you say about it?

(In reply to comment #8)
> (In reply to comment #6)
> > (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
> 
> I've understood your position and tried to use space characters you've advised
> for my aims and got a result, that is attached.
> 
> Both U+2001 EM QUAD and U+2003 EM SPACE are mapped to aux.box element, which
> has attribute alignmentContent = null. Furthermore lot's of well-known text
> editors such as MS Word or Adobe Indesign let the customer set font size and
> line height to simple spaces and set them in pdf like U+0020.
> 
> But if you still disagree with me I offer to modify FOP in the following way:
> if fo:inline contains spaces only then zero width box element should be added
> to the sequence. What can you say about it?

My position is and will remain that whitespace characters (that map to glue) SHALL NEVER generate a box. The correct solution is to use EM|EN QUAD or other spacing characters that map to a box in a font. If necessary, FOP can be modified to synthesize this mapping in the absence of a specific cmap entry for the character in a font. I would support such a modification.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > (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
> > 
> > I've understood your position and tried to use space characters you've advised
> > for my aims and got a result, that is attached.
> > 
> > Both U+2001 EM QUAD and U+2003 EM SPACE are mapped to aux.box element, which
> > has attribute alignmentContent = null. Furthermore lot's of well-known text
> > editors such as MS Word or Adobe Indesign let the customer set font size and
> > line height to simple spaces and set them in pdf like U+0020.
> > 
> > But if you still disagree with me I offer to modify FOP in the following way:
> > if fo:inline contains spaces only then zero width box element should be added
> > to the sequence. What can you say about it?
> 
> My position is and will remain that whitespace characters (that map to glue)
> SHALL NEVER generate a box. The correct solution is to use EM|EN QUAD or other
> spacing characters that map to a box in a font. If necessary, FOP can be
> modified to synthesize this mapping in the absence of a specific cmap entry for
> the character in a font. I would support such a modification.
I don't think Aleksev was talking about making glue into boxes he was
simply suggesting giving them a height (alignmentContext). This is 
completely outside of the Knuth algorithm and has nothing to do with it. 
This information is not currently used by the Knuth algorithm and there
is no proposal here I can see to make the algorithm use it. Attaching
non Knuth algorithm related information to the Knuth elements is simply
a convenient way to hold on to some stuff required for line building in
this case. 
It's too long ago since I wrote this code for me to assess if the 
proposal is in compliance with the FO spec but I can't see it being
'contrary to the Knuth algorithm' as the data we are talking about is 
not being used by it and its presence or absence will not change the 
outcome of the algorithm.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #6)
> > > > (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
> > > 
> > > I've understood your position and tried to use space characters you've advised
> > > for my aims and got a result, that is attached.
> > > 
> > > Both U+2001 EM QUAD and U+2003 EM SPACE are mapped to aux.box element, which
> > > has attribute alignmentContent = null. Furthermore lot's of well-known text
> > > editors such as MS Word or Adobe Indesign let the customer set font size and
> > > line height to simple spaces and set them in pdf like U+0020.
> > > 
> > > But if you still disagree with me I offer to modify FOP in the following way:
> > > if fo:inline contains spaces only then zero width box element should be added
> > > to the sequence. What can you say about it?
> > 
> > My position is and will remain that whitespace characters (that map to glue)
> > SHALL NEVER generate a box. The correct solution is to use EM|EN QUAD or other
> > spacing characters that map to a box in a font. If necessary, FOP can be
> > modified to synthesize this mapping in the absence of a specific cmap entry for
> > the character in a font. I would support such a modification.
> I don't think Aleksev was talking about making glue into boxes he was
> simply suggesting giving them a height (alignmentContext). This is 
> completely outside of the Knuth algorithm and has nothing to do with it.

I understand, and that is why I oppose it. Glue does not  have height. Changing it to have height amounts to a fundamental change in the Knuth algorithm. If you want width and height, you need a Knuth box. Whitespace maps to glue, not boxes; therefore, it does not have height.

If you want height, you need a box.

> This information is not currently used by the Knuth algorithm and there
> is no proposal here I can see to make the algorithm use it. Attaching
> non Knuth algorithm related information to the Knuth elements is simply
> a convenient way to hold on to some stuff required for line building in
> this case. 
> It's too long ago since I wrote this code for me to assess if the 
> proposal is in compliance with the FO spec but I can't see it being
> 'contrary to the Knuth algorithm' as the data we are talking about is 
> not being used by it and its presence or absence will not change the 
> outcome of the algorithm.

To repeat, the correct way to deal with this issue is to use a character that maps to a box, and not to change the fundamental semantics of the line break algorithm by assigning height to glue.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #6)
> > > > (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
> > > 
> > > I've understood your position and tried to use space characters you've advised
> > > for my aims and got a result, that is attached.
> > > 
> > > Both U+2001 EM QUAD and U+2003 EM SPACE are mapped to aux.box element, which
> > > has attribute alignmentContent = null. Furthermore lot's of well-known text
> > > editors such as MS Word or Adobe Indesign let the customer set font size and
> > > line height to simple spaces and set them in pdf like U+0020.
> > > 
> > > But if you still disagree with me I offer to modify FOP in the following way:
> > > if fo:inline contains spaces only then zero width box element should be added
> > > to the sequence. What can you say about it?
> > 
> > My position is and will remain that whitespace characters (that map to glue)
> > SHALL NEVER generate a box. The correct solution is to use EM|EN QUAD or other
> > spacing characters that map to a box in a font. If necessary, FOP can be
> > modified to synthesize this mapping in the absence of a specific cmap entry for
> > the character in a font. I would support such a modification.
> I don't think Aleksev was talking about making glue into boxes he was
> simply suggesting giving them a height (alignmentContext). This is 
> completely outside of the Knuth algorithm and has nothing to do with it. 
> This information is not currently used by the Knuth algorithm and there
> is no proposal here I can see to make the algorithm use it. Attaching
> non Knuth algorithm related information to the Knuth elements is simply
> a convenient way to hold on to some stuff required for line building in
> this case. 
> It's too long ago since I wrote this code for me to assess if the 
> proposal is in compliance with the FO spec but I can't see it being
> 'contrary to the Knuth algorithm' as the data we are talking about is 
> not being used by it and its presence or absence will not change the 
> outcome of the algorithm.

One more point. If someone can demonstrate that XSL-FO would assign height to an inline that contains only XML whitespace, then I would be willing to alter my position.

(In reply to comment #10)
<snip/>
> I don't think Aleksev was talking about making glue into boxes he was
> simply suggesting giving them a height (alignmentContext). This is 
> completely outside of the Knuth algorithm and has nothing to do with it. 
> This information is not currently used by the Knuth algorithm and there
> is no proposal here I can see to make the algorithm use it. Attaching
> non Knuth algorithm related information to the Knuth elements is simply
> a convenient way to hold on to some stuff required for line building in
> this case. 
> It's too long ago since I wrote this code for me to assess if the 
> proposal is in compliance with the FO spec but I can't see it being
> 'contrary to the Knuth algorithm' as the data we are talking about is 
> not being used by it and its presence or absence will not change the 
> outcome of the algorithm.

I would agree with that. Knuth elements are one-dimensional only, and in the present case this dimension applies to the inline-progression-direction. That is, for Western scripts and the default settings, the line width.

What we are talking about here is the line height, and as described in Section 4.6, "Inline-areas" of the XSL-FO 1.1 Recommendation, "An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline [...] by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude".

So even if an fo:inline only contains white space characters, it would still have a height calculated from the font-size that applies to it.

My concern with adding an AlignmentContext to KnuthGlue elements is that it may cause regressions regarding line stacking in some cases. I don't know this area of the code very well so cannot predict all the implications of such a change. That said, it's just a matter of increasing the test coverage and experimenting.

Vincent

resetting P2 open bugs to P3 pending further review

i've reviewed this, and the originally reported bug is not a bug, for the following reasons:

(1) line-stacking-strategy defaults to max-height, which means the allocation rectangle of the line area is the maximum-line-rectangle as defined in XSL-FO 1.1, Section 4.5;

(2) specifying line-area on an inline only affects the expanded-rectangle of the inline area, which is used only when line-stacking-strategy is line-height;

(3) the line-height line stacking strategy is not currently supported by XSL-FO;

if you would like to submit a patch that adds support for the line-height line stacking strategy, i will apply it asap

in the mean time, i'm moving this to resolved+invalid

batch transition resolved+invalid to closed+invalid