Bug 51639 - Height of <inline> element is not correctly computed if the text contains white space only
Height of <inline> element is not correctly computed if the text contains whi...
Status: CLOSED INVALID
Product: Fop - Now in Jira
Classification: Unclassified
Component: pdf
all
PC All
: P3 normal
: ---
Assigned To: fop-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-08-09 15:23 UTC by Aleksey Hlyavich
Modified: 2012-04-30 00:11 UTC (History)
0 users



Attachments
source fo and desired pdf (4.67 KB, application/octet-stream)
2011-08-09 15:23 UTC, Aleksey Hlyavich
Details
Example .fo and .pdf files. (4.74 KB, application/octet-stream)
2011-10-06 14:10 UTC, Aleksey Hlyavich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksey Hlyavich 2011-08-09 15:23:54 UTC
Created attachment 27364 [details]
source fo and desired pdf

1) Create fo:block with 2 fo:inline elements. First one contains some characters, second one includes spaces only.

2) Set different line heights for those. Line height of first fo:inline element is smaller then second one.

3) PDF will not take into a count line height of second fo:inline element.

Simple test file is attached
Comment 1 Vincent Hennebert 2011-09-12 14:08:22 UTC
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.
Comment 2 Aleksey Hlyavich 2011-09-28 10:08:53 UTC
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
Comment 3 Vincent Hennebert 2011-10-05 17:26:10 UTC
(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
Comment 4 Glenn Adams 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
Comment 5 Aleksey Hlyavich 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
Comment 6 Glenn Adams 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
Comment 7 Aleksey Hlyavich 2011-10-06 14:10:04 UTC
Created attachment 27711 [details]
Example .fo and .pdf files.
Comment 8 Aleksey Hlyavich 2011-10-06 14:10:33 UTC
(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?
Comment 9 Glenn Adams 2011-10-07 10:41:51 UTC
(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.
Comment 10 Manuel Mall 2011-10-07 11:21:39 UTC
(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.
Comment 11 Glenn Adams 2011-10-07 14:01:21 UTC
(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.
Comment 12 Glenn Adams 2011-10-07 14:04:52 UTC
(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.
Comment 13 Vincent Hennebert 2011-10-12 18:41:50 UTC
(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
Comment 14 Glenn Adams 2012-04-07 01:41:48 UTC
resetting P2 open bugs to P3 pending further review
Comment 15 Glenn Adams 2012-04-23 05:53:49 UTC
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
Comment 16 Glenn Adams 2012-04-30 00:11:07 UTC
batch transition resolved+invalid to closed+invalid