Re: line-height suggestions and easier alignment

On 09/01/2012 12:02, Matthew Wilcox wrote:
>> From what I can tell, CSS's line heights seem to be fine; the problem
> is a lack of proper treatment with regard to the baseline. In printed
> type the baseline is king - everything is measured against it because
> it is the root of type. In CSS the EM box is king, and the baseline is
> merely a sub-component of the EM box. That's where most type layout
> problems are coming from. CSS bases type layout on the EM box
> boundaries, and print uses the baseline grid. The baseline can "move"
> in the em box, which means CSS is never properly aligned as it would
> be in print.

It is true that there is no baseline grid in general because line boxes 
may have different heights.  This is not so much because the em-box is 
used but more to do with the fact that browsers can use fallback fonts 
to obtain glyphs, and different fonts have different metrics.

In manual type, if a glyph is missing from a font then it can be 
replaced with one from another font and the publisher can manually 
choose an appropriate size and alignment.  The web has a much harder 
problem to solve: no manual adjustment is possible so the layout 
algorithm has to produce a general solution that most people can accept 
most of the time.  In the early days of the Web, fonts didn't cover a 
particularly large range of glyphs, so there was a lot of fallback going on.

The CSS model tries to find a compromise between avoiding fallback 
glyphs from bleeding too much into surround line boxes and not 
increasing the height of line boxes too much.  (Many people don't like 
the CSS model, and I also think it's odd, but it is a reasonably 
effective solution to the problem it was trying to solve.)  How would 
print solve the problem of a large fallback glyph?  It would probably 
keep the baseline grid fixed (ie keep the line boxes at constant height) 
and allow the glyph to bleed to the maximum extent.  I wonder if it 
would do that if there were hundreds of fallback glyphs on every page, 
though... as there were in the early days of the Web when the font 
landscape was bleak.

I recommend that people describe (clearly and with test cases) perceived 
failings of the current model to this mailing list.  Ric did this, and 
was met with an enthusiastic response since there was a clear technical 
solution to his issue that complemented the existing model.

> Weirdly, it's perfectly correct in modern digital fonts for parts of
> the character to be renderable outside of the EM box. Though I'd
> contest that it's bad practice generally. From my understanding of the
> matter this is because the font glyph can be larger than the EM box.
> It's analogous to having part of the character protruding above or
> below the type slug in metal print (and thus never happened in metal
> print).

Yes, this strikes me as odd too; but I'm no typography expert.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 9 January 2012 11:35:03 UTC