Emoji/Unicode support

[Andrew Scholer]

Floating an idea inspired by a book I looked at in breakout that was using unicode glyphs in a web build and a brief conversation with Rob there...

Our support for authored icons/symbols is currently (very) limited by font awesome 5. More recent versions of font awesome are incompatible license wise with our needs.

Maybe it is time to swap out font-awesome for a better icon background. I think we could do so in a way that supports relatively safe use of arbitrary unicode symbols.

Tools:

1) Google's noto-emoji font has broad and ongoing support for unicode emojis. There is a ttf font under the Open Font License as well as svg/png images of each glyph under Apache 2.0. Furthermore, there is metadata available (under Apache 2.0) for all the glyphs in JSON format. It is the default emoji font for Overleaf for HTML rendering, which seems promising.

2) Symbolla font. Used by Overleaf for B & W output.

3) Lists of supported glyphs can be scraped from https://www.fileformat.info/info/unicode/font/index.htm or derived via a little bit of python

Given those tools, it seems reasonable to have an author supply a unicode point as part of an <icon>. We can use that to verify the icon is available in both symbolla and noto-emoji and report an error if not. If so, we should have all we need to either bake the right font into the output document or use an image version from noto-emoji (though that would be nice to avoid).

From the noto-emoji metadata, we can grab a description of any arbitrary emoji and use that text to auto generate screen reader accessible versions of the icon - e.g. "Icon of poop". (Or to render those into braille).

<icon> might also support:
@decorative to indicate that it should be hidden from accessibility tools

@description (@alt?) to provide an alternate piece of text if the author wants to provide a customized description of what a symbol is meant to imply. (They are using a turtle symbol but want it to be described by something like "Uses turtle graphics")

Thoughts?

[Rob Beezer]

Dear Andrew,

Thanks for the further investigation. Thoughts (as requested!), in no
particular order.

* We are putting fonts into the distribution to support the XSL-FO conversion
"out of the box". Do the two suggested fonts have licenses (Apache) allowing
that? They would *need* to be added to continue the plan for font support for
XSL-FO.

* I should think we could make these fonts availble to a LaTeX build through an
absolute path computed in the Python (perhaps into stylesheets as a string
parameter).

* I really like the current use of icon/@name. Notice that here we could have
a smooth upgrade path for existing uses - no author would need to know the font
files had been swapped out. Maybe icon/@unicode could be some adventurous route
for the daring, an escape hatch.

* I like the idea of default descriptions, etc. And @decorative as we do now
(for #image, iirc). You have seen the lookup table for #icon, no?

* I could see these being used by style writers. Every #warning gets a stop
sign in the margin, and so on. Out of scope here, but if all teh font info is
available.

* Specifying the Unicode value is a bit more technical, and less semantic, than
I would like. I can understand the arguments against, but our job is to
encourage quality source and make author's life easier. Even if it makes our
job harder. And I should think we do not want folks getting various "strange"
characters by this route. But we can certainly expand the limited selection we
have now.

* Does a poop icon belong in a scholarly document? Ever?

Rob

On 8/25/26 13:09, Andrew Scholer wrote:
> Floating an idea inspired by a book I looked at in breakout that was using
> unicode glyphs in a web build and a brief conversation with Rob there...
>
> Our support for authored icons/symbols is currently (very) limited by font
> awesome 5. More recent versions of font awesome are incompatible license wise
> with our needs.
>
> Maybe it is time to swap out font-awesome for a better icon background. I think
> we could do so in a way that supports relatively safe use of arbitrary unicode
> symbols.
>
> Tools:
> 1) Google's noto-emoji font has broad and ongoing support for unicode emojis.
> There is a ttf font under the Open Font License as well as svg/png images of
> each glyph under Apache 2.0. Furthermore, there is metadata available (under
> Apache 2.0) for all the glyphs in JSON format. It is the default emoji font for
> Overleaf for HTML rendering, which seems promising.
>
> 2) Symbolla font. Used by Overleaf for B & W output.
>
> 3) Lists of supported glyphs can be scraped from https://www.fileformat.info/

> info/unicode/font/index.htm <https://www.fileformat.info/info/unicode/font/
> index.htm> or derived via a little bit of python

>
>
> Given those tools, it seems reasonable to have an author supply a unicode point
> as part of an <icon>. We can use that to verify the icon is available in both
> symbolla and noto-emoji and report an error if not. If so, we should have all we
> need to either bake the right font into the output document or use an image
> version from noto-emoji (though that would be nice to avoid).
>
> From the noto-emoji metadata, we can grab a description of any arbitrary emoji
> and use that text to auto generate screen reader accessible versions of the icon
> - e.g. "Icon of poop". (Or to render those into braille).
>
> <icon> might also support:
> @decorative to indicate that it should be hidden from accessibility tools
> @description (@alt?) to provide an alternate piece of text if the author wants
> to provide a customized description of what a symbol is meant to imply. (They
> are using a turtle symbol but want it to be described by something like "Uses
> turtle graphics")
>
> Thoughts?
>

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N-O69v6AuFX-pK%2BK7pEnd0RAi08sYGJZ%3D9wZp2AASGwZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/CACm44N-O69v6AuFX-
> pK%2BK7pEnd0RAi08sYGJZ%3D9wZp2AASGwZg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Andrew Scholer]

The google fonts are OFL 1.1 which allows for embedding. Symbola is freeware.

Naming could be done via unicode names... but those are sometimes unwieldy - see "BLACK RIGHT-POINTING DOUBLE TRIANGLE" instead of "fast-forward". That would be semantic and tied to a universal standard. Which seems preferable to inventing our own standard.

It looks like existing icon names either map to a similar enough icon (wrench/gear), or do not map to a standard name, which means we could rewrite them ("file-save" --> "FLOPPY DISK").

As to poop... I don't know that you were expecting a serious answer, but the Codelens widget represents the value of an invalid pointer with a poop emoji. So if you wanted to describe what a user was seeing in a text using it, you would likely want to use that emoji in your description. :)

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0eEhtMDllV2k.1787711471%40pnsh.

[Rob Beezer]

On 8/26/26 13:51, Andrew Scholer wrote:
> The google fonts are OFL 1.1 which allows for embedding. Symbola is freeware.

Excellent.

> Naming could be done via unicode names... but those are sometimes unwieldy - see
> "BLACK RIGHT-POINTING DOUBLE TRIANGLE" instead of "fast-forward". That would be
> semantic and tied to a universal standard. Which seems preferable to inventing
> our own standard.

Unicode names. Yuck! ;-) You would have to look them up each time you wanted
them. That's not convenient. I have been thinking overnight that I think I
really want to stick with @name, rather than Unicode numbers.

I'll grant you "fast-forward" is maybe not great. But I think
"double-right-triangle" is workable. And note that we could keep
"fast-forward", in this case for backward compatibility, but also perhaps as an
alias (or something with a better/different description).

Rob