RE: List cases for a cap height unit

See comments below.

Steve Zilles


> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Tab Atkins Jr.
> Sent: Wednesday, October 26, 2011 10:37 AM
> To: Alan Stearns
> Cc: www-style list
> Subject: Re: List cases for a cap height unit
> 
> On Wed, Oct 26, 2011 at 10:13 AM, Alan Stearns <stearns@adobe.com> wrote:
> > It all depends on the font. In some fonts ascent will be significantly
> > taller than cap height, so a lowercase 'f' will loom above a capital "A."
> > What "size of the text" means is a little fuzzy - is it cap height,
> ascent,
> > the max of those, or an optic average?
> 
> For use case 1, "size of the text" means "a normal height for a
> capital letter, so it blends in typographically".  For use-cases 2 and
> 3, it means "the largest height such that, when the image is placed on
> the baseline, it doesn't change the line's height".
> 
> I *think* that cap height works for both of these definitions.  Am I wrong?
[SZ] There is a difference.

First, the OpenType definition of the CapHeight metric:

sCapHeight
Format:  SHORT
Description:  This metric specifies the distance between the baseline and the approximate height of uppercase letters measured in FUnits. This value would normally be specified by a type designer but in situations where that is not possible, for example when a legacy font is being converted, the value may be set equal to the top of the unscaled and unhinted glyph bounding box of the glyph encoded at U+0048 (LATIN CAPITAL LETTER H). If no glyph is encoded in this position the field should be set to 0.

This metric, if specified, can be used in systems that specify type size by capital height measured in millimeters. It can also be used as an alignment metric; the top of a drop capital, for instance, can be aligned to the sCapHeight metric of the first line of text.
====

This definition does introduce a new use case, that of aligning the top of a Drop Cap with the CapHeight of the line it is aligned with. Not currently doable in CSS, I believe.

But, the point that is more relevant to the question you asked is the that top of the line, the Ascender height normally allows room for accents, such as the ring in A-ring. Thus, you can go as high as the Ascender height without causing a collision with the line above.

> 
> 
> > The discussion so far seems to be around wanting to size things based on
> cap
> > height, which is perfectly fine. Another possible use case could be
> wanting
> > to size things based on ascent, which would require a different unit than
> > "cap height." I just want to be precise about what the current proposal
> will
> > be providing.
> 
> What, precisely, is a use-case for wanting to base something off of
> the ascent?  Describe something an author would want to do, without
> using the word "ascent".  ^_^
[SZ] You have already done that in your description of usecases 2. And 3. See the comments above.

The feedback I have gotten so far on usecase 1. Is as follows (and agrees with your "ascent" question):

"I wouldn't think it made sense to include calculations like accent heights in any system; the objective is to align with the visual body of the text, and accents (or ascenders and descenders) are extraneous to that.

I agree that in a Western context (i.e. bicameral alphabets) the cap height is likely to be your best default. If one knew more about the intended use of the inserted graphic, one could do better. For your example of a new math sign, of course the figure height (usually slightly less than the cap height) would make more sense.

In a Middle Eastern context (i.e. unicameral "alphabets" - Arabic, Armenian, Coptic/Ethiopic, and Hebrew) I would suggest using the figure height - although there's a risk that figures in many fonts for these systems will not be well fitted to the design."
> 
> ~TJ

Received on Wednesday, 26 October 2011 18:11:08 UTC