[cairo] Re: Cairo font size should be in units
cworth at east.isi.edu
Wed Sep 29 11:47:04 PDT 2004
On Tue, 28 Sep 2004 16:15:27 -0400, "graydon hoare" wrote:
> On Tue, 28 Sep 2004 11:11:30 -0700, Bill Spitzak <spitzak at d2.com> wrote:
> - the line spacing is only one metric of a font. you might be interested in
> its ascent, descent, control box height, line spacing, max advance,
> or any number of metrics (in device-dependent or device-independent terms).
> if we make the API take a single number to "size" a font, it's always going
> to be arbitrary which metric that number corresponds to.
Actually, I'm not sure we have that much choice here. I'm not a
typography expert, but a quick scan of various systems suggests to me
that when a font is describe with a single size, the metric being
referred to is what is known as the "point size" which is the default
inter-line spacing, (or the sum of the ascent, the descent, and any
built-in leading). The point size is often specified in units of
"points", but we don't necessarily have to do that to use this
definition for the size of a font. To avoid this confusion, I'll prefer
the term "font size" over the term "point size".
Just as one example, the SVG specification interprets the "font-size"
parameter as "the size of the font from baseline to baseline when
multiple lines of text are set solid".
Even more relevant to cairo is the following description from the
PostScript Language Reference:
A font defines the glyphs for one standard size. This standard
is so arranged that the nominal height of tightly spaced lines
of text is 1 unit. In the default user coordinate system, this
means the standard glyph size is 1 unit in user space, or 1/72
inch. The standard-size font must then be scaled to be usable.
So we do seem to have a fairly standard defintion of what the "size" of
a font is.
> - the font itself doesn't actually provide any interface to asking for font
> sizes by line height; it can at best give you fonts by EM size (either in
> points -- accompanied by a device DPI -- or device units). EM size
> is a completely useless unit for doing layout in, but it turns out that
> many fonts have manual hints at particular integral EM sizes, such as
> 10, 12, and 14 points.
>From what I can tell, the EM size is actually the same size that I
described above. For example, CSS2 defines the following length unit:
em: the 'font-size' of the relevant font 
So I think you and Bill are actually in agreement, when you say we have
to use the "EM size" provided by the font and he says he'd like to
specify a font size based on line spacing.
What's left then is to decide the size of a font with an identity
matrix, (eg. immediately after calling cairo_select_font). I propose
following the convention of PostScript in that the default font size is
1 user-space unit.
Cairo is different from PostScript in that under the default
transformation matrix, this font will have a device-space size of 1/96
inch rather than 1/72 inch, (more or less when under the influence of
the whole-pixel rounding used in setting up the CTM for display
> - many APIs start with points. many naive programmers sitting down to work
> with cairo will want to speak in terms of points. points are a natural
> unit which users work in. they may expect to be able to say something like
> "cairo_scale_font(12)" to get a 12 point font. if they do that with our
> current setup, they will get a 12*(72/96) = 9 point font, which in many
> typefaces doesn't even have proper hinting and looks terrible. sure, you
> may say "they are dumb and need to learn the right thing to do"; I think
> part of cairo's purpose, however, is to make the API easy to use correctly.
I hope it's obvious that cairo_scale_font accepts a scale factor rather
than a size with units. We will need to document the "1 user-space unit"
behavior of cairo_select_font as well as the 4/3 factor needed to
compute a scale factor when using a size in points and the default CTM.
> perhaps a "cairo_set_font_pointsize()" call would suffice?
I don't think that call can work as any size that passes through the
user-level API must be in user-space units. "set_font_pointsize" sounds
to me like something that would set the device-space size of the font,
which is obviously unacceptable.
> in a sense this is exactly what we'll be doing if we adopt the approach which
> is actually permitted by the font API, which is "make the font appear to have
> a 1 user unit EM square when first constructed". I find this not significantly
> superior to using "1 point" -- you still should not use that number to do any
> layout calculations -- but maybe the ability to draw a box around the EM tile
> of the font is important. who knows.
Why can't you use the number? The references I referred to above all say
that the "point size" is the designer-specified default (or minimal)
inter-baseline spacing. So, would I be insane to actually use that size
to space my lines of text? (I'm talking about toy usage here ---
obviously anything fancy can check any relevant metric using the extents
APIs in cairo.)
> I would however argue that the approach of hard-coding in a "search for a
> particular line height" heuristic is not desirable.
As I've explained, I don't think we need anything like this in cairo.
But please do let me know if I have misunderstood all the font size
explanations I could find. It's not a simple matter and the terminology
out there isn't 100% consistent, (not to mention the interesting
historical variations in the point unit).
More information about the cairo