Noto Color Emoji from google.com/get/noto/#emoji-qaae-color
is only usable in Android. On Windows, that font will not install (it is considered broken.invalid), because the Windows text renderers do not support colors in fonts.
To display those colorful emojis, you'll need a plugin in your browser that will substitute SVG images (if the browser supports SVG), otherwise a scaled down bitmap (scaled bitmaps can be rescaled in HTML with simple CSS, on browsers that support zoom in CSS, or geometric transforms in the Canvas, so that the image will render at the expected font-size).
However I have no problem at all displaying all emojis listed in the Unicode charts on Wikipedia with my browser (Chrome on Windows 10).
But it's true that I have installed the FULL Noto font collection (except the Color Emojis font that Windows does not want), and even made it the default in my browser (because it has coherent metrics across all scripts) and supports almost all of them, many with various styles, and most of them are well hinted.
"Noto" is a fabulous collection of free fonts (with a free licence). Its development continues as Google wants it for Android in all languages of the world. Things are regularly updated to fix minor quirks. It is intended to cover all characters standardized in the Unicode/ISO 10646 repertoire.
"Robo" was an initial "fast" fallback collection created with less care but that provided missing characters for the huge ideographic scripts. But its design was not so careful. Progressively, characters are integrated to Noto and removed from the Robo collection. Also Robo exists in only one style (for other styles such as bold and italic, the text renderer of the browser will synthesize them, notably in Chrome, but italics may be too much slanted, and strokes may collide ungracefully in complex scripts with many strokes such as sinograms: there's no such problem with Noto that even provides 6 font-weights for CJK sinograms). So, use it only as a fallback for those that have old versions of Noto in CSS like as following: font-family:Noto,Robo,sans-serif;
That's all what is needed (you don't need more fonts, the last fallback to sans-serif allows getting access to some OS-specific fonts that would be present for implementing characters not found in Noto and not even in early versions of Robo when using early versions of Noto).
I really love Noto. Thanks to Google for making it fully open-sourced (and to all those that have contributed to extend it and fix quirks in complex scripts). It's definitely a huge improvement compared to what Microsoft did in the past (but only for Windows, and still with many mis-matching across world scripts).
Best Answer
Many programs have explicitly dropped support for Type 1 fonts, years ago. While
fontconfig
and FreeType do support Type 1 fonts, many other libraries and programs don't. In most cases,fontconfig
just passes font locations to the program, which can either use another library or render them itself. That's why the fonts render inconsistently across programs.Cross-platform applications, such as LibreOffice, Inkscape, and Firefox, in particular are likely to have dropped Type 1 support because they are working with the least common denominator. According to Wikipedia, "[Type 1 fonts] are not supported in the Windows GDI+, WPF or DirectWrite APIs." Other issues with Type 1 fonts are limited character set and absent unicode support.
Going forward, the trend is to see less and less Type 1 use. Ultimately, the only programs that will support it are the ones that have to, namely PDF/PS viewers and font editors. Once this happens, there's no easy way to recover Type 1 support except to go back to using software from five or more years ago, when Type 1 support was more prevalent.
To avoid seeing "broken" Type 1 fonts, you can configure
fontconfig
to hide them. This is basically jumping forward to where Type 1 support is heading.Create the file
/etc/fonts/conf.d/00-reject-type1.conf
with the following contents:Then refresh the font cache with
sudo fc-cache -r
.Font viewers and editors should continue to work as expected, as long as they access the font files directly.
PDFs with embedded fonts should display correctly. When external fonts are referenced, they should use the OpenType or TrueType font that
fontconfig
specifies. (I use Okular. Other Poppler based viewers should behave similarly.)TrueType and OpenType versions of most Type 1 fonts are available. Many converted fonts have been extended with unicode support. Here are a few packages:
fonts-urw-base35
fonts-texgyre
fonts-lmodern
Some typefaces will have different names. If the fonts are installed via the package manager,
fontconfig
should be configured to substitute the correct fonts. If you install fonts by copying font files, you'll have to configure font substitution yourself or manually change font names in documents.The behavior of TeX Live with Type 1 fonts hidden in
fontconfig
is as follows...latex
+dvipdf
embeds Type 1C fonts.pdflatex
embeds Type 1 fonts.xelatex
andluatex
embed Type 1C and CID Type 0C fonts.This is the test document I used: