643015 - Some OpenType (OTF) fonts linked inside an SVG file don't render

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Eric Warnke]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Firefox 4.0 RC

When embedding an SVG file into a webpage the OFT font files specified using the @font-face attribute inside of the SVG file don't properly render. TTF fonts work.

Chrome has the same problem. Safari surprisingly renders OTF inside an SVG just fine.

I can specify an OpenType font using @font-face in the HTML of a website and the text will reflect it. However, in that exact same website and embedded SVG won't render the text, even if the font is specifically placed in the defs section of the SVG file that is embedded.

Reproducible: Always

Steps to Reproduce:
1. Create an SVG file with a linked OpenType font file in the CSS declarations
2. Embed that SVG file into a webpage
3. View the webpage, you will see default fonts


Expected Results:  
The SVG should display the text in the SVG with the font that it has linked to.

Some other bug fixes say that zooming fixes it. In this case, it does not.

Comment 1

[Jonathan Kew [:jfkthame]]

If you could provide a simple/minimal testcase that demonstrates the problem, that would be helpful - thanks.

Comment 2

[Eric Warnke]

Here's a test case. I'll try to keep it there as long as possible:
http://dev.campuscards.ca/test2.php?loadSVG=lib/cards/templates/mozilla_test_case.svg

Comment 3

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I see identical behavior on that page in Chrome, Firefox, and Safari on Mac.. at least as far as I can tell.

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to comment #3)
> For what it's worth, I see identical behavior on that page in Chrome, Firefox,
> and Safari on Mac.. at least as far as I can tell.

Are you sure? Try zooming in and look closely at the font used for "{name}" ... I'm seeing the downloaded font (MetaPro-Bold) used in Safari, but fallback in Firefox.

The reason is that the MetaPro-Bold.otf file is being rejected by the OTS font sanitizer. (Which means Chrome should be expected to behave the same, as per comment #0, as it also uses OTS.) Safari must not be applying such strict validation.

Unfortunately, OTS does not currently return any specific indication of the reason for rejecting a font, so diagnosing the cause of this requires tracing in a debugger, or using other font-validation tools. But it's almost certainly correct that there is some structural flaw in the .otf file, and therefore it is being rejected rather than expose platform font-rasterizers to potentially corrupt data.

Comment 5

[Jonathan Kew [:jfkthame]]

The specific issue in MetaPro-Bold is that the StringIndex of the CFF table includes a zero-length (empty) string, at index 674. The OTS index-checking code requires every item to have a positive length, and so it rejects this table:
http://mxr.mozilla.org/mozilla-central/source/gfx/ots/src/cff.cc#106

It's not clear to me from anything in the CFF specification that an empty string is in fact illegal, so this may be a case where the OTS validation is over-zealous.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: patch, allow zero-length entry in CFF indexes

This change allows the MetaPro-Bold.otf font in the testcase to be loaded; John, do you see any reason this shouldn't be permitted? I looked through the Adobe spec at http://www.adobe.com/content/dam/Adobe/en/devnet/font/pdfs/5176.CFF.pdf and didn't see anything suggesting that a zero-length string entry should be illegal.

Comment 7

[John Daggett (:jtd)]

Comment on attachment 520438 [details] [diff] [review]
patch, allow zero-length entry in CFF indexes

Yeah, I don't see any reason for requiring strings of non-zero length.  Having zero-length strings is kind of silly but I'm guessing this is just the byproduct of some font tool setting.  There's no real reason to toss out the font for this reason.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Are you sure?

No, hence the "as far as I can tell". ;)

Comment 9

[Jonathan Kew [:jfkthame]]

http://hg.mozilla.org/projects/cedar/rev/8887ebd9a6c8

Comment 10

[Masatoshi Kimura [:emk]]

This bug is wontfixed in the upstream.
https://code.google.com/p/chromium/issues/detail?id=69341
Should we convince them that zero length shouls be allow for some fonts such as MetaPro-Bold?

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to comment #10)
> This bug is wontfixed in the upstream.
> https://code.google.com/p/chromium/issues/detail?id=69341
> Should we convince them that zero length shouls be allow for some fonts such as
> MetaPro-Bold?

Yes, I think we should urge them to fix this, because it is affecting real fonts in use on the web.

I notice that comment #5 in the chromium bug report says that "I checked the spec(*) but it doesn't specify zero-length string is allowed"; however, it also doesn't specify that a zero-length string is _NOT_ allowed, so I see no reason to reject it.

Comment 12

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/8887ebd9a6c8