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"!