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