.

[curya]

.

[rsheeter]

I don't believe this is something we can fix; Adobe would need to support the format we use for color emoji (https://developer.chrome.com/blog/colrv1-fonts/).

[rsheeter]

It's possible we include fairly nasty xml in that one. Or ... @anthrotype does this seem potentially related to the subsetting issue you were poking at?

[anthrotype]

@curya in the screenshot you show two fonts, and then you say "the bottom one does work." Where did you get the two fonts from exactly? We need to know to be able to inspect them and try to reproduce.

[anthrotype]

does this seem potentially related to the subsetting issue you were poking at?

you mean https://github.com/google/fonts/issues/6295 ? Maybe..

[anthrotype]

I don't think it's the subsetting issue because I tried downloading the font from fonts.google.com and it looks ok in Safari (which also uses the OT-SVT table inside this hybrid COLRv1+SVG noto emoji font). I don't have Photoshop available to test this unfortunately. It might be that the OT-SVG table that nanoemoji produces is too complicated for Photoshop, as nanoemoji tries to share elements between SVG glyphs and to do that it has to merge them into single svg documents in the SVG table. I believe the second font from @curya screenshot (which they say 'works') is the version of Noto Emoji that Adobe produced with their own tooling, https://github.com/adobe-fonts/noto-emoji-svg; that one has one glyph per svg document and thus no reuse or sharing of elements between different glyphs. Despite no reuse, their font's SVG table is actually 3 MB smaller than the one we make with nanoemoji, maybe they have optimized the svgs more aggressively (our picosvg makes SVG simpler to parse, not necessarily more compact).

[anthrotype]

oh, their SVG table is 3 MB smaller mostly because they use SVGz (zip compressed) variant, whereas we keep it uncompressed since it yields better result when it is converted to WOFF2

[anthrotype]

@curya I made a version of the Noto Color Emoji font that has a simplified SVG table (with one color glyph per svg document, and no sharing of elements across glyphs) like the Adobe one. Can you please test if this works in Photoshop? You'll find it inside this zip archive: Noto-OTSVG.ttf.zip

Please let us know, thank you!

[anthrotype]

@rsheeter this is the only change to maximum_color to build a simpler SVG table (with no reuse). The ttf is bigger than the one with picosvg reuse (a whopping 46MB vs 23.7MB), but when both are compressed to WOFF2 they get 5.9 MB vs 5.4 MB so it's still manageable. If we use SVGZ for the at-rest TTF file, then we get 19MB font (which is actually smaller than the 23.7 MB one we make with uncompressed picosvg reuse). If the goal of including an SVG table in the COLRv1 fonts we serve is to increase compatibility and the one-glyph-per-svg-no-reuse variant has greater compatibility, then I would argue we should go for that one. I also think that parsing and rendering the "dumb" SVG table may be quicker (but have no metrics to support this theory).

diff --git a/src/nanoemoji/maximum_color.py b/src/nanoemoji/maximum_color.py
index 73e0771..20cd1c4 100644
--- a/src/nanoemoji/maximum_color.py
+++ b/src/nanoemoji/maximum_color.py
@@ -92,8 +92,9 @@ class WriteFontInputs(NamedTuple):
         table_version = self.table_version

         if identifier == "svg":
-            # for good woff2 performance, at cost of inflated size
-            return "picosvg"
+            # no picosvg reuse, store one svg document per glyph for greater
+            # compatibility
+            return "untouchedsvg"
         elif identifier == "colr":
             # optimize for woff2 performance
             if table_version not in (0, 1):

[anthrotype]

version of Noto Emoji somehow comes bundled with Photoshop...

hm maybe it does come bundled. We could ask our friends at Adobe to confirm /cc @miguelsousa

In any case, the font I sent you early on should have a different family name, "Noto Color Emoji", whereas the one from Adobe I think they named it "Noto Color Emoji SVG"

[anthrotype]

I think the top one is the font from Google Fonts (named "Noto Color Emoji Regular"), whereas the second one (which you said it works) is the bundled font from Adobe ("Noto Color Emoji SVG"):

I installed yours and see no difference.

that's a pity

Either I have to restart

please try :)

or the alleged bundled version is taking priority.

that's unlikely, they have different names so they count as two distinct fonts

[anthrotype]

ok so it works in Illustrator, good. It takes time to load because it's huge big font, and it has to parse loads of SVGs. The fact that you see all those glyph "parts" in the Illustrator Glyph Window is because the COLRv1 glyphs are composed using outlines from the glyf table (where regular black & white glyphs are also stored in non-color fonts). The font you download from the fonts.google.com zip file (as well as the custom one I uploaded here) is a hybrid font that contains both COLR and SVG tables; COLR table is used in Chrome, FireFox, Android, etc. wheres SVG table is used in Safari and Adobe desktop apps.

[miguelsousa]

version of Noto Emoji somehow comes bundled with Photoshop...

hm maybe it does come bundled. We could ask our friends at Adobe to confirm

Confirmed.

[anthrotype]

thanks Miguel! Do you know if Photoshop has any known issues with OT-SVG fonts? Does it use different font rendering stack from Illustrator?

[rsheeter]

If the goal of including an SVG table in the COLRv1 fonts we serve is to increase compatibility and the one-glyph-per-svg-no-reuse variant has greater compatibility, then I would argue we should go for that one. I also think that parsing and rendering the "dumb" SVG table may be quicker (but have no metrics to support this theory).

I think you are right. The original implementation with shape sharing, etc was built to allow a fair comparison of binary size. In that context we ofc do want reuse. We're now using them for compatibility and, as you say, in that context we probably want the simple (no reuse, aka "dumb") model.

Maybe max color should support both options, with simple on by default?

[miguelsousa]

AFAIK both Photoshop and Illustrator use the same stack. My guess is that Photoshop has the original font cached and that's why it's not rendering the one you modified. You may be able to workaround that by giving the font a different PostScript name.