Re: Possible Pango 1.4 ideas

[Damon Chaplin <damon karuna uklinux net>]

On Mon, 2003-01-20 at 02:35, Owen Taylor wrote: 

> >  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.

OK. I'll post my design ideas in a day or two.


> >  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). 


> >  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. 


> 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'?


> 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. 


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.

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.

Damon