migueldeicaza / SwiftTerm

Xterm/VT100 Terminal emulator in Swift
MIT License
970 stars 142 forks source link

Unicode Block “Miscellaneous Symbols and Pictographs” like 🌍 or 💡 seem to be partly hidden? #351

Open rduivenvoorde opened 2 weeks ago

rduivenvoorde commented 2 weeks ago

Thanks for SwiftTerm !

Not sure if this is a bug, or an utf-thingie...

Describe the bug

Writing a simple mqtt curses client, I wanted to use some of the tiny icons/chars, like these 🌍 or 💡 See Unicode Block “Miscellaneous Symbols and Pictographs” at: https://www.compart.com/en/unicode/block/U+1F300

In a normal terminal that looks like:

image

But in SwiftTerm (tested both on an ipad and an iphone), it looks like this:

image

To Reproduce

Save the following in test.py:

#!/usr/bin/env python3

print("💡test")

and run it by running python test.py

Expected behavior

Hoping to see the full light bulb :-)

Screenshots

See above

migueldeicaza commented 2 weeks ago

Currently there is a hardcoded table of emojis that use up two spaces:

Sources/SwiftTerm/Utilities.swift

See the table twoColumnEmoji, and the function columnWidth there.

A quick hack would be to add these values to the table.

But I think the problem that we are facing is that the width of those characters might change from font to font, or platform to platform, so rather than having a static table of widths, we might need to replace that with code that would measure the cells and determine if this needs two cells or one cell.

migueldeicaza commented 2 weeks ago

Mhm, that table already considers that value (0x1f4a1) as using two cells, so that's not the issue.

That code is correctly returning 2.

migueldeicaza commented 2 weeks ago

Ok, something went wrong at some point, but we are not taking into consideration the width of the cell at all, the renderer just goes by the column size of the glyphs rendered in a run to compute the target column.

Rather than using the width for the cell, I think it might be be good to use the actual displayed size and then snap to the next column.

rduivenvoorde commented 2 weeks ago

That sounds like an even better approach, not sure if there are any performance implications on this? But, I think even taking 2 columns/positions already probably would look better :-) Thanks for looking into this!