[Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #16 from Glenn Adams gad...@apache.org --- batch transition resolved+invalid to closed+invalid -- You are receiving this mail because: You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #15 from Glenn Adams gad...@apache.org 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #14 from Glenn Adams gl...@skynav.com 2012-04-07 01:41:48 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #13 from Vincent Hennebert vhenneb...@gmail.com 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #9 from Glenn Adams gl...@skynav.com 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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #10 from Manuel Mall man...@apache.org 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
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #11 from Glenn Adams gl...@skynav.com 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
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #12 from Glenn Adams gl...@skynav.com 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
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
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.
Re: DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
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.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
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.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #7 from Aleksey Hlyavich alexey.hlyav...@duallab.com 2011-10-06 14:10:04 UTC --- Created attachment 27711 -- https://issues.apache.org/bugzilla/attachment.cgi?id=27711 Example .fo and .pdf files. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #8 from Aleksey Hlyavich alexey.hlyav...@duallab.com 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? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #3 from Vincent Hennebert vhenneb...@gmail.com 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #4 from Glenn Adams gl...@skynav.com 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 --- Comment #2 from Aleksey Hlyavich alexey.hlyav...@duallab.com 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51639] Height of inline element is not correctly computed if the text contains white space only
https://issues.apache.org/bugzilla/show_bug.cgi?id=51639 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Summary|Line height of inline |Height of inline element |element is not applied |is not correctly computed |correctly if the text |if the text contains white |contains spaces only. |space only OS/Version||All --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com 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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
