Arch Linux

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.

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.

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)

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

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.

Jiachen, you go ahead and fix this one.

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.
https://github.com/telegramdesktop/tdesktop/commit/8ee958bfa08b2ba87cffaf8de4b65b6890e59ea3 . 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: https://github.com/telegramdesktop/tdesktop/issues/5459#issuecomment-446221727 https://github.com/telegramdesktop/tdesktop/issues/5463#issuecomment-446296514

2. The upstream decided to disable Qt DemiBold styling and rely solely on font family name to select "Open Sans SemiBold" font. (https://github.com/telegramdesktop/tdesktop/commit/0718520f3649c9ebaf54c02961811fa94a9ac2c0). This is their attempt to fix ugly font rendering reported in https://github.com/telegramdesktop/tdesktop/issues/5368 . 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 (https://salsa.debian.org/debian/telegram-desktop/blob/debian/master/debian/patches/Use-system-wide-font.patch) 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 (https://github.com/telegramdesktop/tdesktop/commit/310c68a744ae8163c96b88944d96a6f6b14b3cdf). 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?

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

Option 3: Now I am considering moving ttf-opensans into community and add an optdepends on it.

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.

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 ~