Issue 721750  has been merged into this issue.

From  bug 721750 

Compare   issue 617168   in Chromium:

Compiling FreeType without HarfBuzz support leads to autohinter issues with ligatures. The FreeType autohinter - without HarfBuzz support - cannot support mappings through GSUB  and GPOS tables and cannot identify Latin ligatures for example as belonging to the Latin character/glyph set. 

For Chrome on Desktop, we're now compiling FreeType with HarfBuzz support. CrOS may consider doing the same, although the issue may have less impact due CrOS devices usually having HiDPI screens (?).
 

I'll do this after updating FreeType on CrOS to 2.8 (which I'm doing now)

I need to figure out how to handle circular dependency in Gentoo build system:

I can take the following 3 steps manually, but I don't know what build_packages and build_image script do when there's a circular dependency. 

1. Build FreeType without harfbuzz dependency

$   USE='-harfbuzz' emerge-${BOARD} freetype
 
2. Build Harfbuzz

$ emerge-${BOARD} harfbuzz

3. Build FreeType with harfbuzz dependency 

$ emerge-${BOARD} freetype

there is no silver bullet here.  circular deps between libs in general is craziness as there's no clean way to handle it.

what is it that each library needs out of the other ?  is it header files, library linkage, build time tools, something else ?  in other words, we might be able to create a third package from one of them which contains the reduced set of things ...

+behdad (I thought I had added him earlier). 

When Harfbuzz is enabled in FreeType, FreeType's autohinter relies on HB's shaping APIs (some of them take parameters of FreeType types such as FT_Face). 

Harfbuzz uses FT APIs to access cmap, metric (advance, extent,height..), etc of a font. 

To Behdad, what if HB exclusively uses hb_ot_*'s and does not include hb_ft_*'s? 

if each library requires linkage & headers of the other, i can't see how this would work for any distro, not just Gentoo/CrOS.  people would have to do the same juggle you describe in comment #5.

Yes, all distros do some juggle to get this built.

... so can we fix this ?  requiring one of the libs to be rebuilt from scratch isn't ideal.

What Chrome (browser) does now is describe in 

https://chromium.googlesource.com/chromium/src.git/+/7619f01f1fa10674df56b9921df2f94718478201

What Chrome did before that is described in 

https://chromium.googlesource.com/chromium/src.git/+/a377e3e1fa4f44a58f70abb2402e6cc79e210945

if the upstream projects can't figure out how to link against each other sanely, the only thing i can think of on our side is to create a custom ebuild that downloads & builds the two packages and does all the hacks itself.

re comment 12:

I guess that's similar to what Chromium does now. Perhaps, Gentoo upstream should consider it because FreeType has to rely on Harfbuzz to hint fonts for complex scripts (Latin is complex, too :-) ) automatically. 

I'll file a bug in the Gentoo bugzilla. 


Currently, Chrome ignores built-in hint instructions for *web fonts* on Linux/CrOS and relies on FreeType's autohinting. For that reason, Google Web Fonts send down unhinted fonts to Linux (saving bandwidth is another obvious reason for that). 


Another alternative is to link FreeType+HarfBuzz statically to CrOS Chrome instead of dynamic linking to the OS copy (as is done on other platforms) and drop HarfBuzz from the cros image. 

This is assuming that the only user of Harfbuzz on CrOS is Chrome. In case of FreeType, ghostscript uses it (among potentially other things) so that we have to keep it around and pay for the duplicated copy of FreeType (standalone and as a part of Chromium binary). 

If harfbuzz is necessary outside Chrome browser, it also has to be kept around.  

If we do the 2nd (static linking + separate copies as necessary for non-Chrome binaries), the size impact would be about 1.3MB.  

libharfbuzz: 649 kB
libfreetype: 657 kB

i would like to say 1.3MB is no big deal, but currently i don't think that's the case :(

I forgot that we have Dejavu fonts still around. We may just drop them and can recoup well over 1.3MB.  

1. Remove Dejavu fonts
2. Make Chrome on Chrome OS link Harfbuzz+FreeType combo statically
3. Keep separate copies of libharfbuzz so and libfreetype.so for GS and other non-Chrome consumers. 

This is more or less what Chrome on Linux does.  

Dominik, am I right on this?  

In Chrome on Linux, I don't think we have other clients, so we have only one build. In the unbundled build for Linux distros or in certain rare configurations, we can use system HarfBuzz and FreeType in which case we lose ligatures and complex scripts autohinting. 

If Chrome OS release managers are fine in terms of the binary size swap/trade, it may be feasible like you suggest. I cannot judge whether DejaVu is needed on Chrome OS - for fallback or the like. (It has a rather large coverage.)

I hope this answers your question.

Upstreams cannot figure this out. If you have any suggestions I like to hear.

Thank you, Dominik !

> In Chrome on Linux, I don't think we have other clients,

By other clients, I meant binaries (other than Chrome) that rely on FreeType (or Harfbuzz). On Chrome OS, ghostscript is one of them.  GS is and will be dynamically linked to system freetype. 


My main concern was whether there's been any issue with the co-existence of Chrome with FT/HB combo statically linked and system FT/HB (shared libraries).  Apparently, not. 
(in the past, when HB was statically linked to Chrome and Chrome used dynamically linked Pango which was in turn linked to system HB, there's a bit of issue to work around as you remember). 

Then, it should work for Chrome OS, too. 

> whether DejaVu is needed on Chrome OS - for fallback or the like. (It has a rather large coverage.)

Noto font family's character coverage is much larger than Dejavu :-). So, I hope dropping Dejavu has little impact. When variable fonts are enabled, Dejavu's advantage in width coverage (condendesed support) would be moot as well. 

An alternative to drop DejaVu is to just wait for a couple of months until the rootfs has more free space with a big chunk moving out of it. 

as long as Chrome doesn't link to anything else that uses freetype/harfbuzz, statically linking them in Chrome itself shouldn't cause any runtime issues.  there is "just" the matter of disk space & runtime RAM wastage.

as i noted in comment #12, since we maintain freetype & harfbuzz ebuilds ourselves already in our overlay, we could add one ebuild that deals with upstream's broken build logic.

if Dejavu fonts aren't being used right now, sounds like a good time to delete them regardless.

> as long as Chrome doesn't link to anything else that uses freetype/harfbuzz, statically linking them in Chrome itself shouldn't cause any runtime issues

Yup. In the past, Chrome on Linux used Pango which is dynamically linked to Harfbuzz while it was also statically linking HarfBuzz. And, there was an issue. Chrome does not use use Pango any more.  My question earlier was to make sure that there's no such issue with other things that I don't know of.

> as i noted in comment #12, since we maintain freetype & harfbuzz ebuilds ourselves already in our overlay, we could add one ebuild that deals with upstream's broken build logic.

Thanks for the suggestion. That's certainly an alternative to what I wrote in comment 15.  The reason I like the comment 15 approach better is

1) I don't have to chase the latest version of FreeType/HarfBuzz any more for features/bug fixes for Chrome OS (because Chrome does that :-) ). For Ghostscript, I still have to be mindful of security fixes, though and cherry-picking security only fixes is rather tricky. So, this point is kinda moot.

2) I don't have to tinker with ebuild syntax to write a FT+HB combo ebuild.

A question about this:  Is it possible to do something like this in a FT+HB ebuild? 

   a. build FreeType without HB dependency
   b. build HB (with FT dependency) and install
   c. build FreeType again with HB dependency and install

> Yup. In the past, Chrome on Linux used Pango which is dynamically linked to Harfbuzz while it was also statically linking HarfBuzz. And, there was an issue. Chrome does not use use Pango any more.  My question earlier was to make sure that there's no such issue with other things that I don't know of.

I don't think the Pango dependency is completely removed in Chrome on Linux at least. But we have it under control by prioritizing our own HarfBuzz+FreeType, compare https://cs.chromium.org/chromium/src/chrome/browser/ui/libgtkui/BUILD.gn?type=cs&q=pango+harfbuzz&l=104

> A question about this:  Is it possible to do something like this in a FT+HB ebuild? [...]

Could you merge FreeType and HarfBuzz to one ebuild project and build them together, similar to what we do for Chrome?

if you wrote a custom FT+HB ebuild, you could anything you wanted in its workdir.  you wouldn't be able to install it to the sysroot, but nothing is stopping you from running the HB/FT configure scripts and telling them to use the compiled files in the workdir.

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/c987705b527c34ca4612810c284f157fa913c396

commit c987705b527c34ca4612810c284f157fa913c396
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed May 09 01:16:48 2018

hterm: add Noto Sans Mono to the default font list

CrOS is dropping DejaVu in favor of Noto, so add Noto to the search
list.  We put it behind DejaVu in the list so we don't change the
defaults on most users.

BUG= chromium:694137 ,chromium:718724

Change-Id: I1fba0109597b293f99d5d77f8a5e14904a1c4563
Reviewed-on: https://chromium-review.googlesource.com/1049412
Reviewed-by: Dan Erat <derat@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/c987705b527c34ca4612810c284f157fa913c396/hterm/js/hterm_preference_manager.js

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

commit d28166eb4026634bd397a5b91c5cceb64d97a15e
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue May 22 10:19:23 2018

Bundle FreeType/Harfbuzz with Chromium browser

To make FreeType's autohinting work properly (even Latin script),
HarfBuzz and FreeType need to be built to depend on each other.
It's tricky to do that right, but Chromium solved that puzzle
and includes FreeType-Harfbuzz. CrOS can benefit from them by
using a bundled copy of FreeType and HarfBuzz in Chromium browser.

Moreover, FreeType and HarfBuzz are rather frequently updated in
Chromium. By using Chromium's copy, this CL gets rid of the need
for chasing Chromium.

Non-Chromium parts of CrOS does not need as frequent FreeType/HarfBuzz
update as Chromium.

BUG= chromium:694137 
TEST=Chrome binary does not depend on freetype/harfbuzz and can render
text.

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

[modify] https://crrev.com/d28166eb4026634bd397a5b91c5cceb64d97a15e/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

This is fixed. So no more need for manual update of FT and Harfbuzz. We can get them updated for free from Chrome :-). 

Now we can get rid of hint instructions from our fonts and add variational fonts. 

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

commit 5dc2d92ffbdf38612359901953a86930e85dc3e7
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Jan 08 03:41:03 2019

Drop DejaVu fonts

Noto font family covers more than what's covered by DejaVu. We'd
not need DejaVu any more. A follow-up to this CL will add Noto
variable fonts to support condensed width variants.

This frees up 8.9M diskspace, some of which will be reclaimed
for variable font support (see crbug.com/747459 ). This
reduction also makes up for the size increase (1.2M) due to
statically linking HarfBuzza and FreeType to Chromium browser
(https://crrev.com/c/1050389 ).

Because the dejavu font package is pulled in by virtual/ttf-fonts
in portage, it's overriden by a copy in chromiumos-overlay that only
depends on chromeos-base/chromeos-fonts.

In fontconfig, delete 45-latin and 60-latin that refer to Dejavu
fonts and other fonts not installed on Chrome OS.

10-antialiasing is not available any more and anti-aliasing is ON
by default so that there's no need to add it. Delete the lines for
them in the fontconfig ebuild.

BUG= chromium:694137 ,chromium:747459
TEST=No new "tofus" in web pages of rarely used scripts.
Change-Id: I92f69ccce43c8120751057ac1ba5a12e5933f2ea
Reviewed-on: https://chromium-review.googlesource.com/1048320
Commit-Ready: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[add] https://crrev.com/5dc2d92ffbdf38612359901953a86930e85dc3e7/virtual/ttf-fonts/ttf-fonts-1-r1.ebuild
[rename] https://crrev.com/5dc2d92ffbdf38612359901953a86930e85dc3e7/chromeos-base/chromeos-fonts/chromeos-fonts-0.0.1-r38.ebuild
[rename] https://crrev.com/5dc2d92ffbdf38612359901953a86930e85dc3e7/media-libs/fontconfig/fontconfig-2.13.0-r9.ebuild
[modify] https://crrev.com/5dc2d92ffbdf38612359901953a86930e85dc3e7/media-libs/fontconfig/files/local.conf
[modify] https://crrev.com/5dc2d92ffbdf38612359901953a86930e85dc3e7/chromeos-base/chromeos-fonts/chromeos-fonts-0.0.1.ebuild