I'm not seeing this with Linux 56.0.2924.87 and z.html. The fonts look different. Locally I have Verdana. It looks like you have DejaVuSans and LiberationSans. Not sure why our computers are rendering with different fonts. I do have fonts-liberation installed, but I also have ttf-mscorefonts-installer.

Deleted: z_good.pdf 12.8 KB

z_good.pdf 12.8 KB Download

This is on Fedora, no proprietary fonts. Happens with both the official Google Chrome and Fedora-packaged Chromium.

It could be a font bug in Fedora. If it looks like that to you, I'm happy to file a Fedora bug. We'd need to figure that out first though.

Let me try on Ubuntu without MS fonts and see what happens.

I removed Verdana and Arial to coerce Chrome into using LiberationSans. Still looks fine here on Ubuntu 14.04, which has fonts-liberation 1.07.3-3. [1] What version of Fedora are you using? What's the version number of the Liberation Fonts package there?

[1] http://packages.ubuntu.com/trusty/fonts-liberation

Deleted: z_good_liberation.pdf 16.8 KB

z_good_liberation.pdf 16.8 KB Download

On Fedora, I have liberation 1.07.4. I get the same results when I install the Ubuntu version of the font. Still digging.

http://pkgs.fedoraproject.org/cgit/rpms/liberation-fonts.git/tree/?h=f25

This is reproducible directly from newly-installed ubuntu 16.04.

Deleted: z_bad_ubuntu16.04.pdf 16.7 KB

z_bad_ubuntu16.04.pdf 16.7 KB Download

And it does not have problems on a newly installed ubuntu 14.04.

Deleted: z_good_ubuntu14.04.5.pdf 16.8 KB

z_good_ubuntu14.04.5.pdf 16.8 KB Download

I copied libfreetype.so.6.11.1 from the ubuntu trusty machine to my Fedora machine and used LD_LIBRARY_PATH to override. This results in correct output in Chrome.

trusty freetype [GOOD]: 2.5.2-1ubuntu2.5
xenial freetype [BAD]: 2.6.1-0.1ubuntu2

I am bisecting freetype.

Bisecting from freetype git did not work, but building from the ubuntu source did. It's one of the ubuntu/debian patches.

freetype git 2.4.4 works

Here is the bad commit
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72

It was reverted for a time in Ubuntu (including Trusty) but ultimately accepted once toolkit bugs were fixed?
http://lists.nongnu.org/archive/html/freetype-devel/2012-04/msg00001.html

This is also reproducible on Chrome OS if I explicitly set font-family: "Liberation Sans".

It is definitely a problem with kerning. font-kerning:none shows correct (unkerned) PDF output.

The weird thing is, the amount of kerning error differs depending on how much kerning has taken place so far in the line, and seems modulated by font-size.

Here is a simple reproduction with Arial.

Deleted: z_arial.html 847 bytes

z_arial.html 847 bytes View Download

Deleted: z_arial.pdf 18.7 KB

z_arial.pdf 18.7 KB Download

z_arial.html renders in the same way on Chrome OS.

Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel samus
ARC Version 3756504
Firmware Google_Samus.6300.174.0

"The weird thing is, the amount of kerning error differs depending on how much kerning has taken place so far in the line, and seems modulated by font-size."

This makes sense.  SkPDF will try to save space in the output file by using the default advance whenever the glyphs are positioned exactly where the default would put them. See
    https://skia.googlesource.com/skia/+/fc75b5a/src/pdf/SkPDFDevice.cpp#969

Does this patch fix the behavior?
    https://review.skia.org/9286

Yes, the skia patch fixes the problem.

Deleted: good_with_skia_patch_9286.pdf 42.3 KB

good_with_skia_patch_9286.pdf 42.3 KB Download

Here is the original discussion of the metrics bug in 2011 if that helps with Skia debugging:
http://lists.gnu.org/archive/html/freetype-devel/2011-07/msg00022.html

bungeman@ and I looked at this.  I specify that the font size is 9.3299999 (from SkPaint::getTextSize(), but the advances all assume the font size is really 9.000000.  Manually changing the font size fixes the bug.

Can we ask FreeType what the *real* font size is?

From reading parts of this thread,
https://lists.gnu.org/archive/html/freetype-devel/2012-04/msg00013.html

My guess is you might need to tell Freetype that you are running at a resolution >72dpi ?

Also see this 2012 webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=102374

(actually I think the 102374 webkit bug might be a red herring, sorry)

Consider PDF to be an infinite resolution display!

Right. What does harfbuzz do? I see it does some careful stuff to extract metrics. https://github.com/behdad/harfbuzz/blob/master/src/hb-ft.cc

Skia requests a size of ~9.33 and then uses FreeType to get all of its information, so all is well and consistent. However, with the FreeType change (which is no longer being patched out by debian) from comment 15, FreeType respects 'head' table 'flags' bit 3 (see https://www.microsoft.com/typography/otspec/head.htm ). This means that FreeType is actually rounding the size to 9. This currently affects everything, including linear metrics (which seems iffy), and there seems to be no way to directly request FreeType not to do this.

In the PDF generator there is a size optimization so that instead of individually placing each glyph, if the glyphs use the default advances those advances are just listed and then used. When you do this you must specify the size. Currently the PDF is written with the requested ~9.33 but everything was laid out with 9. As a result the line of text ends up ~104% the intended length.

We either need to really get linear metrics out of FreeType when we want them (even with this change) or we need to let PDF know what the 'real' size is.

*That* commit...

IMO, FreeType should not respect head flag bit 3 if hinting is disabled.  Can you report on freetype-devel please?

Bungeman@, can we make a special "vector glyph cache" that Blink can use in printing mode and always get linear results by wrapping a regular glyph cache at 1000pts?  I'll sketch it out for you tomorrow, but I mention it now so I don't forget.

A bug has been opened against FreeType at http://savannah.nongnu.org/bugs/?50470 .

What API is used on Windows to load these fonts and get this data? My understanding is that FreeType is supposed to be bug-compatible with Windows.

Check out http://savannah.nongnu.org/bugs/?50470#comment1

The suggestion is to look at linearHoriAdvance at https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_GlyphSlotRec

Looking at skia, I see linearHoriAdvance is already in use. Also, I'm not what this has to do with outlines... so I'll let folks comment on the bug over there.

As mentioned in http://savannah.nongnu.org/bugs/?50470 this was fixed by reverting the patch upstream:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bcc74f4dafee25ea89f1d3144646cba7e30f9908

I can file a Fedora bug to ask them to cherrypick, though they will likely pick up the change when Freetype releases a new version.

For Chrome OS, we should cherrypick.

I confirmed the FreeType patch fixes the issue.

This is cherrypicked in Fedora now:
http://pkgs.fedoraproject.org/cgit/rpms/freetype.git/commit/?id=8d9deda0abc81ebc983f9417588d2df5ee29fe0a

This should be fixed with the new release of FreeType (http://lists.nongnu.org/archive/html/freetype-devel/2017-05/msg00078.html)

I don't think there is anything to do here, outside of updating Chrome OS (https://packages.gentoo.org/packages/media-libs/freetype)

As described in #c34, I have worked around this issue in SkPDF in m59.

agoode@: I'm updating FreeType to 2.8 now on CrOS ( bug 722589  )

didn't mean to drop halcanary@chromium.org 

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

commit a81623747d0e78c88e9744e4bcee0f3d8c413270
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri May 19 23:23:37 2017

Update FreeType to 2.8 from 2.7.1+patches (e432ebf)

A few notable changes include:

 - Autohinting support for a number of "small" scripts
 - Variable font support fixes (e.g. MVAR/HVAR/VVAR handling, CFF2,
   instance namining)
 - Sanitizer issue fixes
 - Allow linear scaling for unhinted rendering ( crbug.com/696356 )

The first one will allow us to use autohints for more fonts.

Changlog:

https://chromium.googlesource.com/chromium/src/third_party/freetype2/+log/e432ebf..a12a344

BUG= chromium:722589 , chromium:696356 , chromium:716995 
TEST=emerge-{x86-alex,amd64-generic,daisy} freetype succeeds.
TEST=cbuildbot chromiumos-sdk
TEST=cbuildbot  amd64-generic-full x86-generic-full arm-generic-full
TEST=manual/visual: WebUI rendering and web page rendering do not have any noticeable regression. (they can be slightly different).

Change-Id: I08504ddf568ce0cb2e73fe05c4013ebd92dc3240
Reviewed-on: https://chromium-review.googlesource.com/506850
Commit-Ready: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/files/freetype-2.7.1-ttnames.patch
[rename] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/freetype-2.8.ebuild
[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/freetype-2.7.1-r1.ebuild
[modify] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/Manifest
[delete] https://crrev.com/e523e17f5f8eb48bb5f2482dd4a11d807c377916/media-libs/freetype/files/freetype-2.7.1-e432ebf.patch
[add] https://crrev.com/a81623747d0e78c88e9744e4bcee0f3d8c413270/media-libs/freetype/freetype-2.8-r1.ebuild

Fixed in CrOS ToT. 

For Linux Chrome, it should also be fixed (even without a work-around) in ToT because Linux Chrome is now statically linked to a bundled FreeType (and it's 2.8 now) thanks to Dominik.