Closed Bug 1710965 Opened 4 years ago Closed 3 years ago

Goudy Old Style font displayed italic

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 88
Desktop
Windows 10
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: duchuan1024, Unassigned)

Details

Attachments

(4 files)

Attached file GOUDOS.TTF

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.

Attached file GOUDOSI.TTF

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.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Component: CSS Parsing and Computation → Layout: Text and Fonts

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?

Flags: needinfo?(duchuan1024)
Flags: needinfo?(duchuan1024)
OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop
Attached file test.HTML
Attached image sccreenshot.png

(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.

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.)

Now I think this issue can be closed.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: