[cairo] GTKCairo development

[Bill Spitzak]

On Wednesday 05 May 2004 02:50 am, Turner David wrote:

> Would you care to elaborate a bit about your proposed API for Cairo,
> because I clearly don't get exactly what you're describing.

What I want to *guarantee* is that even the stupidest program can use the 
simple Cairo "toy" interface (or the Pango->Cairo interface with the xy glyph 
locations), and that every glyph they send (except for those defined by 
Unicode as blank) will produce a visible glyph, and that there is a 90% or 
better chance that a user, seeing what is printed for a code assigned by 
Unicode to a glyph in a language that user understands, will be able, even 
with difficulty, to decode what was intended.

Complaining that the output is not perfect is like complaining that we could 
never have used typewriters because the non-proportional font must have been 
unreadable. This is obviously false.

It is also frustrating that Plan9 had this over 15 years ago, but neither 
Unix or Windows has this today. All I want is for a program to be able to 
dump a string and to figure out what it said. Then maybe I can get over the 
initial hurdles of writing an I18N program, and perhaps be able to even 
consider using Pango.

> To me, it seems that you're basically telling us to exclusively index
> glyphs through Unicode points in "cairo fonts" (otherwise, what does
> "equivalent Unicode coverage" really means ?).

Yes that is what I meant. By "equivalent Unicode coverage" I mean that no 
matter what font you choose you will always get at least the original set of 
glyphs. The only way a Japanese glyph will print wrong is if the current font 
actually defines a wrong glyph for that code point (this is allowed, IMHO the 
Symbol font really should define "wrong glyphs" for all the ISO-8859-1 
characters)

> You do understand that mapping character codes to real font glyph
> indices is a bit more complex than a simple dictionary lookup, since
> it can heavily depend on context...

Of course, but that can be done at a higher level. What I propose is to put 
some more code into Cairo so the vast majority of the mapping is now to 
codes, and not to font + character code, and that there is a reasonable 
fallback if a font is not available. Unicode has been designed so the 
alternative presentation forms are different codes for most common languages 
(ie ligatures for Latin, and the Arabic presentation blocks you mentioned). 
Yes some languages have to change fonts, and Pango would still do that, but 
it could "work" when those fonts are missing and produce ugly output, which 
is a lot better than *no* output which is the situation we have now.

> I have five open questions:
>
>  1. How do you implement this without duplicating _most_ of the
> functionality of Pango, Uniscribe or ATSUI ?

Like you said, it would be a strict dictionary lookup. There are 2^31 
possible UTF-8 codes and it acts exactly like they map 1:1 to a set of 2^31 
different glyphs. The image drawn cannot depend on anything other than the 
current font, ctm, font matrix, and the code number. The "toy" interface will 
also position glphs by summing two values called "x" and "y" from all 
previous glyphs. All rules for turning a code into a missing glyph are 
hard-coded into Cairo, it does not matter if they are wrong or stupid, since 
Pango can ignore them by using it's own rules first. In fact I expect the 
initial version will just turn all missing codes into a Hex representation.

>  2. How do you define and select a "cairo font" exactly. Should it include
>     locale, writing direction, and other context information ?

A "cairo font" is exactly the same as it is now, and maps 1:1 to whatever the 
system considers a "font" to be. When the system font says "I don't know how 
to draw this code number" Cairo then uses fixed built-in rules to come up 
with a glyph to draw anyway.

>  3. How do you push data from fonts into Cairo. What kind of data can
>     libraries and applications extract from a "cairo font". Especially
>     things like Pango itself.

Exactly the same data it can right now. The current interface would return 
the information for the fallback glyph if the current font does not define a 
glyph.

The only addition would be to the system-specific area. This would be one 
call that is "for this glyph, return the system font it is drawn from". This 
will allow Pango to access Cairo's decisions about the font to use, if it 
wants.

>  4. What kind of glyph codes should the application send to Cairo.
>     what level of processing is required by the app when dealing with
>     complex combinations for example.

Cairo would simply provide "for this code print an image that is very likely 
to look like the code's Unicode assignement". It is Pango's job to select 
positioning, change presentation forms, or handle multiple fonts.

>  5. How do you keep this simple ?

Anything is simpler than the current interface:

> Again, I may misunderstand your proposal. Any example code to show this API
> would be welcome.

Here is my proposed interface to Cairo:

cairo_select_font(ct, "Name of any font whatsoever");
cairo_draw_text(ct, utf8string);

As opposed to the current interface:

bool japanese = analize_string_and_see_if_japanese(utf8string);
bool arabic = analize_string_and_see_if_arabic(utf8string);
if (japanese && arabic) fatal("too bad you lose because I am not in any mood 
to split the string into multiple calls");
if (japanese) cairo_select_font(ct, "name of font that has Japanese glyphs on 
my machine and I hope works on yours");
else if (arabic) cairo_select_font(ct, "name of font that I hope will have 
Arabic glyphs");
else cairo_select_font(ct, "any font for those lucky western users");
cairo_draw_text(ct, utf8string);
// Too bad if you are not English, Japanese, or Arabic!

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