[ Adding gtk-i18n-list back to the CC, since it's quite relevant to Pango development ] > On Wed, Mar 16, 2005 at 11:17:26PM -0500, Owen Taylor wrote: > > > Non-greedy linebreaking is very challenging to do with good > > internationalized shaping. > > In another window I have code that implements non-greedy line breaking > (not in pango). It's for research purposes (to do with choosing sizes > for table cells), and doesn't make much attempt yet to get international > text right at the moment. However, we do have some interest in getting > non-greedy line breaking into pango or inkscape, so I have looked a > little at what issues are presented by international text. Can you give > a reference to the issues? The issues I'm aware of are: > > - Identifying line-breaking opportunities. > > - Changes to text (and more importantly widths) depending on whether > or not a break appears, i.e. suppression of spaces, and possible > changes to spelling as mentioned at > http://www.unicode.org/reports/tr14/#SoftHyphen, and possibly > kerning/ligature issues for scripts like Thai. > > - If using non-rectangular text areas, then we need to be aware of > bidi reordering. (If using rectangular text areas, then I believe > we can ignore bidi except to the extent that it affects widths of > things via kerning, ligatures.) > > That's all I can think of at the moment. Are those not enough? :-) Beyond those, there are some issues specific to how Pango works, e.g. you don't have the information about "what would be the change in line length if I broke here" until you do the break. There is also the problem that most features in PangoLayout (letter spacing, tab alignment, forced break, etc) tend to complicate the line breaking ... they all interact to some extent. I haven't really investigated non-greedy breaking for Pango very much, but I can say that we've spent a *lot* of effort getting the greedy text working correctly. Something that seems like it would be pretty trivial. > > As well as performance considerations, [non-greedy line breaking] is > > just the wrong behavior for most interactive applications. > > What do you mean here? Use of greedy algorithm causes sufficient > badness that I sometimes manually change line breaking in plain text > contexts (e-mail, source code comments). I'm not so aware of badness in > dialog boxes or web pages though for some reason: maybe because I spend > more time looking at e-mail & source code text, or maybe the wider > monospace fonts accentuate badness. In any case, do you mean that > non-greedy line breaking is actually wrong as distinct from unneeded, > for such applications? Non-greedy breaking is quite disorienting during interactive editing. Users don't expect inserting text at a position to change the layout *before* that position. So, I think it's just wrong for most interactive editing, except in DTP applications where the user can be assumed to be sophisticated and tolerant. (Even there, you may want to do things like holding off reflowing a paragraph until the user is done editing it.) > > Non-rectangular layout, on the other hand, is pretty easy. It's > > not totally trivial when you have mixed fonts within a line and > > thus uneven line spacing, but I think the main challenge there is > > simply coming up with a good interface for representing the shape > > to Pango. > > Incidentally, each of non-rectangular text areas and non-uniform text > height adds difficulties to various types of optimal line breaking, > particularly if one has to choose what y coordinate to start a line / > paragraph at: e.g. what's the first y coordinate that would allow > fitting at least the first "word" on the line. (`Word' here defined in > terms of line-breaking opportunities.) Indeed. Owen
Attachment:
signature.asc
Description: This is a digitally signed message part