Re: Possible Pango 1.4 ideas

[Owen Taylor <otaylor redhat com>]

Damon Chaplin <damon karuna uklinux net> writes:

> > >  o Justification.
> > 
> > Make sure that you keep Arabic Kashida insertion in mind for this one.
> 
> Yes, it is on my list. But I need an Arabic expert to tell me the rules
> for inserting Kashidas (where in the word can they be inserted? how many
> can be inserted in a word?).
> 
> I hope it is easy to calculate the width that they can extend a word by
> (without having to try inserting them in lots of places and shaping them
> to get the extents). 
 
The way that Microsoft does it, as I recall, is that there is a flag
in their equivalent of PangoGlyphVisAttr as to whether a Kashida
can be inserted before the Glyph. So the shape engine would take
care of figuring out where to put them.

Note that Kashida insertion probably has to be virtualized through
PangoEngineShape because things like selecting the right Kashida glyph
are dependent on font technology. (*)

One possibility is that justification should be entirely virtualized;
the layout engine should just figure out how wide a run needs to be
and then tell the shape engine "make it so wide". But that could
result in a lot of duplicated code between all the shape engines
that justify by adding space.

> > >  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.
> 
> Yes, I was assuming the shaper would do normal kerning, as the ft2
> backend does already. 
> 
> Can we use a new PANGO_ATTR_KERN attribute on the first character of the
> pair to kern? I don't really think apps should have to insert extra
> characters to do the kerning. 

We could. 

> > 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.
> 
> What sort of API did you have in mind for 'small caps for n lines'?
 
No particular API in mind. However, it does seem to me that:

 pango_layout_set_small_caps_for_first_n_lines (PangoLayout *layout,
                                                int          n_lines)

is way wrong. With greedy line layout it would be pretty easy to 
create a "layout engine" that sets attributes on the text depending
on which line of the paragraph and chains to the real layout engine
below. It would be hard to do that with global paragraph optimization.
 
> > 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.
> 
> Actually I've hardly changed pango-layout.c at all so far. I just
> replaced the code that calls process_line() with a call to my own
> function. So it is fairly pluggable already. 
 
I don't see how you can do TeX style global paragraph optimization
at that level.

Also, note that putting ParaBreakState into a public header is actually
exporting a really large chunk of poorly defined API, so should
be done with extreme caution.
 
> My layout code won't replace the current layout code, since my code
> won't implement the WORD/CHAR/WORD_CHAR wrap modes, and we'll still need
> them for backwards compatability.

And because we need them... hyphenation isn't the right thing to do
for many cases.
 
> Also, the current layout code won't have all the new features of the new
> code. So some of the API would only be relevant in one mode, and some in
> the other, which may be a little confusing.
>
> I'm unsure of how to switch from one mode to the other. I suppose we
> could add a BEST_FIT wrap mode, and use that to switch to the new layout
> code. But a more explicit function to switch modes may be better, e.g.
> pango_layout_set_engine (layout, "advanced"). Or maybe I should create a
> subclass of PangoLayout.

I suspect the ability to set a layout engine (probably as an object
rather than a text string) will turn out to be better than a 
subclassing approach; a subclassing approach would put more constraints
on the details of the "basic" engine.

On the other hand, subclassing would allow adding new PangoLayout
properties. I think we probably need to get a bit more of an idea
of exactly what the "layout engine" API looks like before we make
a final descision here.

Regards,
                                        Owen

(*) An alternative is that there could be a generic "Kashida Glyph"
    glyph index that the layout engine would set in combination with 
    the desired width, and then the rendering part would figure out
    what glyph was needed.