https://issues.apache.org/bugzilla/show_bug.cgi?id=51639
--- Comment #9 from Glenn Adams <[email protected]> 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.
