Tracked down the bug to 10140.0.0 by bisecting the output of gstoraster[1] over the attached sample file.  go/bzmqeb

Comparing 10139.0.0 to 10140.0.0, https://crosland.corp.google.com/log/10139.0.0..10140.0.0 suspicious commit to freetype found[2].  

Attempted to revert the CL, image built with reverted CL restores rasterization.

[1] /usr/libexec/cups/filter/gstoraster 1 'foo' 'test' 1 '' /home/chronos/user/Downloads/pdf-sample.pdf > /home/chronos/user/Downloads/test.raster
[2] "
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/b97c53f1c90fd9ea70af9e40c7b2b37a665c67fb

Deleted: pdf-sample.pdf 7.8 KB

pdf-sample.pdf 7.8 KB Download

Fast follow this needs an autotest.

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/758744

disabled some FreeType modules. Perhaps, one or more of them are necessary to render the above PDF.  

A quick fix for M64  would be to add back pcr, winfonts, lzw, bzip2, MAC_FONTS.

I'm pretty sure bdf/pcf (X11 bitmap) are not necessasry for PDF.

Then, in trunk, we can find out exactly which one is necessary for PDF rendering by gs. 

By running ghostcript directly, identified the fonts that are being used.

gs -dBATCH -dSAFER -sDEVICE=cups -sMediaClass=PwgRaster -sOutputFile=render.raster pdf-sample.pdf

Querying operating system for font files...
Substituting font Helvetica-Bold for Arial-BoldMT.
Loading Arimo-Bold font from /usr/share/fonts/croscore/Arimo-Bold.ttf... 5473708 3870674 6852964 3206103 3 done.
Substituting font Times-Roman for TimesNewRomanPSMT.
Loading Tinos-Regular font from /usr/share/fonts/croscore/Tinos-Regular.ttf... 5493808 3906075 8281456 4738323 3 done.
Using Tinos font for Tinos-Regular.
Loading NotoSansSymbols-Regular font from /usr/share/fonts/noto/NotoSansSymbols-Regular.ttf... 5574208 3978480 8479064 5033449 3 done.
Substituting font Helvetica for ArialMT.
Loading Arimo-Regular font from /usr/share/fonts/croscore/Arimo-Regular.ttf... 5574208 3982200 9493864 6161252 3 done.
Using Arimo font for Arimo-Regular.
Substituting font Times-BoldItalic for TimesNewRomanPS-BoldItalicMT.
Loading Tinos-BoldItalic font from /usr/share/fonts/croscore/Tinos-BoldItalic.ttf... 5574208 3982499 10885236 7663703 3 done.

kbleicher@ - FYI, putting this bug on your radar as I think we should fix this for the M64 stable release. Please let me know if you have any concerns, thanks!

Given comment 6, it appears that the PDF in comment 1 does not have ArialMT embedded, but just has a reference to ArialMT which is substituted by Arimo on CrOS. 

In that case, it's rather strange that there's an issue. Anyway, adding back disabled modules is the first thing to try. 

Assume no impact to GRD / String Translation and this is just adding font modules?  Confirmed that this was the root cause / fix?

Also with #9, will the modification require a merge?

No GRD or string changes.  Root cause is the update to freetype.  It's possible the freetype update uncovered a bug in Ghostscript but it's definitely a system package.

Re: #10 this is currently broken in M64 and should be merged.

skau@: have you tried adding back FreeType modules  (comment 5)?  Does it work? 

No.  I've removed all the disable_module lines and I'm seeing the same problem.  Does freetype have tests to ensure that Arimo is rendering properly?

More notes from my investigation:

I've been diffing debug output from ghostscript in 63 v 65 and the problem seems to lie in NotoSansSymbols-Regular.ttf.  It seems that in 63, this font didn't have a post table so ghostscript assumes ISOLatin1Encoding.  In 65, this font has post information ...

Continuing to work on confirming.

>  Does freetype have tests to ensure that Arimo is rendering properly?

It does not, but if FreeType has an issue with Arimo, web pages all over the place (a lot of them specifying 'font-family: arial' ) would be broken. 

> I've removed all the disable_module lines and I'm seeing the same problem. 

How about these lines? Did you remove them as well?

	disable_option "FT_CONFIG_OPTION_MAC_FONTS"
	disable_option "TT_CONFIG_OPTION_BDF"

I've removed those lines and it doesn't seem to help.

I'm writing a few short postscript files to isolate the issue. It seems like the version of Ghostscript we are using is incompatible with Freetype 2.8.1.  But I can't prove it just yet.

I rendered a simple postscript file to png and it looks like ghostscript may be incompatible with this version of freetype.  It looks like the indexes into the character map are incorrect.

Deleted: M63.render.png 8.4 KB

	M63.render.png 8.4 KB View Download

Deleted: M65.render.png 9.0 KB

	M65.render.png 9.0 KB View Download

Deleted: test.ps 355 bytes

test.ps 355 bytes Download

From the FreeType release notes, I believe that I've found my culprit.

    - FreeType  now synthesizes  a  missing Unicode  cmap for  (older)
      TrueType fonts also if glyph names are available.

Ghostscript might need a patch.

[1] https://sourceforge.net/projects/freetype/files/freetype2/2.8.1/

I'm at a loss as to how this hasn't broken anything else.  Between freetype 2.8 and 2.8.1 they changed how they handle empty charmaps.  Attached is the output from ./ftdump -V Arimo-Regular.ttf

Deleted: Arimo2.8.txt 61.2 KB

Arimo2.8.txt 61.2 KB View Download

Deleted: Arimo2.8.1.txt 85.3 KB

Arimo2.8.1.txt 85.3 KB View Download

More investigation.  I've split the fonts into two categories.  One which works where the character mapping hasn't changed between the versions of freetype.  The other where the character map is different.  By sampling a few of the fonts, I've found that the first category still renders fine.  This includes Roboto.  The second category is broken in M65.

Deleted: different.txt 5.7 KB

different.txt 5.7 KB View Download

Deleted: identical.txt 1.1 KB

identical.txt 1.1 KB View Download

Alright.  This is a bug in Ghostscript.  It looks like characters are being looked up twice where the glyph index is being used as a character index resulting in the offset we're seeing.  From Arimo starting with 'P'.  'P' in Unicode is 0x0050.  In the charmap for Arimo, the cooresponding glyph is at index 51 (0x33).  In unicode, 0x33 is '3' and that's what we see rendered in the broken pages.

Sampling the files in the identical list, it looks like none of them have viable name lookups.  This leads me to believe that the problem is in the use of fonts that have named symbols.

Filed bug with ghostscript

https://bugs.ghostscript.com/show_bug.cgi?id=698856

Thank you for the great detective work. I was aware of that cmap handling change in FreeType 2.8.1, but didn't suspect that it could be an issue because Arimo does have a Unicode cmap (PID=3 and EID=1).

The FreeType change is at  https://goo.gl/5zcXQh. 

Arimo2.8.txt and Arimo2.8.1.txt are different in that the latter has a postscript name while the former does not. It's not clear why the above FreeType can lead to that difference. 

> the problem is in the use of fonts that have named symbols.

Some TTFs on CrOS have post table while others have just nominal/empty post table. 

Follow up, Ghostscript reports this is the appropriate fix.

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ead0b5bee

It's been landed in their tree.  I'm trying to pick it.

Turns out that Ghostscript had a bug in the code that looked up a glyph by name.  So, once characters suddenly had names, the bug was exposed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/91c6f48c6fb0d8a40174c8b9b6a297b077d48da9

commit 91c6f48c6fb0d8a40174c8b9b6a297b077d48da9
Author: Sean Kau <skau@chromium.org>
Date: Fri Jan 19 01:40:38 2018

app-text/ghostscript-gpl: Backport fix for glyph lookups

There is a bug in glyph index resolution for certain
character maps which surfaced with the upgrade to
freetype 2.8.1.  This is a backport of the patch
from ghostscript.

BUG= chromium:792297 
TEST=Verify that various fonts are rasterized correctly
by Ghostscript.

Change-Id: I2b2c003cb85159c3108a8047bb9be500fdf7915f
Reviewed-on: https://chromium-review.googlesource.com/867949
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Sean Kau <skau@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/91c6f48c6fb0d8a40174c8b9b6a297b077d48da9/app-text/ghostscript-gpl/ghostscript-gpl-9.19.ebuild
[add] https://crrev.com/91c6f48c6fb0d8a40174c8b9b6a297b077d48da9/app-text/ghostscript-gpl/files/ghostscript-gpl-9.23-Ensure-is_glyph_index-flag-is-consistent.patch
[rename] https://crrev.com/91c6f48c6fb0d8a40174c8b9b6a297b077d48da9/app-text/ghostscript-gpl/ghostscript-gpl-9.19-r10.ebuild

Landed in platform 10321.0.0

Waiting to verify on canary before picking back.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

Request merge to 64.  I've confirmed that the change works on a peppy running R65-10322.0.0

This bug requires manual review: We are only 3 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/46d6a5f5d5373ae05af5248ff626bf2ac2d88fe4

commit 46d6a5f5d5373ae05af5248ff626bf2ac2d88fe4
Author: Sean Kau <skau@chromium.org>
Date: Mon Jan 22 20:32:24 2018

app-text/ghostscript-gpl: Backport fix for glyph lookups

There is a bug in glyph index resolution for certain
character maps which surfaced with the upgrade to
freetype 2.8.1.  This is a backport of the patch
from ghostscript.

BUG= chromium:792297 
TEST=Verify that various fonts are rasterized correctly
by Ghostscript.

Change-Id: I2b2c003cb85159c3108a8047bb9be500fdf7915f
Reviewed-on: https://chromium-review.googlesource.com/867949
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Sean Kau <skau@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
(cherry picked from commit 91c6f48c6fb0d8a40174c8b9b6a297b077d48da9)
Reviewed-on: https://chromium-review.googlesource.com/879421
Reviewed-by: Sean Kau <skau@chromium.org>
Trybot-Ready: Sean Kau <skau@chromium.org>
Commit-Queue: Sean Kau <skau@chromium.org>

[modify] https://crrev.com/46d6a5f5d5373ae05af5248ff626bf2ac2d88fe4/app-text/ghostscript-gpl/ghostscript-gpl-9.19.ebuild
[add] https://crrev.com/46d6a5f5d5373ae05af5248ff626bf2ac2d88fe4/app-text/ghostscript-gpl/files/ghostscript-gpl-9.23-Ensure-is_glyph_index-flag-is-consistent.patch
[rename] https://crrev.com/46d6a5f5d5373ae05af5248ff626bf2ac2d88fe4/app-text/ghostscript-gpl/ghostscript-gpl-9.19-r10.ebuild

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot