Re: [Gnome-print] Pango and gnome-print

[Lauris Kaplinski <lauris ximian com>]

Hello Owen!

> But simply switching over to your glyphlist representation
> is not an option:
> 
>  - It's more complex than is useful for simple font formats, like X
>    fonts; making shapers harder to write, and layout operations
>    slower.

Yeah, the X and interactivity requirements are hard - and of absolutely
no interest for printing system.

>  - It is insufficient for OpenType, which is our targeted font format
>    of the future. For instance, a common and useful positioning
>    operation in OpenType is to position one glyph with respect to a
>    hinted control point of another glyph.

I'll explain my concerns, ideas about OpenType and how to handle that.

IMHO OT took a quite wrong approach to addressing language-related
complexities, trying to write these down in abstract way, instead
of trying to standardize basic list of per-script features. I am
mostly talking about GSUB here.

Instead of rules like:

Replace glyphs 'xyz' with 'q'
If tension of line is gt A, replace 'q' with 'rs'

I'd like to see:

Script A
  [Subscript B]
     Rule X glyph 'q'
       [Exception line tension gt A glyph 'rs']

You get the idea. Instead of list of anonymous procedures, there are
named ones.
Of course it involves extra work of creating big per-script rule
lists. But IMHO it would be justified, as per-script/language
renderers have much cleaner acess to rules. What remains out of
standardization, are true font-specific things. Current approach
gives me uneasy feeling, that somebody is hoping to embed all
script-specific writing rules inside fonts.

Gnome-print core is not interested in GSUB. It has to be fed with 
glyphs, and is prohibited in doing any replacement.
So my interest is restricted mainly to GPOS and GDEF.

Now, OT is file format, not API. I'd like to see OT API, for
several reasons:

1) Effectively isolating ugly table parsing into single part
   of code.
2) Way to implement OT wrapper around ordinary fonts - either
   by using separate metadata, or some inherent knowledge about
   font.
3) Add semantic information to API (i.e. named rules instead of
   anonymous ones).

Now I kept OT in mind for GlyphLists.
GlyphList is:

array of glyphs
array of rules

While the only positioning rules at moment are abspos, rpos and advance,
there is no problem extending it to cover OT things. My only concern
is, whether to do that by generic way (using OT API extraction) or
font-specific way (using some numbering scheme referring to specified
OT file). I very much prefer API, but I have not had time to think
much about how to do the abstraction.

Example (fake one), how things may be done:

Glyph Array      Rule Array
---------------------------
                 x y pos
                 advance
a                push
                 class q cpointpos
'                class r cpoint
                 pop
c
u
t
e

Positions single 'a', saves pen position and renders acute using
right connection points. Then renders 'cute'
The number of rules is big, but it may be reduced for common usages.
'advance' rule is specified once and affects all following glyphs.
I am not happy with push/pop, so maybe there will be indexed
pen positions instead.

So control points fit relatively easily withing Glyphlist idea, as
do other OT positioning rules. But only positioning ones - there
should not be any glyph substitution at that point.

And if unsure, there is always a way to do:

f  x0 y0 pos
e  x1 y1 pos
e  x2 y2 pos
l  x3 y3 pos
...
So it does translate always to/from PangoGlyphString IMHO.

Best wishes,
Lauris Kaplinski