Re: Possible Pango 1.4 ideas

[Owen Taylor <otaylor redhat com>]

Damon Chaplin <damon karuna uklinux net> writes:

> Hi,
> 
> I noticed the discussions on gtk-devel about GTK+ 2.4 plans, so I
> wondered if we should try to get some better layout features into Pango
> for the next release. Quite a few people seem interested in using Pango
> for DTP or printing now!
> 
> I'm going to work on these (practically full-time):
> 
>  o Hyphenation.

This is probably the most far-reaching item you list in terms of
it's affect on Pango internals. I'd be interested in seeing your
design for this. It's also something that presumably has some
fun internationalization aspects that don't come up in English.
German has traditionally had spelling changes in hyphenation,
though this isn't that different to handle than the insertion
of the '-' character.

>  o Justification.

Make sure that you keep Arabic Kashida insertion in mind for this one.

>  o Tab stops - left/center/right alignment, fill characters,
>    aligning on specific characters.
>  o Underlines - word-underline (only underlines characters,
>    not whitespace), and squiggly red underlines, for spelling errors.
>  o Displaying invisible chars, like spaces, tabs, paragraph terminators.

There is support for paragraph terminators in there already, so
that probably can be extended.

>  o Drop capitals.
>  o Small caps for first n lines of paragraph.
>  o Kerning - customizable kerning for particular character pairs.

Generally this should be in the shaper and driven from font 
information. Though customizable kerning and manual adjustment
of particular characters is interesting at a sufficiently advanced
level. My idea about manual kerning was to represent it by applying
a PangoAttrShape attribute with negative width to a ZWNBSP character.

>  o Tracking - customizable for particular paragraphs.
>  o Runarounds & shaped text boxes - would need to cooperate with
>    higher-level code to determine where text can be placed on each line.
>  o Leading - locking to a baseline grid.
> 
> I think that lot should make it possible to produce fairly decent
> word-processor/DTP apps (if we can get printing working as well!).

Sounds like a reasonable list; should keep your busy for a little 
while :-). One underlying design principle I'd advocate is to
try to provide as flexible API additions as possible - for instance
a "Small caps for first n lines of paragraph." API that wasn't also
good for "All caps for the first n lines of the paragraph" or
"put the first word of each line in small caps"  probably would
be too specific.
 
> TeX-like hyphenation & justification is well underway (it works but
> there are lots of bits to sort out). And compared to those, the others
> are a doddle.

It looks like most of these items (except for Kerning) involve
PangoLayout. I think one of the most basic things that will have
to be dealt with is how to implement them and not turn PangoLayout
from barely-maintainable to unmaintainable.

PangoLayout is currently about 4700 lines of code ... that's 
far from the biggest file in the GTK+ libraries, but in terms
of shear complexity, it's probably close to the top. It's
also 3x as big as any other file in Pango (except for OpenType
parsing code.)

What I think would make sense is to look at adjusting the 
information that is stored in PangoLayoutLine so that the
entire 2D layout is explicitely there. (Currrently the 
vertical position and horizontal alignment of the lines is 
implicit rather than stored.)

Then PangoLayout could be split into:

 - Line layout
 - Code for dealing with the lines once laid out

By making the first part "pluggable", it would also then become
possible for people to use PangoLayout in highly customized
situations, though my primary motivation for suggesting this
is maintainability.

Regards,
                                        Owen