- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 8 Feb 2015 13:55:38 +1100
- To: Alan Stearns <stearns@adobe.com>
- Cc: "public-houdini@w3.org" <public-houdini@w3.org>, John Daggett <jdaggett@mozilla.com>, Bram Stein <stein@adobe.com>
On Sun, Feb 8, 2015 at 1:45 PM, Alan Stearns <stearns@adobe.com> wrote: > So we’ve resolved to create a spec for a font interface that contains font > metrics information necessary [1] for script to produce interesting > typographic effects (drop caps, baseline grids, etc.) I have some initial > thoughts about how this information should be exposed, and some concern > about how we should rationalize what’s currently specified for canvas > TextMetrics [2]. > > There are quite a few metrics we could expose. I don’t know that it’s > necessary to include every possible metric in the first cut of this > interface. It seems to me that we could start with a reasonable subset and > add more information as needed. I think a reasonable subset would include: > > alphabetic baseline > hanging baseline > ideographic baseline > ascent > descent > x height > cap height > > > Steve warned that there are several different meanings for ‘ascent’ and > ‘descent’ in different fonts. So I assume this interface should pick one > and describe how to translate known differences to what the interface > provides. > > The TextMetrics interface has attributes for some of these metrics in CSS > pixel units. This makes sense for the canvas measurements being made by > that interface, but I’m thinking the font interface we’re designing should > be expressed in more abstract units. One possibility is to add a > unitsPerEm attribute and express all the other metrics in those > font-specific units. That’s probably the most natural thing to do for > typographers. But I think it could also work to rationalize on a single > unitsPerEm value or use an em percentage. An em percentage is fine with me. No need to indirect through some variable amount of units. ~TJ
Received on Sunday, 8 February 2015 02:56:25 UTC