'AW: X Logical Font Description and HiDPI'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    AW: X Logical Font Description and HiDPI
From:       Walter Harms <wharms () bfs ! de>
Date:       2021-02-04 9:05:24
Message-ID: 0bb4e83a2a93460b857eb7e27af71b4c () bfs ! de
[Download RAW message or body]

Hi Andrey,
not being an expert on X11 fonts i would like to condense
your question a bit;

when you use a scaleable font:
> -monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
> -monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1

you expect a font depending on you DPI setting ?

Die you ever change your DPI setting ? \
(https://linuxreviews.org/HOWTO_set_DPI_in_Xorg) you may try to set
Xft.dpi: 162 in you .Xdefaults and see what is happening (i know older programms work \
fine (most times))

re,
 wh
________________________________________
Von: xorg <xorg-bounces@lists.x.org> im Auftrag von Andrey ``Bass'' Shcheglov \
                <andrewbass@gmail.com>
Gesendet: Mittwoch, 3. Februar 2021 12:07:27
An: xorg@lists.x.org
Betreff: X Logical Font Description and HiDPI

Hello,

*The problem*: X-server serves fonts at a fixed resolution of 100dpi, rather than the \
current window system resolution (`xdpyinfo | grep -F resolution`).

*A bit of theory*. There are legacy server-side fonts which are sent to X clients \
over the network (via TCP or UNIX socket) either by the X server itself, or by a \
separate X Font Server (single or multiple). Unlike the usual client-side fonts (Xft, \
GTK 2+, Qt 2+), the "server" backend (also called the core X font backend) does not \
support anti-aliasing, but supports network transparency (that is, bitmaps, without \
any alpha channel, are sent over the network). At the application level, server-side \
fonts are specified not as an `XftFontStruct` (which most often translates into the \
familiar "DejaVu Sans Mono:size=12:antialias=true", see \
<https://keithp.com/~keithp/talks/xtc2001/paper/>), but as an XLFD \
<https://wiki.archlinux.org/index.php/X_Logical_Font_Description>. If we are talking \
about a local machine, then the same font file can be registered in both subsystems \
at once and be available to both modern GTK and Qt-based applications, and legacy \
ones (Xt, Athena, Motif, GTK 1.2, Qt 1.x).

Historically, server fonts were bitmap, or raster (*.pcf), and a raster has a \
resolution of its own (not necessarily the same as the window system resolution). \
Therefore, XLFD has fields such as RESOLUTION_X and RESOLUTION_Y. For a raster font \
not to look ugly when rendered onto the screen and still have the requested \
rasterized glyph size, the raster resolution must be close to the screen resolution, \
therefore raster fonts were usually shipped with native resolutions of 75 dpi and 100 \
dpi (that's why we have directories such as /usr/share/fonts/X11/75dpi and \
/usr/share/fonts/X11/100dpi). So, the below lines represent the same 12 pt font

> -bitstream-charter-bold-r-normal--12-120-75-75-p-75-iso8859-1
> -bitstream-charter-bold-r-normal--17-120-100-100-p-107-iso8859-1

with a rasterized glyph size of

 * 12 px at 75 dpi, and
 * 17 px at 100 dpi, respectively.

But, in addition to bitmap fonts, there are vector, or outline fonts (TrueType, \
OpenType, Adobe Type 1), which can be scaled by any factor and still look good when \
rendered onto the screen. Some X-server implementations (notably, XSun) also \
supported the Adobe Type 3 format, where glyphs were described using the \
Turing-complete PostScript language.

Of course, the concept of raster resolution does not apply to vector fonts, so I can \
request zeroes (`0`) or even asterisks (`*`) in the RESOLUTION_X and RESOLUTION_Y \
fields, and, in theory, my X server should give me exactly the font requested. This \
is directly stated in the _Arch Wiki_ article at the link above:

> Scalable fonts were designed to be resized. A scalable font name, as shown in the \
> example below, has zeroes in the pixel and point size fields, the two resolution \
> fields, and the average width field. 
> ...
> 
> To specify a scalable font at a particular size you only need to provide a value \
> for the POINT_SIZE field, the other size related values can remain at zero. \
> The POINT_SIZE value is in tenths of a point, so the entered value must be the \
> desired point size multiplied by ten.

So, either of the following two queries should return a 12 pt `Courier New` font at \
the window system resolution:

> -monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
> -monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1

*Or so I thought*. The thing is, having migrated from 96... 15 dpi monitors to a 162 \
dpi 4k monitor, I noticed that my carefully chosen vector fonts suddenly became too \
small.

And it turned out that unless you explicitly set RESOLUTION_X and RESOLUTION_Y fields \
to 162 (and no one in his right mind will do so -- it would require rewriting dozens \
of Xresources lines every time one changes his monitor), then X server defaults to \
rendering the font at 100 dpi instead of 162. The difference between 17 and 27 pixels \
(the factor of 1.62 = 162 / 100) is quite noticeable. Here's an example for a modern \
Debian 10 box: <https://habrastorage.org/webt/uq/m5/ej/uqm5ej9ys9ynb3vwanrqioayxns.png>.

I thought this regression was a consequence of people gradually cutting out obsolete \
subsystems from X11, but in Debian Woody, released in 2002 and having a 2.2 kernel, I \
saw exactly the same thing: \
<https://habrastorage.org/webt/j9/24/0r/j9240rroo5q9wasvpn8s9zhpjke.png>. The only \
difference is that Debian Woody renders fonts in a "cleaner" manner, apparently, \
applying hinting on the server side, before sending bitmaps over the network.

So this is not a regression. The problem has always been there and equally affects \
all vector font types (TrueType, OpenType, Type 1).

*Now, the question*. Is there a way, without hard-coding window system resolution \
into user settings for each individual resource, to get by with less effort than \
recommended by the author of the "Sharing Xresources between systems" article \
<https://jnrowe.github.io/articles/tips/Sharing_Xresources_between_systems.html>?

Is it possible to solve the problem by changing the global configuration of the X \
server itself or the libraries it relies on (libfreetype, libxfont)?

Regards,
Andrey.

_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[prev in list] [next in list] [prev in thread] [next in thread] 