- From: Alan Stearns <stearns@adobe.com>
- Date: Tue, 10 Feb 2015 05:26:39 +0000
- To: John Daggett <jdaggett@mozilla.com>, Chris Lilley <chris@w3.org>
- CC: Stephen Zilles <szilles@adobe.com>, Tab Atkins Jr. <jackalmage@gmail.com>, "public-houdini@w3.org" <public-houdini@w3.org>, Bram Stein <stein@adobe.com>
On 2/10/15, 1:05 PM, "John Daggett" <jdaggett@mozilla.com> wrote: >> > I don't think defining an API for font metrics is the right place to >> > start. First off, you're really probably talking about some form of >> > *line* metrics rather than actual font metrics. >> >> The desirability of an API for linebox metrics (which is not under >> dispute, and was also agreed to at the Houdini meeting) does not in >> itself argue for the undesirability of a Font metrics API in addition. > >The argument has been made that providing font metrics is a good >starting point and I don't think it is. If an author is trying to get >line metrics, then *those* are the metrics for which there should be an >API. The two should not be conflated, since there are many scenarios >where knowing the metrics for fonts used along a line will *not* tell >you the line metrics. There are some cases where line metrics are needed, such as trying to position a drop cap’s baseline with the appropriate baseline in the main text. There are other cases where just the font metrics are required, such as trying to size a drop cap based on cap height. Both line metrics and font metrics will be useful. I don’t have a firm opinion on which is the better ‘starting point’. But I do think that progress can be made on both in parallel (line metrics should be part of the fragment tree spec). Thanks, Alan
Received on Tuesday, 10 February 2015 05:27:11 UTC