Last Comment Bug 698369 - Font weight of Univers 45 appears to be too heavy
: Font weight of Univers 45 appears to be too heavy
Status: UNCONFIRMED
: fonts
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: 9 Branch
: x86_64 Windows 7
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://jsfiddle.net/CYTdd/9/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-31 04:01 PDT by Steve Workman
Modified: 2011-11-01 10:54 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case image for font type comparison (343.77 KB, image/png)
2011-10-31 04:01 PDT, Steve Workman
no flags Details
Changes seen when using font-face rule for local fonts (155.94 KB, image/png)
2011-10-31 04:37 PDT, Steve Workman
no flags Details
Test case HTML for font-face vs font-family rendering (1.46 KB, text/html)
2011-10-31 06:54 PDT, Steve Workman
no flags Details

Description User image Steve Workman 2011-10-31 04:01:58 PDT
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.
Comment 1 User image Steve Workman 2011-10-31 04:05:43 PDT
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
Comment 2 User image Steve Workman 2011-10-31 04:37:59 PDT
Created attachment 570650 [details]
Changes seen when using font-face rule for local fonts
Comment 3 User image Jonathan Kew (:jfkthame) 2011-10-31 04:49:30 PDT
Please attach a complete testcase - it's not entirely clear to me what CSS properties you're setting in each case.
Comment 4 User image Jonathan Kew (:jfkthame) 2011-10-31 04:59:47 PDT
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.)
Comment 5 User image Steve Workman 2011-10-31 06:35:51 PDT
(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:
Comment 6 User image Steve Workman 2011-10-31 06:54:10 PDT
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
Comment 7 User image Jonathan Kew (:jfkthame) 2011-10-31 09:37:33 PDT
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?
Comment 8 User image Steve Workman 2011-11-01 10:03:38 PDT
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 User image Bram Pitoyo [:bram] 2011-11-01 10:54:04 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.