User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Steps to reproduce: I tried to use the AdobeBlank2 font. AdobeBlank is a font that covers the full Unicode range and maps characters to a blank character. It can be used to show a blank character instead of leaving the browser use a default font. AdobeBlank (https://github.com/adobe-fonts/adobe-blank) is using CMAP format 12 and works. AdobeBlank2 (https://github.com/adobe-fonts/adobe-blank-2) is a newer version of this font that is 10% smaller because it uses the range mechanism of CMAP format 13. This font does not seem to work in Firefox on the windows platform. # steps to reproduce 1. Add the following snippet on a web page <link href="https://rawgit.com/adobe-fonts/adobe-blank-2/master/adobe-blank-2.css" rel="stylesheet"/> <span>---></span> <span style="font: 12pt AdobeBlank2;">A</span> <span><---</span> and see what appears on screen. Additional ressources : - issue created on adobe-blank-2 : https://github.com/adobe-fonts/adobe-blank-2/issues/1 - spec opentype CMAP - https://www.microsoft.com/typography/otspec/cmap.htm Note that the expected result happens on chrome 54 (windows platform), probably because this browser uses HarfBuzz to parse CMAP tables. Actual results: the following text is shown : --->A<--- Expected results: The letter A should have been replace by an empty blank character ---><---
Let me add that the developer does not show any font-related error/warning. The following snippet <link href="https://rawgit.com/adobe-fonts/adobe-blank/master/adobe-blank.css" rel="stylesheet"/> <span>---></span> <span style="font: 12pt AdobeBlank;">A</span> <span><---</span> which uses the AdobeBlank font (CMAP format 12) shows the expected "--><--" result so this probably has to do with the way format 13 is handled.
I can reproduce this on both Mac and Windows platform. Chrome got the *Expected results* mentioned in this bug. Actually I am not sure whether we should have plan to fix or even implement it. Maybe someone can answer it. AdobeBlank (https://github.com/adobe-fonts/adobe-blank) is using CMAP format 12 and works. AdobeBlank2 (https://github.com/adobe-fonts/adobe-blank-2) is a newer version of this font that is 10% smaller because it uses the range mechanism of CMAP format 13.
Yes, we should implement this. It's not a widely-used format, as it's designed for a rather special use case, but for fonts (like AdobeBlank) that can benefit from it, there are potentially big size savings. Fortunately, it's easy to support, as the structure is exactly like format 12; we just have to interpret the glyph ID field differently.
Created attachment 8818237 [details] [diff] [review] Add support for 'cmap' subtable format 13
Created attachment 8818264 [details] [diff] [review] Reftest for font using 'cmap' format 13 Here's a reftest to go with the patch, checking that Adobe Blank 2 loads successfully.
https://hg.mozilla.org/integration/mozilla-inbound/rev/59bdf1eb5d2d34e4acf52df73802e91f1351c3af Bug 1320665 - Add support for 'cmap' subtable format 13. r=jrmuizel https://hg.mozilla.org/integration/mozilla-inbound/rev/b2bac083c74e01ca19486e3e2466c6fcb0c4f423 Bug 1320665 - Reftest for font using 'cmap' format 13. r=jrmuizel
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/6dfee6a56324 for not looking very good on Windows, https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1481645881/mozilla-inbound_win7_vm_gfx_test-reftest-bm140-tests1-windows-build584.txt.gz&only_show_unexpected=1
Ah, drat. :( According to https://github.com/adobe-fonts/adobe-blank-2/issues/1, it looks like that format isn't supported at all by the Windows font system(s). So even though we could in principle handle the cmap, the font simply fails to load. I'll mark the test as expected to fail on Windows.
Hmm, now that more results are showing up on https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=b2bac083c74e01ca19486e3e2466c6fcb0c4f423, it looks like the test passes on Win8; it's only Win7 where it fails. So some kind of support for this subtable must have been added in the Win8 timeframe. Will annotate accordingly.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e92988d277ae11130bf5e6774bc0c1bbaf1521b4 Bug 1320665 - Add support for 'cmap' subtable format 13. r=jrmuizel https://hg.mozilla.org/integration/mozilla-inbound/rev/27a902904b474b0e1d2b613afd033ab01f5e47c4 Bug 1320665 - Reftest for font using 'cmap' format 13. r=jrmuizel