Comment 23 for bug 199331

That still doesn't answer the question why fontforge now sets Latin1 *and*
Symbol bits in the ulCodePageRange1 fileld in the OS2 TrueType header, while
previously it only set the Symbol one.

At the very least there should be a way to tell fontforge what code page
bits should be set in the ulCodePageRange1 fileld, and relying on the file
extension looks wrong to me.

Also, there is a thing called backwards compatibility. A behaviour of
fontforge that was valid for years now suddenly called broken, making
previously valid .sfd files useless.