-
-
Notifications
You must be signed in to change notification settings - Fork 121
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
Comments
With the full strings, we do run into a problem. Behold:
this is using "⌈x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪" if we shorten that to "x⌉=−⌊−x⌋,α∧¬β=¬(¬α∨β)⎪⎢⎜│───── ⎟⎥⎪", we get:
|
definitely seeing some odd behavior with |
Hrmmm, surely this has nothing to do with it:
How embarrassing, if so! |
FUCK |
Alright, that's a solid fix for the long-strings issue:
|
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 :). |
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. |
Look at this using the mathtext PoC:
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! |
oh, and this is weird, there aren't extra spaces until we get down in the output:
i think something's rotten deep in our rendering here. |
|
so, our plane is the full width of the screen. each of these wide chars starts, and then gets intercepted... |
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. |
it's not seeing them as wide, i think? |
uh-oh |
sure enough, chan is coming up all 0s... |
ok, yeah. look at
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... |
That fixes us for mathtext, but unfortunately doesn't seem to have any positive impact on witherworms :(. |
this shit's killing me |
ok so here we go -- why is [⎷] moving us two cells? that's what's blowing out the bottom mathtext. |
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. |
looks like we are indeed eliding the space. so where's our skip? |
that certainly doesn't look right |
so how is ⎷popping up as wide? |
we're somehow setting a character wide in |
yeah, got a failure here. that's a smoking gun. |
GOT IT. |
Alright. Marking this fixed, though we still have some small issues. They're not this issue, though. |
I've added and attempted to enable the
mathblock
part of 'witherworms'. It looks supershitty to the max:this one's somehow even worse. what's up with these empty spaces?
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:The text was updated successfully, but these errors were encountered: