Adobe's Source Sans Pro

[Dave Crossland]

http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html

[vern adams]

:) OFL'd too. That's really quite something.

Will make a very handy resource.

Would be very handy if the source fonts were in ufo too.

-v

Post by Dave Crossland
http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss

[Dave Crossland]

Post by vern adams
Would be very handy if the source fonts were in ufo too.

I don't think Adobe uses a UFO based workflow ;p

[Alexandre Prokoudine]

Post by Dave Crossland

Post by vern adams
Would be very handy if the source fonts were in ufo too.

I don't think Adobe uses a UFO based workflow ;p

Are you by any chance referring to a particular lizard that was last
seen running freely in 90s? :)

Speaking of OFL typefaces, Jovanny just announced availability of
Oranienbaum, a new ultracontrast antiqua.

http://jovanny.ru/eng-free-fonts.html

Alexandre Prokoudine
http://libregraphicsworld.org

[Alexandre Prokoudine]

Post by Dave Crossland
http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html

Okay, this is becoming extremely puzzling.

According to metadata:

- typefaces were made by Ascender Corporation
- the license is Apache v2.0
- Open Sans is a trademark of Google and may be registered in certain
jurisdictions.
- Digitized data copyright © 2010-2011, Google (not 2012-2012)

The blog posting doesn't mention any of that. What gives?

Alexandre Prokoudine
http://libregraphicsworld.org

[Dave Crossland]

On 2 August 2012 13:40, Alexandre Prokoudine
What metadata?

[Alexandre Prokoudine]

Post by Dave Crossland
On 2 August 2012 13:40, Alexandre Prokoudine
What metadata?

Oh, please ignore it. I'm a doofus :)

Alexandre Prokoudine
http://libregraphicsworld.org

[Dave Crossland]

Haha damn you that would have been my fault if it was messed up! XD

[Alexandre Prokoudine]

Post by Dave Crossland
Haha damn you that would have been my fault if it was messed up! XD

BTW, it's the first time I noticed this: is Pango really uncapable of
seeing Extra Light weights?

More than that, it renames weights. E.g. in both Inkscape and GIMP, I
get Heavy instead of Black.

Alexandre Prokoudine
http://libregraphicsworld.org

[Khaled Hosny]

Post by Alexandre Prokoudine

Post by Dave Crossland
Haha damn you that would have been my fault if it was messed up! XD

BTW, it's the first time I noticed this: is Pango really uncapable of
seeing Extra Light weights?
More than that, it renames weights. E.g. in both Inkscape and GIMP, I
get Heavy instead of Black.

That would be FontConfig not Pango.

Regards,
Khaled

[Alexandre Prokoudine]

Post by Khaled Hosny

Post by Alexandre Prokoudine

Post by Dave Crossland
Haha damn you that would have been my fault if it was messed up! XD

BTW, it's the first time I noticed this: is Pango really uncapable of
seeing Extra Light weights?
More than that, it renames weights. E.g. in both Inkscape and GIMP, I
get Heavy instead of Black.

That would be FontConfig not Pango.

Hmmm, grepping /etc/fonts doesn't return anything related

Alexandre Prokoudine
http://libregraphicsworld.org

[Khaled Hosny]

Post by Alexandre Prokoudine

Post by Khaled Hosny

Post by Alexandre Prokoudine

Post by Dave Crossland
Haha damn you that would have been my fault if it was messed up! XD

BTW, it's the first time I noticed this: is Pango really uncapable of
seeing Extra Light weights?
More than that, it renames weights. E.g. in both Inkscape and GIMP, I
get Heavy instead of Black.

That would be FontConfig not Pango.

Hmmm, grepping /etc/fonts doesn't return anything related

I wouldn't expect to find anything useful there (that logic is in the
library itself).

Using fc-query, it reports the same weight value for Light and Extra
light fonts (50). Looking into the fonts OS/2 table, the Extra Light has
weight value of 250 (not sure about the exact relation between FC weight
and OS/2 one) while FontForge's predefined values suggest 200 for Extra
Light, which corresponds to OS/2 table documentation:
http://www.microsoft.com/typography/otspec/os2.htm#wtc

So I'd say it is a font bug (might be a FontConfig limitation as well, I
have some vague recollection about some discussion somewhere on whether
OS/2 weight must be multiples of 100 or not).

fc-query reports Black weight not Heavy.

(I didn't installed the fonts, just using fc-query on the downloaded
files).

Regards,
Khaled

[Khaled Hosny]

Post by Khaled Hosny
So I'd say it is a font bug (might be a FontConfig limitation as well, I
have some vague recollection about some discussion somewhere on whether
OS/2 weight must be multiples of 100 or not).

http://lists.w3.org/Archives/Public/www-font/2011JanMar/0042.html

(check the whole thread)

Regards,
Khaled

[vern adams]

That's right (i think) the usWeightClass in OS/2 tables must be multiples of 100. Source Sans Extra Light has a value of 250. The value should be 200, as the Light version is already 300.
-v

Post by Khaled Hosny
So I'd say it is a font bug (might be a FontConfig limitation as well, I
have some vague recollection about some discussion somewhere on whether
OS/2 weight must be multiples of 100 or not).

[Alexandre Prokoudine]

Okay, I pinged Paul via Twitter about that. Thanks for the hint!

Alexandre

Post by vern adams
That's right (i think) the usWeightClass in OS/2 tables must be multiples of
100. Source Sans Extra Light has a value of 250. The value should be 200, as
the Light version is already 300.
-v
So I'd say it is a font bug (might be a FontConfig limitation as well, I
have some vague recollection about some discussion somewhere on whether
OS/2 weight must be multiples of 100 or not).

[Denis Jacquerye]

OpenType allows weight values from 1 to 999.
CSS is the one rounding those to multiples of 100 from 100 to 900.
Fontconfig maps them to some range from 0 to 210 (I'm not sure there).
Fontconfig also has multiple aliases for its weight value 40:
extralight or ultralight, and its weight value 210: black or heavy. So
applications just using those values to name variants might not match
the OT names.

On Fri, Aug 3, 2012 at 10:42 AM, Alexandre Prokoudine

Post by Alexandre Prokoudine
Okay, I pinged Paul via Twitter about that. Thanks for the hint!
Alexandre

Post by vern adams
That's right (i think) the usWeightClass in OS/2 tables must be multiples of
100. Source Sans Extra Light has a value of 250. The value should be 200, as
the Light version is already 300.
-v
So I'd say it is a font bug (might be a FontConfig limitation as well, I
have some vague recollection about some discussion somewhere on whether
OS/2 weight must be multiples of 100 or not).

--
Alexandre Prokoudine
http://libregraphicsworld.org

[vern adams]

It's a bad OS/2 usWeightClass value (nothing to do with CSS). So, the '250' is getting rounded up to '300' and therefore clashing with the Light version which already has WeightClass of 300.
I think it's simple human error; the usWeightClass in the 'font.ttf' that Adobe have included with the source of Source Sans Extra Light is '200'.
Also, some of the fonts have fsType of 0x0004 (Documents containing Preview & Print fonts must be opened "read-only;" no edits can be applied to the document), but i assume Adobe means all the Source Sans fonts should be set to 0x0000.
-v

Post by Denis Jacquerye
OpenType allows weight values from 1 to 999.
CSS is the one rounding those to multiples of 100 from 100 to 900.
Fontconfig maps them to some range from 0 to 210 (I'm not sure there).
extralight or ultralight, and its weight value 210: black or heavy. So
applications just using those values to name variants might not match
the OT names.

[John Haltiwanger]

Post by vern adams
It's a bad OS/2 usWeightClass value (nothing to do with CSS). So, the
'250' is getting rounded up to '300' and therefore clashing with the Light
version which already has WeightClass of 300.
I think it's simple human error; the usWeightClass in the 'font.ttf' that
Adobe have included with the source of Source Sans Extra Light is '200'.
Also, some of the fonts have fsType of 0x0004 (Documents containing
Preview & Print fonts must be opened "read-only;" no edits can be applied
to the document), but i assume Adobe means all the Source Sans fonts
should be set to 0x0000.
-v

And (finally) we are legally allowed to fix a broken element in an Adobe
font!

[Denis Jacquerye]

Post by vern adams
It's a bad OS/2 usWeightClass value (nothing to do with CSS).

Where do you get that from?
The specs http://www.microsoft.com/typography/otspec/os2.htm do not
specify such restriction on usWeightClass, even if it describes
specific values. Microsoft and Adobe frequently talk about a 1 to 999
range (see http://blogs.adobe.com/typblography/atypi2006/CSS%20%26%20OT%2015.pdf
or http://msdn.microsoft.com/en-us/library/system.windows.fontweights.aspx).

Post by vern adams
So, the '250'
is getting rounded up to '300' and therefore clashing with the Light version
which already has WeightClass of 300.
I think it's simple human error; the usWeightClass in the 'font.ttf' that
Adobe have included with the source of Source Sans Extra Light is '200'.

The 250 is common practice, not human error. See
http://www.adobe.com/devnet/opentype/afdko/topic_font_wt_win.html

Post by vern adams
Also, some of the fonts have fsType of 0x0004 (Documents containing Preview
& Print fonts must be opened "read-only;" no edits can be applied to the
document), but i assume Adobe means all the Source Sans fonts should be set
to 0x0000.
-v
OpenType allows weight values from 1 to 999.
CSS is the one rounding those to multiples of 100 from 100 to 900.
Fontconfig maps them to some range from 0 to 210 (I'm not sure there).
extralight or ultralight, and its weight value 210: black or heavy. So
applications just using those values to name variants might not match
the OT names.

[vern adams]

You can use whatever value you like, BUT, Thin=100, ExtraLight = 200, Light=300 etc etc
So if you create a font with a usWeightClass of 250 it's neither ExtraLight or Light, but some software will need to know which it is and decide :)
Hence, it's a good idea to stick with a multiple of 100.
An app like DTL's OpenTypeMaster flags non multiples of 100 as 'invalid usWeightClass'

-v

Post by Denis Jacquerye

Post by vern adams
It's a bad OS/2 usWeightClass value (nothing to do with CSS).

Where do you get that from?
The specs http://www.microsoft.com/typography/otspec/os2.htm do not
specify such restriction on usWeightClass, even if it describes
specific values. Microsoft and Adobe frequently talk about a 1 to 999
range (see http://blogs.adobe.com/typblography/atypi2006/CSS%20%26%20OT%2015.pdf
or http://msdn.microsoft.com/en-us/library/system.windows.fontweights.aspx).

[Dave Crossland]

Post by vern adams
An app like DTL's OpenTypeMaster flags non multiples of 100 as 'invalid usWeightClass'

That's a web specification, and this is (like vertical metrics) a
situation where you can't make a good tradeoff, the metadata either
has to be set for the web or for the desktop.

As Denis said, 250 is a legacy Windows workaround -
http://www.adobe.com/devnet/opentype/afdko/topic_font_wt_win.html -

The fonts in GWF have 100s values.

[Dave Crossland]

Post by vern adams
some of the fonts have fsType of 0x0004 (Documents containing Preview &
Print fonts must be opened "read-only;" no edits can be applied to the
document), but i assume Adobe means all the Source Sans fonts should be set
to 0x0000.

Really?

$ for i in `ls -1 *ttf`; do showttf $i | grep -i fst; done
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0

[vern adams]

ah it's the font files called 'font.ttf' in each weight that seem to have fstype 0x0004.
I guess they don't count. My mistake ;p

Post by Dave Crossland

Post by vern adams
some of the fonts have fsType of 0x0004 (Documents containing Preview &
Print fonts must be opened "read-only;" no edits can be applied to the
document), but i assume Adobe means all the Source Sans fonts should be set
to 0x0000.

Really?
$ for i in `ls -1 *ttf`; do showttf $i | grep -i fst; done
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0
fstype=0x0

[Khaled Hosny]

Don't be so sure:
http://www.adobe.com/devnet/opentype/afdko/topic_font_wt_win.html

Post by vern adams
It's a bad OS/2 usWeightClass value (nothing to do with CSS). So, the '250' is
getting rounded up to '300' and therefore clashing with the Light version which
already has WeightClass of 300.
I think it's simple human error; the usWeightClass in the 'font.ttf' that Adobe
have included with the source of Source Sans Extra Light is '200'.
Also, some of the fonts have fsType of 0x0004 (Documents containing Preview &
Print fonts must be opened "read-only;" no edits can be applied to the
document), but i assume Adobe means all the Source Sans fonts should be set to
0x0000.
-v
OpenType allows weight values from 1 to 999.
CSS is the one rounding those to multiples of 100 from 100 to 900.
Fontconfig maps them to some range from 0 to 210 (I'm not sure there).
extralight or ultralight, and its weight value 210: black or heavy. So
applications just using those values to name variants might not match
the OT names.

[Nicolas Mailhot]

Post by Denis Jacquerye
OpenType allows weight values from 1 to 999.
CSS is the one rounding those to multiples of 100 from 100 to 900.
Fontconfig maps them to some range from 0 to 210 (I'm not sure there).
extralight or ultralight, and its weight value 210: black or heavy. So
applications just using those values to name variants might not match
the OT names.

The canonical weights and names have been defined by Microsoft at Vista
time in

http://web.archive.org/web/20100311051429/http://blogs.msdn.com/text/attachment/2249036.ashx

There is one *50 weight there (ExtraBlack)

The canonical name for ultra light is ExtraLight

IIRC fontconfig constants originated in this paper once upon a time