Re: Linebreaks around e-g and i-f-o
On Thu, 10 Nov 2005 09:34 am, Andreas L Delmelle wrote: > On Nov 9, 2005, at 23:38, J.Pietschmann wrote: > > Manuel Mall wrote: > Now, I have another question / remark. > > Look at InlineCharIterator: the boundary EOT characters for start and > end of the inline, are they passed on to Layout? No they are not. CharIterator is only used during the refinement step by the fo.Block object and the EOT character is only used by the refinement step as a boundary indicator. It is not stored nor passed to layout. > > Cheers, > > Andreas
Re: Linebreaks around e-g and i-f-o
On Nov 9, 2005, at 23:38, J.Pietschmann wrote: Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rule LB20 the way that it also recommends b). Also seems to make sense, because both e-g and i-f-o are monolithic inlines. Now, I have another question / remark. Look at InlineCharIterator: the boundary EOT characters for start and end of the inline, are they passed on to Layout? If so, currently the following fragment: ... would, according to UAX#14 LB2b, always create a favorable line- break, even without adding explicit ZWSP. = no break-before (already starting a line) = idem dito Now I'm confused: are there any cases where option a) (in combination with surrounding characters/sibling nodes) is different from option b)? (That is, apart from adding 'boundary characters' between the graphic and the surrounding content?) IOW: Would the element list not always look like the one described in option b), if we take into account the influence from surrounding elements and/or PCDATA? (Even in case of option a)) If one focuses solely on the element list for e-g or i-f-o, I'd still go for a), but I do agree that even if we decide on following that option, the end-result would look more or less the same as option b) because an e-g/i-f-o cannot appear completely loose in the source document. There is always a parent block, neighbouring inline and/or preceding/following characters, which would generate the penalties (correct?) Cheers, Andreas
Re: Linebreaks around e-g and i-f-o
Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rule LB20 the way that it also recommends b). J.Pietschmann
Re: Linebreaks around e-g and i-f-o
I agree that a) is probably best. See e-g/i-f-o just like a glyph in a word, for example. At least, it could be used that way. In most situations you'll probably surround the graphic with spaces anyway, so break possibilities come from there. On 09.11.2005 05:51:03 Manuel Mall wrote: > What's the opinion around the group on how external-graphics / > instream-foreign-objects are suppose to be handled with respect to > determining linebreak opportunities. > > a) There is no intrinsic linebreak opportunity on either side of an > e-g/i-f-o (of course if surrounded by spaces or other breaking chars > these will produce a linebreak opportunity) > Knuth sequence: > box w="..." > b) They act more like a word surrounded by zero width spaces, ie one can > break before and after. > Knuth sequence: > pen w="0" p="0" > box w="..." > pen w="0" p="0" > c) Like b) but its undesirable so we penalise it, like a hyphen. > Knuth sequence: > pen w="0" p="FLAGGED" > box w="..." > pen w="0" p="FLAGGED" > d) Some (weird) combination like only allow a break after > > a) is certainly the simplest and an author can always put a ZWSP around > an e-g/i-f-o element. But would the "average" user expect it to behave > more like b) or c) (FWIW - MS Word behaves more like b)? On the other > hand for b) and c) we need an override if an author doesn't want a > break, ie. an explicit zero width joiner would be required. I am > tending towards a). > > Manuel Jeremias Maerki
Re: Linebreaks around e-g and i-f-o
On Nov 9, 2005, at 05:51, Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. I am tending towards a). Same here: let the break opportunities depend on surrounding content, if any. In case of more e-g/i-f-o in sequence (no chars in between), break before the first one that would overflow (unless the user expressed an explicit desire to clip). Cheers, Andreas
Linebreaks around e-g and i-f-o
What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. a) There is no intrinsic linebreak opportunity on either side of an e-g/i-f-o (of course if surrounded by spaces or other breaking chars these will produce a linebreak opportunity) Knuth sequence: box w="..." b) They act more like a word surrounded by zero width spaces, ie one can break before and after. Knuth sequence: pen w="0" p="0" box w="..." pen w="0" p="0" c) Like b) but its undesirable so we penalise it, like a hyphen. Knuth sequence: pen w="0" p="FLAGGED" box w="..." pen w="0" p="FLAGGED" d) Some (weird) combination like only allow a break after a) is certainly the simplest and an author can always put a ZWSP around an e-g/i-f-o element. But would the "average" user expect it to behave more like b) or c) (FWIW - MS Word behaves more like b)? On the other hand for b) and c) we need an override if an author doesn't want a break, ie. an explicit zero width joiner would be required. I am tending towards a). Manuel