Glyphs-output > ERROR: invalidfont

I exported a correct OTF-data from Glyphs, but some customer got problems with it:

Errors
TextEdit (OS X 10.9.5) OR
MSWord2010 (OS X10.8) OR
Pages (5.5.2 2120 + Yosemite) OR
keynote (6.5.3 +Yosemite) OR

=

ERROR: invalidfont OFFENDING COMMAND: definefont
STACK:
/Font-dictionary- /MCLEPS+MyFont-Bold

— Problem seems to be the Bold weight/instance
— On OS X 10.10 the Bold weight can be printed without any error.

Glyphsfile (e xported by Version 2.0.1 (754) )
— global parameter “Family Alignment Zones”
— per master some vertical metrics parameters like “winAscent”
— per instance “rename Glyphs” “remove Glyphs”
— stylelinked the “bold” as “bold to Regular”
— also used some “TTFAutohint options” (guess not relevant to OTF export)

Also tried to remove the “Compatible Name Table” but error still present.

Any Idea how to solve this — thought that an Export without any erros will create well working font-files.

could you send me the .glyphs file?

The fonts work fine for me. I tested on 10.9.5 and 10.10.3, Textedit, Pages and Word 2011. Can you reproduce the problem?

thank you georg!

problems were reported by two different users.
christoph koeberlin checked them to, without any solutions either.

seems to be a problem of the printers (xerox and some brand I do not know)

Hi Jakob, Georg,

I hope all is well with you guys!

We have just got a new Xerox printer here and have run into the same PS ‘Invalidfont’ errors with a new font that I am testing. I have tested the same font on an HP printer without any issue. Did you or your client ever find a solution?

The issue occurs when printing OTFs from MS Word and Pages on a Xerox printer.
TTF’s print as expected as do older fonts exported from Fontlab. :grimacing:

Any help or further insight would be greatly appreciated.
Phil

What exactly is the error message/offending command on the printer? Also definefont?

No message on the printer display itself, it simply prints a page with this error set in Courier:

ERROR: invalidfont
OFFENDING COMMAND: definefont
STACK:
/Font
-dictionary-
/ZYZKXU+FontName-Regular

Any thoughts?

Could you send me one of the .otf.

There is something similar on the Xerox forum, is the font embeddable?

@mekkablue I have seen this post but I am unable to follow these steps as the options don’t exist for our printer — Xerox Phaser 7500. Our IT guy is going to hopefully run a firmware update on the printer next week. Will update here if it resolves the issue.

@GeorgSeifert I’m sending the otf files over to your gs email. Thanks for taking a look!

An update on this issue —

I’m finding that OTF’s that were generated with Glyphs 2.2 (827) — 2.3 (895) are printing just fine on a Xerox printer. But all OTF fonts that were generated in Glyphs 2.1 and Glyphs 2.4 (Nov’16) — 2.4.4 (Nov’17) will display the postscript error message.

@GeorgSeifert did you manage to have a look at the otfs I sent on Friday?

Tomorrow our studio IT chap will be updating the firmware on the printer.
I’ll let you know whether this resolves the problem of printing OTFs from MS Word/Apple Pages on a Xerox printer.

I’m teaching a workshop right now. I have a look as soon as possible. If you could also send me a working font, that might help figuring this out.

Hi, I think we may have resolved the problem this evening. There was a duplicate value in the Horizontal PS Stem settings. We removed the duplicate and printed 1 weight of the family successfully. Perhaps the Xerox Phaser PS Print Driver is sensitive to hint stem settings. I didn’t have time to test the whole family so will confirm if the issue is resolved tomorrow. Thanks!

1 Like

I would have looked exactly in this area of the font file. There is a ‘font dictionary’ and it contains the hinting settings. This is good to know.

Hi folks, this issue is now resolved :smile: These are @ammazzarella and my learnings…

A Xerox Phaser PS Print Driver requires that PS Stem settings must be defined in an increasing value order across all Masters and you cannot duplicate stem values at all.

The number of values is irrelevant, you don’t need to have a consistent set across masters, but they must be in the right order as shown here:

1 Like

Increasing order is what the Type1 specification demands:

The entry StemSnapH is an array of up to 12 real numbers of the most common widths (including the dominant width given in the StdHW array) for horizontal stems (measured vertically). These widths must be sorted in increasing order. For example:
/StemSnapH [32 41] def

Amazing, thank you for the detective work and the feedback!

I will add that to the Handbook and the tutorials. Does this include StdHW and StdVW somehow? Or can these values be smaller, larger, somewhere in between and even the same as the StemSnap values?

1 Like

The requirement of the Xerox driver is what the Type1 spec requires anyway, so Glyphs could sort the values correctly no matter the order they are entered. I think Glyphs uses the first value for StemHW and this plus the other values for StemSnapH (Same for StemVW and StemSnapV). It would just need to sort the StemSnapH and StemSnapV values when exporting the font. The StemHW/StemVW value must also be part of the StemSnapH/StemSnapV lists.

Example:

Glyphs:
Vertical Stems: 90 86 82 92 100 60

Font:
StemVW: 90
StemSnapV: 60 82 86 90 92 100

1 Like

Totally agree with @jkutilek. Sorting the values on export will resolve the problem for those unaware of the issue.
The handbook update will certainly help too.

Thanks for the feedback. I fixed it.

1 Like