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

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

Open
rduivenvoorde opened this issue Sep 23, 2024 · 4 comments

Comments

@rduivenvoorde
Copy link

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
Copy link
Owner

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
Copy link
Owner

migueldeicaza commented Sep 24, 2024

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
Copy link
Owner

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
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants