-
-
Notifications
You must be signed in to change notification settings - Fork 117
Unicode character display (strangely wide or missing) #423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Lol, I love your scripts, man. Many thanks for these. I think I somehow should integrate some of these into some kind of CI tests :) Well. The strangely sized glyphs are colored (most likely) bitmap glyphs. It is very well interesting to know which font and respective glyph index have caused this (you might need some assistance to find that out, not too urgent). There was a name for the thing of spamming a system (e.g. TE) with every possible glyph. I have to look at the notcursses project that once had something similar too. However, at least one problem is that the glyph cache is getting bigger and bigger on the master branch. Which causes it to get bloated (therefore slow when spamming glyphs). - I have that redesigned in the grid branch I am currently actively working on (say: 75% done). I'll be focusing on your other report first and then head back here (hopefully all fixable also without that special grid branch) :) |
@hackerb9 ah damn, I can't test on OS/X, because fonttable doesn't like it.
Will be trying ASAP on Linux. |
Is GNU awk available in So, just for fun, I tried the same test in the improvements/grid branch with the XFT_DEBUG environment variable set to 3. XFT_DEBUG=3 src/contour/contour fonttable | less
> # To go to the end of the buffer
bb # To go back two pages While many of the missing characters at the end now appear, [EDIT: I was mistaken. I had forgotten they do show up when piped into less]. the strangely wide characters are still there if I scroll back two pages. Also, XFT_DEBUG seemed to have no effect; I believe it should have printed out what fonts were getting chosen, but maybe that's just an XTerm thing. |
oh damn. I should have told you that I'm currently in v2-full-rework of the grid branch. So expect it to be broken. But I have the fundamentals done. Now I need to polish it (and improve missing unit test cases :D). This grid branch will most likely be coming for 0.3.0 then. I can ping you then :) |
this isn't addressed in the grid branch. The grid branch is a full grid rewrite in order to "dramatically" improve performance (goal number one) along with code refactors for better reusability / cleanups. the strange character thing you experience can very well go into the next bugfix release (0.2.1) as soon as i can repro it :) |
No problem, I went back to the main branch. I may have narrowed down the rogue characters. It appears to be "NEGATIVE SQUARED LATIN CAPITAL LETTERS" A, B, O, and P. For some reason all other letters are missing, which seems weird for a font to do. (What can you even spell? "Poppa Baobab"? Oh, wait! Those are blood types.) Now to find out what font it is... By the way, I tested that unicode range on XTerm and it worked fine, but it used a standard (non-colorful) font. |
I found the font that's triggering the strangely wide glyph bug. $ fc-list :charset=1F170
/usr/share/fonts/truetype/ancient-scripts/Symbola_hint.ttf: Symbola:style=Regular
/usr/share/fonts/truetype/unifont/unifont_upper.ttf: Unifont Upper:style=Regular
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular
$ fc-list :charset=1F171
/usr/share/fonts/truetype/ancient-scripts/Symbola_hint.ttf: Symbola:style=Regular
/usr/share/fonts/truetype/unifont/unifont_upper.ttf: Unifont Upper:style=Regular
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular
$ fc-list :charset=1F172
/usr/share/fonts/truetype/ancient-scripts/Symbola_hint.ttf: Symbola:style=Regular
/usr/share/fonts/truetype/unifont/unifont_upper.ttf: Unifont Upper:style=Regular NotoColorEmoji.ttf defines color characters for 🅰 and 🅱, but not 🅲, so that's our culprit.¹ But this also points out another bug. All the other NEGATIVE SQUARED letters were blank in Contour, even though my machine has the fonts needed to render them. ¹ Maybe I'm a weirdo, but I actually would prefer that letter like characters like these not be pre-rendered in color. |
What I'd like you to do is something like this: This will generate debug output to your current terminal's screen. you can pipe it into a text file or clipboard and then paste it here. (you may want to have a look at You can then paste that in here, most likely you want to wrap that spam though behind the |
That is most likely a fontconfig configuration problem (not necessarily on your side though). Maybe you really want to dump the logs with
Users that wish that are adviced (AFAIK) to tweak fontconfig for that (on Linux). Hm, I just checked. these colored glyphs you see are actually meant to be colored: Any codepoint (grapheme cluster) who's indication is "emoji" (screenshot above) is supposed to be rendered in square block (colored or not) EDIT: I still wonder why you are getting the uberly huge pictograms rendered. Maybe you want to email me your faulty |
Results from test.sh
|
Looks like it's using |
I am using the standard fonts-noto-color-emoji package from the current version of Debian GNU/Linux. It has not been modified. I have uploaded a copy here: https://git.io/JgnwD
|
Could it be that TextShaper is fibbing? fc-list did not include Vera as one of the fonts that had a glyph at that codepoint, so it should just be blank if it used Vera. |
I first verify of the debug prints is 100% right and 0% lying before i can answer that. My guess? I gave you the wrong debug tag to test with and Vera Mono is your primary configured font. What we want to see is the actual don't used in text shaping. |
Any guesses what the right debug tag would be? Were you able to reproduce it using the font I uploaded? I tried using debug renderer.text and got this output which seems to be indicating the font rendering size: [renderer.text:contour/src/terminal_renderer/Renderer.cpp:107] Using font locator: fontconfig. As you can see, I added an extra line to your script so that it first shows a codepoint Contour renders correctly for comparison: ugrep U+1F1
ugrep 1F170..98
sleep 5 I'm not exactly sure what the "metrics" numbers mean, but I'm seeing this:
A pattern or mere pareidolia? |
I also tried
|
Description
Contour displays some characters very strangely or not at all.
Environment
Steps to Reproduce
fonttable | less
. Use the>
key to go to the end of input.The text was updated successfully, but these errors were encountered: