I can confirm this behavior, using chromium v53.0.2785.116 and freetype v2.7 (on Arch Linux).

Happen to know if this is supposed to work?

Out of curiosity, ju.orth, would you have an example string of what this variable was set, too? 

However, I am closing this as WontFix, this is a not a way of configuring our rendering path that we currently support.

>this is a not a way of configuring our rendering path that we currently support

I don't understand what you mean by this. FREETYPE_PROPERTIES affects the freetype library only. Chromium does not have to do anything besides not clearing the environment variables. It seems completely arbitrary that chromium allows me to change the behavior of fontconfig, which is configured via configuration files, but not the behavior of freetype, which is configured via environment variables.

>Out of curiosity, ju.orth, would you have an example string of what this variable was set, too? 

----
~$ cat /etc/profile.d/freetype2.sh 
# Subpixel hinting mode can be chosen by setting the right TrueType interpreter
# version. The available settings are:
#
#     truetype:interpreter-version=35  # Classic mode (default in 2.6)
#     truetype:interpreter-version=38  # Infinality mode
#     truetype:interpreter-version=40  # Minimal mode (default in 2.7)
#
# There are more properties that can be set, separated by whitespace. Please
# refer to the FreeType documentation for details.

# Uncomment and configure below
export FREETYPE_PROPERTIES="truetype:interpreter-version=35"
----

Thanks for the details. I believe the security sandbox of the renderer process shields it from access to environment variables (haven't verified this). This is why this variable does not have any effect on FreeType's hinting mode.

I've filed a bug with freetype to allow the configuration via files: https://savannah.nongnu.org/bugs/index.php?49187

I consider it a *very* bad idea that the FREETYPE_PROPERTIES environment variable gets ignored.  The transition from v35 to v40 TTF rendering in FreeType is a very visible change, and there are certainly users who wan't the old behaviour back.

If you insist on Chromium's current behaviour please provide a command line option that provides the same functionality.

Thanks, Werner, for your input on this. I'll reopen the issue, but can't promise anything at the moment - we need to see how and if we can make this user configurable. 

drott, I tested chrome without chrome-sandbox installed. Without chrome-sandbox, all environment variables are preserved in every chrome processes (by "ps e" or "cat /proc/xxx/environ"). Even so, the font of chrome still can't be affected by changing the value of REETYPE_PROPERTIES.

Thanks for the additional observation.

bungeman@ for Skia. 
bug 654563 is about adjusting rendering parameters on CrOS. 

Interestingly, what's in /proc/xxx/environ probably doesn't make much difference to 'getenv' (what FreeType is using), since when Chromium forks a subprocess it re-writes the 'environ' global after the fork, overwriting whatever the runtime startup set 'environ' to be ('getenv' reads from 'environ'). See https://cs.chromium.org/chromium/src/base/process/launch_posix.cc?sq=package:chromium&dr=CSs&rcl=1476184839&l=75 for where this appears to be handled. May want to get someone who understands that code on this issue to get a better overview.

Fixed in Skia. I can try to verify it once Skia rolls past the fix in Skia commit 2a098d09edfb. 

I believe this is now fixed. I tested with current Chromium Dev 59.0.3067.0 and a build of FreeType at current master eb0683129bc5 . Turned on "Experimental Web Platform features" and ran Chromium Dev with LD_LIBRARY_PATH pointing at my local FreeType build and with FREETYPE_PROPERTIES=truetype:interpreter-version= set alternately to 35 and 40. I then created a small page using the "Selawik Variations" font with the text "\ttversion". The actual displayed glyphs correctly showed "35" or "40" as appropriate.

Great, nicely done. We should perhaps use Selawik or approaches like in Selawik for testing gasp as well - if possible - perhaps using the \ttmode ligature.

Regarding the display of the current bytecode interpreter version: You might also have a look at

  https://www.freetype.org/freetype2/docs/rasterinfo/rasterinfo.html

Thanks for pointing out the rasterinfo font. I remember having seen it and it was the font I was originally looking for. I'll just have to remember it's at the bottom of the "Documentation" page for FreeType.

Sound likes I've posted a dupe,  bug 743063 , but I can reproduce this problem in Fedora 26 x86-64 and Freetype freetype-2.7.1-9.fc26.x86_64

FREETYPE_PROPERTIES=truetype:interpreter-version=35 is exported for the entire X session yet Google Chrome ignores it.

From https://www.freetype.org/freetype2/docs/rasterinfo/rasterinfo.html

The version of the TrueType bytecode interpreter (‘1’): 40

The Skia change was https://skia.googlesource.com/skia/+/2a098d09edfb7f02139a9537df6f1c0ac514fd74 and the required FreeType change is http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=693f56ffcdb91512b1d40ac45b1c503bef978b81 .

freetype$ git describe --contains 693f56ffcdb91512b1d40ac45b1c503bef978b81
VER-2-8~161
freetype$ git describe 693f56ffcdb91512b1d40ac45b1c503bef978b81
VER-2-7-1-46-g693f56ff

The Skia change is in Chromium, but your FreeType will need to be 2.8 or later (or cherry-pick in this change).

 Issue 743063  has been merged into this issue.

With FreeType 2.8.1 and chromium 60.0.3112.90 I still have this problem. I set FREETYPE_PROPERTIES="truetype:interpreter-version=35" , and I can even see it in /proc/($pidof chromium)/environ. I also straced chromium to be sure it was loading my newly-built-from-source libfreetype.so.6.15.0. But on the rasterinfo page I still see "The version of the TrueType bytecode interpreter (‘1’): 40" and my fonts still hint incorrectly. (As a sanity check, I grepped both the chromium binary and the libfreetype.so for FT_Set_Default_Properties, and both matched.)

Any ideas what might be wrong?

Deleted: chromiumfont.png 1023 bytes

	chromiumfont.png 1023 bytes View Download

Do you have a custom built of Chromium that loads system FreeType? In our Chrome Linux release we ship our own. Are you sure both interpreter levels are built into the libfreetype.so.6.15.0 that you built? 

Did you try FREETYPE_PROPERTIES with the official Chrome build? 
 

Thanks #25! It actually works great in google-chrome-stable 60.0.3112.90 . I was using the version of chromium built by nix, so I will have to try to investigate how it was built. (And it's certainly possible that I didn't build my libfreetype correctly.)