Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#61032 - [telegram-desktop] Telegram defaults to an ugly (most likely) monospace font

Attached to Project: Community Packages
Opened by Annonym (Hasbeen) - Tuesday, 11 December 2018, 13:04 GMT
Last edited by Jiachen Yang (farseerfc) - Wednesday, 12 December 2018, 16:31 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Jiachen Yang (farseerfc)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No


Since the patch (, which enables system-wide fonts was added, Telegram defaults to the fixed-width font even though I successfully used `qt5ct` to select a font of choice for other QT5 programs.
It should be noted that installing `ttf-opensans` from AUR restores Telegram back to the standard look prior to the patch. Neverthless, an AUR package, as I suppose, ought not to be mandatory for a program from the official "Community" repository and thus I don't count it as a solution.
Please correct me if I'm wrong or missing an obvious point in bringing the patch into effect.

Additional info:
* package version(s) `telegram-desktop` 1.5.0-2
* config and/or log files etc.

Steps to reproduce:
- Update to `telegram desktop` 1.5.0-2
This task depends upon

Closed by  Jiachen Yang (farseerfc)
Wednesday, 12 December 2018, 16:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  telegram-desktop 1.5.1-3 added a new optdepends=(ttf-opensans)
Comment by Annonym (Hasbeen) - Tuesday, 11 December 2018, 21:01 GMT
The patch is back in 1.5.1-2 and the font is same as before..
I should not have requested the task closure so early.
Comment by Lev Lybin (lybin) - Wednesday, 12 December 2018, 09:15 GMT
I confirm, ugly fonts after added patches.
Yep, after installing `ttf-opensans` from AUR restores Telegram back to the standard look prior to the patch.
These patches look like a hardcoded. I vote for remove it.
Comment by Konstantin (Pegasov) - Wednesday, 12 December 2018, 09:55 GMT
I confirm, fonts look ugly and installing ttf-opensans from AUR fixes it. However I believe fonts should look like the ones with ttf-opensans by default (as they did before patch)
Comment by Antonio Rojas (arojas) - Wednesday, 12 December 2018, 10:11 GMT
What is the point of this patch? It is called "use-system-wide-font", but what it really does is remove the link to the bundled Open Sans font (the font itself is still bundled) while still hardcoding the font name to "Open Sans". So of course this will break (or fallback to who knows what) if you don't have that font, which is not even available in our repos. Perhaps you meant to set the font to "Sans" (so it really uses the system-wide default font)?
Comment by Annonym (Hasbeen) - Wednesday, 12 December 2018, 10:41 GMT
I wouldn't mind the patch and open the bug report if it worked in the way that its name suggests. In any case, I read the wiki and I have remembered it is against Arch's basic principles to ship software with unnecessary additions or modifications. I too vote for removing it.
Comment by Sven-Hendrik Haase (Svenstaro) - Wednesday, 12 December 2018, 11:13 GMT
Jiachen, you go ahead and fix this one.
Comment by Jiachen Yang (farseerfc) - Wednesday, 12 December 2018, 13:44 GMT
Sorry for the unfortunate result. I need to explain the situation and timeline of telegram-desktop font rendering of the upstream "official" binary and the packaged version in our community repository.
The binary from upstream bundled a custom (patched) version of qt5 and fontconfig and the Open Sans fonts, among other things. We applied the "systemqt" patches from debian to use system-wide qt5 and fontconfig. This is the same situation from the beginning when Sven-Hendrik Haase moved the aur/telegram-desktop-systemqt into community/telegram-desktop.

Up until 1.4.3, systemqt patch allow us to configure the fonts for telegram-desktop using user level fontconfig xml files. This "feature" or "side-effect" of systemqt patch is important for non-European language users, because it allows us to set fallback fonts for many languages with characters not included in the bundled opensans font. Also with a correct user level fontconfig, this allow Bold style to apply correctly on the desired fallback fonts.

Between 1.4.3 and 1.5.0 the upstream touched these 2 things regarding the font rendering:

1. Because their bundled fontconfig cannot parse system fontconfig settings if the system fontconfig version is newer than 2.13, they decided to ship a custom fontconfig file only apply to their binary. . This fontconfig file is poorly written and not suitable for Arch Linux in many ways: it hardcoded non-existence path, it forced subpixel order, and most importantly it does not consider font fallback. Fortunately the upstream provided TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION macro to disable this behavior. So I disabled it in 1.5.0-2, and according to upstream issue reports people tends to agree with my decision:

2. The upstream decided to disable Qt DemiBold styling and rely solely on font family name to select "Open Sans SemiBold" font. ( This is their attempt to fix ugly font rendering reported in . But the side effect of this change is that this breaks SemiBold style for any fallback fonts than "Open Sans Semibold".

And my attempt to fix these things are in the following order:
1. In 1.5.0-2 I tried to set the TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION macro to disable custom fontconfig file generation. Also I applied the "Use-system-wide-font.patch" taken from debian ( to disable bundled opensans font, so that telegram can pick up user level fallback configs.
2. After 1.5.0-2 release, people reported to me that without "ttf-opensans" installed, bold text cannot render correctly even for English text. I looked into the problem and decided to bundle opensans again in 1.5.0-3 temporarily to at lease recover bold fonts for english before I have time to understand the problem.
3. This is followed by 1.5.1-1 release from the upstream immediately. I didn't change any patches for 1.5.1-1 .
4. After some further investigation into the code, I found the reason for losing bold style, so I reverted the commit to add back bold style ( Since bold style font can now be replaced in user level fontconfig settings, I also add back "Use-system-wide-font.patch". Then I released 1.5.1-2

So now I have 2 conflicting options:
1. Keep the patch in 1.5.1-2 , and users have to define their own fontconfig fallbacks (or install aur/ttf-opensans) to meet their taste in font selection. Or
2. Remove the "Use-system-wide-font.patch" and release 1.5.1-3 , and users will lose the ability to replace the bundled opensans with their own fonts (for the characters defined in the opensans font).

Which one do you guys think is better?
Comment by Jarkko Torvinen (fernie) - Wednesday, 12 December 2018, 14:12 GMT
1. I prefer keeping the patch as it makes the font configurable. But perhaps I would introduce dependency to ttf-dejavu so it can fall back to dejavu fonts instead of some monospaced (Hack in my case), by default without any user fontconfig configuration.

It is simple to bind Open Sans and Open Sans Semibold to Noto Sans and Noto Sans Medium in fontconfig
Comment by Jiachen Yang (farseerfc) - Wednesday, 12 December 2018, 14:30 GMT
Option 3: Now I am considering moving ttf-opensans into community and add an optdepends on it.
Comment by Annonym (Hasbeen) - Wednesday, 12 December 2018, 15:20 GMT
That sheds light on a problem and legitimates the incorporation of the patch. In another words, if I were to choose now, I would go with the third option instead of the first one, as an update should be seamless for all other users, so that they would not need to either dig logs in the git clone of the "community" repository up to, ultimately, find this bug report; or go to the forums asking for help. I have not been an Archer for very long, but I think that this should also be noted somewhere so that the others will know that their own defined fallback fonts now apply to Telegram.
Comment by Jiachen Yang (farseerfc) - Wednesday, 12 December 2018, 16:30 GMT
Sorry again for all the inconvenience. I would have chosen option 3 if I follow the upstream development more carefully to know these issues back when I was trying to fix it.
telegram-desktop 1.5.1-3 now added a new optdepends of ttf-opensans. Cheers and back to telegraming ~