openTypeOS2CodePageRanges incorrectly exported

Glyphs
#1

I am aware of Glyph’s own codePageRanges Custom Parameter which, in an exported UFO, is stored in a private lib.plist key. However, I’d like to export a UFO2-compatible font with this information stored in the openTypeOS2CodePageRanges key of fontinfo.plist.

If I add openTypeOS2.CodePageRanges as a Custom Parameter, I can then select the desired codepages. However the exported UFO is incorrectly structured. What I see in fontinfo.plist is:

<key>openTypeOS2CodePageRanges</key>
<array>
	<integer>1252</integer>
	<integer>1256</integer>
</array>

but what I believe I should see is:

<key>openTypeOS2CodePageRanges</key>
<array>
	<integer>0</integer>
	<integer>6</integer>
</array>

The UFO2 fontinfo.plist specification says the value of this key is to be:

A list of bit numbers that are supported code page ranges in the font. The bit numbers are listed in the OpenType OS/2 specification. Corresponds to the OpenType OS/2 table ulCodePageRange1 and ulCodePageRange2 fields.

Glyphs Version 2.4.2 (1038)

1 Like
#2

True. Thanks for pointing it out.

#3

As of 2.5b (1066) this is still an issue.

#4

I fixed it. And unicodeRanges/openTypeOS2UnicodeRanges is handled correctly now, too.

1 Like
#5

On a related note, the “postscriptBlueFuzz” font custom parameter doesn’t get exported as well, it is always exported as 0. It is imported from a UFO but not exported to the font.

#6

BlueFuzz? To my knowledge, it has been long deprecated, and in a compiled font should always be zero. That is why I wrote the BlueFuzzer script for extending and shrinking zones.

#7

Is it deprecated? I didn’t know. Enlarging the zones may give a different result in some cases, because e.g. if there is a point just below a top zone, but is inside the BlueFuzz distance, it gets pulled up to the zone. Enlarging the zone would pull all other points in the zone down when overshoots are suppressed. That may be a visible difference in some sizes.

I used BlueFuzz to fix a rendering issue regarding an OT-CFF font in DirectWrite only recently.

#8

I thought the whole point of BlueFuzz was for testing purposes during development only.

#9

I agree, BlueFuzz is a useful mechanism that cannot be simulated by other means. For example, if the z or f bar is just below the x-height but I still want it to be caught by the zone. Extending the zone downwards would give different results, as Jens noted: All x-height glyphs would become too small (as in: not representing the design as closely as possible) at certain sizes.

#10

By the way, @mekkablue, can you point us to a source that says BlueFuzz is deprecated?

#11

This is contrary to what Adobe says about it:

BlueFuzz has been a convenient means for compensating for slightly inaccurate coordinate data. The effect of a non-zero value for BlueFuzz can usually be better achieved by adjusting the sizes of the alignment zones.

— Type 1 spec, bold by me

Do you have an example where BlueFuzz=1 gives a different result than expanding all zones accordingly?

I was wrong, it is technically not deprecated, but it is not intended for shipping fonts, and is supposed to be set to zero. At least that is how I read it:

Adobe suggests that new font programs not rely on it and disable the feature by explicitly setting BlueFuzz to 0 in the Private dictionary.

#12

I see Tims point. I added that the postscriptBlueFuzz parameter will be exported.

1 Like
#13

Ah, excellent. Thanks Georg.

Seems like BlueFuzz was devised at a time when most fonts were literally digitisations of analogue models, and the outlines were somewhat inaccurate. I don’t agree with the notion that it should be used only for that purpose.

To me, PostScript hinting, just like TrueType hinting, should be treated as a set of (design) tools that can be used actively and purposefully by the font maker. It seems it is regarded as an unwelcome but necessary technicality. Another example is the notion that the “correct” BlueScale value can be determined objectively on the basis of the largest zone, as it is promoted by Adobe. Completely wrong in my opinion: It is a very important tool that allows the designer to control the rendering of the font, and should be set on the basis of visulal judgement, as a design decision.

Maybe we need some education for beginners, and exchange between those who have some experience, on PS-hinting related issues? Seems like no-one is really discussing it.

1 Like