https://issues.apache.org/bugzilla/show_bug.cgi?id=51639
--- Comment #12 from Glenn Adams <[email protected]> 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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
