Since recently the LCD filter weights can be tuned by specifying the numbers[1].
Maybe that needs to be exposed through fontconfig and Xsettings and Cairo, etc.


It is important to note that not all combinations make sense together. The current presets »Best Shapes« and »Best Contrast« don’t make a lot of sense.

The Byte-Code Interpreter is also available to enable by all distros from now on. We should add this option explicitly. But BCI is not compatible with all of the other options. There should be some logic behind it. 

The most insightful proposal for a revamped font dialog came from David Turner years ago. I quote:


,----(by: David Turner <david <at> freetype.org> on  2007-02-05 00:19:57 GMT)
,     see http://article.gmane.org/gmane.comp.lib.cairo/9347/

Also, I don't use the bytecode interpreter on my own FreeType builds, and
the libXft filter *totally* sucks in this case, the color fringes are too
obvious to go unnoticed. At least the default filter gives consistent results,
independent of the hinting technology being used. And it also looks good on
CRT screens.

Also, I think a revamp of the desktop font rendering preferences is needed;
I have not dug the question a lot, but I'd like to replace the current scheme with
something like the following (a + denotes a radio button, a ? a checkbox,
a <XXX> is a spinner/numeric entry, and a = entries in a single combo box):

  text rendering:
    + best shapes
    + best contrast
    + use native TrueType hints
        ? optimized TrueType anti-aliasing
          disable anti-aliasing for sizes under: <NNN>

  text anti-aliasing    = standard
                        = light
                        = best for CRTs

  LCD display type      = standard (RGB)
                        = mirrored (BGR)
                        = rotated  (VRGB)
                        = rotated mirrored (VBGR)

main ideas behind this interface:

- LCD rendering is the default, unless disabled by your FreeType build,
  or if the user selects "best for CRTs"

- there is no point in having a "monochrome" rendering mode, like we
  do currently, it just looks ugly unless you have activated native
  TrueType hints, so make this explicit in the interface.

  Also, this gets rid of the big confusion in the current scheme regarding
  "light/medium/full" hinting. In "gray" renderig, medium==full, while
  for LCD rendering, "full != medium", and full hinting produces very slightly
  crisper glyphs with sometimes atrocious diagonals, and is thus not
  recommended at small sizes.

  monochrome rendering is only useful with native TrueType hints so make
  it apparent. Using a numeric value as the size selector allows best of
  both worlds.

- "optimized TrueType aliasing" really means use the libXft/legacy filter,
  but the user doesn't need to know this level of detail. It would *only*
  apply to TrueType fonts. Possibly, we would want to filter the fonts it
  would apply to, because there is a large number of fonts available with
  none-to-average hints that render more poorly with this filter.

- if the bytecode interpreter is not activated in your FreeType build,
  the "use native TrueType hints" line and its dependent elements are
  gray-ed out. If the user hovers it, a popup explains that this is due
  to patent reasons

- "LCD Display Type" would be gray-ed out when "best for CRTs" is
  selected, of if the build doesn't support LCD rendering (need a
  way to explain that, probably a popup on hover)

All of this is doable, but would probably require a new fontconfig
enumeration option. I'll try to do a prototype one day...

‘
‘---end quote


[1] http://sourceforge.net/projects/freetype/files/freetype2/2.4.0/NEWS/view

This bug hasn't received any action for several years. Is there anything that needs to be done now?

IMHO Gnome 3.x went backwards on this vs Gnome 2.x

When the bug was reported it was possible to configure the font appearance in Settings (or 'gnome-appearance-properties'). Now in 3.x it's only in gnome-tweak-tool, which is really a step backwards because it's a significant setting users should have more direct access to in Settings.

So yes the bug is still valid, but also more significant than when it was first logged.

Daniel, you might be better off filing a new bug or working with the GNOME Design Team on which specific font settings you want in gnome-control-center.

Otherwise, unless someone has specific font settings they want added to gnome-tweak-tool, this bug will eventually be closed.

Yes sorry, that was off-topic.

Back on topic:

gnome-tweak-tool is today still missing subpixel order selection (org.gnome.settings-daemon.GsdFontRgbaOrder). That's the second thing mentioned in the bug description at the top. That's actually important for some people as BGR LCDs etc do exist, as do pentile LCDs.

The first thing mentioned in the bug description is a bit harder I think; "choice between the autohinter and bytecode interpreter". Sounds good, but is there even a schema for that yet?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/14.