[cairo] Font options patch, first draft
spitzak at d2.com
Tue Jul 19 10:39:38 PDT 2005
Owen Taylor wrote:
> Well, most of the same comments apply to it as to a FcPattern-style
> - 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.
> - 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
(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
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.
More information about the cairo