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

Ideas to improve fg/bg discrimination for invertable glyphs. #127

Open
clort81 opened this issue Feb 2, 2023 · 1 comment
Open

Ideas to improve fg/bg discrimination for invertable glyphs. #127

clort81 opened this issue Feb 2, 2023 · 1 comment
Labels
quality Output quality

Comments

@clort81
Copy link

clort81 commented Feb 2, 2023

Not unique to chafa, but all image to text convertors that support the invertable characters (half blocks, quarter blocks and braille) generate useless images when the output device has some asymmetry in rendering the normal and inverted glyph.
The two bad cases are:

  1. When the terminal adds pixels of vertical space between lines - these typically get filled with the background color and creates ugly pictures.
  2. When the font's symmetric glyphs are not truly symmetric to inverted, as common with the braille set. e.g.:

braille_inverses

What could be added to chafa to make rendering consistent there? Two ideas:

  1. Add a flag to have chafa always assign the brighter color to the foreground (or vice versa)
  2. Allow chafa to import two images, for the conversion. One would be the foreground image, the other the background. Then artists could export say, the above text as the foreground layer, and the background as the background layer.

Anyone have thoughts on this?

@hpjansson
Copy link
Owner

I think 1) could be interesting, and it should be fairly easy to test. It's a bit similar to --fg-only with a dark background, or the 16/8 mode, which allows bright colors in FG only.

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

No branches or pull requests

2 participants