[cairo] GTKCairo development

[Jon Smirl]

A straight x/y layout does not work for all languages. Take Thai for example, I
don't know Thai so I may be completely wrong on this. But in Thai the consonants
are circled by the vowels. A program uses the string 'Cvvvv'  (C-consonant,
v-vowel) but it lays out like this:

     v
v   C   v
     v

Thai also has funny symbols that change heights depending on what characters are
next to them. Dengavi, an Indian language has similar problems. This is really
weird to type on because your cursor jumps around to the different vowel
locations. Download the Thai language pack for Win2K and try it.

You really have to give the strings to something like Pango and let Pango figure
these things out. Pango has plugin libraries for laying out these non-Roman
languages.  Pango needs to handle the font substitution problem so that is can
properly calculate the x/y coordinates. Once Pango figures out where the glyphs
go it can call into Cairo to paint the glyphs.

A simple text API can do "Hello World" in the Roman languages; it just doesn't
work for a lot of other ones.

--- Bill Spitzak <spitzak at d2.com> wrote:
> 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
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo


=====
Jon Smirl
jonsmirl at yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover