in reply to Emoji Progress Spinners

While the code runs for me and I do use unicode-enabled terminals for pretty much everything, the problem I encounter is that the fonts don't necessarily cover the codepoints. Most of the time I use urxvt256c with xft:Hack-Regular and it has none of these characters. The default font in terminology (which is DejaVu Sans Mono (Book)*) does have all of the clockface characters but only about half (!) of the moon phase ones.

There is probably no way to be able to tell reliably from within the script whether these codepoints will be rendered correctly by the terminal so there's no fall-back option. While this is a cool demo, I don't think it can be used universally just yet.

* I can't recall if this was the default when it was installed or something I configured at the time. It was years ago :-)


🦛

Replies are listed 'Best First'.
Re^2: Emoji Progress Spinners
by kcott (Archbishop) on Feb 07, 2021 at 18:06 UTC

    G'day hippo,

    As you can see, I made some serious attempts to choose the best Perl version. There are, of course, other considerations such as platforms and available fonts; for instance, check parv's shell problems.

    "There is probably no way to be able to tell reliably from within the script whether these codepoints will be rendered correctly by the terminal ..."

    As an absolute statement, I would have to agree; however, there are ways to mitigate this. In a recent module (Tk::Aux::Font) that I wrote — purely for my own use — I had this subroutine:

    sub _best_family { my ($mw, $type) = @_; state $families = { sans => ['Verdana', 'DejaVu Sans', 'Helvetica'], serif => ['Times New Roman', 'DejaVu Serif', 'Times'], mono => [ 'Menlo', 'Andale Mono', 'Lucida Console', 'Consolas', 'Courier New', 'Courier' ], emoji => ['Times New Roman', 'DejaVu Serif', 'Times'], }; my $actual_family; for my $family ($families->{$type}->@*) { my $test_font = $mw->fontCreate(-family => $family); $actual_family = $mw->fontActual($test_font, '-family'); last if $actual_family eq $family; } return $actual_family; }

    Whilst developing, I tweaked this multiple times, especially with respect to the actual font order for various families. My overall findings were that "sans" and "mono" failed to produce many glyphs; "serif" and "emoji" (in this instance, the same lists) rendered many more. On my Win10/Cygwin, "Times New Roman" was the best; "DejaVu Serif" came a very close second (it seemed to render glyphs a pixel or two below the optimal position); "Times" was OK but resolution was poor and I'd rank it as a poor third cousin.

    Based on all of this, I'd recommend that you render with "DejaVu Serif", instead of "DejaVu Sans".

    Please bear in mind that was, as stated, intended to be "a little more visually appealing"; it solves no bugs nor improves any optimisations. It's possibly a nice-to-have but never essential.

    If it's of any use, here's a relevant extract from my local CSS:

    :root { --font-pref-sans-serif: "Verdana"; --font-pref-serif: "Times New Roman"; --font-pref-monospace: "Menlo", "Andale Mono", "Lucida Console", +"Courier New"; --font-manuscript-base: "Junicode"; --font-alchemy-base: "Newton Sans Regular"; --font-emoji-base: "Apple Color Emoji", "Segoe UI Emoji", "EmojiOne", "AndroidEmoji", "emojidex", "fxemoji", "NotoColorEmoji", "Twemoji"; --font-symbol-base: "Symbola"; } :root { --font-std-sans-serif: var(--font-pref-sans-serif), sans-serif; --font-std-serif: var(--font-pref-serif), serif; --font-std-monospace: var(--font-pref-monospace), monospace; --font-std-cursive: cursive; --font-std-fantasy: fantasy; } :root { --font-manuscript: var(--font-manuscript-base), var(--font-std-serif); --font-alchemy: var(--font-alchemy-base), var(--font-std-sans-serif); --font-emoji: var(--font-emoji-base), var(--font-std-monospace), var(--font-std-sans-serif); --font-symbol: var(--font-symbol-base), var(--font-std-monospace), var(--font-std-sans-serif); --font-emoji-or-symbol: var(--font-emoji-base), var(--font-std-monospace), var(--font-std-sans-serif); /* var(--font-symbol-base); */ --font-unicode-raw: var(--font-pref-serif), var(--font-symbol-base), serif, var(--font-std-sans-serif), var(--font-std-monospace), var(--font-std-cursive), var(--font-std-fantasy); }

    — Ken

      Based on all of this, I'd recommend that you render with "DejaVu Serif", instead of "DejaVu Sans".

      Having just tried that I regret to report that it has made no difference. There's also no real mono DejaVu Serif available so the terminal just looks awful too. :-)

      It will doubtless all work fine when I get around to upgrading.


      🦛

        It's unfortunate this didn't work for you. The Unicode® version required (9.0) is fairly old; and a reasonably old Perl version should have handled it.

        Of course, OS versions, command line capabilities, and so on, make all the difference. When you "get around to upgrading" perhaps your outcome might be more favourable.

        I'm sorry I'm unable to provide further assistance with this.

        — Ken