Closed Bug 643015 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Graphics, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: eric, Assigned: jfkthame)

Details

Attachments

(1 file)

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.
Summary: OpenType (OTF) fonts linked inside an SVG file don't render → Some OpenType (OTF) fonts linked inside an SVG file don't render
If you could provide a simple/minimal testcase that demonstrates the problem, that would be helpful - thanks.
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
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.
(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.
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.
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.
Assignee: nobody → jfkthame
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #520438 - Flags: review?(jdaggett)
Component: Layout: Text → Graphics
OS: Windows 7 → All
QA Contact: layout.fonts-and-text → thebes
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.
Attachment #520438 - Flags: review?(jdaggett) → review+
> Are you sure?

No, hence the "as far as I can tell". ;)
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?
(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.
http://hg.mozilla.org/mozilla-central/rev/8887ebd9a6c8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
Target Milestone: --- → mozilla2.2
Blocks: 643460
No longer blocks: 643460
You need to log in before you can comment on or make changes to this bug.