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

Multicolor glyph support #231

Open
hpjansson opened this issue Nov 7, 2024 · 15 comments
Open

Multicolor glyph support #231

hpjansson opened this issue Nov 7, 2024 · 15 comments
Labels
feature New feature or request symbols Fonts and symbols

Comments

@hpjansson
Copy link
Owner

@PhMajerus suggested color emoji/glyph support in #201. Especially the various color hearts are interesting. This requires:

  • A new glyph matching path for RGBA8888 data.
  • A small API addition in ChafaSymbolMap to import multicolor glyphs.
  • Probably at least one new symbol tag -- CHAFA_SYMBOL_TAG_EMOJI, CHAFA_SYMBOL_TAG_HEARTS, or something like that.

We could seize the opportunity to allow monochrome glyphs to be represented this way too (as grayscale coverage), using bigger 16x16 pixmaps for matching, then employ it automatically at high work factors to maximize quality.

@hpjansson hpjansson added feature New feature or request symbols Fonts and symbols labels Nov 7, 2024
@PhMajerus
Copy link

PhMajerus commented Nov 7, 2024

If you want to support several shapes, there are 3 sets that can easily be handled with the same converter as they provide the same colors and just need a chars lookup table change:
Squares: ⬛⬜🟥🟧🟨🟩🟦🟪🟫, they are in Unicode 12.0, but be aware that the first two might not look the same as the rest of the set in some fonts, or even render as monochrome symbols instead of Emojis.
Circles: ⚫⚪🔴🟠🟡🟢🔵🟣🟤, they are in Unicode 12.0, and again the first two might look different.
Hearts: 🖤🤍❤️🧡💛💚💙💜🤎, this set is in Unicode 12.0 and should render as consistent color Emojis in all fonts.

And then there is the better but less supported one:
Hearts (extended): 🖤🩶🤍❤️🧡💛💚💙🩵💜🤎🩷, this set is nicer as it provides 12 colors instead of 9 and the lighter gray and blue really help for many images, but it requires Unicode 15.0, so it should probably be a separate explicit choice.

@oshaboy
Copy link
Contributor

oshaboy commented Nov 10, 2024

First things first, there should be some way of testing these with multiple fonts. None of the emoji have a "canonical" exact color like 16 color ANSI does (sure you can customize them in most terminals, but traditionally ANSI art assumes the colors match the behavior of default VGA)

I tried installing many emoji fonts on a Linux system but they all caused conflicts and I haven't come up with a better way of testing for multiple emoji fonts. Some of the colors can vary wildly in hue, saturation and brightness across fonts.

So there needs to be a program that allows someone to quickly swap and compare emoji heart images in several popular fonts

@stgiga
Copy link

stgiga commented Jan 5, 2025

If you want to support several shapes, there are 3 sets that can easily be handled with the same converter as they provide the same colors and just need a chars lookup table change: Squares: ⬛⬜🟥🟧🟨🟩🟦🟪🟫, they are in Unicode 12.0, but be aware that the first two might not look the same as the rest of the set in some fonts, or even render as monochrome symbols instead of Emojis. Circles: ⚫⚪🔴🟠🟡🟢🔵🟣🟤, they are in Unicode 12.0, and again the first two might look different. Hearts: 🖤🤍❤️🧡💛💚💙💜🤎, this set is in Unicode 12.0 and should render as consistent color Emojis in all fonts.

And then there is the better but less supported one: Hearts (extended): 🖤🩶🤍❤️🧡💛💚💙🩵💜🤎🩷, this set is nicer as it provides 12 colors instead of 9 and the lighter gray and blue really help for many images, but it requires Unicode 15.0, so it should probably be a separate explicit choice.

I should mention that Windows 11 Terminal just added color emoji support that can be toggled.

UnifontEX being based on Unifont-JP 15.0.06+15.1.01 + Unifont 11.0.01 Upper (and thus Unicode 15.1 for Plane 0 and Unicode 11 for Plane 1) has some support factors to consider. Since the colored squares were added post-Unicode 11 they will display in color. The hearts are all monochrome except for the white heart emoji (there are other white heart characters), light blue heart, gray heart, pink heart, and brown heart. Basically, UnifontEX doesn't contain the needed heart colors to do a trans flag in hearts (though it does have the symbol), and it can't do the brown heart if doing a progress flag.

The only colored circles UnifontEX does are blue and red.

UnifontEX follows Unicode code charts on how to draw stuff in color but monochrome and does so via different shading. Unifont Upper versions higher than my usage actually went to the rest of the hearts but the new designs are larger and the newer colored circles are less round. Unicode 12 is when 16x16 started getting the most annoying to fit into and when style took a downturn. Once again, the colored stuff in Unifont(EX) is done as pattern fill.

The "Red Envelope" emoji and the colored notebook emojis also follow the shading too.

Note that another factor is that Unifont(EX) does not do Zero-Width Joiners in emoji. Emoji that use them are rendered as their components sequentially.

@oshaboy
Copy link
Contributor

oshaboy commented Jan 5, 2025

Doesn't unifont not support colors at all and uses heraldic hatching patterns?

@stgiga
Copy link

stgiga commented Jan 5, 2025

Doesn't unifont not support colors at all and uses heraldic hatching patterns?

Precisely! The problem is that if you're in one-TTF/file (most programs) 65535-glyph-max (this max count applies in non-HarfBuzz, non-BDF, and non-iOS-SVG fonts) fonts, you're not going to clear a Plane 1 Unicode version that has colored squares or most of the colored circles or some of the colored hearts. The stuff from Unicode 12+ displays in color on MODERN devices. But then you have stuff in the wild significantly older than 2019. Those don't have anything to insert.

@oshaboy
Copy link
Contributor

oshaboy commented Jan 5, 2025

I don't see what that has to do with anything.

@stgiga
Copy link

stgiga commented Jan 5, 2025

I don't see what that has to do with anything.

I'm saying that yes, Unifont(EX) uses the heraldry color hatching, and as such if you don't have a system emoji font that colorizes them and your only option is Unifont(EX), things will get a bit wild.

@oshaboy
Copy link
Contributor

oshaboy commented Jan 5, 2025

I don't see what that has to do with anything.

I'm saying that yes, Unifont(EX) uses the heraldry color hatching, and as such if you don't have a system emoji font that colorizes them and your only option is Unifont(EX), things will get a bit wild.

I doubt there's anyone who doesn't have some sort of color emoji font installed considering how common emoji are.

@stgiga
Copy link

stgiga commented Jan 5, 2025

Think Linux, though maybe BSDs and Hurd. At least the OSes that can technically run Chafa. That, or you're using the BDF version in your terminal and haven't ran X. Also Windows 11 Terminal is now able to toggle color on/off.

Also the amount of older devices able to browse modern sites is not insignificant.

@oshaboy
Copy link
Contributor

oshaboy commented Jan 5, 2025

I feel like "Chafa doesn't work if your system doesn't support the characters" is a given.

@hpjansson
Copy link
Owner Author

Thanks, @stgiga. I'm glad to have this feedback! UnifontEX' impressive glyph count helps us push the envelope too.

The color emoji support wouldn't be something that'd be enabled by default, so it shouldn't cause any compatibility issues with your font. The coincidental 16x16 coverage (and 32x16 for fullwidth) should enhance the monochrome output, though.

@stgiga
Copy link

stgiga commented Jan 6, 2025

Thanks, @stgiga. I'm glad to have this feedback! UnifontEX' impressive glyph count helps us push the envelope too.

The color emoji support wouldn't be something that'd be enabled by default, so it shouldn't cause any compatibility issues with your font. The coincidental 16x16 coverage (and 32x16 for fullwidth) should enhance the monochrome output, though.

The Unicode 15.1 version has 65422 glyphs (compared to the 65417 of prior), and that's even closer to 16bit grayscale, and when you have the ability to choose foreground and background color of such a gamut you can achieve output that is extremely accurate to an input image. Humans are actually more sensitive to changes in brightness than color. Also I got better results on the Unicode 15.1 version when converting photos to text art.

Here's an example of using Chafa in fine detail:

ChafaTest
FullHeight

Fancy

@stgiga
Copy link

stgiga commented Jan 6, 2025

Also the black and white circles you chose show up as halfwidth in UnifontEX while the colored circles are fullwidth, even the red and blue ones that are present in UnifontEX hatched. The black and white squares in UnifontEX are close in size to the colored Unicode 12+ squares, and the hearts that are hatched or monochrome are close in size to the newer color hearts.

I should mention that on NTSC if you have a very ancient monochrome TV (pre-1953), and you feed it a color signal, in colorful areas you will see a hatching pattern, essentially chroma dots. The Apple 2 if plugged into a PAL or SECAM TV will show as hatched monochrome because the Apple 2 uses NTSC artifacts to be color, and essentially what would be a sort of hatched pattern is artifacted by NTSC TVs into color.

On Windows I've seen situations in which ClearType makes certain characters have rainbow fringes if scrolled.

Basically, the hatched approach to colors isn't far off how some situations handle colors.

@hpjansson
Copy link
Owner Author

Thanks for the samples - one issue I see is the ambiguous-width symbols, which we basically can't do anything about :-/

@stgiga
Copy link

stgiga commented Jan 7, 2025

Thanks for the samples - one issue I see is the ambiguous-width symbols, which we basically can't do anything about :-/

Theoretically since I'm using Symbols=imported you could also read widths from the TrueType when calculating characters. At least I've demonstrated how high you can go.

Using the extremely janky Ascify-Art I was able to get a decent Bad Apple on the old version, and I think the extra glyphs could improve quality. But yeah, photorealistic text art is possible when you have ~2^16 characters involved. And yes, the test image is one of my artworks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request symbols Fonts and symbols
Projects
None yet
Development

No branches or pull requests

4 participants