[cairo] Re: Cairo font size should be in units

[Carl Worth]

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"[1].

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 [2]

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
devices).

>   - 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).

-Carl

[1] http://www.w3.org/TR/SVG/text.html#FontPropertiesUsedBySVG

[2] http://www.w3.org/TR/REC-CSS2/syndata.html#length-units