rsms
Printing issues with Microsoft Word
The bug I face a stange error when it's come to print with the Inter v3.5. and my custom version too. The printed text does not look the one in Word the leading is good but the letters are bigger and the metrics are not respected. Same error on Pages. It seems the font is not propelly interpreted by a printer.
Here is a preview with my custom version :
To Reproduce Steps to reproduce the behavior:
-
Compose my text on Word it looks ok here
-
Sent to print from Word on a postscript printer
-
No issues when I make a PDF
-
No issues with an other fonts
Expected behavior The printing should look like the composition in Word
Screenshots If applicable, add screenshots to help explain your problem.
Environment
- macOS 10.11.6
- App that renders the font Microsoft Word 15.13.3 and Pages 5.6.2
- Version of font "Inter Regular 3.0v5"
All best
This is really strange — it seems like a bug in Word to me. Exactly which font files do you have installed?
I printed the default sample text from rsms.me/inter/lab using Apple Pages 8.0 with Inter Regular 3.5 OTF installed to a CUPS-connected postscript laser printer. It looks correct to me.
Have you tried printing with a different printer? Could it be a printer issue..? I only have one printer at home, but I can try on a few other printers at the office next week.
Hi Rasmus, thanks for your answer, here is a new test. I have a Post-script Printer (HP LaserJet 5200tn). The SF pro text look the same no matter the technique. The Inter look différent, the metrics values are changed and the size too.
Hypothesis :
- The Post-script printer does not interpretate the right metrics value. Is there in the font file a default metrics value ?
- Units per EM (2816) is too big for a good Postscript interpretation.
Very interesting. SF Pro Text looks different in your prints as well, though less difference. Spacing is different and stroke weight seems to vary a little. Wonder if Word does something crazy, maybe Windows GDI -> PostScript translation?
The PDF is of course postscript, so if printing the PDF on the same printer yields expected results, then this means that Word produces different PostScript code depending on if you print or generate a PDF (and thus, this is a bug in Word.)
I think the variation in SF pro is due to the size and printing speed. If I put the two layers on top of each other the SF look quiet similar.
Next week I will check with an other version of Word.
@rsms Current Word uses DirectWrite everywhere (yes they ported DWRITE), but I have no idea how Word 15 on Mac works. There's maybe something wrong with the PPEM, like rounding error?
@superpapuche Could you please provide more detail. like:
- Which Inter version
- Which variant (TTF vs OTF vs VAR)
- Does this bug reproduce on latest O365 Word? If so, what is the version number of it?
We're also experiencing this at our company. We printed something yesterday, and the letter-spacing/kerning was too tight. Our marketing designer is on a Mac, so maybe its Word for Mac? I'll ask her to upload a photo of the print too.
@jaminroe What happens if you print to the same printer from TextEdit on that same Mac computer?
@jaminroe What happens if you print to the same printer from TextEdit on that same Mac computer?
Sorry I never got back to you. I'll follow up with you later this week. Will ask our marketing designer again too.😊
To add... We also get considerably tighter kerning printing directly from Pages v8 and TextEdit on High Sierra 10.13.6.
- Font we use is Inter Version 3.011;git-f93a4a705 (non-variable)
- Printer is HP LaserJet 1320
To add... We also get considerably tighter kerning printing directly from Pages v8 and TextEdit on High Sierra 10.13.6.
- Font we use is Inter Version 3.011;git-f93a4a705 (non-variable)
- Printer is HP LaserJet 1320
You should try the latest release. You're behind quite a few versions! 3.11 is the latest. 😄
...
- Font we use is Inter Version 3.011;git-f93a4a705 (non-variable) You should try the latest release. You're behind quite a few versions! 3.11 is the latest. 😄
Checked. This should be the latest version. 3.11 zip release (12 days ago) contains otf files labelled version 3.011, created 22 Oct 2019. Release 3.10 contains otf files font version 3.010. This did not seem problematic knowing font versioning numbers.
...
- Font we use is Inter Version 3.011;git-f93a4a705 (non-variable) You should try the latest release. You're behind quite a few versions! 3.11 is the latest. smile
Checked. This should be the latest version. 3.11 zip release (12 days ago) contains otf files labelled version 3.011, created 22 Oct 2019. Release 3.10 contains otf files font version 3.010. This did not seem problematic knowing font versioning numbers.
Oh interesting, I'll need to check my files later when I'm back in the office. I have seen Font Book not update the version if you just try to install and override your current version installed. I've had to delete the Inter font in Font Book and then install fresh with the lastest version.
I'm guessing you're taking about the file names though in the zip file?
Zip file from Releases page here on GitHub is named 'Inter-3.11.zip'. Unzipped, in Finder/File info, says: Version 3.011;git-f93a4a705. Using non-variable fonts.
Version number did not seem alarming. Considering font versioning goes X.000 to X.999, version 3.011 seemed equivalent to 3.11. I might be wrong, of course. ... It is not 3.0.11, or 3.110 either ;). Plus, 'created' date seemed fine.
- Fonts have been deleted from FontBook prior to installing fonts from 3.11 zip.
- Just in case, font caches have been cleared this way and Mac restarted. Still, FontBook says: Version 3.011;git-f93a4a705
Additionally, Affinity Designer printing directly to HP LaserJet 1320 (PostScript, I believe) exhibits the same issue.
Might be wrong but, I have seen a similar glitch using multiple master fonts before. The big difference here is that with a multiple master font wrong kerning was visible on screen, too. With this issue, conventional fonts are used and on screen appearance is flawless, while printing is tight.
XXL 'Thank you' for quick replies and making/opening Inter!
Test. Printing the same file... OK on inkjet OfficeJet Pro 8100 (above), tight on LaserJet (below). Funny, after measuring printouts it seems that the overall line length stays the same but the glyphs are bigger on laser.
Ah okay yes I see! The web font is a different version that the OTF :ok_hand:
@rsms our marketing designer did a print yesterday and good news, the kerning seemed to be fixed! 🙌
- The version of Inter is
3.011 - MS Word is
16.30 - Mac with OS
10.14.16
@rsms @megaroeny I just try a new print I have the same issue.
- Inter is
3.011 - MS Word is
16.16 - Mac with OS
10.11.6
As I see it it's neither a Kerning problem nor a spacing one. But the glyphe get bigger in the same box.
I have the same issue on Mac, but does not occur on Windows. Printing from MS Word on Windows renders the font properly, but incorrectly on Mac.
Mac settings: OS 10.14.16, MS Word 16.31 Windows settings: Windows 10, MS Word 365 Pro Plus 1902
Additionally, when printing from Mac MS Word, one of our office printers that runs through a Fiery server threw a font error instead of printing a document (Ricoh Pro C5200 Series E-24B)
ERROR: invalidfont
OFFENDING COMMAND: definefont
STACK:
/Font
-dictionary-
/IHTAOE+Inter-Regular
For the time being, I'll be printing PDFs from a Mac, which obviously renders correct prints.
Considering font versioning goes X.000 to X.999, version 3.011 seemed equivalent to 3.11.
You're correct. The OpenType spec has many weird things; the version metadata is one of them where the word “Version” is actually part of the value in the spec! Ha, ha. The use of exactly 3 ASCII numbers following the “.” after the major version ASCII digit number is a convention that some legacy font interpreters rely on, thus it’s a requirement by Google Fonts (my understanding.)
https://docs.microsoft.com/en-us/typography/opentype/spec/name#nid5
By the way, thank you all so much for investigating this issue. It does seem like a potential bug in Microsoft Word for Mac. I’m not sure what we could do with Inter, and even if we could, if we should.
I just learned that @arrowtype had a similar issue and decomposing nested components was an acceptable solution.
I've applied the same method to Inter and attached here is a build of font files which would be great if you could try these and see if they print correctly: cc @YorelCayla @creative-pfnyc @alex-kovac
Inter-3.15-text-b4f4ad1aea.zip
The issue I experienced in Recursive was slightly different – for me, the biggest problem was that nested/scaled/flipped components weren’t being placed correctly. Generally, they were way to the left of where they should have been. This also impacted ligatures like f_i, because these used nested components (like the idotless, via i). https://github.com/arrowtype/recursive/issues/412
This could be the same issue here, and because I had problems with nested components through multiple printers, it is definitely something I think is worth fixing.
However, if I had to guess, I bet this specific issue might be caused by something else. I know the UPM of Inter is kind of unique ... have you tested whether it makes any difference to have a more-common UPM, like 1000, 2000, or 2048?
A colleague suggested that it's possible it might have something to do with the different ways platforms define the size of a "point". Not sure how likely that is, but it seems reasonable. I wonder if this is happening to fonts besides Inter...
https://github.com/w3c/csswg-drafts/issues/4430
@arrowtype re UPM, InterDisplay uses 2048 so that would be an interesting thing to test; ie use Inter and Inter Display with the same software and compare the results. I would be surprised if the UPM mattered. The whole point with a local coordinate system is so that it can vary :-)
Just finished reading the CSS conversation. pt as in typographic points are tricky indeed in a web browser since currently web browsers don't know about the physical size of your displays pixels, which it would need to do in order to provide accurate typographic pt (I say typographic pt here to disambiguate from other pt like for example what Apple iOS and macOS uses.) CSS already has its funky "pixels" (really, dp, but named px for historical reasons) which is what web developers use as the "millimeter" of their world, for better and for worse. Mapping 1 css pixel to 1 optical size unit makes a lot of sense to me (and I totally see ppls point about wanting to map it to pt instead but maybe not in web browsers.)
@rsms, Thank you for test files.
Something changed. Comparing Inter V Extra Light and Inter Extra Light fonts, printing directly to LaserJet from Apple Pages; I can report that Inter V Extra Light seems to print correctly while Inter Extra Light is displaying the same unwanted glyph growth like before :).
@rsms thanks for the insights! So, it seems like you have never really encountered issues with a non-standard UPM? If so, it’s nice to learn that it might be a piece of "dogma" that isn’t as important as it would seem to be.
Re: CSS px and optical sizing ... that compromise would almost be okay, if it weren’t the case that it goes in the wrong direction. I.e. 12px in css would be needed to show the 12pt opsz, but 12px in CSS is smaller than 12pt be in print – despite screens almost always having a lower resolution than print – and so 12px in CSS would actually benefit from smaller opsz values rather than larger. It’s somewhat alright if it is fuzzy, but a shame if it’s fuzzy in the wrong direction. But, you already know that, and that’s another conversation anyway. 😄
So, it seems like you have never really encountered issues with a non-standard UPM? If so, it’s nice to learn that it might be a piece of "dogma" that isn’t as important as it would seem to be.
Yeah, I haven't run in to any issues that seems related to Inter's non-standard UPM over the years. I'd be surprised if there were issues though since all implementations need to multiply coordinates with a font's UPM anyway to support the two most common values 1000 and 2040. None of those values yield perfect results though and always ends up with fractions so implementations would need to handle that no matter what, which is why I'd be surprised if there was a "fast path" dedicated to—for example—2048.
A UPM of 2816 is great for Inter since that means that its cap height is exactly 2048 units (64× 32-unit squares) and its x-height is 1536 (48× 32-unit squares) which both makes the design easier (can deal with only integers, never any fractions, plus use a perfect grid) and it makes the target "small size" of 11dp a pixel-perfect match — at 11px rasterization 1 pixel is exactly 256 units in the design! At 11dp with a 2x scaling factor 1 pixel is 128 units, 64 units at a 3x scaling factor and so on. This makes it feasible to really tune Inter for detailed rasterization.
