--symbols all including all and only glyphs specified in --glyph-file

[clort81]

Shouldn't --symbols all with a specified --glyph-file include all but only glyphs specified in the glyph file? (font).

 chafa --color-space din99d  --symbols all --glyph-file /pr/Fonts/fonted/Blapinus3ChafaSet-12.pcf.gz -w 6 --size $(tput cols)

Seems to give me a lot of glyphs not extant in said font

Sample font:
Blapinus3ChafaSet-12.pcf.gz
Font for terminal (I may have made mistakes, if anyone finds any, let me know)
Blapinus3Medium-12-12.pcf.gz

[clort81]

This may be in an invalid issue. Is it intended for chafa to dynamically generate the list of valid symbols to encode-to based on contents of --glyph-file?

By the way it's a revelation how well --glyph-file works with braille when the font uses edge-to-edge braille glyphs.

Here's a midjourney v4 forest at 132 columns, x11 default 6x12 vs blapinus:

chafa --color-space din99d  --symbols block+space+solid+stipple+quad+half+hhalf+vhalf+inverted+braille  --glyph-file /usr/share/fonts/X11/misc/Blapinus3Medium-12-12.pcf.gz -w 6

forest_atmos_001.ans.gz

[clort81]

And with braille and blapinus font we're in this territory:

Trails-GME.ans.gz
131 columns, with mixed braille and blockchars.

sam-coromon02.ans.gz

[hpjansson]

That looks really sweet.

--glyph-file is orthogonal to --symbols. It doesn't affect the symbol selection at all. I'm really glad you filed this issue, because your intuition is right: There should be a way to say "include all/only the symbols from imported glyphs". Chafa already has the list of symbols from the imported file, so it should provide that convenience.

I'll see if we can add a --symbols glyph or similar.

[clort81]

Thinking in terms of bitmasks it seems to me the selection range should be logical:

(Glyphs_in_font_file_if_supplied) AND (Glyphs_in_Predefined_Ranges OR Glyphs_in_user_supplied_ranges)

Where the Glyphs_in_Predefined ranges are e.g. blocks, braille etc.

Something something chafa_symbol_map_find_candidates(

Aaa the whole thing is built around bitmasks? Not an array of glyphs that gets populated? This is real work to implement?

[hpjansson]

Aaa the whole thing is built around bitmasks? Not an array of glyphs that gets populated? This is real work to implement?

It's just the selectors that're a bitfield. They're stored as a list and applied in order to each symbol, and the symbols passing through the "sieve" of multiple selectors get added to an array.

It's not a lot of work to implement, in fact I did it just now :-)

The commit adds a new selector class: "imported" ("import" works too). This selector matches glyphs from any --glyph-file argument. So for instance, you can do --symbols imported-block-border-dot if you want to use only symbols for which there are imported glyphs, but throw out the block, border and dot-like ones.

The + and - operators aren't perfect. Long term it might be better to have something like s-expressions so you can do (imported & (ascii | braille)) to get only the ascii and braille symbols from the imported set. But alas, that would require writing a more competent parser.

[hpjansson]

@clort81 Let me know if this works for you!

[clort81]

Thank you hpjannson! Definitely works for not getting unmapped glyphs +++

No luck getting petscii diagonals yet.
Here's a test image i'm working with.

Is the PUA range blocked?

Oh and this perl script is useful to see the codepoints i get.

chafa (etc) |unicp.pl |sort -u
unicp.pl.gz

[EDIT]
I am attaching a 6x12 pcf "chafatest" testfont with glyphs i am considering using. Many are taken from the unicode 13 classic computer additions, but mapped into the PUA (private user area) range per the Unscii schema, due to Xorg bitmap fonts not supporting codepoints above U+FFFF.
The braille glyphs are drawn as connecting blocks, and not the more common 'dot-braille' shape.

The experimental glyphs I am most interested in are the four between U+E1AB to E1B2, as these render with a slope of 45 degrees. Glyphs to render 45 degree angles with are regrettably missing from both the Unicode Consortium and Viznut's "Unscii" set.

The pcf.gz file is here and is free to use. I drew all of these and declare them to be under SIL license, if any jurisdiction still considers tiny bitmap fonts to be under copyright.
chafatest.pcf.gz

The new chafa with symbol-delimiting import was invoked with:

$ /usr/local/bin/chafa  --symbols imported --glyph-file /usr/share/fonts/X11/misc/chafatest.pcf.gz -w 7 -s 78 -c 2 45triatest.png

The results at 78 column width looked like this:

Notice that I do not get any glyphs u+E1AB to u+E1B2 corresponding to 45 degree diagonal. I also tried with --symbols imported-braille to try to give the petscii a scoring advantage but that didn't work.

In chafa/chafa-symbol-map.c , I noticed the ifdef 0 /* Private */ and it seems that setting the ifdef to 1 would hide the PUA range. Is that correct? Since it was 0, it seems that's not the cause of the failure.

I've tried here to provide a test case free of complicating factors. If there's any interest, I can provide my complete 6x12 bitmap terminal font with retro-graphics and good latin coverage.

Cheers!

[hpjansson]

Thanks for all the info. I'll need some time to digest it. Two quick comments:

• Did you try with -w 9?
• Have you tried with --symbols e1ab..e1b2?

[hpjansson]

The PUA range is not explicitly blocked (see the block lists in

chafa/chafa/internal/chafa-symbols.c

Line 93 in 03affd6

static const UnicharRange ambiguous_ranges [] =

and below), but there may be exclusions due to the Unicode metadata in GLib (I don't think this is the case, but they may be "ambiguous width", for instance). You can make sure you get everything by adding +bad to the symbol selection.

[clort81]

Thanks, I needed the +bad flag!
For technical drawings where i want exact angles, I'm not there yet.
Will investigate more.

But ... it's AMAZING on pictures, with my font. Maybe i should make a gist or webpage for this.
132 columns, some contrast enhancing with imagemagick ahead of conversion.

80 columns:

[hpjansson]

Wow, I love this.

You shouldn't be needing the +bad selector for PUA, that's probably a bug. I'll fix that.

[clort81]

Maybe anything in an imported glyph should override 'bad'? not sure.
If i include +bad, i also get crazy codepoints not found in my imported font.
Pics are ai-generated so no copyright. Feel free to use them.

[cdluminate]

This is awesome. I love it too! It has much less tricky details than my k-means font (LOL). I was just too lazy to draw anything manually, but I did not realize a small amount of manually drawn glyph can already lead to such a wonderful result.

[clort81]

I'm adding new glyphs and scoring them with chafa - i wouldn't say the font is finished.
It takes a while to run through sets and score fonts but there is a fairly small set that gets us to high ultility.
Even for the small 6x12 bitmap we have 2^(6*12) possible glyphs, which is a lot to go through programmatically :)

[hpjansson]

@cdluminate I improved the font loader, so it may be possible you'd get different (even better) results from your fontgen today :-)

[cdluminate]

Great! I think I need to fine a time slot to get the python code updated 😆

[hpjansson]

You shouldn't be needing the +bad selector for PUA, that's probably a bug. I'll fix that.

Done, fixed in 58f40ca.