W3C home > Mailing lists > Public > www-style@w3.org > February 2000

Re: :first-letter errors and ambiguities

From: Chris Lilley <chris@w3.org>
Date: Sun, 06 Feb 2000 17:10:56 +0100
Message-ID: <389D9D10.753D12EF@w3.org>
To: Matthew Brealey <thelawnet@yahoo.com>
CC: www-style@w3.org

Matthew Brealey wrote:
> <Q>
> Note that the :first-letter pseudo-element tags abut the content (i.e.,
> the initial character),
> </Q>
> abut?

Yes, abut, to: verb.

> <Q>
> In order to achieve traditional drop caps formatting, user agents may
> approximate font sizes, for example to align baselines. Also, the glyph
> outline may be taken into account when formatting.
> </Q>
> This paragraph is hopelessly vague. 


> How does a UA know when the user
> wants baselines to be aligned? - more often it is the tops of glyphs
> that should be aligned.

Agree. Other times, different parts of the glyph are to be aligned.
Basically, CSS does not yet give the ability to do proper drop caps, which
require the ability to say what part of the glyph is to align with the
(optical) bottom of the lower of the spanned lines, and what part of the
glyph is to align with the (optical) top of the spanned lines. This is
moderately difficult to specify for Latin typography, and very difficult to
specify purely algorithmically for arbitrary Unicode text.

However, feel free to give it a shot.

> Such a statement would be useful, but to be so it should be specified in
> far more detail - there certainly are very serious issues relating to
> drop caps; for example, if I want to dropcap a T, if I know the height
> and width of the T glyph in the users font, then I can make my drop cap
> look good, but if I don't and I specify the appropriate
> height/line-height (it makes no difference which is used) and width
> appropriate for the fonts on _my_ computer, then I risk ugly overlap.


> For example, at Arial in a P element with 21-pixel line height and
> 16-pixel font size, these are the 'correct' values for 3-line
> top-ascender and bottom-baseline alignment.
> font-size: 76px;
> margin-top: 7px;
> line-height: 56px;
> width: 46px
> whereas if the user insists on Comic Sans MS, these are the 'correct'
> values:
> font-size: 76px;
> line-height: 43px; /* If this were 1 pixel less, it wouldn't span three
> lines! */

Using which renderer? the Win98 renderer without font smoothing, the Win98
renderer with font smoothing, the WinNT renderer with font smoothing, the
MacOS default renderer, the MacOS renderer with smoothtype, the Freetype
renderer, the BeOS renderer, or anotherone that I didn't think of offhand?

> A set of settings designed for one font would make the other look
> horrendous (If you're wondering why I don't use ems, it's because of Win
> IE's inadequate rounding routines

Yes. Possibly the gd unit might be useful, since typically the important
thing to specify is the number of spanned lines. As you say,ems should be
useful for this also; except that the font size required is

numlines * line-height - (line-height - font-size)

or to put it another way, n font-size and n-1 leadings.

> (Incidentally, on the use of points - please can we not have any
> examples using points in CSS 3 - it only encourages people.)

;-) perhaps, no examples using the screen media type

> There are in fact four or possibly five things that one must always set
> on dropcaps:
> 1. width - depends on the font - ALWAYS UNKNOWN ON THE WWW


> 2. float
> 3. line-height  - depends on the font - ALWAYS UNKNOWN ON THE WWW

No, its specified in the style sheet. However, the cap height may well be

> 4. margin-top (sometimes)  - depends on the font - ALWAYS UNKNOWN ON THE

I think you are using margin-top to account for the required optical
alignment axis, which is not necessarily the top of the design square for
the font.

> 5. font-size  - depends on the font - ALWAYS UNKNOWN ON THE WWW

This is also specified,though there may be roundoff between computed and
actual valuie, and it is computed value whichis inherited; this is a
problem if the drop cap is i a different font to the body type.

Received on Monday, 7 February 2000 19:38:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:53 UTC