Although not something you would need to do in a research paper, this would be useful in other contexts (e.g., a TODO TeXmacs document).
You should check if a font has it. Then use the unicode code to get them into the document. I’m not sure how they work usually.
Emoji only seems to work for a few icons. When pasting “🖛” into TeXmacs, only “” shows up, the others are shown as unicode. I’ve tried different fonts and verified that they support all of these icons in LibreOffice.
Upon closer investigation the standard fonts in TeXmacs don’t support emoji. I have used Gnome Font Manager to check. LibreOffice must do some substitution when a character is not available in the font.
The only Emoji font in the TeXmacs font database is Apple Color Emoji.
I have tried importing an emoji font from my system (Noto Color Emoji) but TeXmacs crashed.
Some more things I have found out trying to get more emoji to work.
TeXmacs looks recursively in specific paths for fonts:
- On all systems:
- On Linux:
- On Windows:
- On Mac:
In my case (Fedora Linux) the default system font path is
/usr/share/fonts/, which isn’t searched. A quick fix is to create a symlink in
$HOME/.fonts to that path. There is also a preference “imported fonts” that is searched (see
(set-preference "imported fonts" "/usr/share/fonts") should add the directory to the search path.
This way I could select Emoji fonts without TeXmacs crashing. However, color emoji don’t seem to be supported. This led me to this site:
The best current choice for me seems to be SymbolA. Color fonts with black and white fallbacks also don’t seem to work.
And, GNU TeXmacs does not support Noto fonts.
This is not immediately relevant, but I was curious what the “Import…” button in the font selection dialog does. Perhaps it will be useful to others.
It basically adds the parent directory of the selected font file to the “imported fonts” preference (as a colon-separated list) and adds the font file to the global “font_table”.
So, if you move the font file later on, the font will stop working. The file is not copied into your
.TeXmacs/fonts folder, for example.
A side-effect of this mechanism is that paths in
imported fonts are searched by the “Look for more fonts” function. So, if you import one font from a directory containing many fonts, the next time you search for more fonts they will all appear in the font database.
Note that there now is a nice package to use Font Awesome icons in TeXmacs:
I think what I did for font awesome could be done for other symbol fonts. We have to single out a nice free alternative and maybe ship it with TeXmacs. Any suggestion?
If I understand correctly, the situation for Emoji fonts is somewhat different. If the font supports the Unicode character you are after, you can simply insert it into TeXmacs as you would in any other program. The problem is however, that TeXmacs doesn’t support colour emoji, so yo need to use a black and white font.
Some colour emoji fonts are supposed to have included fallback black and white version, but I haven’t found a way yet to check this. Then still, I don’t know if there is a mechanism in TeXmacs to select such variants of fonts.
With SymbolA you can get a fair selection of emoji. This is a sample:
Ok, thanks @jeroen. The problem is the color then. Indeed I’m looking right now into the font stuff and would like maybe later on to improve also on this matter. There are nice fonts which require more complex rendering and which we would like to use. Does pdfTeX supports them? How emoji are implemented there. Note that for a one-shot use, one can always embed the image, or we can have a scheme plugin which renders the emoji in an image (e.g. from an SVG description) and packs it as a TeXmacs macro for easy use.
It seems not:
I saw the SVG tables in the OpenType specification, I think. However I looks a lot of work to integrate in TeXmacs. A solution based on images should be preferable. We can just integrate the SVG (or PDF) description in a scheme file or a similar database and then use scheme to render them to PDF and include in the document as raw data.
What about SVG -> tm graphics and embed those? Wouldn’t that be a nice plugin project…
If there is no need to edit then I think it is better to embed SVG or PDF (currently I think we cannot render directly SVG in vector form). However SVG->TM would be really cool to have. I do not think should be really difficult for a basic support. We already can parse HTML and XML so it is just a matter of implementing the dispatch. It would also be useful to have TM->SVG.
SVG has been improved now.