Bug 211683 – Text is clipped when rendered with fonts which have a negative line gap metric

• Component: New Bugs
• Status: RESOLVED FIXED

[Myles C. Maxfield]

Text is clipped when rendered with fonts which have a negative line gap metric

[Myles C. Maxfield]

Created attachment 398957 [details]
Patch

[Myles C. Maxfield]

<rdar://problem/62192986>

[Myles C. Maxfield]

Created attachment 398958 [details]
Patch

[Myles C. Maxfield]

Created attachment 398961 [details]
Patch

[Sam Weinig]

Comment on attachment 398961 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=398961&action=review

> Source/WebCore/ChangeLog:17
> +        There are some typographical reasons to want a negative line gap, which is why this clamping
> +        behavior shouldn't be done in the platform text library. In the interest of matching other
> +        browsers, we should perform this clamping ourselves in WebKit.

Out of curiosity, what are the reasons one might want a negative line gap? Given that WebKit is used for more than just browsers, would any of those reasons apply to other uses of WebKit? Should this perhaps be a preference?

[Darin Adler]

Comment on attachment 398961 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=398961&action=review

>> Source/WebCore/ChangeLog:17
>> +        browsers, we should perform this clamping ourselves in WebKit.
> 
> Out of curiosity, what are the reasons one might want a negative line gap? Given that WebKit is used for more than just browsers, would any of those reasons apply to other uses of WebKit? Should this perhaps be a preference?

(Heretic speaks) Or a non-standard CSS property?

[Myles C. Maxfield]

(In reply to Darin Adler from comment #6)
> Comment on attachment 398961 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=398961&action=review
> 
> >> Source/WebCore/ChangeLog:17
> >> +        browsers, we should perform this clamping ourselves in WebKit.
> > 
> > Out of curiosity, what are the reasons one might want a negative line gap? Given that WebKit is used for more than just browsers, would any of those reasons apply to other uses of WebKit? Should this perhaps be a preference?
> 
> (Heretic speaks) Or a non-standard CSS property?

There are two reasons why a designer or font creator might want it:

1. They just plain want tighter line spacing. One reason for this is the font's design might include swashes and diacritics which necessitate a large ascent (for things like the text selection rectangle), but the line height looks too large. Another possible reason is the font is designed for a script which has these typographic attributes.

2. CSS uses a different model of line-height than most other design systems. In CSS, half-leading is added to the ascent and descent of the line during layout. However, in most other layout systems, the line gap is modeled as a strut between successive lines. For interior lines of a paragraph, there is no difference, but for the first and last lines, there is a difference. I most other layout systems, if a font has a negative line gap, it means that the interior lines of a paragraph appear closer together, but the first line of the paragraph still has plenty of space on its upper half. This look can add emphasis on the first line of text in a paragraph, which can be typographically valuable. However, for CSS's model, this logic doesn't really hold so much.

I could see this being configurable, but I think this specific patch is too low-level to warrant its own switch. If anything, we might want to have a "make line layout work the same as native TextKit" where we redesign line-height to act like their design, and honor these negative line gaps in that mode. If we do something like this, it makes sense for the switch to be API or SPI rather than a CSS property, because the audience for this kind of switch would be app developers who want to present a native-like interface.

[EWS]

Committed r261573: <https://trac.webkit.org/changeset/261573>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398961 [details].