xterm-352 and x11-fonts/iosevka

Thomas Dickey dickey at his.com
Fri Jan 24 00:31:08 UTC 2020


On Thu, Jan 23, 2020 at 06:46:05PM -0500, Thomas Dickey wrote:
> On Thu, Jan 23, 2020 at 10:07:04PM +0300, Yuri Pankov wrote:
> > Hi,
> > 
> > After updating xterm to version 352, x11-fonts/iosevka is rendered as if
> > being twice as wide; reverting to 351 makes everything look normal.
> > 
> > Relevant entries from .Xresources (same with using -fa option):
> > 
> > UXTerm*faceName: Iosevka
> > UXTerm*faceSize: 18
> > 
> > Anyone seeing the same and has any hints on the problem/fix?
> 
> I'll look into it (I can see a difference).

The likely cause is this change:

     * improve  checkXft  logic  which  attempts  to  detect  fonts whose
       max-advance-width  is  inconsistent  with the actual glyph widths.
       For  some  fonts,  it  is necessary to check additional characters
       (report/analysis by Jan Engelhardt).

Before, xterm checked only the widths of the first 256 codepoints.
Jan reported a case where line-drawing in a given font was not correct,
and suggested that the fix would be to check the whole range of characters.
That was not a good idea (since it would be slow), but I compromised to
check up to U+3000

Looking at the font in xfd, I can see the problem.

On the page beginning 0x002700 (U+2700), there is a group of double-width
glyphs from 0x2776 to 0x277f, where xterm expects single-width characters.

In Unicode, those are "ambiguous width", which means that the font isn't
exactly _wrong_, but it's not very useful without telling xterm to use
a different assumption about the font:

       -cjk_width
               Set the cjkWidth resource to “true”.  When turned on,
               characters with East Asian Ambiguous (A) category in UTR 11
               have a column width of 2.  Otherwise, they have a column width
               of 1.  This may be useful for some legacy CJK text terminal-
               based programs assuming box drawings and others to have a
               column width of 2.  It also should be turned on when you
               specify a TrueType CJK double-width (bi-width/monospace) font
               either with -fa at the command line or faceName resource.  The
               default is “false”

       -fa pattern
               This option sets the pattern for fonts selected from the
               FreeType library if support for that library was compiled into
               xterm.  This corresponds to the faceName resource.  When a CJK
               double-width font is specified, you also need to turn on the
               cjkWidth resource.

Not all fonts are even that good - last year I was testing against some
font which ignored the distinction altogether and made all of the symbols
double-width.

I'll probably add a resource-setting for the range to test, since
	a) U+3000 is too arbitrary, and
	b) users might prefer the old behavior...

It might also improve things to factor in the ambiguous-width codepoints
(but won't help with the case I mentioned above though).  Doing that would
probably restore the old behavior for you, though attempting to display
ambiguous-width characters with the existing locale support would be
futile...

-- 
Thomas E. Dickey <dickey at invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20200123/81af2206/attachment.sig>


More information about the freebsd-x11 mailing list