You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2005/11/09 05:51:03 UTC
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
Re: Linebreaks around e-g and i-f-o
Posted by Manuel Mall <mm...@arcus.com.au>.
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:
<snip/>
> 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.
<snip/>
>
> Cheers,
>
> Andreas
Re: Linebreaks around e-g and i-f-o
Posted by Andreas L Delmelle <a_...@pandora.be>.
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:
...</fo:inline><fo:external-graphic src="..." />
would, according to UAX#14 LB2b, always create a favorable line-
break, even without adding explicit ZWSP.
<fo:block><fo:external-graphic .../> = no break-before (already
starting a line)
</fo:block><fo:external-graphic .../> = 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
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
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.
> <snip />
> 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