New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some Google fonts print incorrectly on anisotropic RIPs #1370

Open
Buckers66 opened this Issue Nov 29, 2017 · 12 comments

Comments

Projects
None yet
7 participants
@Buckers66

Buckers66 commented Nov 29, 2017

Does anyone have any insight into why some google fonts print distorted when a RIP using unequal resolutions? We have designers and laypersons sending in PDF's using free Google fonts for book production. Most of our work isn't proofed before printing so if the printer doesn't notice we potentially have a pallet of paper destined for the trash. This problem has only been apparent for the last couple of years and I have no way of knowing that the font is going to be a problem.
The printing device is a SCREEN Truepress jet520, the most productive resolution is 360dpi x 720dpi and google truetype fonts are the only problem fonts.

@thlinard

This comment has been minimized.

Contributor

thlinard commented Nov 30, 2017

Some Google fonts… what fonts?

@graphicore

This comment has been minimized.

Collaborator

graphicore commented Nov 30, 2017

@Buckers66 this is really hard to analyze or debug. We need much more information to even get started.

A list of fonts that trigger the issue as well as fonts that don't would be a good start. Best if all fonts are in Google fonts, if possible, because we have access to them and, can look into them and compare. Not all of our fonts are made the same, so it would be strange if really all trigger the issue. (Maybe all that use ttfautohint do, or something like that.)

Then, we need a reproducible example of your issue. That way, when fixed, we can't reproduce it anymore and then we know we're good. This is however really hard, because we don't have access to a SCREEN Truepress jet520. Is there a way for you to get a PDF or bitmap image proof from the RIP, without printing it? One that displays the behavior? That way a developer could send you pdfs and you could send back proofs.

Did you try to contact the company "SCREEN"? Maybe it's an issue with their software. Maybe we can find out what software they use as a RIP and use it ourselves directly. It's also possible that there is a bug in the RIP, not in our fonts. I'm sure SCREEN would be interested to get this sorted out as much as we do.

@Buckers66

This comment has been minimized.

Buckers66 commented Dec 5, 2017

Hi, Thanks for the prompt response although mine wasn't as I got rather busy the last few days. First of all here is my current but ever expanding list of fonts that are not printing correctly on this device:
Raleway
Raleway-Black
Raleway-Bold
Scada-Regular
RobotoSlab-Regular
Charter-Regular
Handy-Regular
PlayfairDisplay
PlayfairDisplay-BoldItalic
PlayfairDisplay-Italic
Catamaran-Regular
Catamaran-ExtraBold
Catamaran-SemiBold
Catamaran-Bold
Catamaran-Black
Baloo-Regular
Roboto-Black
Oswald-Regular
JuliusSansOne-Regular
Lato-Light
Lato-LightItalic
Lato-Italic
Lato-Regular
Lato-Semibold
Lato-BoldItalic
Lato-Heavy
Lato-Bold

There is one other font that is not a google font we discovered in 2011:
TimesNewRomanPS-ItalicMT (Only character "a" was a problem)

We contacted SCREEN about this issue who in turn contacted ADOBE and here is their responses to the small "a" problem:

_FROM SCREEN JAPAN:

This font is embedded in the PDF. Therefore, the font WAS NOT substituted in SV-110. The font was a True type font.
Use a Preflight program to check for True Type fonts if True Type has been used be cautious in using 720x360dpi

FROM ADOBE:

The file contains TrueType fonts which are being ripped at anisotropic resolution of 720x360. TrueType fonts can have size dependent instructions.

TrueType fonts can have instructions that test for anisotropic scaling and change their instruction processing sequence accordingly. Since this is an uncommon rendering mode, some fonts exhibit bugs that are only triggered under these circumstances.

The issues demonstrated with this bug submission reflect defects in the font program, not in the font processing software.

Using TrueType fonts with anisotropic transforms is generally problematic.

This is not a CPSI issue, these kind of problems can arise with some TrueType fonts, if you try to render them at anisotropic resolutions e.g. 720x360. We have seen these kind of problems in past, these are TrueType Font issues._
......................................................................................................

In regards testing fonts, there is no access to this RIP without printing onto paper, there is a low res RIP feature but it is only in non isotropic resolution eg 72 x 72 dpi so will not reproduce the error. I will however print test samples if anyone on this forum wants to test a corrected font.
I did not collect names of fonts in the same family that didn't cause the problem for you to compare but I will be looking out for those and will inform you as soon as I know.

Kind Regards
Pat Buckley

@thlinard

This comment has been minimized.

Contributor

thlinard commented Dec 5, 2017

Very interesting. Many of my own teams use Google Fonts for print, we never experienced any problems (but we don't use anisotropic RIPs).

Some fonts mentionned exist in TTF and OTF (CFF) format. It might be useful to compare tests:
Raleway https://github.com/impallari/Raleway/tree/master/fonts/v4020
Scada https://github.com/googlefonts/scada/tree/master/fonts
Charter – not a Google Font
Handy – not a Google Font
Playfair Display https://github.com/clauseggers/Playfair-Display/tree/master/fonts
Oswald https://github.com/googlefonts/OswaldFont/tree/master/fonts

@Buckers66

This comment has been minimized.

Buckers66 commented Dec 7, 2017

thlinard: Thanks for that suggestion, the OTF versions of those fonts print perfectly. On the flipside I had probably the worst example of my troubles printing this morning with 18 fonts behaving badly. All the fonts in the book were TT, the list of fonts in the publication are here and I've put the word (faulted) next to the troublesome fonts. If someone could compare the structure of the problematic fonts with the structure of another font in the list that didnt cause any issues I would be most appreciative:
ArialMT
CaveatBrush-Regular
ContrailOne-Regular
JuliusSansOne-Regular (Faulted)
Courgette-Regular (Faulted)
AbrilFatface-Regular
PatrickHand-Regular
Monofett
TheGirlNextDoor
Spectral-Bold (Faulted)
PermanentMarker-Regular
BubblegumSans-Regular
Lobster-Regular (Faulted)
SedgwickAve-Regular (Faulted)
Monoton-Regular
Questrial-Regular
BungeeShade-Regular
LondrinaShadow-Regular
Arial-BoldMT
TimesNewRomanPSMT
Arial-BoldItalicMT
Calibri
Calibri-Bold
Comfortaa-Bold (Faulted)
Comfortaa-Regular (Faulted)
Acme-Regular
Alegreya-Regular
BreeSerif-Regular
AmaticSC-Bold (Faulted)
Caveat-Bold (Faulted)
Caveat-Regular (Faulted)
ComicSansMS-Bold
Oswald-Regular
Pacifico-Regular (Faulted)
RobotoMono-Regular
Shrikhand-Regular
CourierNew-Bold
Aclonica-Regular
Aladin-Regular
Bangers-Regular (Faulted)
BowlbyOne-Regular
ChangaOne
Creepster-Regular
LilitaOne
Handlee-Regular
GloriaHallelujah
FredokaOne-Regular
Julee-Regular
LobsterTwo
EBGaramond-Regular (Faulted)
Alegreya-Bold
AlfaSlabOne-Regular (Faulted)
Cardo-Regular
PlayfairDisplay-Regular (Faulted)
PoiretOne-Regular
Pompiere-Regular
Cookie-Regular
EBGaramond-Bold
FrederickatheGreat
Asap-Regular
BerkshireSwash-Regular
Righteous-Regular
ShadowsIntoLight
TrebuchetMS
Chewy-Regular
FrancoisOne-Regular (Faulted)
KaushanScript-Regular (Faulted)
Orbitron-Regular
YanoneKaffeesatz-Regular (Faulted)
Yellowtail-Regular
ArchitectsDaughter-Regular

Kind Regards

Pat

@thlinard

This comment has been minimized.

Contributor

thlinard commented Dec 8, 2017

Hi,

I did some research, and the printing problems aren't new:

About Lato, Adam Twardoch commented: "I did hear of printing problems, even with the most current version, which most likely are related to hinting and ttfautohint — but it's next to impossible to debug those problems"
#6 (comment)

I looked at the Truepress Jet520 specifications, and the printer have two isotropic resolutions:
http://www.screen.co.jp/ga_dtp/en/product/digitalprint/tp_jet520/spec.html

So, for a short-term resolution, perhaps you can:

  1. Use OTF (CFF) fonts.
  2. When OTF fonts aren't available, use 720×720dpi or 360×360dpi resolution.

For long-term resolution, the problem lies probably in a common production tool (ttfautohint is a good candidate, like @graphicore and Adam Twardoch have said). Also, the "faulted" fonts, for those I know, are all, Lato aside, produced with Glyphs (or .glyph file + fontmake), if you use their latest version.

@webberig

This comment has been minimized.

webberig commented May 25, 2018

I think I have a problem related or equal to the OP.

This is how the corrupts output looks like: https://imgur.com/a/JUMpCRQ
For reference, this is how it should look like (Firefox): https://imgur.com/a/d19zIiO

As you can see, Dosis (used for the titles) works fine, Lato does not.

  • 2 people in our team seem to have the problem, others in my company do not.
  • Those 2 people now got brand new Macbook pro laptops. I still have the problem, my colleague has no more problems. I was still unable to figure out why.
  • The problem only appears in Chrome. Firefox and Safari don't seem to affected.
  • I tried adding Lato using Typekit (Adobe) and that works just fine.
  • I've used a self-hosted version of Lato for a different website, that works just fine.
  • I've tried replacing Lato with Open-sans, that font also has the same corrupted output

As far I can tell this won't affect a big group of users, but since some of our clients started complaining, I need to solve this. For now, I'm going for the self-hosted option but being able to use google fonts would be much easier!

@webberig

This comment has been minimized.

webberig commented May 25, 2018

Almost forgot... I also have the problem on other websites using google fonts. For example: imgur.com and codepen.io.

@chiss22

This comment has been minimized.

chiss22 commented Jun 8, 2018

@webberig Same problem here. Google Web Fonts not working with Lato on Chrome when printing, and the glyphs we are getting look the same.

@chiss22

This comment has been minimized.

chiss22 commented Jun 8, 2018

@webberig turns out it could have been caused by two different things:

  1. Our webserver was not configured for the .woff2 mime type (https://github.com/fontello/fontello/wiki/How-to-setup-server-to-serve-fonts)
  2. Adobe TypeKit was loading the Lato font on my Mac. Local fonts will cause the browser to not use the font loaded in with @font-face, so the Adobe TypeKit version was loading in instead. As soon as I remove the sync through TypeKit, the issue disappeared. I have a feeling this was the only thing that resolved it, however, the missing mime type was suspicious too.

Chris

@davelab6

This comment has been minimized.

Member

davelab6 commented Jun 10, 2018

I'm setting this as a high priority bug, but I don't know when we will get to fix it

@Kenichiwaa

This comment has been minimized.

Kenichiwaa commented Jun 15, 2018

I have this issue during print preview of my page and when saving via .pdf.
Seems to occur only on my Mac using chrome. Firefox works fine, and coworkers PC and Linux rendered the font fine using chrome. This issue started to occur yesterday afternoon out of nowhere. Been working on my project for a few weeks with no issues.

I've isolated the issue to "font-style: italics" CSS to be the problem.

I'm running
Computer: macOS Sierra 10.12.6
Browser: Chrome Version 67.0.3396.87 (Official Build) (64-bit)

Italic style is missing and some letters get replaced with symbols
image

Kind regards,
Ken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment