FS#66454 - [telegram-desktop] Single or triple backtick blocks do not use monospace, 2.1.0 regression?
Attached to Project:
Community Packages
Opened by Adam Hirst (aphirst) - Tuesday, 28 April 2020, 18:36 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Wednesday, 29 April 2020, 12:36 GMT
Opened by Adam Hirst (aphirst) - Tuesday, 28 April 2020, 18:36 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Wednesday, 29 April 2020, 12:36 GMT
|
Details
Description:
Telegram supports monospace cosmetic rendering for message text in `single backticks` or ``` in triple-backtick blocks ``` in a similar fashion to markdown. In telegram-desktop 2.0.1, this particular feature worked, but in 2.1.0 it just uses the standard font (not monospace). If I downgrade to 2.0.1, this cosmetic behaviour is restored. If I use telegram-desktop-bin 2.0.1 or 2.1.0 from the AUR (with qt etc. statically linked) the bug does not occur. Similarly, if I rebuild 2.0.1 of telegram-desktop myself, the bug does not occur. Additional info: * package version(s) 2.1.0 * config and/or log files etc. N/A ? * link to upstream bug report, if any I will make one later if necessary. Steps to reproduce: * Install telegram-desktop 2.1.0 from community/ * Log in to your Telegram account * View/create a message containing text in either single or triple backticks |
This task depends upon
Closed by Sven-Hendrik Haase (Svenstaro)
Wednesday, 29 April 2020, 12:36 GMT
Reason for closing: Not a bug
Wednesday, 29 April 2020, 12:36 GMT
Reason for closing: Not a bug
Does anything seem suspicious here?
$ pacman -Q | grep ttf
kanjistrokeorders-ttf 4.002-1
lib32-sdl2_ttf 2.0.15-1
lib32-sdl_ttf 2.0.11-5
perl-font-ttf 1.06-3
sdl2_ttf 2.0.15-1
sdl_ttf 2.0.11-5
ttf-bitstream-vera 1.10-12
ttf-dejavu 2.37-2
ttf-hanazono 20170904-3
ttf-inconsolata 1:3.000-2
ttf-indic-otf 0.2-9
ttf-liberation 2.1.0-1
ttf-linux-libertine 5.3.0-4
ttf-opendyslexic 1-3
ttf-opensans 1.101-1
ttf-symbola 13.00-2
$ pacman -Q | grep otf
libotf 0.9.16-1
otf-ipafont 003.03-7
otf-overpass 3.0.4-1
ttf-indic-otf 0.2-9
$ pacman -Q | grep font
adobe-source-code-pro-fonts 2.030ro+1.050it-5
adobe-source-han-sans-jp-fonts 2.001-1
adobe-source-han-sans-otc-fonts 2.001-1
adobe-source-han-serif-jp-fonts 1.001-2
adobe-source-han-serif-otc-fonts 1.001-2
cantarell-fonts 1:0.201-1
consolas-font 1.1-1
fontconfig 2:2.13.91+24+g75eadca-2
fontforge 20200314-2
gnome-font-viewer 3.34.0+27+g5ffd1ba-1
gnu-free-fonts 20120503-7
gsfonts 20180524-2
lib32-fontconfig 2:2.13.91+24+g75eadca-2
libfontenc 1.1.4-1
libxfont2 2.0.4-2
noto-fonts 20190926-4
noto-fonts-cjk 20190409-1
noto-fonts-emoji 20191016-6
otf-ipafont 003.03-7
perl-font-ttf 1.06-3
soundfont-fluid 3.1-2
texlive-fontsextra 2019.52580-1
xorg-font-util 1.3.2-1
xorg-font-utils 7.6-5
xorg-fonts-100dpi 1.0.3-4
xorg-fonts-75dpi 1.0.3-4
xorg-fonts-alias 1.0.3-2
xorg-fonts-encodings 1.0.5-1
xorg-fonts-misc 1.0.3-6
xorg-fonts-type1 7.7-3
xorg-mkfontscale 1.2.1-2
xorg-xfontsel 1.0.6-1
At any rate, I think we can conclude that this is not a packaging bug.