Tested the issue on chrome reported version 64.0.3282.119 and latest chrome version 66.0.3345.0 using Ubuntu 14.04, we have compared the chrome behaviour of the PDF file attached in comment#0 (A.pdf) with the Firefox, observed both behaviours are same.

@Reporter:
Please find the attached screen shots(811110_Firefox & 811110_Chrome) for reference, could you please elaborate the excepted behaviour of the issue which helps us in further triaging it.

Thanks!  

Deleted: 811110_Firefox.png 297 KB

	811110_Firefox.png 297 KB View Download

Deleted: 811110_Chrome.png 249 KB

	811110_Chrome.png 249 KB View Download

viswa.karala@ as you can see on your screenshots, *all* bold characters are distorted (broken):
  科學工業園區管理局作業基金
  一、基金概況：
  二、最近五年主要業務項目：
For example, look at the last character in the second heading - 目 - and compare it to the correct one in the attached screenshot.
It should be noted, your Firefox screenshot also shows broken characters.

Deleted: ok - acrobat reader.png 66.0 KB

	ok - acrobat reader.png 66.0 KB View Download

Thank you woxxom for explaining it clearly to everybody!

Thank you for providing more feedback. Adding requester "viswa.karala@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Just looking at the first line of text in the PDF - that regressed ~1 year ago when I upgrade FreeType for PDFium in r460687. It's still broken in Chrome Canary, so presumably we need to fix the issue in FreeType.

So we believe this is a FreeType regression between 2.6.1 and 66725768cdf758cfb3f9abf03cbf5e5a77f42088 ? In any event it appears that this font, which is identified in the PDF as FPFICO+DFMing-Bd-HK-BF is a much minified ttf font, which I will attach here since it isn't generally useful (it has no cmap table). This is what FreeType calls a 'tricky' font, in that it composes all of its glyphs by using hinting instructions. As such it requires that bytecode hinting be enabled. FreeType has an internal list of known fonts which require this, but this particular subset appears to be unknown. As a result, this mostly the result of moving to the v40 hinter which ignores hints in the x direction. This would explain why bits of the glyphs appear to line up in the vertical direction but not the horizontal. I can confirm this is the case by launching my local build of chrome with and without "FREETYPE_PROPERTIES=truetype:interpreter-version=35" being set.

Deleted: FPFICO_DFMing_BD_HK_BF.ttf 162 KB

FPFICO_DFMing_BD_HK_BF.ttf 162 KB Download

Issue opened at https://savannah.nongnu.org/bugs/index.php?53554 , and the addition of these 'tricky' fonts was done at http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=26ad1acbcb4ca9e25163bd102971c8f0e1b56d87 . We will need to roll FreeType to pick up this change at tip of tree. After ensuring this fixes things, this commit can easily be cherry-picked if needed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5e4114c0275b6182f40f82a2ea94ed9c009baaa5

commit 5e4114c0275b6182f40f82a2ea94ed9c009baaa5
Author: Ben Wagner <bungeman@chromium.org>
Date: Thu Apr 05 13:35:53 2018

Roll src/third_party/freetype/src/ 61ee69a66..26ad1acbc (5 commits)

https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+log/61ee69a66e73..26ad1acbcb4c

$ git log 61ee69a66..26ad1acbc --date=short --no-merges --format='%ad %ae %s'
2018-04-04 mpsuzuki * src/truetype/ttobjs.c (trick_names): Add 3 tricky fonts (#53554), `DFHei-Md-HK-BF', `DFKaiShu-Md-HK-BF' and `DFMing-Bd-HK-BF'. (tt_check_trickyness_sfnt_ids): Add checksums for 3 tricky fonts in above.
2018-04-03 wl Minor comment improvement.
2018-04-01 wl * builds/toplevel.mk (work): Use $(SEP).
2018-03-30 wl [truetype] Fix memory leak (only if tracing is on).
2018-03-26 apodtele Documentation improvement.

Created with:
  roll-dep src/third_party/freetype/src
R=bungeman@chromium.org,drott@chromium.org
BUG= chromium:811110 

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_msan_rel_ng

PDFium-Issue:  pdfium:1053 
ChromiumOS-Issue:  chromium:825973 
Change-Id: Icfc49484a500e0c75edebb7d58b76d3c7442d5ea
Reviewed-on: https://chromium-review.googlesource.com/995918
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548408}
[modify] https://crrev.com/5e4114c0275b6182f40f82a2ea94ed9c009baaa5/DEPS
[modify] https://crrev.com/5e4114c0275b6182f40f82a2ea94ed9c009baaa5/third_party/freetype/README.chromium
[modify] https://crrev.com/5e4114c0275b6182f40f82a2ea94ed9c009baaa5/third_party/freetype/include/freetype-custom-config/ftoption.h
[modify] https://crrev.com/5e4114c0275b6182f40f82a2ea94ed9c009baaa5/third_party/freetype/roll-freetype.sh

Able to reproduce the issue on chrome reported version 64.0.3282.119
Verified the fix on Ubuntu 14.04 on Chrome version #67.0.3390.0 as per the comment#0 & 3
Attaching screenshot for reference.
Observed "Able to see pdf file rendering correctly"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 811110.png 278 KB

	811110.png 278 KB View Download

Considering this has been an issue for a year already, I'm not requesting a merge of this FreeType change to m66 unless someone really needs it. On Chrome versions before 67 which exhibit this issue, it can be worked around locally if one launches Chrome with the environment variable "FREETYPE_PROPERTIES=truetype:interpreter-version=35" set.