Support Unicode 16 octants #2820

eschnett · 2024-12-20T22:03:38Z

This is a first stab at supporting Unicode 16 octants #2669 . Comments welcome.

dankamongmen · 2024-12-21T01:37:34Z

whoa!

dankamongmen · 2024-12-21T01:40:59Z

i haven't looked yet, but some questions i'll be keeping in mind:

can we reuse the braille code in terms of projection onto the plane? (almost certainly)
is this better than braille? (i suspect yes)
ought it replace braille for NCBLIT4x2? (probably, but need consider backwards compatability, see below)
ought it entirely displace braille? (less sure)
how widespread are octants in font stacks? can support be detected at runtime?
if we try to emit octants, and they are not supported in the font, what is the failure mode?
same if they are not supported in the libc/libunistring?

i'm very excited, and look forward to reviewing this!

update: turns out NCBLIT4x2 doesn't exist, just NCBLIT_BRAILLE. good!

dankamongmen · 2024-12-21T01:43:33Z

ahhh shit, i salute my homie from PITP! did you know annie ray by any chance? i was writing a length essay involving canadian politics (particularly the "Western alienation" of the 90s) when i saw your PR. though i see you are german, by way of...LSU? huh

dankamongmen · 2024-12-21T01:48:28Z

i notice with a very superficial survey that:

the majority of https://www.fileformat.info/info/unicode/block/symbols_for_legacy_computing_supplement/utf8test.htm does not render on my chromium/debian browser
the majority of the block does not render in my kitty/debian terminal
the block in toto is not recognized by my unicode(1)/debian

with that said, we don't need to wait for everyone else. just investigating.

dankamongmen · 2024-12-21T01:49:38Z

the majority of https://www.fileformat.info/info/unicode/block/symbols_for_legacy_computing_supplement/utf8test.htm does not render on my chromium/debian browser

the majority of the block does not render in my kitty/debian terminal

the relevant glyphs do render, however. so this isn't really applicable.

the block in toto is not recognized by my unicode(1)/debian

this remains true, but of rather less significance.

dankamongmen · 2024-12-21T01:59:55Z

STAy AwESOME LINUX

dankamongmen · 2024-12-21T02:26:24Z

README.md

-and sextants are not the place to demonstrate your design virtuosity. To
-inspect your environment's rendering of drawing characters, run
+rather than loading them from a font. This is generally desirable. Quadrants,
+sextants, and octants are not the place to demonstrate your design virtuosity.


i'm guessing your methodology for this kind of thing involved grepping for at a minimum sextant. i'm trying to think of other stuff we'd want to check. NCBLIT is broad but probably a good one. i'll run these checks, just thinking aloud.

Correct. I looked for sextant, but not for NCBLIT.

doc/man/man3/notcurses_capabilities.3.md

dankamongmen · 2024-12-21T02:35:19Z

doc/man/man3/notcurses_visual.3.md

-aspect-preserving **NCBLIT_2x1** will be returned. If sextants are available
-(see **notcurses_cansextant**), this will be **NCBLIT_3x2**, or otherwise
-**NCBLIT_2x2**.
+**NCBLIT_1x1**. If octants are available, (see **notcurses_canictant**), the


canoctant i think you mean. and i don't think 4x2 is aspect-preserving? am i being stupid?

the whole reason why 2x1 preserves aspect (mostly) is that a cell is (usually) (roughly) twice as tall as it is wide. so when you put two pixels in there, on top of one anotther, you suddenly have pixels be squares, like they (usually) are in your image. but, 4x2 is a linear map from 2x1, so yeah, i guess that works too. good deal. nice to have another aspect-preserving blitter!

i'm not sure about it being the default for NCSCALE_NONE and NCSCALE_SCALE, though. 2x1 allows full color fidelity. remember, you only have a background and foreground for each cell. so with two source pixels mapped to the cell, you can do both colors losslessly. there's no way to losslessly pack 8 pixels into 2 cell colors, though. so you're going to lose some image quality for certain images, and ruin pathological ones.

so i think we stick with 2x1.

now, maybe it should be the default for NCSCALE_STRETCH (which is currently 3x2, which is honestly a garbage blitter).

I don't quite follow the reasoning. The 4x2 aspect-preserving mode is never chosen when the caller wants to preserve the aspect, but it might be chosen when the caller explicitly allows non-aspect preserving mapping? That seems a bit confusing.

I'd be fine with never making 4x2 the default (at the moment it's new and untested). In the future, maybe there could be a new flag to preserving colour accuracy?

i'm thinking of octants as basically a more attractive, predictable braille. i.e. both are just implementing a 4x2 blitter, but you pretty much know what octants are going to look like. so octants have the same advantages and disadvantages otherwise that braille does -- the advantage is that you can get higher resolution in a fixed cell geometry, and the disadvantage is that you stand to lose color fidelity (which can in certain cases make the image effectively unrecognizable).

4x2 is chosen when the user requests 4x2, whether they choose _SCALE, _NONE, or _STRETCH. this only affects the case where they choose NCBLIT_DEFAULT together with _SCALE or _NONE. if you choose 4x2 explicitly, you get 4x2 (unless we can't do it). does that make sense?

Yes, I agree.

dankamongmen · 2024-12-21T02:35:53Z

include/notcurses/ncseqs.h

+  "\U0001CEA3\U0001CD36\U0001CD37\U0001CD38\U0001CD39\U0001CD3A\U0001CD3B\U0001CD3C"\
+  "\U0001CD3D\U0001CD3E\U0001CD3F\U0001CD40\U0001CD41\U0001CD42\U0001CD43\U0001CD44"\
+  "\U00002596\U0001CD45\U0001CD46\U0001CD47\U0001CD48\U0000258C\U0001CD49\U0001CD4A"\
+  "\U0001CD4B\U0001CD4C\U0000259E\U0001CD4D\U0001CD4E\U0001CD4F\U0001CD50\U0000259B"\


dankamongmen · 2024-12-21T02:36:24Z

include/notcurses/ncseqs.h

+  "\U0001CDCB\U0001CDCC\U0001CDCD\U0001CDCE\U0001CDCF\U0001CDD0\U0001CDD1\U0001CDD2"\
+  "\U0001CDD3\U0001CDD4\U0001CDD5\U0001CDD6\U0001CDD7\U0001CDD8\U0001CDD9\U0001CDDA"\
+  "\U00002584\U0001CDDB\U0001CDDC\U0001CDDD\U0001CDDE\U00002599\U0001CDDF\U0001CDE0"\
+  "\U0001CDE1\U0001CDE2\U0000259F\U0001CDE3\U00002586\U0001CDE4\U0001CDE5\U00002588"
 #define NCBRAILLEEGCS \
 L"\u2800\u2801\u2808\u2809\u2802\u2803\u280a\u280b\u2810\u2811\u2818\u2819\u2812\u2813\u281a\u281b"\


oh apparently i pulled this shit too, hah

include/notcurses/notcurses.h

dankamongmen · 2024-12-21T02:38:06Z

README.md

@@ -309,7 +309,8 @@ If things break or seem otherwise lackluster, **please** consult the
  Notcurses will not make use of bitmap protocols unless the terminal positively
  indicates support for them, even if <code>NCBLIT_PIXEL</code> has been
  requested. Likewise, sextants (<code>NCBLIT_3x2</code>) won't be used without
-  Unicode 13 support, etc. <code>ncvisual_blit()</code> will use the best blitter
+  Unicode 13 support, octants (<code>NCBLIT_4x2</code>) won't be used without
+  Unicode 17 support, etc. <code>ncvisual_blit()</code> will use the best blitter


have we traveled to the future in a Delorean? unicode 17 does not yet exist afaik

eschnett · 2024-12-21T03:06:37Z

the majority of https://www.fileformat.info/info/unicode/block/symbols_for_legacy_computing_supplement/utf8test.htm does not render on my chromium/debian browser

the majority of the block does not render in my kitty/debian terminal

the relevant glyphs do render, however. so this isn't really applicable.

See also wez/wezterm#6502.

include/notcurses/notcurses.h

dankamongmen · 2024-12-21T07:32:32Z

src/lib/blit.c

+octant_blit(ncplane* nc, int linesize, const void* data, int leny, int lenx,
+            const blitterargs* bargs){
+  const unsigned nointerpolate = bargs->flags & NCVISUAL_OPTION_NOINTERPOLATE;
+  const bool blendcolors = bargs->flags & NCVISUAL_OPTION_BLEND;


there's a lot of cut-and-paste going on here. i understand that, but one thing i was hoping to do was to come back and parameterize a general geometric character blitter. if you think that's beyond your abilities / the scope of this pr, that's fine, but it's something i'd like to do sooner rather than later.

maybe i ought do a parameterization, and then fold your patch into it? unsure.

reviewing this is definitely....dicey.

i think at a minimum i'd like to see this share the braille solver code. it seems like they ought be the exact same logic, just with two distinct sets of EGCs, no? i think that's a requirement for getting this in, unless you can show me why they'd be different solvers. what do you think?

I currently replicated the search-over-everything logic from the sextant solver. I can switch to using the Braille solver logic. The EGCs for octants are not ordered regularly, so there will need to be a lookup table. If you're fine with using a lookup table for Braille as well then I can combine the solvers.

yeah let's use the braille code plus a lookup table. if it's easiest, we can just use a lookup table for the braille, too, and pass them in as parameters.

Here's the generic blitter.

beautiful. i'll try to look at this today, but it might not be until tomorrow. thanks a lot for your work here. fwiw, i think this will likely be the largest contribution to the notcurses c core by someone who is not me.

dankamongmen

ok, i looked over this and dropped some thoughts. overall, i like it, and thanks a ton for writing this. i hope it wasn't too difficult.

the two things i'd like to see before merging it:

1: i think this and the braille code ought share solver code, distinguished by two sets of EGCs. i'm going to gate merging this on either (a) explaining why i'm wrong or (b) doing so.

2: i think 2x1 ought remain the default for NCSCALE_NONE/NCSCALE_SCALE, for reasons of color fidelity explained in a comment.

other than those two things, this looks awesome!

eschnett · 2024-12-21T19:22:45Z

Both ideas look reasonable. It should also be possible to combine this with the sextant code, or to have a generic solver for any size.

dankamongmen · 2024-12-25T00:35:54Z

alright i think i'm going to go ahead and merge this, and then make some changes on top of it. i don't want to hold back your pr, though. do you mind me asking you for review of my changes?

eschnett · 2024-12-25T00:38:27Z

I'd be happy to have a look at your changes.

dankamongmen · 2024-12-25T00:40:18Z

thanks a lot for this contribution to Notcurses, @eschnett ! i'm delighted, and you've inspired me to get some longstanding work done. huzzah!

eschnett · 2024-12-26T15:39:08Z

@dankamongmen I never answered: No, I don't know Annie Ray. (I don't spend much time at IQC.) The world is small...

Support Unicode 16 octants

19ff574

dankamongmen self-assigned this Dec 21, 2024

dankamongmen requested changes Dec 21, 2024

View reviewed changes

dankamongmen reviewed Dec 21, 2024

View reviewed changes

dankamongmen added perf sweet sweet perf enhancement New feature or request and removed perf sweet sweet perf labels Dec 21, 2024

dankamongmen reviewed Dec 21, 2024

View reviewed changes

include/notcurses/notcurses.h Show resolved Hide resolved

dankamongmen reviewed Dec 21, 2024

View reviewed changes

dankamongmen requested changes Dec 21, 2024

View reviewed changes

eschnett added 2 commits December 22, 2024 16:37

Correct mistakes, update default blitter choice

3ee3dc0

Implement generic 4x2 blitter

ede060d

dankamongmen merged commit 531bdd0 into dankamongmen:master Dec 25, 2024

dankamongmen mentioned this pull request Dec 28, 2024

Unified hires block blitter #2823

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support Unicode 16 octants #2820

Support Unicode 16 octants #2820

eschnett commented Dec 20, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024 •

edited

Loading

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

dankamongmen Dec 21, 2024

eschnett Dec 25, 2024

dankamongmen Dec 21, 2024

eschnett Dec 22, 2024

dankamongmen Dec 23, 2024

eschnett Dec 23, 2024

dankamongmen Dec 21, 2024

dankamongmen Dec 21, 2024

dankamongmen Dec 21, 2024

eschnett commented Dec 21, 2024

dankamongmen Dec 21, 2024

eschnett Dec 22, 2024

dankamongmen Dec 23, 2024

eschnett Dec 23, 2024

dankamongmen Dec 23, 2024

dankamongmen left a comment

eschnett commented Dec 21, 2024

dankamongmen commented Dec 25, 2024

eschnett commented Dec 25, 2024

dankamongmen commented Dec 25, 2024

eschnett commented Dec 26, 2024

Support Unicode 16 octants #2820

Support Unicode 16 octants #2820

Conversation

eschnett commented Dec 20, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024 • edited Loading

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

dankamongmen commented Dec 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eschnett commented Dec 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dankamongmen left a comment

Choose a reason for hiding this comment

eschnett commented Dec 21, 2024

dankamongmen commented Dec 25, 2024

eschnett commented Dec 25, 2024

dankamongmen commented Dec 25, 2024

eschnett commented Dec 26, 2024

dankamongmen commented Dec 21, 2024 •

edited

Loading