Menu
▾
▴
1 Attachments
#2310 Chinese characters are only properly monospaced when font size is a multiple of 6
closed-fixed
nobody
5
2022-02-09
2022-01-25
No
Using a custom font, variants of sarasa and noto, Chinese characters in Chinese monospaced fonts only line up with letters of the alphabet and other characters when the font size is a multiple of 6. A font where this occurs is attached. Unable to find a font unaffected by this.
Found in and tested from Geany.
gtk4-4.4.1-1.fc35.x86_64
Also installed, gtk3-3.24.31-2.fc35.x86_64
Fedora 35
Also confirmed on noto variant Noto Sans Mono CJK TC. Also some chinese text, 半角中文對齊, that we were able to produce this bug with.
Similar to [bugs:#2070] and [feature-requests:#1311], you can try Ubuntu Mono.
https://design.ubuntu.com/font/
Related
Bugs: #2070
Feature Requests: #1311
Issue is still present in ubuntu mono.
I was a little impatient with my earlier testing, after some more thorough but tedious testing found that it's actually font sizes that are multiples of 3 that are monospaced correctly, not multiples of 6.
I don't see this as a Scintilla bug as it is system behaviour shared with, for example, gedit the system "Text Editor" which uses GtkSourceView, not Scintilla.
With SciTE and "font.base=font:Sarasa Mono Slab SC", for a file containing
Pango (the system library which determines text drawing) returns these character widths at increasing sizes (9,10,11,12):
(edit: wrong examples; added 9 case and removed 13 case)
Pango used to return fractional character positions but it appears that no longer occurs on current Linux distributions - also tried Ubuntu 21.10.
Last edit: Neil Hodgson 2022-01-26
Alright, I'll take this another step up to pango then
There is an option in Pango,
pango_context_set_round_glyph_positions, that can be used to turn on fractional positions.https://docs.gtk.org/Pango/method.Context.set_round_glyph_positions.html
https://blogs.gnome.org/mclasen/2019/08/07/pango-1-44-wrap-up/
A patch is attached. Not tested much and may change behaviour in unexpected ways. Only available from Pango 1.44 which was released in 2019 so probably has to have version check #if.
Tested, patch resolves the issue, closing and going back down to geany with the fix.
Well, can't find the close button but something in the spirit of it.
Oh, I neglected to ask but probably should, will this patch be incorporated into mainline scintilla, or should Geany patch it in independently? I did attempt to add it when the patch worked, but it failed build because pango is pinned to an older version on guake CI and I wrote it off to being solved by the next scintilla merge.
Oh, nevermind, clicked around to the front page and saw the commit from three hours ago.
The [c69263] commit is slightly different from the patch shown earlier. The issue is that, using the commit, positions are slightly less than integer pixels at 9, 12 and other divisible-by-3 points:
The earlier patch tweaked the font size up by a single Pango unit which resulted in the 9 point characters being exactly 12.0 or 6.0 pixels wide.
Switched to Pango calls for calculations with [47d2b7] instead of Scintilla's custom scaling code but that has the same effect.
It is unlikely there will be much difference with just less than whole pixels but such issues are more likely with very long lines.
Related
Commit: [47d2b7]
Commit: [c69263]
Oh, probably fine, people aren't programming horizontally anyways where they'll use monospace. Some floating point nonsense I presume
The [c69263] commit is slightly different from the patch shown earlier. The issue is that, using the commit, positions are slightly less than integer pixels at 9, 12 and other divisible-by-3 points:
The earlier patch tweaked the font size up by a single Pango unit which resulted in the 9 point characters being exactly 12.0 or 6.0 pixels wide.
Switched to Pango calls for calculations with [47d2b7] in case there was a bug in Scintilla's custom code but that has the same effect.
Related
Commit: [47d2b7]
Commit: [c69263]