Skip to content
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

Bad interactions remain between wide chars and higher planes #260

Closed
dankamongmen opened this issue Jan 5, 2020 · 29 comments
Closed

Bad interactions remain between wide chars and higher planes #260

dankamongmen opened this issue Jan 5, 2020 · 29 comments
Assignees
Labels
bug Something isn't working demo relevant to notcurses-demo
Milestone

Comments

@dankamongmen
Copy link
Owner

I've added and attempted to enable the mathblock part of 'witherworms'. It looks supershitty to the max:

2020-01-05-025842_802x602_scrot

this one's somehow even worse. what's up with these empty spaces?

2020-01-05-025910_802x1417_scrot

beyond that, it seems NCALIGN_RIGHT is fucked up with these. i had to disable the extra parts of these strings. look at the third row here:

2020-01-05-030152_802x602_scrot

@dankamongmen dankamongmen self-assigned this Jan 5, 2020
@dankamongmen dankamongmen added bug Something isn't working demo relevant to notcurses-demo labels Jan 5, 2020
@dankamongmen dankamongmen added this to the v1.1.0 milestone Jan 5, 2020
dankamongmen added a commit that referenced this issue Jan 12, 2020
@dankamongmen
Copy link
Owner Author

It's not the text itself. We can print that just fine, aligned right:

2020-01-11-204330_802x602_scrot

@dankamongmen
Copy link
Owner Author

With the full strings, we do run into a problem. Behold:

                                           ∮E⋅da=Q,n→∞,∑f(i)=∏g(i)⎧⎡⎛┌─────┐⎞⎤⎫ 
                                                                  ⎪⎢⎜│a²+b³ ⎟⎥⎪ 
                                                                                
                                                                  ⎪⎢⎜⎷ c₈   ⎟⎥⎪

this is using "⌈x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪"

if we shorten that to "x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪", we get:

                                           ∮E⋅da=Q,n→∞,∑f(i)=∏g(i)⎧⎡⎛┌─────┐⎞⎤⎫ 
                                                                  ⎪⎢⎜│a²+b³ ⎟⎥⎪ 
                                             x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪ 
                                                                  ⎪⎢⎜⎷ c₈   ⎟⎥⎪ 

@dankamongmen
Copy link
Owner Author

definitely seeing some odd behavior with U+2308 LEFT CEILING in all contexts. need to drill in on this.

@dankamongmen
Copy link
Owner Author

Hrmmm, surely this has nothing to do with it:

[schwarzgerat](0) $ echo "⌈x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪" | wc -c
83
[schwarzgerat](0) $ echo "x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪" | wc -c
80
[schwarzgerat](0) $ set | grep COLUMNS
COLUMNS=80
[schwarzgerat](0) $ 

How embarrassing, if so!

@dankamongmen
Copy link
Owner Author

const size_t size = n->lenx + 1; // healthy estimate, can embiggen below

FUCK

@dankamongmen
Copy link
Owner Author

Alright, that's a solid fix for the long-strings issue:

                                           ∮E⋅da=Q,n→∞,∑f(i)=∏g(i)⎧⎡⎛┌─────┐⎞⎤⎫ 
                                                                  ⎪⎢⎜│a²+b³ ⎟⎥⎪ 
                                       ∀x∈ℝ:⌈x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪ 
                                                                  ⎪⎢⎜⎷ c₈   ⎟⎥⎪ 
                                       ℕ⊆ℕ₀⊂ℤ⊂ℚ⊂ℝ⊂ℂ(z̄=ℜ(z)−ℑ(z)⋅𝑖)⎨⎢⎜       ⎟⎥⎬ 
                                                                  ⎪⎢⎜ ∞     ⎟⎥⎪ 
                                             ⊥<a≠b≡c≤d≪⊤⇒(⟦A⟧⇔⟪B⟫)⎪⎢⎜ ⎲     ⎟⎥⎪ 
                                                                  ⎪⎢⎜ ⎳aⁱ-bⁱ⎟⎥⎪ 
                                        2H₂+O₂⇌2H₂O,R=4.7kΩ,⌀200µm⎩⎣⎝i=1    ⎠⎦⎭ 

@dankamongmen
Copy link
Owner Author

On at least one geometry, witherworms now runs correctly with the mathtext enabled, but this is not the case all the time.
2020-01-11-215455_3434x602_scrot

dankamongmen added a commit that referenced this issue Jan 12, 2020
@dankamongmen
Copy link
Owner Author

If I empty out the plane underneath us, I now at least print the higher plane entirely correctly. We're now down to just interactions with underlying wide chars, the original topic of this bug :).

@dankamongmen
Copy link
Owner Author

Alright, on a 70x80 geometry, the ⊥ character is printed at y=66 x=45, and that is correct. This is with all single-width characters. When we go to wide characters, it ends up at...hrmm, the render sequence still thinks it's placing it at the same place (which it indeed ought)...hrmm.

@dankamongmen
Copy link
Owner Author

Look at this using the mathtext PoC:

det gør ikke ondt på mig㎚ ㎛ ㎜ ㎝ ㎞ ㎟ ㎠ ㎡ ㎢ ∮E⋅da=Q,n→∞,∑f(i)=∏g(i)⎧⎡⎛┌─

there should not be spaces between those ㎜ ㎝ etc. I think that's what's throwing us off here, at least. Here's the code:

    "㎚㎛㎜㎝㎞㎟㎠㎡㎢㎣㎤㎥㎦㎕㎖㎗㎘㏄㎰㎱㎲㎳㎍㎎㎏㎅㎆㏔㎇㎐㎑㎒㎓㎔㎮㎯"

see, ma? no spaces!

@dankamongmen
Copy link
Owner Author

oh, and this is weird, there aren't extra spaces until we get down in the output:

g𝐸=𝑚𝑐²JagkanätaglasutanattskadamigJegkanspiseglasdetgørikkeondtpåmig㎚㎛㎜㎝㎞㎟
㎠㎡㎢㎣㎤㎥㎦㎕㎖㎗㎘㏄㎰㎱㎲㎳㎍㎎㎏㎅㎆㏔㎇㎐㎑㎒㎓㎔㎮㎯Ækaæeglassuhenatdetg
omænaueက္ယ္ဝန္တော၊က္ယ္ဝန္မမ္ယက္စားနုိင္သည္။၎က္ရောင္ထိခုိက္မ္ဟုမရ္ဟိပာ။ကျွန်တောကျွန်မမှန်စားနိုင်တယ်။၎င်းကြေင့်ထိခိုက်မှုမ
ရှိပါ။Tôicóthểănthủytinhmàkhônghạigì些𣎏世咹水晶𦓡空𣎏害ខ្ញុំអាចញុំកញ្ចក់បានដោយគ្មានបញ្ហាຂອ້
ຍກິນແກ້ວໄດ້ໂດຍທີ່ມັນບໍ່ໄດ້ເຮັດໃຫ້ຂອ້ຍເຈັບฉันกินกระจกได้แต่มันไม่ทำให้ฉันเจ็Бишилидэйчаднанададхортойби
ᠪᠢᠰᠢᠯᠢᠢᠳᠡᠶᠦᠴᠢᠳᠠᠨᠠ᠂ᠨᠠᠳᠤᠷᠬᠣᠤᠷᠠᠳᠠᠢᠪᠢᠰमकाँचखानसक्छूरमलाईकेहिनीहुन्न्ཤེལ་སྒོ་ཟ་ནས་ང་ན་གི་མ་རེད我J
egkanspiseglassutenåskademegEgkannetaglasskaðaleysurÉggetetiðgleránþessaðmeiðami
g𝐸=𝑚𝑐²JagkanätaglasutanattskadamigJegkanspiseglasdetgørikkeondtpåmig㎚㎛㎜㎝㎞㎟
㎠ ㎡ ㎢ ㎣ ㎤ ㎥ ㎦ ㎕ ㎖ ㎗ ㎘ ㏄ ㎰ ㎱ ㎲ ㎳ ㎍ ㎎ ㎏ ㎅ ㎆ ㏔∮E⋅da=Q,n→∞,∑f(

i think something's rotten deep in our rendering here.

@dankamongmen
Copy link
Owner Author

notcurses_render() thinks it's always dumping the ㎡ at column 2--where it ought indeed be--but the last two times it prints it, we're actually at column 3. yeah, this is at the heart of our problems, i'm pretty sure.

@dankamongmen
Copy link
Owner Author

60 0 depth: -2 0
60 1 depth: -3 0
60 2 depth: 2 0
60 3 depth: -3 0
60 4 depth: 2 0
60 5 depth: -3 0
60 6 depth: 2 0
60 7 depth: -3 0

so, our plane is the full width of the screen. each of these wide chars starts, and then gets intercepted...

@dankamongmen
Copy link
Owner Author

dankamongmen commented Jan 12, 2020

to assist in interpreting that output, depth -3 means no glyph, -2 means stdplane, and -1 (not pictured) is the mathtext plane. we do see -1 later, where expected.

so first off, i'm confused as to how we're seeing the wide glyphs at all in mathtext PoC. we don't set mathplane transparent there, so it ought be blocking them (we are transparent in witherworms)...ok, nevermind, that's as expected unless we set a base char. transparency and glyph presence are distinct, dumbass, read your own documentation.

@dankamongmen
Copy link
Owner Author

p: 0x5636f50831e0 depth: 1
p: 0x5636f506aee0 depth: 2
60 0 depth: -2 0
INRIFGHT: 0 ㎠

it's not seeing them as wide, i think?

@dankamongmen
Copy link
Owner Author

[schwarzgerat](0) $ cat e | grep y
y/x 4 0 INRIFGHT: 1 ㎠
y/x 11 0 INRIFGHT: 1 ㎠
y/x 18 0 INRIFGHT: 1 ㎠
y/x 25 0 INRIFGHT: 1 ㎠
y/x 32 0 INRIFGHT: 1 ㎠
y/x 39 0 INRIFGHT: 1 ㎠
y/x 46 0 INRIFGHT: 1 ㎠
y/x 53 0 INRIFGHT: 1 ㎠
y/x 60 0 INRIFGHT: 0 ㎠
y/x 67 0 INRIFGHT: 0 ㎠
[schwarzgerat](0) $ 

uh-oh

@dankamongmen
Copy link
Owner Author

p: 0x5635eba031e0 depth: 1
gcluster: 0  attr: 0x00000000 chan: 0x2000000020000000
p: 0x5635eb9eaee0 depth: 2
gcluster: 0  attr: 0x00000000 chan: 0x0000000000000000
EXITING p: 0x5635eb9eaee0 depth: 2
gcluster: 19572 ㎠ attr: 0x00000000 chan: 0x0000000000000000
60 0 depth: -2 inr: 0 wide: 0
INRIFGHT: 0 ㎠

sure enough, chan is coming up all 0s...

@dankamongmen
Copy link
Owner Author

ok, yeah. look at dig_visible_cell():

        // if we have no character in this cell, we continue to look for a
        // character, but our foreground color will still be used unless it's
        // been set to transparent. if that foreground color is transparent, we
        // still use a character we find here, but its color will come entirely
        // from cells underneath us.
        if(c->gcluster == 0){
          if( (c->gcluster = vis->gcluster) ){ // index copy only
            glyphplane = p; // must return this ncplane for this glyph
            c->attrword = vis->attrword;
          }
        }

so we're not taking the channels on here, but we should be taking at least those elements independent of color. yeah, that's our problem, at least for this...

@dankamongmen
Copy link
Owner Author

That fixes us for mathtext, but unfortunately doesn't seem to have any positive impact on witherworms :(.

@dankamongmen
Copy link
Owner Author

this shit's killing me

https://www.youtube.com/watch?v=h7975tw0EJA

@dankamongmen
Copy link
Owner Author

[g] [63/63] 0x00 0x00 0x00 0x564266beaee0
[ì] [63/64] 0x00 0x00 0x00 0x564266beaee0
[些] [63/65] 0x00 0x00 0x00 0x564266beaee0
[⎢] [63/67] 0x00 0x00 0x00 0x564266c073c0
[⎷] [63/69] 0x00 0x00 0x00 0x564266c073c0
[c] [63/71] 0x00 0x00 0x00 0x564266c073c0
[ ] [63/73] 0x00 0x00 0x00 0x564266c073c0
[ ] [63/75] 0x00 0x00 0x00 0x564266c073c0
[⎥] [63/77] 0x00 0x00 0x00 0x564266c073c0
[#] [63/79] 0x00 0x00 0x00 0x564266beaee0
[စ] [63/10] 0x0e 0x0b 0x01 0x564266beaee0
[န်] [63/09] 0x0e 0x0d 0x02 0x564266beaee0

ok so here we go -- why is [⎷] moving us two cells? that's what's blowing out the bottom mathtext.

@dankamongmen
Copy link
Owner Author

Rather, c ought indeed be printed at 71, but we ought be emitting a space after the ⎷, and we don't seem to be doing so. If it's being elided, we're not skipping it properly.

@dankamongmen
Copy link
Owner Author

PRE[⎷] [63/69] 0x00 0x00 0x00 0x56392ad143c0
[⎷] [63/69] 0x00 0x00 0x00 0x56392ad143c0
PRE [ ] [63/70] 0x00 0x00 0x00 0x56392ad143c0
PRE [c] [63/71] 0x00 0x00 0x00 0x56392ad143c0
[c] [63/71] 0x00 0x00 0x00 0x56392ad143c0
PRE[₈] [63/72] 0x00 0x00 0x00 0x56392ad143c0

looks like we are indeed eliding the space. so where's our skip?

@dankamongmen
Copy link
Owner Author

[些] [63/65] 0x02 0x00 0x01 0x560d13ebcee0
PRE[⎪] [63/66] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎢] [63/67] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎜] [63/68] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎷] [63/69] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [ ] [63/70] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [c] [63/71] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[₈] [63/72] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [ ] [63/73] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [ ] [63/74] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [ ] [63/75] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎟] [63/76] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎥] [63/77] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE[⎪] [63/78] 0x02 0x00 0x01 0x560d13ed93c0 depth: -3
PRE [#] [63/79] 0x02 0x00 0x01 0x560d13ebcee0 depth: -3
NEEDMOVE: 12
[#] [63/79] 0x02 0x00 0x01 0x560d13ebcee0

that certainly doesn't look right

@dankamongmen
Copy link
Owner Author

YES [些]
PRE[些] [63/65] WIDE: 1 0x10 0x0f 0x12 0x558b2e6b5ee0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE[⎪] [63/66] WIDE: 0 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE[⎢] [63/67] WIDE: 1 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE[⎜] [63/68] WIDE: 0 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
!!⎷ PRE[⎷] [63/69] WIDE: 1 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
PRE[⎷] [63/69] WIDE: 1 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE [ ] [63/70] 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE [c] [63/71] 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE[₈] [63/72] WIDE: 0 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE [ ] [63/73] 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE [ ] [63/74] 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE [ ] [63/75] 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE[⎟] [63/76] WIDE: 0 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE[⎥] [63/77] WIDE: 1 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
PRE[⎪] [63/78] WIDE: 0 0x10 0x0f 0x12 0x558b2e6d23c0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 1
PRE [#] [63/79] 0x10 0x0f 0x12 0x558b2e6b5ee0 depth: -3
NEEDMOVE: 2147483647 INRIGHT: 0
AHHH, THE LATE SKIP
YES [空]
YES [𣎏]
YES [害]
YES [我]
YES [能]

so how is ⎷popping up as wide?

@dankamongmen
Copy link
Owner Author

we're somehow setting a character wide in cell_blend_bchannel(), locked it down to that.

@dankamongmen
Copy link
Owner Author

          bool before = cell_double_wide_p(c);
          cell_blend_bchannel(c, cell_bchannel(vis), bgblends);
          bool after = cell_double_wide_p(c);
          assert(before == after);

yeah, got a failure here. that's a smoking gun.

@dankamongmen
Copy link
Owner Author

GOT IT.

@dankamongmen
Copy link
Owner Author

Alright. Marking this fixed, though we still have some small issues. They're not this issue, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working demo relevant to notcurses-demo
Projects
None yet
Development

No branches or pull requests

1 participant