[cairo] GTKCairo development
spitzak at d2.com
Thu May 6 12:43:21 PDT 2004
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
> 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
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
> 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");
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
else cairo_select_font(ct, "any font for those lucky western users");
// Too bad if you are not English, Japanese, or Arabic!
,~,~,~,~ ~ ~ ~ ~
/\_ _|_========___ Bill Spitzak
~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com
More information about the cairo