[cairo] Font options patch, first draft

[Bill Spitzak]

Owen Taylor wrote:

> Well, most of the same comments apply to it as to a FcPattern-style
> varargs:
> 
>  - It is extremely flexible and extensible

It is better than FcPattern, in that arbitrary controls may be added 
without the need for them to be added to header files. This allows a 
font description to be portable between multiple backends. I consider 
this vital for Cairo to be usable.

> But:
> 
>  - It is imprecisely specified and hard to document

True, I was pretty vague about the format of the string, except I want 
PostScript/Quartz names to work as a subset of possible names.

Here is my description:

The name is a utf8 string, although only characters less than 128 have 
any meaning other than parts of identifiers, so the parser can treat it 
as bytes. Delimiters between words are any sequence of whitespace ascii 
bytes. The first word must be a name and is considered the value for 
"family", all the rest of the words can be name or name=value. A name 
can contain any byte other than = and whitespace. A value can contain 
any byte other than whitespace. Use of bytes other than ascii letters, 
numbers, whitespace, and a few punctuation marks, is *discouraged*, but 
not illegal.

(biggest problem with this is that spaces are not allowed in family 
names or other values. However I think substituting underscore should be 
acceptable, the GUI can substitute these back & forth. Putting in a utf8 
encoded non-breaking space character would work as well).

There are no errors. Unrecognized names are ignored. Values are forced 
to the nearest legal value (if numeric) or otherwise mangled to a legal 
value or ignored for text ones. There may be back-end specific 
interfaces to parse a name and report if any errors were found, but the 
portable interface is completely incapable of returning an error.

>  - It doesn't have compile-time type safety

The type-safe thing is the Cairo font_t or whatever you get after you 
select the font, not the arguements to the font selector. It should be 
obvious that I can put a string intendend for some other purpose into 
the name field in your structure just as well.

>  - It isn't very convenient for programmers (sprintf, anyone?)

Are you kidding? My main argument for strings is that it is *VERY* 
convienent for programs. I can put this into a file with almost zero 
effort, and it is 100% compatable with every language binding in existence.

The size (font matrix) is a seperate argument. That's the only thing 
that is controlled by a variable in virtually any program. If you really 
believe people are putting things other than constants into the "weight" 
you should examine real programs and real font choosers, not theoretical 
constructs.

I'm not sure if you are looking at this from the point of view of a 
programmer writing an end-user program. For me, your structure means 
that if I want to use a user's font preference, I need to read that from 
a file, parse the string (possibly using many different parsers because 
there is no standard on how to put a font in a file), figure out what 
keywords work for the current backend I have, fill in your structure, 
and pass it to the backend.

Under my scheme, I read the string and pass it to the backend.