Font weight of Univers 45 appears to be too heavy

UNCONFIRMED
Unassigned

Status

()

Core
Layout: Text
UNCONFIRMED
6 years ago
6 years ago

People

(Reporter: Steve Workman, Unassigned)

Tracking

({fonts})

9 Branch
x86_64
Windows 7
fonts
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 570638 [details]
Test case image for font type comparison

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.15 Safari/535.7

Steps to reproduce:

I have the Univers 45 Light and Univers 55 fonts installed on this Windows 7 computer. I used these fonts on a web site and compared their font renderings of each weight, including bold.


Actual results:

The Univers 45 normal weight appeared to be heavier than the Univers 55 weight. It looks like the bold font is being used where the regular one should be used


Expected results:

The Light font should have been rendered, which is lighter than the Univers 55 used for comparison.

I've also tested this in IE10pp2, Chrome 16 and IE8. IE10, which also has GPU accelerated type, appears to have the same problem. Chrome 16 and IE8 show the correct font.
(Reporter)

Updated

6 years ago
Keywords: fonts
(Reporter)

Comment 1

6 years ago
Test case: http://jsfiddle.net/CYTdd/

Note, you must have the Univers 45 Light, Univers 45 Light Oblique, Univers 55 and Univers 55 Oblique fonts installed on the computer
(Reporter)

Comment 2

6 years ago
Created attachment 570650 [details]
Changes seen when using font-face rule for local fonts
Please attach a complete testcase - it's not entirely clear to me what CSS properties you're setting in each case.
Note that the @font-face rules shown in your second image are incorrect (e.g. 'src: "Univers 55"' is invalid; did you mean "src: local('Univers 55')"?), and as a result you're not getting Univers at all in some of those examples, you're getting fallback to the default sans-serif font, probably Arial. Look at the shape of the "5", for example.

Also note that under the DirectWrite model, font families are organized differently from the old GDI model. Family names like "Univers 45 Light" are not generally used; instead, all the faces belong to a single family, with distinct font-weight values. (But I haven't examined the Univers family to see exactly how they're organized.)
(Reporter)

Comment 5

6 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> Note that the @font-face rules shown in your second image are incorrect
> (e.g. 'src: "Univers 55"' is invalid; did you mean "src: local('Univers
> 55')"?), and as a result you're not getting Univers at all in some of those
> examples, you're getting fallback to the default sans-serif font, probably
> Arial. Look at the shape of the "5", for example.
> 
> Also note that under the DirectWrite model, font families are organized
> differently from the old GDI model. Family names like "Univers 45 Light" are
> not generally used; instead, all the faces belong to a single family, with
> distinct font-weight values. (But I haven't examined the Univers family to
> see exactly how they're organized.)

Thanks Jonathan:
(Reporter)

Comment 6

6 years ago
Created attachment 570689 [details]
Test case HTML for font-face vs font-family rendering

Note the difference in rendering when the font is included as font-face (i.e. correctly) compared to attached simply by font-family.

This test case is on JSFiddle: http://jsfiddle.net/CYTdd/6/

The Univers font can be licensed from http://www.linotype.com/1560/univers-family.html
Attachment #570689 - Attachment mime type: text/plain → text/html
And what does that testcase look like on screen?

The @font-face and non-@font-face cases there aren't comparable. When you say
  font-family: "Univers 55";
without the use of @font-face, you're requesting that _font family_, which may have multiple faces with different weights. What you'll get when you use font-weight:bold along with this depends which faces have been grouped under that family name - which may well differ between GDI and DirectWrite environments. And if there's no "bold" face in the family, then the browser will artificially "embolden" the text. (You can tell exactly which font is really being displayed using the "font-info" add-on, btw.) I suspect you might get a true bolder face in one case and synthetic bold in the other, but that depends very much on the structure of the font families you're using.

In the @font-face case, you're defining your own font families (independently of how the OS or the font designer organized things), and your CSS only assigns them a single (normal-weight) face each, which means that when your styles ask for font-weight:bold, you should be getting synthetic emboldening rather than a real face with a heavier weight.

To see what faces are supposed to be available within each family, look in the Windows Fonts folder - IIRC, this should reflect the DirectWrite organization of the fonts. Do you see separate "Univers 45" and "Univers 55" families? What faces exist in each?
(Reporter)

Comment 8

6 years ago
I've given as much detail as I can in this blog post: http://www.steveworkman.com/html5-2/html5-css3/2011/problems-loading-local-fonts-with-font-family/

It looks like my issues with font-family are unfounded. However, there are differences between Firefox and IE10 when addressing the font file using @font-face. From my test Firefox looks for the Title property in the font properties, and IE10 looks at the font name in the file system (see the images in the blog post).

Which of these implementations matches the spec?

Comment 9

6 years ago
There are a few potential areas of problem:

1. The font foundry generates different “Name” and “PostScript Name” for the same file. The font could have “Univers 55 Normal” as name, but “Univers 55 Roman” as PostScript name. The font could have “Univers 55 Black” as name, but “Univers 85 Black” as PostScript name.

2. The OS either couldn’t handle misnaming and reports of naming conflict, or DirectDraw’s implementation in Windows 7 has a bug (Steve tweeted that he didn’t see the same problem in XP).

3. The browser couldn’t handle naming conflict, which in this case could be a legitimate bug. Perhaps Firefox could recognize any name that user calls a font, as long as that name exist somewhere within the font metadata.
You need to log in before you can comment on or make changes to this bug.