Bug 4842 - Small caps should use uniform antialiasing settings
Summary: Small caps should use uniform antialiasing settings
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2005-09-04 08:01 PDT by Alexey Proskuryakov
Modified: 2023-03-23 09:03 PDT (History)
9 users (show)

See Also:


Attachments
test case (420 bytes, text/html)
2005-09-04 08:02 PDT, Alexey Proskuryakov
no flags Details
Screenshot from Safari 5.0.5 on Mac OS X 10.6.8 (2.59 KB, image/png)
2011-07-29 22:50 PDT, Alexey Proskuryakov
no flags Details
[wrong settings] Screenshot from Safari 5.1 on 10.7.0 (8.46 KB, image/png)
2011-07-29 22:51 PDT, Tim Horton
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2005-09-04 08:01:34 PDT
Text rendered with font-variant:small-caps CSS style uses uppercase letters rendered at 70% instead of 
lowercase ones. Sometimes, this results in uppercase and small caps having different antialiasing 
settings (because of the system default 8 pt threshold). 

Steps to reproduce:
1. Set "Turn off text smoothing for font sizes 8 and smaller" in Appearance control panel
2. Open the attached test case.

Results: the upper string is not antialiased, the middle one is partially antialiased, and the bottom one 
is antialiased
Expected results: the middle line should be all antialiased, too (or, arguably, all not anti-aliased)

Obviously, it doesn't look nice when some letters of a word are anti-aliased, and others aren't.

See also: bug 4355
Comment 1 Alexey Proskuryakov 2005-09-04 08:02:00 PDT
Created attachment 3753 [details]
test case
Comment 2 David Kilzer (:ddkilzer) 2006-01-08 09:58:16 PST
FWIW, the menu at the top of the NucleusCMS.org web site uses small caps and thus exhibits this issue.

http://nucleuscms.org/
Comment 3 Alexey Proskuryakov 2011-07-29 22:50:07 PDT
Created attachment 102425 [details]
Screenshot from Safari 5.0.5 on Mac OS X 10.6.8
Comment 4 Tim Horton 2011-07-29 22:51:46 PDT
Created attachment 102426 [details]
[wrong settings] Screenshot from Safari 5.1 on 10.7.0

Looks totally different on 5.1/Lion.
Comment 5 mitz 2011-07-29 22:55:33 PDT
(In reply to comment #4)
> Created an attachment (id=102426) [details]
> Screenshot from Safari 5.1 on 10.7.0
> 
> Looks totally different on 5.1/Lion.

Is this with “turn off text smoothing” set to “8 and smaller” in System Preferences > General?
Comment 6 Tim Horton 2011-07-29 23:00:29 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=102426) [details] [details]
> > Screenshot from Safari 5.1 on 10.7.0
> > 
> > Looks totally different on 5.1/Lion.
> 
> Is this with “turn off text smoothing” set to “8 and smaller” in System Preferences > General?

This is why I shouldn't do work at night :-) I missed those instructions because I was stuck thinking about the other bug.

In any case, I don't think they're the same bug (I got here from Alexey's comment on https://bugs.webkit.org/show_bug.cgi?id=36182) because of those restrictions. In 36182, the AA is being disabled way earlier than the system cutoff (and that's what the bug is about), while in this bug, it's respecting the system cutoff (as we can see by my stupid mistake above) in an unfortunate way. But I could be wrong.
Comment 7 Ahmad Saleem 2023-03-17 18:00:05 PDT
@ap - It seems to work fine on WebKit ToT (261814@main) and don’t have difference in antialising shown as in reference issue. Can we close this or it might be specific now to non-retina macs or some older supported setting or system configuration?
Comment 8 Alexey Proskuryakov 2023-03-23 09:03:19 PDT
I don't know if this text smoothing setting still exists. Could indeed be only showing up for non-Retina displays (or even only for CRT displays?!)