[cairo] Font options patch, first draft

[Bill Spitzak]

Owen Taylor wrote:
> 
> I think you are confusing font names with font options. What's under
> discussion here is how to handle things like turning antialiasing on
> or off by user preference set for the target surface. (By X display
> properties, say)
> 
> You might be suggesting that
> 
>  "/TimesRoman-12"
> 
> Gets transformed into:
> 
>  "/TimesRoman-12 antialiasing=False"

No. I am saying the font selector does not see the word "antialiasing" 
there, and thus uses the default value for antialiasing. There is NO 
equivalent to not having the word "antialiasing" there. The word 
"antialiasing=true" means antialiasing turns on, IF the font back end 
has some concept of antialiasing. The word "antialiasing=false" turns it 
off, IF the font back end has a concept of antialiasing and IF it can 
turn it off. If the font back end does not do antialiasing, or cannot 
turn it off, then both those words are IGNORED, they do not produce 
errors, they do not "transform", they DO NOTHING!!! If the word 
"antialiasing" is not there, then the antialiasing is set to some 
default value, such as determined by the font size. There is no possible 
string that has the word "antialiasing" that is equivalent to it being 
missing.

Also I don't understand why you put a slash at the start. The only rule 
I stated was that simple names should look like PostScript/Quartz.

> in some fashion, but I'm really not of the opinion that trying to 
> transform strings like that is a good idea

There is no "transform". You seem to think that somehow this is 
translated to a single unique string that somehow identifies the font 
and is then used to look it up. That is wrong, it is the same stupid 
mistake as Xlfd and the HP printers had. Instead, here is pseudo code 
that a backend might use to parse one of these strings:

	font_structure = GET_DEFAULT_VALUES().
	foreach word in name {
	  if (word == antialiasing)
	    font_structure.antialiasing = get_bool_from_word();
	  else if (word == ...) ...
	}

Please notice the complete lack of an output string. Instead a structure 
containing everything you care about is filled in with the default 
values, and then some of them are replaced if they are recognized in the 
name.

> String forms of font names are of course useful, but they aren't
> good as the *only* form for a font name; I think for a small simple
> API cairo_select_font() is fine.

No, I absolutely disagree. An equivalent claim is that files should be 
identified by structure, where you fill in the device id, the 
filesystem, a parent directory, etc. I hope it is obvious why a string 
API to the file system is vastly superior to that. The same is true of 
fonts.

I am sorry to rant about this, but I am absolutely stumped by what the 
Cairo designers are trying to do. The huge win of Cairo is that you can, 
FINALLY, draw postscript-style graphics with completely portable code. 
It does not have to examine or interface with the backend at all, it can 
spew a lot of calls, ignore the return values, and you will get similar 
output on all backends (notice "similar"). You do not have to list, 
query, fill in structures, etc. This is a HUGE win!

That is, until you try to do fonts. You seem to think that if a program 
is going to be able to obey any user's preferences, it has to allocate 
"font structures" and has to have back-end specific code. It is not 
clear but it sounds like the program must also query the backend to get 
lists of legal things it can put in the structure. This is NOT what 
anybody wants. We want a *STRING* and we want to pass it to Cairo 
WITHOUT LOOKING AT IT!!!