[cairo] GTKCairo development

[Bill Spitzak]

On Monday 03 May 2004 04:12 pm, Carl Worth wrote:
> Cairo needs a text API as text is a primary element of 2D
> documents. Nobody wants cairo to generate PDF output that has text
> converted to paths.
>
> The "real" text API of cairo, (ie. what is intended to be used by
> serious text consumers such as pango), is the following:
>
>         Accept an array of glyphs (ie. indexes into a specific font),
>         along with an absolute coordinate for each glyph. Cairo then
>         renders each glyph at the specified coordinate.
>
> This should be complete support for everything that pango needs, as they
> helped us design it. If not, the pango developers should please let us
> know.

I would prefer Cairo to present a slightly more useful interface. Certainly 
all kinds of calculations about glyph positions belong in a higher-level 
library. However it appears Pango does two things: it calculates positions, 
and it also manages "font sets" and does the "which font do I need to draw 
this glyph" nonsense.

This means that the appearance of even a simple utf8 string can be different 
under Pango than under another library, and that a user-friendly "font name" 
cannot sufficently describe the appearance, leading to very annoying 
incompatabilities between programs, or requiring unreadable complex font 
names. It also means that the "toy" interface is in fact totally useless 
because I cannot guarantee it can be used to display a string that the user 
can read unless they are European.

I think a *killer* feature (one that will make Cairo instantly preferrable to 
every other graphics interface) would be to hide "font sets" inside it. My 
proposal is simple: when you select a font you are guaranteed that you will 
get 2^32 possible glyphs, and that you will get equivalent Unicode coverage 
no matter what font you choose. This will remove the need for Pango to switch 
fonts, for it to figure out what glyphs exist, and eliminate any need for any 
interface to indicate what glyphs exist, thus simplifying both Pango and 
Cairo. More importantly it will mean there will be reasonable compatability 
between programs using Pango and programs using something else, the glyphs 
will at least match, even if the positioning is wrong.

How? Very simple, inside Cairo itself the glyphs can be chosen from many 
sources, not just a "font":

1. A code would first be checked against the selected FreeType (or other) 
font. If it defines a glyph for it, that is used. In addition some fonts with 
odd encodings such as Symbol, if chosen, will replace some of the first 256 
glyphs (this is VITAL for compatability and a serious bug that Xft does not 
do this, the reason programs choose Symbol is so that 'A' prints an alpha, 
not to fill in the unicode entry for alpha!)

If that fails, Cairo falls back on hard-coded internal rules. These rules can 
only be changed by recompiling Cairo (or editing config files and restarting 
Cairo). The reason the rules are fixed is to keep the Cairo interface from 
becoming obese, and to guarantee that only the font name is needed to 
describe how text appears. It also means that once Cairo has figured out a 
code, it knows the result cannot change except for a test for existence in 
the current font.

2. A huge set of codes are composites of other codes. Cairo will attempt to 
overprint the other codes to produce accented letters, etc. Notice that this 
will not break Pango, as Pango will have already decomposed all such 
combinations. (TrueType fonts define their own composite rules, this is a 
backup table)

3. Cairo will have hardcoded and loaded a number of other fonts such as 
Symbol and Zapf Dingbats and others to fill in a backup table. This includes 
"sans" for all the latin characters. This set will be figured out by Cairo 
from the available fonts automatically. It MUST NOT be specified by any Cairo 
interface.

(steps 2 and 3 will probably be null in the initial version of Cairo, so step 
4's bitmaps will be used initially for all missing characters. This will 
produce usable output and I'm sure many hackers will make steps 2 and 3 much 
more powerful than anything Microsoft is coming up with)

4. Cairo will also have access (possibly compiled in so it cannot break due 
to a missing file) to a bitmapped 16x16 "font" of every single assigned 
Unicode character. These are strictly representational but they should allow 
a Chinese or Japanese user to at least guess what was intended if the wrong 
font was chosen and the above steps inside Cairo are not fully implemented.

5. Any code not in the bitmapped font is turned into a cairo-rendered box 
with the hex code inside it: [ea12d]

I certainly understand the reason for Pango and why it should not be in 
Cairo, but I very much believe the division point has not been selected 
correctly yet. I very much want to see font sets eliminated in my lifetime, 
and I'm pretty certain others agree.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com