Goudy Old Style font displayed italic
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: duchuan1024, Unassigned)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
I opened pages use goudy old style
Actual results:
All texts in Goudy Old Style displayed italic, while the regular or bold weight is displayed correctly.
Expected results:
display regular typeface.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Could you please give the location of a specific page where you see the issue, and attach a screenshot to show how it appears?
If you run Firefox in Troubleshoot Mode (see the Help menu), does this make any difference to the problem?
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
Reporter | ||
Comment 5•4 years ago
|
||
Reporter | ||
Comment 6•4 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #3)
Could you please give the location of a specific page where you see the issue, and attach a screenshot to show how it appears?
If you run Firefox in Troubleshoot Mode (see the Help menu), does this make any difference to the problem?
I uploaded "test.HTML" written by myself as a testcase, contains diffrent styled texts, and the screenshot. In the upper of the screenshot is firefox 88 64-bit in troubleshot mode (-safe-mode), and the lower part is Chromium-based Edge.
This issue also occured when I used 32-bit firefox.
Comment 7•4 years ago
•
|
||
OK, this was a strange one, but now I understand what's happening. This is a result of the properties of those specific font faces, as found in the 'OS/2' table of the truetype files.
In the Italic file GOUDOSI.TTF, we have
<OS_2>
<version value="1"/>
<xAvgCharWidth value="718"/>
<usWeightClass value="400"/>
<usWidthClass value="5"/>
...etc
while in the normal face GOUDOS.TTF, the corresponding fragment is
<OS_2>
<version value="1"/>
<xAvgCharWidth value="806"/>
<usWeightClass value="400"/>
<usWidthClass value="6"/>
...etc
Both these faces have weight=400 (normal). But notice the usWidthClass
field: the italic face has 5 = Medium (normal), while the non-italic has 6 = Semi-expanded; see https://docs.microsoft.com/en-gb/typography/opentype/spec/os2#uswidthclass.
So the "regular" (upright) face is actually marked as being 'semi-expanded', while the italic is 'normal' width.
Given this, the Firefox behavior is in fact what the CSS Fonts spec requires; the font matching algorithm says that the font-stretch
property is considered first when choosing a face from those available in a given family, before font-style
is matched. In your example, font-stretch
is normal
(the initial value, as nothing else is explicitly set), and the only Goudy Old Style face that matches this value is the italic one. So that's what gets used.
You can confirm this is what's happening by setting font-stretch: semi-expanded
on the testcase; then Firefox will, as requested, find the non-italic face because it matches that font-stretch
value. (But then for the element styled with font-style: italic
, it will still use the "regular" face because font-stretch
takes precedence, and then it'll apply a synthetic oblique effect as there is no actual italic face with this font-stretch
value.)
So in summary, this is not really a bug; it is correct behavior as per CSS Fonts spec, given the peculiar combination of faces in this family.
(I guess these Goudy files come from an older version of Windows? Old Windows versions didn't really support font families with anything more than regular/bold/italic/bolditalic members, so the inconsistency in the fonts wasn't noticed or important. Probably it seemed a good idea to give the italic face a narrower usWidthClass
value than the regular one, because its glyphs are in fact somewhat narrower; but this interacts poorly with the CSS font matching rules now that a much richer model of font families and styles is defined.)
Reporter | ||
Comment 8•3 years ago
|
||
Now I think this issue can be closed.
Updated•3 years ago
|
Description
•