search

google / fonts

Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
https://fonts.google.com
18.2k stars 2.62k forks source link

Some Google fonts print incorrectly on anisotropic RIPs #1370

Open Buckers66 opened 6 years ago

Buckers66 commented 6 years ago

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 commented 6 years ago

Some Google fonts… what fonts?

graphicore commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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" https://github.com/google/fonts/issues/6#issuecomment-261862254

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 commented 6 years ago

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.

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 commented 6 years ago

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

chiss22 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

Kenichiwaa commented 6 years ago

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

davelab6 commented 5 years ago

Comfortaa was updated today to be a Variable Font, maybe that helps this issue

taylordhermes commented 5 years ago

Currently having the same issues with Montserrat and Roboto Slab. We were able to fix Montserrat by using the OTF and trashing the TTF but Roboto Slab doesn't seem to have an OTF version? Has any resolution been found to fix this problem?

raylopro commented 5 years ago

Currently having an issue with the Prompt Regular and Bold fonts appearing as italic when implemented. Tested with other fonts and they appear correctly. Also, tested with font-style: normal; but the problem is not CSS, it's the font being loaded that's wrong.

josh-d-norman commented 5 years ago

Not ideal, but this works on Mac OS 10.14.5:

Export a PDF Open that document in Acrobat, and select File>Print Click the "Advanced" button in the print dialog box Select the checkbox labeled "print as image" TTF Google fonts will print as intended.