Printing issues with Microsoft Word

[YorelCayla]

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:

1. Compose my text on Word it looks ok here

2. Sent to print from Word on a postscript printer

3. No issues when I make a PDF

4. 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

[rsms]

This is really strange — it seems like a bug in Word to me. Exactly which font files do you have installed?

[rsms]

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.

[YorelCayla]

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 :

1. The Post-script printer does not interpretate the right metrics value. Is there in the font file a default metrics value ?
2. Units per EM (2816) is too big for a good Postscript interpretation.

[rsms]

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.)

[YorelCayla]

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.

[reli-msft]

@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?

[megaroeny]

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.

[rsms]

@jaminroe What happens if you print to the same printer from TextEdit on that same Mac computer?

[megaroeny]

@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.😊

[alex-kovac]

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

[megaroeny]

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. 😄

[alex-kovac]

...

• 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.

[megaroeny]

...

• 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?

[alex-kovac]

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!

[alex-kovac]

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.

[megaroeny]

Ah okay yes I see! The web font is a different version that the OTF 👌

[megaroeny]

@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

[YorelCayla]

@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.

[creative-pfnyc]

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.

[rsms]

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

[rsms]

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.

[alex-kovac]

I'd like to add the error occurs on apple Pages, too.

[rsms]

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

[arrowtype]

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). arrowtype/recursive#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?

[rsms]

@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 :-)

[rsms]

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.)

[alex-kovac]

@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 :).

[arrowtype]

@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. 😄

[rsms]

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.

[arrowtype]

Okay, so first off, I really love ideas of using grids and multiples of 8 in design. It keeps design efficient and helps yield consistent results. I’ve tended to use similar concepts in most of my own type – Recursive is based on a 50-unit grid, for instance, and this helped set modular proportions, stroke thicknesses, and (to an extent) the position of contours.

But, the point I end up questioning in your description is This makes it feasible to really tune Inter for detailed rasterization. The two obvious issues with this are that A) type is set at many sizes, and only sometimes 11dp, and B) how many displays fit 256 pixels (or even a multiple, like 32 or 16 pixels) into 11dp size? (I see in dev tools that Figma has UI text set to 11px, so nicely done there!) I’m not trying to be overly skeptical or anything – I think that the logic here is really smart, and something I may adopt in the future. But, I always like to understand how far claims really extend.

[alex-kovac]

Hi,
to refresh/revive this issue of swelling Inter static font glyphs. At the moment (Inter v3.19), the situation seems to be:

• Static fonts look good on screen but glyphs_swell_ when printing to some printers (mostly laser printers?). This issue has been observed on Mac, Win and Elementary OS 5 (any other?), suggesting printer software incompatibilities initially, but since generated PDFs have the same issue in print while looking good on screen, the problem might be wider (is this correct to assume?).
• Variable fonts print fine where supported. Unfortunately, var. font support among macOS apps is not widespread (no Win to test here, and Elementary OS 6 Odin has issues installing printers so I cannot verify the situation there at the moment... anyone else?)

Perhaps this issue can be renamed/escalated to reflect the situation above?

Time permitting, I would like to look into this issue... but honestly, my typesmithing kung-fu is nowhere close to other people here.

[YorelCayla]

Hi @alex-kovac, Thanks I would love to find a solution for this issues !
I had the problem only when I use Word. On PDF the print result (same printer) was looking good.
It seems one size setting is not propelly understand by laser printer when the text is comming from word.
The box does not change but the glyphe grow inside the box (height and width of the glyphe are affected).

[alex-kovac]

To keep this issue alive...
Attached is an example of this issue in Apple Pages. (latest macOS, Pages and Inter fonts).
Interesting fact... ttf files hinted for Windows print as expected while otf non/variable still suffers from glyph growth. Otf variable prints fine, also.

[kenmcd]

There was a similar issue posted in the Affinity forums.
It appears the issue is a combination of the UPM, HP printer drivers, and the OTF fonts.
The work-around is to use the TTF fonts.

[arrowtype]

@kenmcd interesting! How was it determined that the UPM played a role in the issue?

[kenmcd]

@kenmcd interesting! How was it determined that the UPM played a role in the issue?

Appears to be the case as the Display (2048) worked properly, and the TTF worked properly, and I remember this from an issue with another font (which I of course cannot find now).
So it would be good to confirm this if possible.

I cannot test this as I do not have a printer which displays this issue.
But I did make up test fonts which someone who does have a printer which shows this issue can test.
I just changed the names and the UPM so they can all be installed together.
InterOTF1000-Regular.otf
InterOTF2048-Regular.otf
InterOTF2816-Regular.otf
Fonts are here: InterOTF1000+2048+2816-Regular.zip
These all look and print the same for me.

So could someone who has an HP printer which displays this issue please test?

[alex-kovac]

Thank you @kenmcd I think you found the root of the issue, and @arrowtype indicated UPM as a path to investigate above...
The printout below is from HP LaserJet 1320 from Apple Pages on Monterey. It appears that fonts with UPMs 1000 and 2048 print as expected. Font set at 2816 displays glyph growth.

[rsms]

Nice find. Someone must have been lazy writing those drivers :-P
A key difference between the ttf and otf files is that the ttf ones uses quadratic bezier curves (TrueType curves) while the otf files uses cubic bezier curves (CFF, what most design software uses.) Now, a CFF font file and a TrueType font file has different data structures and so requires different parsers to be used by the font renderer. It is possible that there's a bug in the CFF parser used here or (most likely) in the printer's driver (since I can't repro this myself with Apple Pages.)

[rsms]

I've started work on converting Inter to UPM 2048 in the upm2048 branch

Tracked in issue #458

[rsms]

@alex-kovac would you mind testing this build of Inter with a 2048 UPM?
Inter-3.19-text-faded04f9f.zip

[alex-kovac]

@rsms , with pleasure...
Regular .otf font from Desktop folder seems alright to me (photo included).

...I presume you have adjusted Regular only and other variants are still WIP, right? As you can see on the photo, other variants are displayed in Apple Pages considerably bigger despite being at 18pt. (see screenshot)

.

[rsms]

Thanks @alex-kovac

Actually the entire zip package is Inter in 2048 UPM. Can you double check that you don't have a lingering version installed?

Also I notice that kerning data is not used by Pages in your screen shot (very noticeable with the "Te" pair.) Interestingly, I can't reproduce what you're seeing in Pages. This is what it looks like for me in Pages 11.1

[alex-kovac]

Hmmm... I am doing something wrong.

1. Deleted all other Inter font files.
2. Cleared Cache like this: https://discussions.apple.com/thread/253301202
3. Rebooted.

Still getting size difference... Even in Font Book (see screenshot, font titles).
on M1 Mini, Monterey 12.3.1, Pages 12.0, Font Book 10.0 (404)

Yes, I have seen 'Te' kerning, I imagined that is part of WIP. :)

[kenmcd]

I found some of these beta fonts are 2048 UPM (3) and some are 1000 UPM (6).
See: #458 (comment)

But now this is more confusing.
These beta fonts should still all be the same size (no swelling).
If the unusual UPM (2816) was the issue, even these should be fine.

So now I am wondering if this is a CoreText issue, or what????
It does not make sense.

[rsms]

Fixed the 1000 UPM issue. New build to test: Inter-3.19-b597068546.zip

[alex-kovac]

@rsms thank you,

As fas as I can tell at this moment build Inter-3.19-b597068546

• displays consistently in Font Book and Pages.
• prints properly on HP LaserJet 1320

Maybe other users could report their results?

[rsms]

@rsms thank you,

As fas as I can tell at this moment build Inter-3.19-b597068546

• displays consistently in Font Book and Pages.
• prints properly on HP LaserJet 1320

That is great news! Thank you for taking the time to do these tests.

[alex-kovac]

Thank you @rsms, @kenmcd, @arrowtype on diagnosing and ultimately sorting this one out. This was a gnarly one.

@YorelCayla, @megaroeny, @creative-pfnyc it has been a while, but if you would be so kind and catch some time to see if beta rsms provided here solves the glyph swelling bug on your side? Thank you!

[megaroeny]

if you would be so kind and catch some time to see if beta rsms provided here solves the glyph swelling bug on your side? Thank you!

I no longer work for the company that was using Inter, and I don't have access to Word. Sorry!

[alex-kovac]

Shall we close this issue? Since the updates mentioned above, there were no problems regarding this bug here. Anyone else?