Summary
On Linux, the packaged T3 Code AppImage does not render the embedded bitmap
strikes of fonts such as Terminus.
At a supported native size—Terminus at 16px—the AppImage appears to reconstruct
the glyphs from vector outlines. This produces malformed or inconsistent pixels
in compact interface text such as “No projects yet”.
This is not fixed by disabling antialiasing or subpixel positioning alone.
Before and after
These are 8× nearest-neighbor enlargements of the same 16px text captured from
the packaged AppImage. No interpolation was applied.
| Before: current AppImage rendering |
After: FreeType backend |
 |
 |
Steps to reproduce
- Install Terminus TTF.
- Launch the Linux AppImage.
- Open Settings → Appearance.
- Select Terminus for the interface font.
- Set the interface size to 16px.
- Inspect compact UI text such as “No projects yet”, particularly stems and
intersections in letters such as t, j, and y.
Expected behavior
At a size for which the font provides an embedded bitmap strike, Chromium should
render that strike without reconstructing or resampling the glyph outline.
Actual behavior
The packaged Electron renderer produces a different glyph mask:
- Current AppImage: 118×12 bounding box, 290 foreground pixels.
- Native Terminus bitmap: 118×13 bounding box, 240 foreground pixels.
After selecting Chromium’s FreeType backend, the AppImage produces a 118×13,
240-pixel mask that is pixel-for-pixel identical to native Pango/FreeType
rendering.
Technical findings
Chromium has an existing report stating that monochrome EBDT/EBLC bitmap strikes
do not render with the Fontations backend:
https://issues.chromium.org/issues/441128457
Launching the AppImage with the following feature selection fixes the embedded
bitmap rendering:
--enable-features=FontDataServiceLinux:typeface/Freetype
--disable-features=FontationsLinuxSystemFonts
For a completely aliased pixel-font mode, these switches also prevent coverage
and positioning effects:
--enable-blink-features=NoFontAntialiasing
--disable-font-subpixel-positioning
The FreeType backend selection is the part that fixes the malformed glyphs.
The antialiasing switches alone do not.
Summary
On Linux, the packaged T3 Code AppImage does not render the embedded bitmap
strikes of fonts such as Terminus.
At a supported native size—Terminus at 16px—the AppImage appears to reconstruct
the glyphs from vector outlines. This produces malformed or inconsistent pixels
in compact interface text such as “No projects yet”.
This is not fixed by disabling antialiasing or subpixel positioning alone.
Before and after
These are 8× nearest-neighbor enlargements of the same 16px text captured from
the packaged AppImage. No interpolation was applied.
Steps to reproduce
intersections in letters such as
t,j, andy.Expected behavior
At a size for which the font provides an embedded bitmap strike, Chromium should
render that strike without reconstructing or resampling the glyph outline.
Actual behavior
The packaged Electron renderer produces a different glyph mask:
After selecting Chromium’s FreeType backend, the AppImage produces a 118×13,
240-pixel mask that is pixel-for-pixel identical to native Pango/FreeType
rendering.
Technical findings
Chromium has an existing report stating that monochrome EBDT/EBLC bitmap strikes
do not render with the Fontations backend:
https://issues.chromium.org/issues/441128457
Launching the AppImage with the following feature selection fixes the embedded
bitmap rendering:
For a completely aliased pixel-font mode, these switches also prevent coverage
and positioning effects:
The FreeType backend selection is the part that fixes the malformed glyphs.
The antialiasing switches alone do not.