As all the glhphs in the 2500–259F range, they are drawn manually in vtedraw.cc _vte_draw_terminal_draw_graphic(), rather than taken from the font. This is because in most fonts these line drawing etc. characters do not align properly, do not properly fill up the entire width and height of the cell, antialiasing kicking in looks ugly etc.

The official name of these particular three are LIGHT, MEDIUM and DARK SHADE.

Imagine that we just draw the desired pattern with much smaller dots, and apply antialiasing on top of that. That's what we do :)

With the dotted look, you either go for a fixed amount/layout of dots, in which case antialiasing might look ugly, or for a fixed dot size, in which case the patters do not align on cell boundaries, and also increasing the font size doesn't do what you'd expect. So maybe the first is still the better.

I'm not against this change at all (in fact, these three glyphs do look weird to me too), I'm just wondering about possible downsides, and I'm also arguing that the current implementation is not necessarily broken per se.

Egmont,
I think fixed amount of dots approach would be fine - for example, Firefox is using it, and the dots are still looking good even with the max zoom which is 300%.
In my opinion, it's better to show the dots, even having a risk of blurring them when a high font size is set, than showing solid rectangles which do not look right at all.

I think you see a fixed amount of dots in Firefox simply because it doesn't treat this symbol specially. It just takes it from the font. This presumably means a fixed amount of dots within a font, but probably a different look, varying number of dots across fonts.

In VTE you can easily disable the special handling of these codepoints by excluding them from the interval in vtedraw.cc _vte_draw_unichar_is_local_graphic().

I guess we should check with quite a few monospace fonts whether it looks "good enough", which is obviously not something well-defined concept.

Manually replicating the pattern of any of these fonts should also be a piece of cake.

With my preferred font ("Monospace Regular 10", whatever that means), even when zooming in/out a bit, my eyes perceive weird things happening when I place more of these glyps next to / underneath each other. It doesn't feel gray, I can see lots of red-ish and green-ish tiny dots. The overall shade (whether it feels blue-ish or red-ish or green-ish gray) changes as I zoom in/out.  Also it feels like the typical interference thingy is going on (well, sure it is behind the story).

E.g. at the default zoom, black on white, a block of MEDIUM shades looks red-ish, whereas a block of DARK shades is yellow-green-ish gray.

As the LCD panel with its subpixel ordering also takes an important role in this game, I cannot demonstrate it with regular screenshots. Maybe I'll take photos with a camera if really required.

I've created a test pattern, we {c,sh}ould add it to doc/boxes.txt:

                                ████████████████████████████████
     ░░░░░     ▒▒▒▒▒     ▓▓▓▓▓  ██▓▓▓▓▓█████▒▒▒▒▒█████░░░░░█████
  ░  ░░░░░  ▒  ▒▒▒▒▒  ▓  ▓▓▓▓▓  ██▓▓▓▓▓██▓██▒▒▒▒▒██▒██░░░░░██░██
     ░░░░░     ▒▒▒▒▒     ▓▓▓▓▓  ██▓▓▓▓▓█████▒▒▒▒▒█████░░░░░█████
                                ████████████████████████████████

Sure, add that to boxes.txt.

As to the rendering of these characters, I don't see a problem. In fonts, and historic terminals, they look like that because that's what you have to do when you only have monochrome and need to dither to represent greyshades in ultra-low resolution. Now that we don't have monochrome displays with low resolution anymore, we can draw them better, and that's what we do.

-> WONTFIX

Hi Christian,

Will all due respect, I cannot agree with you. It seems that all other apps, including browsers and text editors, are showing these chars in a dotted way; why should vte be trying to be holier than the pope?
Thanks.

It's fine to disagree; after all I disagree with you, too :-)

I've added the test from comment 4 to boxes.txt now. Comparing the rendering of older vte, current vte, xterm, urxvt and konsole, the one from current console looks much nicer than all the others to me.

...the one from current *vte*...

I cast a weak vote for Igor's preference. It's rendered as dots everywhere, hence it's probably the expected behavior, VTE is the odd one out there.

Also, with true color support available, there's not much point in having three separate glyphs just to get a sold color. (Okay, I know, it's terribly cumbersome to get the exact RGB of the palette colors, and many libs don't support true color, and what if the user wants to use these glyps in a context where he cannot add colors...)

I've created a proof of concept for a manual, antialias-free rendering of a fixed look (fixed amounts of dots) with rounding as per the EIGHTH macro and the corresponding glyphs. I'm not even attaching the code or a screenshot. It looks terribly awful, trust me.

Then I created a PoC for repeating a fixed pattern, increasing the dot size as the font size increases (but keeping it always an integer, so still no antialiasing happens), and let the pattern finish at the right and bottom edges in whichever phase it finishes. It looks surprisingly good. Definitely better than the antialiased glyphs. IMO better than the current grayshades too.

Created attachment 344998 [details] [review]
Manually render the dots

Created attachment 344999 [details]
Screenshot

Screenshot comparing the two, with 33;44;1 colors (Linux console color scheme).

IMHO the apparent dividing line that the dots create when two of these characters meet vertically is rather ugly...

Well, sure not ideal, but there's not much to do about it... I mean, choose a font size of even pixels in both dimensions :)

(I was also thinking about aligning the pattern of each cell to the global canvas. In that case, though, a single cell is painted differently depending on where it is on the screen. That'd probably be even worse.)

On the other hand, it might actually be desirable to see the boundary between such cells.

In the mean time, I'm wondering why the overall perceived colors are so different in the two cases (especially with the light shade, the leftmost squares on the screenshots). Do you happen to know? I think it boils down to color computation being a way more complex math story than just applying the other color with a 25/50/75% alpha. In which case it's another reason to use the dotted pattern rather than the solid color. Or does it rather depend on the monitor?

(It sucks that i's quite hard to talk about it since you might be seeing totally different colors than me, and attaching a photo taken by a camera [which we'd all again view on our own computers] might not help either.)

I did notice that the colours seem off, too, but the rendering was a bigger concern for me :-)

Seeing the significant difference in colors (and having verified that the colors are indeed "correct" according to the trivial way of computing them), I'm changing my "weak vote" to a "strong vote" for the dotted version :D

I'm open to being convinced that the colours in the current rendering are wrong, but I'm not prepared to accept a rendering of the characters where there's a discontinuity when the characters are placed either horizontally or vertically adjacent.

In that case we have to sacrifice the "no antialias" goal (which is there in pretty much all other manually drawn glyps, perhaps the diagonal lines being the only exceptions).

I'll give it a try.

Created attachment 345997 [details] [review]
Manually render - equal sized, antialiased

Here's a PoC patch. For the time being, manually try "xn = 4, yn = 8" and other values.

IMO the way the dots interfere with the LCD pixels look significantly worse than the discontinuity in the previous version.

Created attachment 345998 [details]
Screenshot - equal sized, antialiased

Also note that this latest patch is quite slow -- do a "cat doc/boxes.txt" and zoom in/out, you'll see a significant slowdown compared to previous versions.

I'm still not convinced, but let's reopen this while we're still discussing it, so it won't get lost.

(In reply to Egmont Koblinger from comment #18)
> In that case we have to sacrifice the "no antialias" goal

I'd rather go with global coordinates (comment 14).

(In reply to Egmont Koblinger from comment #21)
> Also note that this latest patch is quite slow -- do a "cat doc/boxes.txt"
> and zoom in/out, you'll see a significant slowdown compared to previous
> versions.

I think that's due to drawing each pixel separately and there being so many of them. That should be easy to fix: create static datas representing a 8x8 (or 16x16, 32x32) of each of the dithering patterns for use in a CAIRO_FORMAT_A1 surface; create a cairo_pattern_t for that surface and use that as the source for the cairo_fill() in the U+2591..U+2593 case. (Benchmark which surface size is fastest at different zoom levels/screen DPIs.)

A counter opinion from https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1770494:

"in Ubuntu Gnome terminal it is rendered as a cursor that is the color of a 50% blend between the background and foreground color, making it the best appearing terminal I've used"

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2372.