- From: Liam R. E. Quin <liam@w3.org>
- Date: Wed, 06 Apr 2016 23:03:43 -0400
- To: Alan Stearns <stearns@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Thu, 2016-04-07 at 00:41 +0000, Alan Stearns wrote: > On 4/6/16, 5:34 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote: [...] > > You just have one of the possible "glyphs" in the pair be SOL or > > EOL. > > Ah! Yes, that could work - and we’ve entertained the idea of letting > authors define pair-kern data before. But I think that would have to > be font-specific, and apply only when the font matches for both items > in the pair. So that quickly becomes complicated, too :) I don't really see how StartOfLine or EndOfLine could be in a different font than the character being "kerned". I've encountered this SOL/EOL concept before under the name of Margin Kerning. Explicit kerning in the font metrics should be just an override though, because existing fonts don't have it. So a default of, e.g. a percentage, or a list, (character percent character percent...) for start of line and for end of line, where 0% is the default and 100% means "sticks out entirely into the margin" and 33.333% means sticks out a third of its width, would be manageable in practice I expect, and would allow different defaults in different languages. I don't think there's much value in sets of characters for Western typography. The ones you want to hang are ( ) , . - and minus, en dash, quotes, and the percentages probably vary. A single default value for start and another for end would go a long way, and the actual list would let tools emulate Illustrator in specific locales/languages. Also, kern pairs are usually defined on a per-glyph basis, since it's the glyph that hangs, but I think we don't expose glyph names or font encoding positions elsewhere. I'm not sure if that would matter in practice, although it'd mean you couldn't hang the "quaint" ct ligature c_t into the margin. -- Liam "Evil XML" Quin <liam@w3.org> The World Wide Web Consortium (W3C)
Received on Thursday, 7 April 2016 03:03:50 UTC