Jeremias Maerki wrote:
I think it's not that simple in the Knuth approach because you cannot
just switch off the breaking as a paragraph is always broken as a whole
("total fit" in Knuth's terms). The easiest would be to simply generate
a zero-width box for the no-wrap inline followed by a hard break. This
would work fine for the text-align="start" case but probably not for the
other cases.
Maybe not even in this case: if the inline with wrap-option = "no-wrap" is
short, and is followed by other text / inline objects, a zero-width box
would cause it to overlap with the following inline areas. We cannot be
sure whether there will be a line break after the non-wrapped inline.
The problem: as soon as the breaker gets a line that is wider than the
available IPD it breaks the element to the next part/line which is not
necessarily expected here.
Maybe it's unexpected, but isn't this the best solution? Moving the
non-wrapped inline to a new line has the effect of minimizing the text
that is printed in the page margins (or even outside them, or even
clipped).
Although I cannot think of a real-life situation where an inline could
have "no-wrap", I think it's always in the user's interests to have most
of the text actually readable! :-)
Another reason supporting this: forbidding the algorithm to move the
inline to a new line would have the same effect of having
keep-with-previous.within-line = "always", which is surely not a default
value.
OTOH, how does a no-wrap look like in case of a text-align="justify"?
Hmm.
If there are non-wrapped inlines, I think that the algorithm should, if
possible, create "normal" justified lines, otherwise the lines containing
the non-wrapped inlines are allowed to be longer than the available width.
Note that, whether or not we let the algorithm move a non-wrapped inline
in a new line (this would happen when there is a restart), there always
would be no more than N overflowing (or clipped) lines, where N is the
number of the non-wrapped inlines.
If the width of all these inlines is greater than the line width, there
would be exactly N overflowing lines; but if some inlines are shorter,
moving them in a new line would produce fewer overflowing lines.
This could happen, for example, if the non-wrapped inline is created in a
xslt template matching an xml element whose text could be either very long
or short.
At any rate, the first step would probably be to create elements inside
the no-wrap inline so that it behaves like a
keep-together.within-line="always".
A way to achieve this could be to handle every space as a non-breaking
space, and not to perform hyphenation, if wrap-option is "no-wrap".
Which, incidentally, makes me wonder why hyphenate applies to blocks and
characters and not to inlines too ...
It's quite frustrating not to have an easy way to put, for example, an
english quotation inside an italian paragraph, allowing hyphenation for
italian words and forbidding it for the english ones, without having to
enclose each english word with an inline having keep-together.within-line
= "always"!
Regards
Luca
