Columns are messed up with ANSI color codes
fardavide opened this issue · comments
Expected behavior
Tables to be correctly drawn with ANSI color codes
Current behavior
Tables are messed up with Chinese ANSI color codes
Version: 0.4.0
OS: MacOS BigSur - english language
IDE: IntelliJ Idea Ultimate 2020.2
Kotlin: 1.4.0
Project type: Multiplatform, JVM variant only for this module ( stdlib-jdk8 )
JDK: 14
TEXT EXAMPLE
"\u001B[46mWelcome to My App!\u001B[0m"
TEXT RESULT
┌───────────────────────────────────────────────────────────────────┐
│ │
│ Welcome to My App! │
│ │
├──────────────────────────────────┬────────────────────────────────┤
│ │ commands │
├──────────────────────────────────┼───────┬────────────────┬───────┤
│ Search a Movie by title │ 1 │ search │ s │
├──────────────────────────────────┼───────┼────────────────┼───────┤
│ Rate a Movie by id │ 2 │ rate │ r │
├──────────────────────────────────┼───────┼────────────────┼───────┤
│ Get suggested Movies for you │ 3 │ suggestion │ g │
└──────────────────────────────────┴───────┴────────────────┴───────┘
Closing. Updated #19 in order to include this scenario, since they can be linked to the same root of the problem
I'm going to keep this separate because it's about non-displaying characters which is significantly easier to handle.
I took a quick stab at this today. Fixing the measurement is easy. Unfortunately, as an effect, that means the column size changes which means the text area into which the string is written becomes smaller than the actual string.
This will require larger changes to how rendering works.
I pushed a branch which has some tests that are Hard™.
Going to take a break for a week or so to just think on this in my idle time. This really destroys the current mechanism by which we create the table which is a 2x2 grid of characters that is treated somewhat like pixels in a bitmap. In this new world, a cell may need 18 characters of width to visually display only 5 characters. This has implications for how alignment works (especially when a single cell spans multiple lines).
I've found that 0x200C (zero-width non-joiner) can be used as a fill character that renders to nothing if we need to pad our text bitmap, but it basically solves no real problems. It's a solution for the second problem, and I haven't solved the first. How the hell we adapt rendering to accommodate what essentially blows up our square table. It would be great to not need this character though, but that then requires measuring every line individually.