83 lines
3.3 KiB
Plaintext
83 lines
3.3 KiB
Plaintext
|
||
|
||
<p><strong>UPDATE 2019-07-01:</strong> I submitted a bug report. <a href="https://protesilaos.com/codelog/2019-07-01-xterm-greek-pi-bug/">Details
|
||
here</a>.</p>
|
||
|
||
<p><strong>UPDATE 2019-06-01:</strong> Upon further inspection, I am using the following
|
||
font-related settings, which address the issue discussed herein. Some
|
||
typefaces might still have <em>minor</em> issues with drawing boxes.</p>
|
||
|
||
<pre><code>! Font settings
|
||
! The font settings address the issue discussed in this blog post:
|
||
! https://protesilaos.com/codelog/2019-05-26-xterm-letter-pi-bug/
|
||
xterm*faceName: Hack,DejaVu Sans Mono,Monospace
|
||
xterm*faceSize: 9.5
|
||
xterm*renderFont: true
|
||
xterm*boldColors: false
|
||
xterm*faceSize1: 8
|
||
xterm*faceSize2: 12
|
||
xterm*faceSize3: 15
|
||
xterm*faceSize4: 18.25
|
||
xterm*faceSize5: 20.5
|
||
xterm*faceSize6: 25.5
|
||
xterm*forceBoxChars: false
|
||
xterm*limitFontsets: 3
|
||
xterm*scaleHeight: 1.0
|
||
</code></pre>
|
||
|
||
<p>Original text below…</p>
|
||
|
||
<hr />
|
||
|
||
<p>Given certain font configuration combinations, the current version of
|
||
Xterm on Debian ‘buster’ has problems displaying the lower case Greek
|
||
letter Pi (π). The terminal will print that letter form as a fixed font
|
||
while keeping everything else as a proportional font. The flow of text
|
||
breaks.</p>
|
||
|
||
<p>This behaviour is exhibited with a variety of typefaces (Debian package
|
||
in parentheses):</p>
|
||
|
||
<ul>
|
||
<li>Hack (fonts-hack)</li>
|
||
<li>IBM Plex Mono (fonts-ibm-plex)</li>
|
||
<li>Iosevka</li>
|
||
<li>Monoid (fonts-monoid)</li>
|
||
<li>Mononoki (fonts-mononoki)</li>
|
||
<li>Source Code Pro</li>
|
||
<li>Ubuntu Mono (fonts-ubuntu-console)</li>
|
||
</ul>
|
||
|
||
<p>A workaround is to define awkard point sizes when using one of the
|
||
offending typefaces, such as <code>10.5</code>, while also tweaking the
|
||
<code>scaleHeight</code> property. This, however, has an undesirable side effect:
|
||
it prevents tmux and other applications that draw boxes from creating
|
||
continuous lines for their borders. Lines appear dashed and, depending
|
||
on the distance between the dashes (and point size), may exhibit a “halo
|
||
effect” around them. Lines become blurry and outright annoying to stare
|
||
at.</p>
|
||
|
||
<p>DejaVu Sans Mono displays lower case Pi correctly at point size 10 (my
|
||
preferred choice), but has problems with drawing borders. Box drawing
|
||
can be fixed by tweaking its <code>size</code> and the <code>scaleHeight</code> property.
|
||
However, that prevents it from properly drawing Pi.</p>
|
||
|
||
<p>The only font family that faces no such trade-off is Fira Code, aka
|
||
<code>fonts-firacode</code> (based on Fira Mono, which is not in the Debian
|
||
archives). Fira {Code,Mono} prints minuscule Pi (π) in its proper form
|
||
and draws continuous lines as expected.</p>
|
||
|
||
<p>All of the above are based on the assumption that <code>forceBoxChars</code> is set
|
||
to <code>false</code>. Otherwise none of the afore-mentioned typefaces can pass
|
||
the test.</p>
|
||
|
||
<p>Modifying the <code>fontconfig</code> rules for aliasing and hinting causes other
|
||
undesired effects. Besides, it makes no sense to distort all letter
|
||
forms across the system for Xterm to draw Pi and box lines as expected.</p>
|
||
|
||
<p>I ultimately do not know what it is specifically about Fira {Code,Mono}
|
||
that lends to its adaptability in this scenario. I would assume it has
|
||
to do with the inherent proportions of its hyphen <code>-</code> and column <code>|</code>,
|
||
though this has not been researched further.</p>
|
||
|
||
|