#StackBounty: #x11 #fonts #x-resources #dpi #high-dpi X Logical Font Description and HiDPI

Bounty: 50

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), but as an XLFD. If we are talking about a local machine, then the same font file can be registered in both font backends 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, there were raster server-side fonts (*.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 (PIXEL_SIZE), the raster resolution must be close to the screen resolution, therefore raster fonts were usually shipped with native resolutions of 75dpi and 100dpi (that’s why we still 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

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

But, in addition to raster 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 Linux 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 12pt 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, after migration from 96…115dpi monitors to a 162dpi 4k monitor, I noticed that my carefully selected 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 would 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 100dpi 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:

Debian 10, Courier New 12pt at 162dpi

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:

Debian 3, Courier New 12pt at 162dpi

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 pain than recommended by the author of the Sharing Xresources between systems article?

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)?


Get this bounty!!!

#StackBounty: #fonts #xorg #dpi #x-windows #high-dpi X Logical Font Description and HiDPI

Bounty: 50

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), but as an XLFD. If we are talking about a local machine, then the same font file can be registered in both font backends 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, there were raster server-side fonts (*.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 (PIXEL_SIZE), the raster resolution must be close to the screen resolution, therefore raster fonts were usually shipped with native resolutions of 75dpi and 100dpi (that’s why we still 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

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

But, in addition to raster 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 Linux 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 12pt 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, after migration from 96…115dpi monitors to a 162dpi 4k monitor, I noticed that my carefully selected 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 would 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 100dpi 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:

Debian 10, Courier New 12pt at 162dpi

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:

Debian 3, Courier New 12pt at 162dpi

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 pain than recommended by the author of the Sharing Xresources between systems article?

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)?


Get this bounty!!!

#StackBounty: #godot #fonts How to draw text with characters rendered in reverse order in a Godot game?

Bounty: 50

I need to have some text showing up in my Godot game in a way that each character overlaps the character directly to its right, like so:

     -- ---    -- --
   /  /      |  |  |
  /  /       |  |  |
 /  /  /---    |   ----
/  /  /       |       |
-- --     -- -- - -------

Using a BMFont (.fnt) in a Label node with the values of xadvance specified in the font smaller than the characters width I get this:

     -- ---    -- --
   /  /      |  |  |
  /  /       |  |  |
 /  /  /---  |  |   ----
/  /  /     |  |       |
-- --     -- -- - -------

What approach can I use to still be able to use my .fnt font and also store the text with the characters in their natural order, as it would be stored for using with a normal Label or Button control? Which would help for language localization purposes.


Get this bounty!!!

#StackBounty: #fonts #xetex #fontspec Latin Modern main font with bold small capitals from CMU Serif

Bounty: 100

I want to use bold small capitals from CMU Serif while setting Latin Modern as my main font.

Minimal working example

documentclass{report}
usepackage{mathspec}

setmainfont{Latin Modern Roman 10 Regular}[
    BoldFeatures = {SmallCapsFont = {CMU Serif Bold}},
    SmallCapsFont = Latin Modern Roman Caps]

begin{document}

Roman. textbf{Bold.} textsc{Small capitals.} 
textbf{textsc{Bold small capitals.}}

end{document}

Output

Output

Errors

Errors

How can I resolve these errors? Bold small capitals from CMU Serif work fine when I’m not using fontspec.


Get this bounty!!!

#StackBounty: #fonts #symbols How to access alternative shapes (e.g. `altS`) in `mtpro2`?

Bounty: 100

I am able to access the normal shapes without loading mtpro2 (I have the full package including all the fonts) by defining

newcommand{Mathscr}[1]{text{usefont{U}{mt2ms}{m}{it}#1}}

and using the command inside an equation, e.g. $Mathscr{S}$. The problem is that I don’t know how to access the alternative shapes, e.g. altS (see here, Section 2.8).

If I open the style file, e.g. here, there are a few definitions including those for the alternative shapes, but how can I access those by modifying my Mathscr command? (or also defining altS on its own in the preamble)


Edit: Alternatively, is it possible to access the alternative shapes via mathalfa?


Get this bounty!!!

#StackBounty: #fonts #root-access How to install new font on Android 10 and set it as default monospaced?

Bounty: 50

I’d like to change the default monospaced font on my rooted Android phone. This is because of things like this, where characters don’t render correctly:

enter image description here

The rectangle is supposed to be the "ɒ" character. I know that it works with Deja Vu Sans Mono, so I’d like to change the monospaced font to that.

I’ve seen methods that change the system default font, but not specifically the default monospaced one.

Some more information:

  • Android 10, rooted
  • Oneplus 7


Get this bounty!!!

#StackBounty: #fonts #symbols How to access alternative shapes (e.g. `altS`) in `mtpro2`?

Bounty: 100

I am able to access the normal shapes without loading mtpro2 (I have the full package including all the fonts) by defining

newcommand{Mathscr}[1]{text{usefont{U}{mt2ms}{m}{it}#1}}

and using the command inside an equation, e.g. $Mathscr{S}$. The problem is that I don’t know how to access the alternative shapes, e.g. altS (see here, Section 2.8).

If I open the style file, e.g. here, there are a few definitions including those for the alternative shapes, but how can I access those by modifying my Mathscr command? (or also defining altS on its own in the preamble)


Edit: Alternatively, is it possible to access the alternative shapes via mathalfa?


Get this bounty!!!

#StackBounty: #html #css #fonts #font-awesome Font Awesome inline within single, portable HTML file

Bounty: 200

I have an HTML file that is supposed to be portable as in just an HTML file and nothing else. This means I usually inline all styles/scripts in their content and it works quite well. I usually link to CDN content if I want to keep HTML clean, but often for offline use, I embed everything. All CSS/All JS there is to include goes directly to header/footer/body.

I’ve done exactly the same thing for Font Awesome which is a bit problematic because except CSS file I needed to convert woff/woff2 font files that normally stay next to them into a binary representation.

This is how it normally looks:

@font-face {
  font-family: 'Font Awesome 5 Brands';
  font-style: normal;
  font-weight: 400;
  font-display: block;
  src: url("../webfonts/fa-brands-400.eot");
  src: url("../webfonts/fa-brands-400.eot?#iefix") format("embedded-opentype"), url("../webfonts/fa-brands-400.woff2") format("woff2"), url("../webfonts/fa-brands-400.woff") format("woff"), url("../webfonts/fa-brands-400.ttf") format("truetype"), url("../webfonts/fa-brands-400.svg#fontawesome") format("svg"); }

.fab {
  font-family: 'Font Awesome 5 Brands';
  font-weight: 400; }
@font-face {
  font-family: 'Font Awesome 5 Free';
  font-style: normal;
  font-weight: 400;
  font-display: block;
  src: url("../webfonts/fa-regular-400.eot");
  src: url("../webfonts/fa-regular-400.eot?#iefix") format("embedded-opentype"), url("../webfonts/fa-regular-400.woff2") format("woff2"), url("../webfonts/fa-regular-400.woff") format("woff"), url("../webfonts/fa-regular-400.ttf") format("truetype"), url("../webfonts/fa-regular-400.svg#fontawesome") format("svg"); }

.far {
  font-family: 'Font Awesome 5 Free';
  font-weight: 400; }
@font-face {
  font-family: 'Font Awesome 5 Free';
  font-style: normal;
  font-weight: 900;
  font-display: block;
  src: url("../webfonts/fa-solid-900.eot");
  src: url("../webfonts/fa-solid-900.eot?#iefix") format("embedded-opentype"), url("../webfonts/fa-solid-900.woff2") format("woff2"), url("../webfonts/fa-solid-900.woff") format("woff"), url("../webfonts/fa-solid-900.ttf") format("truetype"), url("../webfonts/fa-solid-900.svg#fontawesome") format("svg"); }

.fa,
.fas {
  font-family: 'Font Awesome 5 Free';
  font-weight: 900; }

This is its binary representation (just a few lines as it’s quite large)

@font-face {
    font-family: 'Font Awesome 5 Free';
    font-style: normal;
    font-weight: 900;
    font-display: block;
    src: url("../webfonts/fa-solid-900.eot?");
    src: url("../webfonts/fa-solid-900.eot?#iefix") format("embedded-opentype"), url("data:application/font-woff2;charset=utf-8;base64,d09GMgABAAAAATmsAA0AAAADHuwAATlSAUuFYAAAAAAAAAAAAAAAAAAAAAAAAAAAP0ZGVE0cGh4GYACZThEICor0YIjOQAE2AiQDnzALnzQABCAFiisH4i5bMnuSATLvp1Eyvq0KTDRu5CummzsFug2g5kWqjHSuhDve3Urk1BBxZf////+/72iIOaWzdbZjx

I’ve skipped including EOT/TTF/SVG (removed src for them) and simply replaced WOFF2/WOFF as that’s supposed to be enough for modern support.

And it is! It works. However only in one way.

<style>
    .login::before {
        font-family: "Font Awesome 5 Free";
        font-weight: 900;
        content: "f007";
    }

    .tps::before {
        font-family: "Font Awesome 5 Free";
        font-weight: 400;
        content: "f1ea";
    }

    .twitter::before {
        font-family: "Font Awesome 5 Brands";
        content: "f099";
    }
</style>
<span class="twitter"></span>

Above code works

<span class="fas fa-camera"></span>

Above code doesn’t work. This is how it looks (first 3 are using <style> approach):

enter image description here

If I switch to online using

<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.1/css/all.min.css" as="style" type="text/css" rel="stylesheet preload prefetch" />

It works both ways which leads me to think there is a difference between those 2 ways of using Font Awesome. I tried to build it in a 3rd way thinking I may just need to change how I define things but using something like this didn’t go well.

<span style='font-family: "Font Awesome 5 Brands"; content: "f099"; font-weight: 400;'></span>

When I checked the source of all.css the style just defines this:

.fa-twitter:before {
  content: "f099"; }

My 3 questions:

  1. What is the difference between methods using <style></style>, which basically wraps the same thing that all.css does already, and using class "fab fa-twitter"
  2. Any clue why it’s behaving differently for those 2?
  3. Any workaround?


Get this bounty!!!

#StackBounty: #microsoft-word #pdf #fonts #adobe-acrobat How to enable non-English text copying from PDF file?

Bounty: 100

I converted a MS Doc file to a PDF file. If the file contains English then, one can copy text from the converted PDF file. But if the file contains language other than English, and someone tries to copy that non-English text from the converted PDF file, and paste it to a MS doc file, then the pasted text becomes gibberish.

What is the solution?

I tried with Adobe Acrobat and Foxit reader to convert Doc file to PDF file. Also when I save MS Doc file, I keep tick on the Embed fonts in the file in Save.

For example, I write the below line in Mangal font in MS Word

बिहार विधानसभा चुनाव में एक बार फिर एनडीए की सरकार बनती नजर आ रही है।

I convert the file using Foxit reader, when I copy the text from PDF file and paste it to search bar or MS Word, I get –

बहार वधानसभा चुनाव म एक बार फर एनडीए क सरकार बनती नजर आ रह है।

What is the remedy?


Get this bounty!!!

#StackBounty: #kubuntu #fonts #inkscape #texlive PFB fonts are broken in certain applications and missing in others (Kubuntu 20.04)

Bounty: 100

I am running Kubuntu 20.04. I have a problem where certain fonts (Courier and Century Schoolbook L) are broken in applications like Inkscape (where they are invisible) or font-manager where they show like this:
Font-manager with broken fonts

They also don’t show up in Libre office (Don’t really care about this as I rarely touch word-processors).

All broken fonts are .pfb fonts installed through TeX-live or ghostscript. As the font is already installed I am not able to install TTFs of the font I need. Obviously I do not want to uninstall ghostscript or tex-live as I use them regularly.

I have tried running

sudo fc-cache -f -v

to no avail. The font show up find in KFontView:
enter image description here

The bug is particularly frustrating as I have existing artwork in inskcape which used courier and Century Schoolbook L.


Get this bounty!!!