From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20020102 BuildID: 2002010204 SVG graphics may include definitions of custom typefaces in a special SVG font format. This allows for text to be as weird-looking as you want, while still allowing the user to select text and save it to the clipboard or whatever. It seems that when an SVG resource contains SVG fonts it fails to display at all (even the parts of the file that make no reference to the font elements). I get a blank white page. Obviously since SVG support is still a work in progress it isnt surprising that fancy fonts cant be displayed yet, but it would be better if custom fonts were simply ignored rather than causing the whole graphic to vanish. Reproducible: Always Steps to Reproduce: 1. visit http://www.w3.org/Graphics/SVG/Test/20011026/fonts-fontElement-BE-01.svg using Mozilla with SVG compiled in. 2. Observe it is very blank. 3. Visit it again with IE6 or NN4 with the Adobe plug-in. You should see the test text. You can even select the text. Actual Results: No graphics display. Expected Results: Ideally, fonts should be supported, so you see four lines of five large cartoony characters. As a reasonable fall-back, the cartoony font might be replaced by text in a fall-back font (such as Helvetica or Arial). Standardization note: The recent draft of the W3C's SVG Mobile profiles includes limited font support in both the SVG Tiny and SVG Basic profiles.

reporter.. how's this in the very latest?

We don't yet do svg text, let alone custom fonts. Expect to see some basic svg text support for Windows soon. Custom fonts are quite a way off.

Mass reassign of SVG bugs that aren't currently being worked on by Alex to general@svg.bugs. If you think someone should be assigned to your bug you can join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg ) where you can try to convince one of the SVG hackers to work on it. We aren't always there, so if you don't get a response straight away please try again later.

Is there any reason that we couldn't/shouldn't support SVG fonts in non-SVG contexts as well?

*** Bug 354558 has been marked as a duplicate of this bug. ***

A quick and dirty proof of concept implementation, enough to render simple examples, but with serious shortcomings: * no <missing-glyph> * DOM objects for font elements not SVG * invalidation uses wrong metrics * not implemented for <textPath> * DOM text APIs not updated for svg fonts * not effort to make it performant * ... Hopefully it can serve as a useful starting point for people interested in this feature, though.

Hixie: I don't know of any (In reply to comment #4) > Is there any reason that we couldn't/shouldn't support SVG fonts in non-SVG > contexts as well? I don't know of any reason why not from a spec perspective, and in fact I think it's a really good idea.

Extends tor's proof of concept for SVG fonts to handle missing-glyphs and metrics. The SVG font support is implemented by extending the nsSVGGlyphFrame::nsSVGAutoGlyphHelperContext object with an interface for indirect access to its internal gfxTextRun and using this to provide SVG font specific handling when required.

It's unfortunate that you couldn't implement roc's suggestion of a version of gfxFont for SVG fonts. The method used in my proof of concept is truly a hack, with many inefficiencies we wouldn't like to have in a final implementation. The parsing of the path data each time a glyph is used is probably the worst of this. You might want to implement a nsSVGGlyphElement and a nsSVGMissingGlyphElement and have them store the parsed path data (can be parsed lazily on the first time it's used). At some point we'll be wanting to add observers to do invalidation if the glyphs of an SVG font are modified, but that can probably be tackled in a follow-up bug.

marking wanted1.9.1? to get this in the triage queue. Also, set priority to P1.

I've been working on Inkscape and I would like to help to improve Firefox SVG implementation too. Last summer I started working on SVG Fonts support in Inkscape as a summer of code project. It is not complete yet but I already have some good rendering of glyphs made of paths I am using a new cairo feature called userfonts: You register with cairo some callbacks that are called when a glyph needs to be rendered, so, text gets handled naturally as any other cairo text call would do with system fonts My code is still incomplete and probably still non-conformant for some of the svg fonts attributes but it certainly can be helpful as an example of an svgfont initial implementation using cairo userfonts My current implementation in Inkscape is not rendering on canvas yet because for that we would need pango support for userfonts, which is 0% implemented right now. But users can already preview SVGFonts with arbitrary text in a preview widget which is a drawing area where I make cairo calls directly. The code is here: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/display/nr-svgfonts.cpp?view=log Felipe Sanches (a.k.a. "JucaBlues")

I wanted to mention that current betas of both Safari and Opera currently support SVG Glyphs in an html context: http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/SVGfonts_in_HTML.html It would be great if all three of the major alternative browsers (alt to MS IE) could support the same kind of webfonts in the next releases. That would really (finally) mean that we can have some kind of decent typography on the web. Unfortunately, embedding full .otf isn't going to be enough - SVG subsetting (and the required transformation/"embedding") makes this easier to sell to Typeface designers (though still not easy, they are a tough crowd). Also, there are a couple of SVG tests on the opera site that are not working (or are only partially working) in the current beta 3 of Firefox 3.1, but work completely in Opera 10 and Safari 4 betas: http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/#webfontssvg

Kevin, what use cases do SVG fonts address that (subsetted) TTF fonts cannot address until SVG fonts are implemented? I assume you're not dynamically creating the SVG fonts client-side. (If you do, may I respectfully suggest you're insane? :-) )

Work on this is scheduled for 1.9.2. Please limit discussions here to the implementation, broader discussions should take place in the newsgroups.

the attachment "SVG test..." displays identically in mozilla, opera and safari on os x

https://bugzilla.mozilla.org/show_bug.cgi?id=486832 a new bug has been filed for a remaining issue in the uri given in the description, the glyphs and svg font dont match

This is obviously NOT working. Please do not mark bugs assigned to others as resolved if you do not know what you are doing.

#19, what is obviously NOT working? the description for this bug states: "It seems that when an SVG resource contains SVG fonts it fails to display at all (even the parts of the file that make no reference to the font elements). I get a blank white page." this is not the current status for fonts

#19, what is obviously NOT working? the description for this bug states: "It seems that when an SVG resource contains SVG fonts it fails to display at all (even the parts of the file that make no reference to the font elements). I get a blank white page." this is not the current status for fonts. has this bug morphed? in which case what is it's correct description?

This bug is and has always been about implementing SVG fonts. At the time it was filed, SVG text was not supported at all; now SVG text is supported, but SVG fonts are still not implemented. Work to implement them is planned (see comment 15). You've now filled up nearly half the bug report with comments that do not help in fixing it. Please stop.

#24 the screengrab shows what appear to me at least to be SVG fonts in minefield nightly. on the left is: https://bugzilla.mozilla.org/attachment.cgi?id=275755 this appears identical to opera and safari the source appears to be svg fonts including glyphs on the right is: http://www.w3.org/Graphics/SVG/Test/20011026/fonts-fontElement-BE-01.svg clearly this is not right, but again the source is svg fonts including glyphs the description of this bug describes no font being displayed

(In reply to comment #25) > the description of this bug describes no font being displayed Please reread the second sentence of comment 23 and stop commenting in this bug. There are 67 people cc:ed to this bug because they're interested in the progress of SVG fonts being implemented. They're here because this bug has been, for years (see its summary, and the bug history), the bug about implementing SVG fonts. They're not interested in your arguments about whether this bug is the right bug (or your argument that a feature that we know we don't have code to implement might actually be implemented). Which bug represents the need for implementation of SVG fonts is a somewhat arbitrary decision, but it's been made by the people in charge, which you're not. And that decision is clearly reflected in the "Summary" field of the bug.

This bug was set to a P1 by comment 11, and then later made blocking; does it really block Firefox 3.6a1?

No, and given the accelerated schedule I'm skeptical that it can block at all, so changing + to ? for re-evaluation.

This bug is needed to pass at least the following tests from the W3C SVG 1.1 Full testsuite tests: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-align-08-b.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-altglyph-01-b.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-text-04-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-text-05-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-text-06-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-03-b.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-04-b.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-07-b.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-desc-02-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-01-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-02-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-05-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-elem-06-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-glyph-02-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-glyph-03-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-glyph-04-t.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-fonts-kern-01-t.html

Is this going to be blocking 1.9.3?

Not unless someone steps up to work on it. Most SVG folks are focused on getting SMIL animation out the door and basic text layout fixed up for 1.9.3. Note that we're shipping WOFF in 1.9.2 which will help with a lot of the use cases users wanted SVG fonts for (and perform much better than SVG fonts).

I thought John Daggett was working on it? What else does "Assigned to" mean?

It means it's on his list of things to do but I don't believe he's going get to it in that time frame.

I made these match the rest of the interfaces in dom/interfaces/svg.

It appears I forgot the fourth '-' in the uuids starting with 'baf0'. Sorry.

The current Target Milestone has passed quite long ago now. Should we put this on 1.9.3, 1.9.4 or just Future?

If this bug gets fixed, Firefox will pass Acid3 with a 100/100 result. Any chancs of Firefox 3.7 passing Acid3 completely?

The current status is that SVG fonts don't seem to be very important for the Web. Opentype fonts loaded via CSS @font-face are more useful than SVG fonts in almost every way. By far the biggest reason to support SVG fonts is to pass Acid3. I don't think it's a good idea to add an otherwise-unnecessary feature just to pass a test.

Maybe no one uses them because not enough browsers support it. If firefox adds support then a large set of browsers will support it. How can developers use something that almost no one supports? IE leads market share, but soon it will not (speculation based on reports of it shrinking). Obviously, other browsers pass. This means that soon Firefox may be the browser that is holding back web innovation. We aren't going to use features that the top 2 browsers don't support.

"no-one uses them" is not my point.

As a web developer myself, the impression that SVG fonts are not useful is one that saddens me. Opentype, Truetype and WOFF fonts all suffer from very different font rendering depending on platform and even browser. This means that when fidelity is essential, it's best to use an image for the text and use alt tags, even with @font-face. This is a hack and is backwards (particularly for accessibility). SVG fonts consistently implemented would give the opportunity for the browser to do precise vector based (rather than platform font rendering) font control that would make using an image for title text redundant. Windows is particularly aggressive at forcing fonts with truetype outlines into the pixel grid in a way which distorts them significantly. They all end up looking the same. As one of the early adopters of the @font-face rules for my sites I've become very aware of it's limitations with regular fonts.

You don't get complete cross-platform/cross-browser consistency with SVG fonts since SVG doesn't specify exactly how paths get rasterized. Also SVG fonts don't get hinting or subpixel AA, so to a large extent the increase in consistency comes at the expense of quality. It sounds like your complaints are mainly about the Windows GDI font rasterizer. You should try a Firefox trunk build with D2D/DirectWrite enabled; the DirectWrite rasterizer is much better.

(In reply to comment #38) > I don't think it's a good idea to add an otherwise-unnecessary feature > just to pass a test. I agree with this, but sadly this test does get a lot of attention in media. IE 9 seems to aggressively improve the results on the Acid 3 test with each preview release and they might aim for full score for the latest version. This would mean that Firefox would be the only browser out there not passing this test.

I agree with comment #43. Passing the Acid 3 test would be good publicity for Mozilla, and IE is improving very, very fast. In addition to this, full SVG compliance is one of Mozilla's goals. http://www.mozilla.org/projects/svg/ "The goal we're working towards with Mozilla's SVG implementation is SVG 1.1 Full." "Big areas of the SVG specification where we're still lacking include filters, svg defined fonts, and declarative animations." WOFF is an open standard, so is SVG. If Mozilla doesn't support it, the fox cries. http://www.imagebam.com/image/fbfe4179927999

"Opentype fonts loaded via CSS @font-face are more useful than SVG fonts in almost every way" Like for example? The only reason why OTF is better than SVG fonts is manual hinting instructions. Otherwise, OTF is just huge, impenetrable binary blog which has nothing to do with the ease how one can read/write and explore HTML, CSS, JS, ... Good luck parsing "cmap, format 4" table. Also, you seem to forget that sometimes there's need for a custom typeface just for headlines (i.e. a few large glyphs) where SVG fonts would be just the perfect solution. Every major browser would be able to support SVG fonts, except for Firefox. Sadface.

I don't have a clue about whether or not SVG fonts are important or "better" (or not) than Opentype, Truetype or WOFF. But as much as I dislike Acid tests, I'm pretty sure that passing them is a must in terms of brand image. Thus I think that, sadly, passing Acid 3 is by itself a good enough reason to implement the feature.

(In reply to comment #45) > Like for example? Hinting, rasterization with subpixel antialiasing, far richer support for glyph selection and text shaping, vast libraries of available fonts, more compact, ubiquitous support in apps, ubiquitous support in font creation tools. The advantages of SVG fonts are: you can create them with nothing but a text editor, multicolor glyphs, and animated glyphs. But no browser supports the latter two features, as it turns out, perhaps because the spec for glyphs containing arbitrary SVG is insane. That leaves the text editor advantage, but honestly I haven't heard that font designers are eager to throw away their font design tools. If you really must create fonts with a text editor, try TTX: http://www.letterror.com/code/ttx/index.html

(In reply to comment #47) > > Hinting Yep, this one I agree with, see above. > rasterization with subpixel antialiasing Has nothing to do with font format. > far richer support for glyph selection Not true, as in both cases a user could type in just Unicode characters. > and text shaping, Not sure what exactly you mean but I have yet to see a font which defines custom word boundaries. > vast libraries of available fonts You know as good as I do that this not how progress is made. (.gif vs. .png) Why should anyone support SVG font if the second most popular browser refuses to support it? SVG is more recent format. Mozilla could be the first type foundry providing really open (as in human-readable and as in "OFL") fonts. > more compact, Now this is interesting. I expected you to be right but I measured some font anyway. In OTF it has 208 kB, in SVG it has 550 kB, and in SVG.gz it has 88 kB. I guess the conversion from OTF to SVG dropped many tables but I expected SVG to be only a few times larger than OTF, not smaller. In any case, whether it is 88 kB or 208 kB, who cares? (Might I kindly remind you of your own recent blog post about OGG) > ubiquitous support in apps It depends on what do you measure. WOFF in MS Office? Or the number of people accessing web? > ubiquitous support in font creation tools. Unfortunately, I have to agree with you on this one. Unfortunately, because that's why we are stuck with such a mess as OTF and WOFF formats that there are only few people how managed to write apps which fully support their specs. OTOH - if you count SVG as XML - how many creation tools are out there? > The advantages of SVG fonts are: you can create them with nothing but a text > editor, multicolor glyphs, and animated glyphs. But no browser supports the > latter two features, as it turns out, perhaps because the spec for glyphs > containing arbitrary SVG is insane. That leaves the text editor advantage, but > honestly I haven't heard that font designers are eager to throw away their font > design tools. Multicolor or animated glyph - between you and me - it's good no one supports it :) (Just remember Geocities). Glyphs containing arbitrary SVG is insane, I agree. (Plain path would be just enough). But as I tried to say above, I my eyes, the success of web is in large part because of its ability to be read/written in plain text editor. (Think: "Show Source Code") > If you really must create fonts with a text editor, try TTX: > http://www.letterror.com/code/ttx/index.html Is Firefox going to bundle it?

(In reply to comment #48) > > far richer support for glyph selection > Not true, as in both cases a user could type in just Unicode characters. > > > and text shaping, > Not sure what exactly you mean but I have yet to see a font which defines > custom word boundaries. Text shaping is the process of converting Unicode character into positioned glyphs. SVG fonts do not support complex text rendering which is an absolute requirement for supporting scripts like Arabic and Indic. SVG fonts are just a toy in that regard. You can't do serious work with them.

You are telling that SVG Font standard is not good enough to be implemented, phew! Maybe, but you are acting just like the way microsoft done for IE6,7,8. Since SVG Fonts is a standard and because most major browsers support it, it should be implemented. Let people choose what to use for their needs. I agree with comment 45, let's not be the last one that implements the standard.

(In reply to comment #50) > but you are acting just like the way microsoft done for IE6,7,8. I hate to say that, but I agree. I feel that the more the firefox's market share grow, the more firefox is behind when implementing standards.

No one is stopping you guys from going ahead and implementing it and submitting the patch for review. It may even get committed... What I's saying is that it's very low-priority in my list. The same may apply to other developers.

Implementation notes for those interested in working on a patch. Robert O'Callahan wrote: > I guess we'll need a new kind of gfxUserFontSet::OnLoadComplete that > instead of taking binary font data, takes a new kind of object with > callbacks to do shaping, measuring and drawing. On the gfx side, we > use those calls instead of constructing a font directly. On the > layout side, when loading an SVG font instead of creating an > nsFontFaceLoader, we create another kind of loader that contains an > nsReferencedElement to give us a reference to the DOM of the font > (which supports external resource documents). This new loader would > implement the shaping, drawing and measuring callbacks needed by > gfx, by interpreting the DOM. (Instead of direct drawing callbacks, > a nicer approach would be to construct a cairo user font.) > > If the font DOM changes (which we can detect using mutation > listeners) or the referenced element changes (which is reported by > nsReferencedElement), we need to bump the fontset generation and > call nsPresContext::UserFontSetUpdated. I think you should be able to leverage the work that Jonathan Kew has done to break out shaping and font handling. Rather than OnLoadComplete, I would suggest creating a method like MakePlatformFont called MakeSVGFont which returned a subclass of gfxFontEntry (gfx/thebes). Define an interface for this in gfxUserFontSet and override it within nsUserFontSet in nsFontFaceLoader.cpp (layout/style). Then subclass gfxSVGFontEntry, gfxSVGFont and gfxSVGShaper objects that inherit from gfxFontEntry, gfxFont and gfxFontShaper, that will allow you to leverage all the font and style matching code within gfxFont (we *really* don't want multiple copies of that code). The draw method on gfxSVGFont would either draw via SVG code directly or via a cairo user font. One of the sucky things about SVG Fonts is that they sort of live in two worlds, the element/attribute world of SVG and in the CSS @font-face rules that apply to general content, and these two worlds are slightly out of sync. So some of this work will also involve spec'ing out the exact *subset* of the SVG Tiny 1.2 feature set that needs to be implemented. That spec defines the 'font-face' element based on the CSS 2.0 definition of @font-face, so there's lots of spec poop floating around (e.g. 'panose', 'stemv', 'stemh', 'ascent', etc.). For these we probably just need to figure out what Opera/Webkit have implemented and come up with something reasonable. Jonathan Kew or I can answer questions related to gfx code, Daniel Holbert or Jonathan Watt about SVG code and roc can answer anything. ;) Also, Jeff Muizelaar knows about the cairo user font code. > Tricky bit: how do we know whether to use the normal streamloader > path or nsReferencedElement? Can we just assume that a URI with a > fragment reference must be an SVG font, and a URI without a fragment > reference needs normal loading? I hope so. Er, that sounds like a terrible plan, there's no reason a webfont service couldn't reasonably use URL's with fragment id's in them. I think you need to either use the mime type or sniff for something that looks like SVG, whatever we do with normal SVG content. What the loading rules for SVG images referenced within img tags?

Well, the fragment ID does not go to the server, so unless we decide to do something special with fragment IDs for TTF/OTF/WOFF on our side, the fragment is always going to be ignored for those types. I guess it's true that src:url(foo.ttf#xyz) should load foo.ttf and render it correctly, although it's bit perverse for authors to write that... > I think you need to either use the mime type or sniff for something that > looks like SVG, whatever we do with normal SVG content. What the > loading rules for SVG images referenced within img tags? The problem is that to make SVG fonts work you want to be using the external resource loader mechanism via nsReferencedElement. (That handles stuff like references to nodes in the current document, DOM changes that change which element is the first element with a given ID, etc.) But if you start off all your loads using that API, it's hard to get binary data out ... new interfaces would be required. Also, external resource documents have different security, e.g. they don't support CORS yet. So we'd have to start by aligning the security checks performed by the external resource loader and the font loader...

I see no issues with aligning said security checks, other than doing the work. It should also be not that hard to expose a way to wrap an existing channel into an external resource, I think.

@roc: You will never be able to understand the need for SVG fonts as long as you cling to your only web centric view of things. True, SVG was developed for the web and its distributed ressources, but SVG is actually more than this. It is, not in a small degree, also a document format. And as a document format it severely needs the ability to embed fonts. Ask any designer / graphic artist you know. If they can't embed fonts into some document they most likely won't use it as a format for working (for moving a single file between several machines). And so your reluctance towards SVG-fonts could tip the scales whether SVG as a file format gets some relevance or degenerates into insignificance

Please feel free to cc me here again if there's actual work happening, not random advocacy.

The way to proceed here is probably to start by detecting fragment-only URIs and use nsReferencedElement to get the element in the current document, and get all the SVG font support working for that case. Then (or in parallel) work on making all font loading go through nsReferencedElement and the external resource system.

Any news for this bug? This bug blocked acid3 bug and also blocked firefox 4 release.

(In reply to comment #60) > Any news for this bug? This bug blocked acid3 bug and also blocked firefox 4 > release. It does not block the Firefox 4 release, something you can have seen just by visiting the bug. Please read the following before mass-posting any more comments: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Hi, OK, I have read the etiquette, I should not do that, maybe I'm just wasting your time and maybe this comment will be removed, but let me explain why I think SVG fonts are IMPORTANT for Firefox and for the web, and why it kill kittens to postpone implementation. If I had enough skill to do it, I suppose I already submitted a patch, but I'm not, so here I am, arguing. I'm a graphic and web designer, working with FOSS softwares, including Inkscape. I learned more on how to use SVG with the "Introduction to SVG" W3C Tech Course recently (I've started to play with SMIL, and so on). I come from a proprietary world were Flash is the easy and direct solution to produce funny interactive medias in a few hours. Trying to produce half of the same visual result with open standards is a pain for peoples who never learned to code (yes, I try to, as much as I can, and I do not use Flash anymore). Canvas, SVG, CSS, HTML5, WebGL are good steps for more interactivity and fun on the web. But if actors as decisive as Mozilla do not implement them fully, there is no hope on the horizon. Not to mention any authoring tool. It's not about Acid3, even if it may be good for marketing purposes. It's not about Opera, Chrome and Safari who have a minimal implementation of SVG Fonts. It's not because they have one, it's because they have a poor one. It's not about Opentype or @fontface which is better in some ways, and poorer in others. It's another technology, for different purposes, in different contexts. Yes it do part of the same thing, but you can't know in advance how peoples will use it. By not implementing SVG Fonts in a mainstream project like Firefox, tons of smaller projects suffers : An example ? Sozi : http://sozi.baierouge.fr/ and Inkscape : http://inkscape.org/ Another ? The own Mozilla "Game On" : https://gaming.mozillalabs.com/ Yes, we can vectorize fonts, but you know it means killing semantic. It's about hack-ability, openness, standards, and fun on the web. It's more than really important. Please don't postpone by X numbers of releases open interactive medias on the web... Please reconsider priority on this bug.

(In reply to comment #63) > By not implementing SVG Fonts in a mainstream project like Firefox, tons of > smaller projects suffers : An example ? Sozi : http://sozi.baierouge.fr/ and > Inkscape : http://inkscape.org/ > Another ? The own Mozilla "Game On" : https://gaming.mozillalabs.com/ And Typism: http://typism.appspot.com/ (And totally agree!)

Ok, no answers so far, so let's put it crystal clear for the last time : 1) Typography is to design what the ball is to Tenis game. 2) The only serious candidate we have for interactive, animatable, colorful, warpable, paterned, put-on-a-line, morphed open typography on the web is SVG fonts. Conclusion) There is no interactive, animatable, colorful, warpable, ... open web-designs without SVG Fonts.

Trying once again to remove myself from comments on this bug, so that people who wish to evangelise won't bother me with spam anymore.

OK why can I NOT remove myself form CC on this lame bug????

When you posted comment 66 you had "Add me to CC list" checked.

Take a look at this table: "When can I use SVG fonts?" http://caniuse.com/svg-fonts Enter Mozilla, the new Microsoft. Enter Firefox, the new Internet Explorer. It's a bit difficult for web developers to start using a feature that is not implemented by 2 major browsers, which, combined, make more than 75% of the market share. And, of course, the developers of the browsers in question won't implement the feature because web developers aren't using it. Repeat ad infinitum.

(In reply to comment #69) > market share. And, of course, the developers of the browsers in question won't > implement the feature because web developers aren't using it. Repeat ad No, that's not why we're not implementing it. We're not implementing it because we already implement a *better* feature, downloadable fonts, and we don't need to add extra complexity to the Web platform by implementing an inferior feature on top of that. For more information on our support, see: https://developer.mozilla.org/en/CSS/@font-face https://developer.mozilla.org/en/About_WOFF (Yes, there are features, such as color and other SVG features inside individual glyphs, that SVG fonts provide that downloadable fonts don't... but those features aren't implemented by most of the browsers that do "support" SVG fonts. They're also complex to implement, and not particularly useful except in cases where alternative text would be a much better solution anyway.)

First of all, I think that all the (harsh?) criticism in some of the comments stems from our love for Firefox and our wish that Mozilla sticks to its target of supporting open web standards. Sometimes, the ones who love you the most will hurt you the most. *grabs virtual whip* (In reply to comment #70) > No, that's not why we're not implementing it. No, of course it's not. The reason Mozilla won't implement SVG fonts is simply because it doesn't want to. From that point on, all the rest is rationalization of that decision. > We're not implementing it because we already implement a *better* feature, Better? That's just, like, your opinion, man. WOFF is different. Not the same as SVG. Read comment 63, for instance. > (Yes, there are features, such as color and other SVG features inside > individual glyphs, that SVG fonts provide that downloadable fonts don't... but Exactly. WOFF cannot substitute all the features of SVG fonts. > those features aren't implemented by most of the browsers that do "support" SVG > fonts. LOL. Don't you see? Again with the "other browsers don't implement it either and/or they implement it poorly" mantra. Other browsers do a poor job at implementing this feature, so we won't implement it at all. > They're also complex to implement, and not particularly useful except > in cases where alternative text would be a much better solution anyway.) OK, I give you that it is indeed difficult to implement all the features of SVG fonts in one go. Now, why not add the basic support other browsers have so that there is at least a common ground in 4 out of 5 of the major desktop browsers? That's another argument Mozilla keeps repeating: It's all or nothing. But, oh, wait! Mozilla wasn't always all-or-nothing regarding SVG: http://www.mozilla.org/projects/svg/#status "*The goal we're working towards with Mozilla's SVG implementation is SVG 1.1 Full*. What exists now in the tree should be treated as a technology preview. As we implement more of the specification, content written against Mozilla's SVG implementation might break if it unintentionally relies on bugs that are fixed. *We realize this is not ideal, but ask you be patient as we continue implementing an extremely large specification* that lacks a comprehensive test suite. Our goal is specification conformance. Where the specification and other implementations of SVG differ, we will conform to the specification. Where the specification is ambiguous, we will make an informed decision, consulting the SVG working group and other experts as appropriate. *While we are still a long way away from full SVG support, the subset currently implemented is already pretty usable*. We have support for all basic shapes including beziers, stroking and filling with opacity, gradients, scripting, events, and much of the DOM. Big areas of the SVG specification where we're still lacking include filters, *svg defined fonts*, and declarative animations. " *leaves virtual whip*

Mozilla people have their own tasks to work on. If you guys need SVG Fonts so badly code it or hire someone to do that for you. Mozilla is Open Source - patches are welcome. PS: Sorry for bug spam but this kind of comments are getting annoying.

Sorry to add to "spam"... but I agree with Carlos Alén Silva. If we ask so much for SVG Fonts, it's mainly because we love Mozilla and Firefox. Honestly, I'm ready to launch a fund-raising campaign online if needed. Question is : who to hire, and at what cost ? Do Mozilla Foundation accept donation for such campaigns ? If people here can answer that, I volunteer gladly to organize such a campaign.

(In reply to comment #72) > Mozilla people have their own tasks to work on. Well, I think those tasks should include fixing a *9-year-old bug* affecting an open standard that Mozilla explicitly vouched to fully support. >If you guys need SVG Fonts so > badly code it or hire someone to do that for you. Mozilla is Open Source - > patches are welcome. Well, everybody here knows that Mozilla is open source. Look who's talking about annoying comments... Also, removing yourself from the Cc list will help you dealing with spam ;) (In reply to comment #73) "You have my sword!" And perhaps we should move the conversation somewhere else to avoid spamming. Google groups? Facebook? ... I'm all ears.

(In reply to comment #74) > (In reply to comment #72) > > Mozilla people have their own tasks to work on. > Well, I think those tasks should include fixing a *9-year-old bug* affecting an > open standard that Mozilla explicitly vouched to fully support. That a bug is old doesn't mean it is important to fix. If anything, it means the opposite. If the benefits outweighed the costs sufficiently the bug likely would have been fixed already. Also, please stop advocating for SVG fonts in this bug. The place to do that is in the newsgroups. This bug is supposed to be a place to make technical progress on implementing SVG fonts. (Also, the mozilla.org/projects/svg page has likely not been updated in years.)

Hi Kyle, to end with this, can you tell us on which newsgroup we should launch this conversation, and obtain answer to my questions ? the list is huge : http://www.mozilla.org/about/forums/ mozilla.evangelism ? mozilla.wishlist ? mozilla.community.web-standards ? mozilla.dev.tech.svg ? mozilla.dev.apps.firefox ? Most of them look to receive a lot of spam... Thanks in advance @Carlos : Sorry, I'm no Facebook or Google groups user... if a newsgroup is suited for that, we maybe should stick to Mozilla tools.

I would suggest that you start on dev.tech.svg, the relevant folks are likely to read that group.

Thanks for you answer Kyle, to others interested : so discussion will going on there...

(In reply to comment #77) > I would suggest that you start on dev.tech.svg, the relevant folks are likely > to read that group. Are you really serious about this? This "newsgroup" is drowning in pr0n-Spam as you could easily see here: http://groups.google.com/group/mozilla.dev.tech.svg But if you really wanted to *stop* this discussion this was probably the right idea. To say something substancial in my post so it's not completely wasted: I consider the SVG font support pivotal for SVG when using SVG as a file format / stand alone / portable / editable file and *not just as webcontent*. Consider some graphic artists collaborating on some artwork and exchanging SVG files in that process. It seems naturally that those graphic artists would like to embed fonts into their documents (as you can do with PDF for instance) and not fiddle around with several separate fonts which would need to be installed manually on their machines. Life isn't all World Wide Web and servers. FireFox would make a great SVG viewer (remember file:/// URLs?) but without SVG font support not so much.

Adding more noise to this discussion, there's an interesting use case for SVG fonts. Instead of <img ... alt="check"> one can use <span class="icons">+</span> character and this to automagically turn into nice color icon. See http://www.red-team-design.com/feature-table-design-with-css3 to imagine it better.

Noise once again, a must-read article on SVG fonts : http://jeremie.patonnier.net/post/2011/02/07/Why-are-SVG-Fonts-so-different I started the Fund raising discution on mozilla.dev.tech.svg, but no one from Mozilla answered so far. Can anyone wanting to stop "spam" on this bug tell me how to open dialog with Mozilla on this subject ? Maybe we should wait after the Firefox 4 release to reach relevent people ?

For those looking to make progress here, I suggest you help construct a body of evidence surrounding SVG fonts. Here are some things worth including: 1) A technical comparison of WOFF vs. SVG formats - Ideally this would include things like typical size of a font and features that are supported by one format and not the other. 2) A comparison of the tools available for creating SVG vs WOFF fonts 3) An estimation of the added code complexity required for implementing SVG fonts 4) An estimation of the additional security risk of implementing SVG fonts 5) A suggested subset of SVG to be supported in fonts. 5) A list of use-cases for SVG fonts that are not well supported by existing technologies. I would suggest using this wiki page to organize the information: https://wiki.mozilla.org/SVGFonts. Please keep the information as objective as possible. Without a convincing technical argument for SVG fonts, I fail to see how any progress can be made here.

(In reply to comment #82) > For those looking to make progress here, I suggest you help construct > a body of evidence surrounding SVG fonts... The six items in your list would take considerable effort, skills, time, access, and expense to compile. Is the work you suggest be performed a requirement of any formal or informal Mozilla process/es? If so, could you please describe the process/es in detail? Who would evaluate the "body of evidence"? How would they evaluate it? What possible outcomes could occur from this process and what would be the basis for each outcome? How long would the process take? When would the process occur?

(In reply to comment #83) > The six items in your list would take considerable effort, skills, time, > access, and expense to compile. Absolutly that's why a wiki is suggested. That way, anyone can contribute with its own skill and time. > > Is the work you suggest be performed a requirement of any formal or informal > Mozilla process/es? If so, could you please describe the process/es in detail? For what I know there is no formal nor informal process here (but I let Mozilla guys confirm or infirm it), it's just a way to rationalized the discussion and to give some input to explain objectively why it's relevant to push SVG Fonts up in the Mozilla todo list. > Who would evaluate the "body of evidence"? > > How would they evaluate it? No one and everybody, it's an open discussion right at the moment. For now, the Mozilla team has made its choice. It's now up to us, web designers, to stop complaining and start acting to convince them. > What possible outcomes could occur from this process and what would be the > basis for each outcome? Maybe a beginning of implementation of SVG font. Maybe the first step would be to start with the subset defined by SVG 1.2 Tiny. All depend on the use cases people could defined about SVG fonts. > How long would the process take? Maybe a very long time, who knows? But are we really in a rush here? If you are in a hurry maybe you should consider other solutions (the raising fund idea from Camille is pretty good). > When would the process occur? Whenever you take some times to push it live ;) This wiki page is a good start to retrieve facts about SVG fonts. Now, anyone can be part of that quest for SVG fonts, starting now :) Firefox is an open source project and you do not need any permission to start something with it. The only thing you have to ask it's when you want to push some code inside it and in that case there is a formal process (but if you don't want to ask permission for that, just fork it). For everything else, it's up to YOU.

(In reply to comment #83) > (In reply to comment #82) > > For those looking to make progress here, I suggest you help construct > > a body of evidence surrounding SVG fonts... > > The six items in your list would take considerable effort, skills, time, > access, and expense to compile. It's true. However, people on this bug are suggesting that the existing skills, effort and time spent on this issue has come to the wrong conclusion. > Is the work you suggest be performed a requirement of any formal or informal > Mozilla process/es? If so, could you please describe the process/es in detail? This work is not a usual requirement, however, the barrier is necessarily raised because the decision being made is contentious. > Who would evaluate the "body of evidence"? Anyone who would be involved in the writing/reviewing the code for adding support for SVG fonts. > How would they evaluate it? The same way they evaluate other technical decisions? > What possible outcomes could occur from this process and what would be the > basis for each outcome? 1. The new evidence would outweigh the existing evidence on SVG fonts. Implementing SVG fonts would now be more attractive. 2. The new evidence would confirm the existing evidence. > How long would the process take? This depends on those involved. > When would the process occur? It could start now.

Ok, I've put all I know about SVG Fonts on the wiki, trying to be objective. A first version is available now : https://wiki.mozilla.org/SVGFonts. Please read, comment, complete and contribute ! PS : By the way I even learned something : the same font in a WOFF format (23,6 Kio), is smaller size than a SVG Font (52,5 Kio), but much more larger than the same font in SVGZ file format (579 octets !).

I simply don't believe those size numbers. You're saying you managed to get 100X (lossless) compression from gzip. That is totally unrealistic. I uploaded the DejaVu Sans Book Regular font from http://www.fontsquirrel.com/fonts/DejaVu-Sans (DejaVuSans.ttf, 622020 bytes) to the Generator with the default options, except I enabled SVGZ format. In the resulting package, dejavusans-webfont.ttf was 538612 bytes, dejavusans-webfont.svg was 1485741 bytes, dejavusans-webfont.svgz was 317012 bytes, and dejavusans-webfont.woff was 287516 bytes. I also verified that running gzip on the dejavusans-webfont.svg file gave me 317012 bytes. I went through your wiki page and made a few changes and annotations where it was incorrect. Maybe you tried to be objective, but you described our support for SVG filters on HTML content as a "hack" (despite the fact that the feature is in the latest SVG filters draft), and many of your "use-cases for SVG fonts" work perfectly fine with WOFF. Also, listing use-cases that you know can be addressed by WOFF doesn't help your argument. I added a section on "internationalization issues", which we discussed at last week's SVG WG F2F. The key point there is that SVG fonts have very weak shaping support, so all the use-cases that SVG fonts claim to solve are NOT solved by SVG fonts for many of the world's languages. This is a critical problem which means SVG fonts are not likely to be the long-term solution for those use-cases.

Source file is the TTF font. Then we convert them with the fontsquirrel generator http://www.fontsquirrel.com/fontface/generator, in expert mode with only a "western languages" subset to obtain a .woff file, a.svg file, and a .svgz file. Then we open the SVG file with Inkscape, and save as "simple svgz file". Results : WOFF : 23,0 kio SVG: 54,7 kio SVGZ with Fontsquirrel : 13,5 kio SVGZ with Inkscape : 578 octets

Hi Robert, thanks for your work. Thanks Jeff too. You may judge by yourself with this attached package, and reproduce my method. Maybe there is a bug with Inkscape, but I'm honest here, you can check maths. But font size aren't determinant here, 54,7 kio is well enough for today web, even if it is 2x the size of WOFF. For the wiki, I do not pretend to know everything there is to know on the subject... As I said, it was a first draft, I ask for reviews, and I will try to improve that. I tried to be objective, but I'm no god : subjectivity is never out. As an example, let's take the "web-based typing game" use case : you are right : you can achieve such a project with WOFF, with lot of triggers. But it's much more simpler an clean to achieve it with SVG fonts thanks to DOM access. Sorry for the "Hack" on WOFF-SVG filters, but it sounds to me that it started like a hack, and it's a compliment. For the internationalization issues, I admit there are. But as I answered you on the mailing list, that a problem, but in my point of view, that's not a key argument or a blocker in a graphical oriented context. I will try to complete that on the wiki.

(In reply to comment #88) If you extract that .svgz and open it with a text editor, you’ll find that it’s essentially empty. Don’t know what exactly went wrong there. A lot can be achieved by varying compression levels. I’ve more than halved the size of already-compressed PNGs losslessly with pngout, and hand-tweaked .svgz compression with 7-Zip before. But a whole font in 578 bytes is a bit much. :P

Ok, sorry for my mistake (578 bytes amazed me as much as you, and I didn't tried to use the file). At least, I suppose we can assume now that we can easily obtain similar compression levels with SVGZ than with WOFF....

I'm following this discussion long enough to say this: you Mozilla guys seem not to understand this at all. Because this is not a search for "better" font format. To says that SVG fonts have weak support for international shaping(*) is like saying you don't want to support GIF because it cannot contain more than 256 colors. But what if someone does not care about more colors and needs a text-based font format(**) and DOM access? There is a valid standard which covers this and you simply refuse it to support for than 9 years. For some cases WOFF is more suitable, for some other cases SVG is. WOFF is NOT better than SVG, it merely serves a different need. (*) I don't get this argument - are you saying that that's the reason why SVG is not worth of support? (**) Like HTML, CSS or JavaScript. WOFF is just a binary blob. PS: What the different file sizes goes - it might be the case that you conversion tool dropped a few of font tables. On the other hand, it's quite common that TrueType fonts have a few tables repeated (because of different table versions or encodings or ...), while SVG contain only one "table".

Simply put, SVG fonts allow full-blown SVG images (incl. animations) for glyphs, while WOFF is for fast text rendering and complex script handling. Combining characters (e.g. diacritics) can be emulated in SVG fonts with references to <defs>. SVG fonts are not essential for web design typography while WOFF is.

(In reply to comment #92) > I'm following this discussion long enough to say this: you Mozilla guys seem > not to understand this at all. Well It's not that simple. There are very smart people working at and for Mozilla and the fact is that they are really aware that implementing SVG fonts require a lot of time, skills and resources that are better used to improve some other part of Firefox (performance for instance ;). So it's perfectly understandable that Mozilla guys expect for strong use cases to put SVG font implementation on top of the list. IMO if Mozilla have to choose where to put their effort, I'll prefer see them working on bugs #265894 and #265895 which are far more problematic than SVG fonts > For some > cases WOFF is more suitable, for some other cases SVG is. > > WOFF is NOT better than SVG, it merely serves a different need. I strongly agree with you on that point but what Mozilla needs now is use cases where SVG font are OBVIOUSLY a better choice than WOFF. So if you have use cases where you MUST turn your font glyph into a path to achieve want you want to do, it is a damned relevant use case. If any of you have such use case please, share it :) On other use case pointed out in one of the last comment is the file size. At some point, when you have to deal with low bandwidth connexion (maybe a use case for Fennec), it's interesting to be able to serve a smaller font than a WOFF (which is already small, but it seems that SVGZ can be smaller). Of course this has a cost in term of quality of the font rendering (remember, there is no hinting in SVG fonts). For example, in that case, the CSS property (defined in SVG) text-rendering could be used as a switch : by setting its value to "optimizeLegibility" then Firefox could use the WOFF font and by setting its value to "optimizeSpeed" then Firefox could use the SVG Font (here I assume a lot that SVG font would be faster but hey, that depend on the implementation ;) and by setting "geometricPrecision" force the use of the SVG font even if a WOFF font is available. What is important here is that Mozilla should not be blamed but helped. Even web designers, at their own level, can help. Just provide relevant use case, just said "Hey I want to do this, but I can without SVG font nor WOFF font and SVG font would be the best choice to achieve it."

(In reply to comment #92) > For some cases WOFF is more suitable, for some other cases SVG is. Those are not our only two choices. Let's assume there are good use-cases that require browser support for constructing a font represented by DOM nodes. Why should we have to choose between a font format that supports complex shaping but not DOM access (WOFF) and a format that supports DOM access but not complex shaping (SVG Fonts)? We shouldn't, because clearly DOM access will be just as needed by people who use languages with complex shaping. We need a format that will support both. Complex shaping support is hard. Please read http://www.microsoft.com/typography/otspec/ especially http://www.microsoft.com/typography/otfntdev/indicot/default.htm We do not want to have two implementations of something like that in the browser, not if we can help it. In fact, I don't even want to have two separate specs for how stuff like that works. (BTW, if we're going to spend our time engaging with you on this, please in turn do us the courtesy of spending your own time studying font formats and text shaping.) Even if it made sense for SVG Fonts to have its own shaping spec and engine, I don't know of anyone anywhere who has said they're willing to work on that. Personally I think we need to figure out how to integrate OpenType text processing with SVG glyph rendering. The result may look like SVG Fonts, but it may not, and I don't want to implement SVG Fonts and then discover that it's not the long-term solution.

Ok, Think you are a lazy graphic designer, not so far aways in the foreseeable future. A client ask you for a logo. But a fancy-up-to-date one, animated. Let's say the logo is for a company named "Something™". You will work on it three days, producing ten logo a day. Vector graphic is the obvious choice for a logo (resolution independent, etc.). All you need is 8 glyphs (9 with trademark character), that you can easily declare in the SVG <defs>. You can animate them individually and independently with SMIL if you choose SVG Fonts. The stupid client don't know what is a SVG file, a WOFF file, a javascript script, an HTML page, but when you deliver him a SVG file that open and play nice in any web-browser, he is happy, job is done. You better not even try to make him link a WOFF file to your SVG. To achieve such a demand now, you have to convert glyphs to path, or use Flash. Not really dramatic to kill semantic on a logo. But now, let's the client ask for a baseline, a slogan. Then a text-based publicity, and want that to get on top of Google search results. You don't know where on the damn web he will put your file, and want he will do with it. another example ? - an SVG animation added to Wikipedia as an illustrative example of some kind. - a SVG file joined in an email - Sozi usage to make SVG presentations - a single-file game... I think all this is about workflow. Designers have their workflow, and expect to obtain a ready-to-send file out of their authoring tool, without entering the code to prepare a ready-to-break-link to a WOFF file. Coders do not have this use case. @Rob for last comment : we all know this is a risky, up to evolve, complex, not yet finished technology. We want you to take the risk, and you don't want to, and you will have the final word on this. But why not accept a fund-raised development as a technology preview, to start with ? Internationalization issue do not have to be solved now, let's add this to the to-do list. WOFF is not perfect either for complex shaping, and new special characters are added to fonts everyday.

Another use case: say there is a font which has many glyphs. But for my charting web site I only need the numbers. I could open the font in a text editor and simply copy-paste the wanted glyphs to a new font. Also, I don't believe we need a 3rd font spec right now. I think, all we are asking for is basic SVG font support(, WebKit level is useful-enough-for-me). Complex shaping is overrated: we are having discussion right now without any shaping whatsoever.

(In reply to comment #96) > To achieve such a demand now, you have to convert glyphs to path, or use > Flash. Not really dramatic to kill semantic on a logo. Or just use an SVG image in an <img> with alt text. If you don't like to reference an external file you can use SVG <use>, or make any image inline using data: URLs, although very few people ship raster images inline that way so I believe referencing images in external files is not a major problem for Web developers. > But why not accept a fund-raised development as a technology preview, to start > with ? Because I care about finding the right solution for the Web. > Internationalization issue do not have to be solved now, let's add this to the > to-do list. Designing something and adding on "internationalization" later tends to produce bad results. > WOFF is not perfect either for complex shaping, and new special > characters are added to fonts everyday. There's nothing better than OpenType for complex shaping, except maybe SIL's Graphite, but most of the investment is going into OpenType especially on the font side.

(In reply to comment #97) > Another use case: say there is a font which has many glyphs. But for my > charting web site I only need the numbers. I could open the font in a text > editor and simply copy-paste the wanted glyphs to a new font. There are plenty of tools for subsetting OpenType fonts, and they're easy to use. http://www.fontsquirrel.com/fontface/generator can do it. > I think, all we are asking for is basic SVG font support(, WebKit level is > useful-enough-for-me). No, many people in this bug and elsewhere are asking for "full" SVG fonts. This is one thing that frustrates me about discussing SVG fonts. When talking about use-cases, people like to define "SVG fonts" as "SVG 1.1 Full fonts". But when talking about complexity of implementation and browser support, people like to define "SVG fonts" as (roughly) "SVG 1.2 Tiny fonts". > Complex shaping is overrated: we are having discussion > right now without any shaping whatsoever. It's convenient that we both write English, but I think the needs of people writing complex-shaping languages are just as important as the needs of English-speakers.

(In reply to comment #98) > (In reply to comment #96) > > To achieve such a demand now, you have to convert glyphs to path, or use > > Flash. Not really dramatic to kill semantic on a logo. > > Or just use an SVG image in an <img> with alt text. If you don't like to > reference an external file you can use SVG <use>, or make any image inline > using data: URLs, although very few people ship raster images inline that way > so I believe referencing images in external files is not a major problem for > Web developers. You're right, but you loose text selection, and an alt attribute do not have the same semantic value than a text tag... Can we ship a WOFF font as data in a SVG file ? Sorry, but SVG is not used only on the web... Sadly, some contexts are not hypertext-friendly. > > > But why not accept a fund-raised development as a technology preview, to start > > with ? > > Because I care about finding the right solution for the Web. I thank you and Mozilla for that. But here is your mistake in my opinion : you cannot judge what is good or bad for the web alone. There are W3C, web designers, SVG WG, Webkit, Inkscape peoples who think that SVG fonts are good for the web, and they have a voice, as Mozilla have (I suppose you have heard them recently...). > > > Internationalization issue do not have to be solved now, let's add this to the > > to-do list. > > Designing something and adding on "internationalization" later tends to produce > bad results. Sorry, but almost the whole computer story ran like that... As you know, we cannot manage every issue before starting a such complex work, and there will be obstacle on the way, including Internationalization. > > > WOFF is not perfect either for complex shaping, and new special > > characters are added to fonts everyday. > > There's nothing better than OpenType for complex shaping, except maybe SIL's > Graphite, but most of the investment is going into OpenType especially on the > font side. That's my point : it's not perfect. nothing is perfect before working on it.

(In reply to comment #100) > Can we ship a WOFF font as data in a SVG file ? Yes, using data: URIs. > Sorry, but SVG is not used only on the web... Sadly, some contexts are not > hypertext-friendly. I don't really care about stuff that's not the Web. They can do whatever they want. > > > WOFF is not perfect either for complex shaping, and new special > > > characters are added to fonts everyday. > > > > There's nothing better than OpenType for complex shaping, except maybe SIL's > > Graphite, but most of the investment is going into OpenType especially on the > > font side. > > That's my point : it's not perfect. nothing is perfect before working on it. Who's going to work on better internationalization for SVG fonts? As far as I know, no-one's interested.

(In reply to comment #99) > (In reply to comment #97) > > Another use case: say there is a font which has many glyphs. But for my > > charting web site I only need the numbers. I could open the font in a text > > editor and simply copy-paste the wanted glyphs to a new font. > > There are plenty of tools for subsetting OpenType fonts, and they're easy to > use. http://www.fontsquirrel.com/fontface/generator can do it. but you also admit that a text editor is more convenient to keep only 10 glyphs... > > > I think, all we are asking for is basic SVG font support(, WebKit level is > > useful-enough-for-me). > > No, many people in this bug and elsewhere are asking for "full" SVG fonts. > > This is one thing that frustrates me about discussing SVG fonts. When talking > about use-cases, people like to define "SVG fonts" as "SVG 1.1 Full fonts". But > when talking about complexity of implementation and browser support, people > like to define "SVG fonts" as (roughly) "SVG 1.2 Tiny fonts". What we want is killing the "we will not implement SVG fonts" assumption, because we do not feel right with it, and because we think Mozilla shouldn't act like this. If you say us : ok, we will reconsider the issue, discuss with SVG WG on the internationalization issue, and start to work on it for Firefox 5 or 6, we will be happy. > > > Complex shaping is overrated: we are having discussion > > right now without any shaping whatsoever. > > It's convenient that we both write English, but I think the needs of people > writing complex-shaping languages are just as important as the needs of > English-speakers. Agreed, but Indians will wake up and help us when they will see that we can do interesting things with SVG Fonts, and that they can't have it in there own languages. Again, this is about openness and hack-ability. We do not agree on future, and only future will give us right or wrong. But please give us our chance.

(In reply to comment #99) > > There are plenty of tools for subsetting OpenType fonts, and they're easy to > use. http://www.fontsquirrel.com/fontface/generator can do it. If I had to turn to some "tool" everytime I wanted to publish something, the web would go nowhere. Simple editing and "Page Source" is the key. > No, many people in this bug and elsewhere are asking for "full" SVG fonts. What I was referring to is I don't think anyone asks for IFRAMEs in the glyphs. > It's convenient that we both write English, but I think the needs of people > writing complex-shaping languages are just as important as the needs of > English-speakers. The point was, some SVG Fonts support is better than no support.

(In reply to comment #102) > but you also admit that a text editor is more convenient to keep only 10 > glyphs... We're talking about saving a few Web developers a few seconds a week. There are much more important things to work on than that. > If you say us : ok, we will reconsider the issue, discuss with SVG WG on the > internationalization issue We have reconsidered it multiple times. I talked to the SVG WG about SVG fonts in general and the internationalization issues in particular at the face-to-face last week. No-one was interested in working on the internationalization issues. (In reply to comment #103) > > No, many people in this bug and elsewhere are asking for "full" SVG fonts. > > What I was referring to is I don't think anyone asks for IFRAMEs in the glyphs. You confused me by referring to "Webkit-level". Last I checked, Webkit (and Opera) support only the 1.2-Tiny subset, i.e. nothing but a simple path in each glyph. > > It's convenient that we both write English, but I think the needs of people > > writing complex-shaping languages are just as important as the needs of > > English-speakers. > > The point was, some SVG Fonts support is better than no support. Not really, because SVG Fonts support isn't free. A complex-script author could quite reasonably ask us "Why did you implement support for a standard we can't use, instead of extending an existing standard you already support (OpenType/WOFF) to create a solution everyone can use?"

(In reply to comment #104) > instead of extending an existing standard you already support > (OpenType/WOFF) to create a solution everyone can use?" And FWIW I think this can be done. Maybe it can even be done retaining some compatibility with a useful subset of SVG Fonts (1.2-Tiny or 1.1-Full). It needs thought and work, which isn't going to happen in a spam-trap bug like this.

ok... I have tried my best here, you have your reasons, and they are good enough, I can't do much more. Last questions : Why not start with this "useful subset", once defined ? (I think we have already started to work on this on the wiki ...) Will you accept patches from a fund-raised "hired" developer ?

(In reply to comment #106) > Why not start with this "useful subset", once defined ? (I think we have > already started to work on this on the wiki ...) > Will you accept patches from a fund-raised "hired" developer ? Depends on the patches. If they implement something like https://wiki.mozilla.org/SVGOpenTypeFonts, and they're good, I'd like to accept them!

OK, at first read, I didn't understood your proposal. So, your idea is to take the best of both worlds to allow every use case in a new spec called SVG OpenType Fonts, that we can use both in a "blob" and "DOM" form, and an API to convert one into other ? Maintaining compatibility with an "useful subset" on SVG Fonts 1.1 ? Planned to be included in SVG 2.0 ? Sounds good, but it's also a lot of work... Do SVG WG agree with that ? I do not feel comfortable to launch a fund-raising campaign on a not yet well defined project... maybe to launch it on the "useful subset" you wish to keep to transform it in "SVG OpenType Fonts" is more acceptable now, starting to work on SVG OpenType Fonts on the way. Have you an idea on who to hire ? What would be the exact mission ?

A Comparison Table is now available on the wiki : https://wiki.mozilla.org/SVGFonts please review ;)

Excellent work :]

I don't know why you list WOFF as "Vector outlines: no". It's possible to embed bitmap glyphs in a WOFF font but a) no-one does that and b) that's the author's choice. I also don't know why you list for WOFF "Text in a shape: no". If we supported SVG 1.2 Full's textarea stuff, WOFF fonts would work in it.

Humm, for Vector outlines, that's not my part, for Text in a shape it is.... but please correct wrong assertions. I've put "?" in parts where I'm not sure...

Our company's customers and their constituents have requirements that are satisfied by SVG fonts and not by WOFF. See http://www.svgmaker.com We'll commit engineers, a project manager and QA resources to implement SVG fonts in Mozilla, if someone in authority at Mozilla corp will confirm in advance that our work would be accepted once completed and ship as part of FireFox, subject to conforming with Mozilla's specification and quality requirements. If Mozilla corp has decided to block SVG fonts for whatever reason, even with development resources coming from the community at no cost to Mozilla corp, please tell us clearly now before we expend further resources attempting to contribute to FireFox. Is that fair enough? Implementation Questions 1. What is the context of SVG fonts within the browser? Please see comment #4 above (Hixie 2004-09-18 05:36:27 PDT) and comment #7 above (Doug Schepers 2007-05-04 20:50:37 PDT) in the absence of any definitive answer from Mozilla corp., we assume the context of SVG fonts is simply to render SVG fonts with SVG. 2. Is comment #10 above (tor 2007-08-09 16:00:58 PDT) regarding gfxFont still (a) relevant (b) valid? If neither, please update the architectural requirements definitively. 3. Should we fully consider all implications of supporting arbitrary SVG within a glyph, or should we just implement essential text functions to a similar extent to which other UAs already have? Let me answer Question 3 already since it is partly a straw man aimed at streamlining our discussions at this point: For the first patch of this project, we propose to implement the essential requirements for supporting SVGT 1.2 SVG fonts. The 'font' element The 'glyph' element The 'missing-glyph' element The 'font-face' element The 'font-face-src' element The 'font-face-uri' element For further patches after the success of the first, possibilities are open. At this point, we are just offering to resource the development effort required to bring FireFox's capabilities into line with existing Chrome, Safari, Opera, and SVG Web implementations.

(In reply to comment #113) > > 1. What is the context of SVG fonts within the browser? > > in the absence of any definitive answer from Mozilla corp., we assume the > context of SVG fonts is simply to render SVG fonts with SVG. SVG fonts would need to be implemented in a way that was easy to extend to html and/or mathml even if that capability was not initially provided. > > > 2. Is comment #10 above (tor 2007-08-09 16:00:58 PDT) regarding gfxFont still > (a) relevant (b) valid? If neither, please update the architectural > requirements definitively. comment 54 is more relevant.

(In reply to comment #113) > Our company's customers and their constituents have requirements that are > satisfied by SVG fonts and not by WOFF. > > See http://www.svgmaker.com > > We'll commit engineers, a project manager and QA resources to implement SVG > fonts in Mozilla, if someone in authority at Mozilla corp will confirm in > advance that our work would be accepted once completed and ship as part of > FireFox, subject to conforming with Mozilla's specification and quality > requirements. > > If Mozilla corp has decided to block SVG fonts for whatever reason, even with > development resources coming from the community at no cost to Mozilla corp, > please tell us clearly now before we expend further resources attempting to > contribute to FireFox. Is that fair enough? > > > Implementation Questions > > 1. What is the context of SVG fonts within the browser? > > Please see comment #4 above (Hixie 2004-09-18 05:36:27 PDT) > and comment #7 above (Doug Schepers 2007-05-04 20:50:37 PDT) > > in the absence of any definitive answer from Mozilla corp., we assume the > context of SVG fonts is simply to render SVG fonts with SVG. > > > 2. Is comment #10 above (tor 2007-08-09 16:00:58 PDT) regarding gfxFont still > (a) relevant (b) valid? If neither, please update the architectural > requirements definitively. > > > 3. Should we fully consider all implications of supporting arbitrary SVG > within a glyph, or should we just implement essential text functions to a > similar extent to which other UAs already have? > > > Let me answer Question 3 already since it is partly a straw man aimed at > streamlining our discussions at this point: > > For the first patch of this project, we propose to implement the essential > requirements for supporting SVGT 1.2 SVG fonts. > > The 'font' element > The 'glyph' element > The 'missing-glyph' element > The 'font-face' element > The 'font-face-src' element > The 'font-face-uri' element > > For further patches after the success of the first, possibilities are open. > > At this point, we are just offering to resource the development effort required > to bring FireFox's capabilities into line with existing Chrome, Safari, Opera, > and SVG Web implementations. if you sumebit a patch and it works and doesnt cause any regressions/problems they would take it being open source you can work and submit patch for any bug you want (as long as you license the patch under the gpl and the mozila license)

Mike is quite right to ask whether Mozilla would accept a patch to add SVG Fonts support to Mozilla. Sure, being open source means anyone can submit a patch for anything they want, but it does not mean that the individual/organization making the source of their product available will or should accept every patch that anyone wants to add to their product - even if the patch is of good quality. There are often many more factors than patch quality to consider. In the case of patches to improve the Web platform the factors that should be taken into account can sometimes be very complex, requiring a lot of thought and case-by-case decisions. Happily their are some very experienced old hands in the Mozilla community who over the years have learned a lot about improving the Web, avoiding major pitfalls when possible, and making these sorts of decisions. Mike, when you say your customer's requirements are met by "SVG fonts", are you referring to SVG Tiny Fonts (just outlines), or to SVG Full Fonts (rendering arbitrary content)? What specifically is it that WOFF doesn't give you that you need?

Robert, How about a proposal to add a "backing" OpenType font to an SVG font? The backing font will be used for all shaping, etc. The SVG font will be used to "override" some glyphs. Any glyph not overridden by the SVG font will just pickup its shape from the OpenType font. As an enhancement, the SVG font can also add more kerning to the OpenType font, but that's optional.

Behdad, that sounds a lot like https://wiki.mozilla.org/SVGOpenTypeFonts, and since I wrote that page, it sounds good to me :-). (In fact, I arrived at the ideas on that page by starting with the idea of having a separate "backing" OpenType font for shaping, and then recognized that there are some use cases that would benefit from an XML/DOM serialization of the OpenType data.) Mike, that is an awesome offer. Like Jonathan, I'd like to hear exactly what your requirements are. Before responding to that offer, I want a better idea of what the future of SVG fonts should be.

FYI: Most users of email on Japanese cell phone are using emoji. http://en.wikipedia.org/wiki/Emoji http://www.unicode.org/faq/emoji_dingbats.html http://www.appleinsider.com/articles/11/02/27/inside_mac_os_x_10_7_lion_font_book_3_emoji_support.html Unicode 6.0 defines the code points, so, we can use it reasonably now. However, the glyphs of emoji must be displayed with multicolors. And if it's possible, it should be animated. If we support SVG fonts, we're very happy for supporting emoji. See also bug 638335.

(In reply to comment #119) > http://www.appleinsider.com/articles/11/02/27/inside_mac_os_x_10_7_lion_font_book_3_emoji_support.html > > Unicode 6.0 defines the code points, so, we can use it reasonably now. However, > the glyphs of emoji must be displayed with multicolors. And if it's possible, > it should be animated. If we support SVG fonts, we're very happy for supporting > emoji. The Apple Color Emoji font is interesting. It uses a sbix table to store PNG images for each glyph.

(In reply to comment #116) > Mike, when you say your customer's requirements are met by "SVG fonts", are you > referring to SVG Tiny Fonts (just outlines), or to SVG Full Fonts (rendering > arbitrary content)? Jonathan, roc, I am referring to SVG Tiny Fonts as both minimum and sufficient for our customers' current requirements. > What specifically is it that WOFF doesn't give you that you need? Audience reach. Our customers and their constituents need to publish open standard, WYSIWYG vector graphics with searchable, WYSIWYG text to 100% of the web audience today, not a subset of the web audience. SVG fonts is, today, supported by Chrome, Opera, Safari, Batik, BitFlash, Ikivo, TinyLine, ASV, and SVG Web, which renders SVG fonts on IE 6, 7, 8 and 9. FireFox is the only platform missing SVG fonts. So, we can consign FireFox users to the same experience as IE users and render their SVG content with SVG Web, or do the work to get FireFox up to speed with SVG fonts now, if you, the community and your organization want that to happen. We'd prefer to do the development work now, and establish the audience baseline in favor of SVG publishing and native FireFox rendering. Consider the alternative. In the 2 - 3 - 4 years it takes for WOFF to become a ubiquitous standard with > 90% audience reach, how is anybody going to publish open standard vector graphics with WYSIWYG text on the web and reach an arbitrary audience effectively? We see a bright future for WOFF. This SVG fonts project is a necessary and pragmatic part of building that future by servicing customer requirements for open standard publishing in the present, and accessing archives of legacy data in the future. I'm not saying you couldn't change our priorities towards WOFF tomorrow. But to do so, you'd have to at least implement WOFF in SVG Web tonight, so the legacy browsers can use it. Would you consider doing that as a priority, or would you prefer us to implement SVG fonts in FireFox? ;)

(In reply to comment #121) > SVG fonts is, today, supported by Chrome, Opera, Safari, Batik, BitFlash, > Ikivo, TinyLine, ASV, and SVG Web, which renders SVG fonts on IE 6, 7, 8 and 9. > > FireFox is the only platform missing SVG fonts. I'm a little confused. You go on to say that Firefox users can get the same experience as IE users by using SVG Web (I assume that's a plugin; I don't know it). So why are you saying here that IE supports SVG fonts and Firefox doesn't? Also, is there a reason why you can't serve both WOFF and SVG fonts, like Typekit does?

(In reply to comment #122) > I'm a little confused. You go on to say that Firefox users > can get the same experience as IE users by using SVG Web > (I assume that's a plugin; I don't know it). SVG Web is not a plugin as such, it's a javascript library that renders SVG to Adobe's Flash(tm) runtime, which must already be present on the system. It's a way to get SVG to render on browsers that don't support SVG natively. SVG Web home http://code.google.com/p/svgweb/ SVG Web renders a subset of SVG on Flash, which is a better baseline user experience than the browser failing to render SVG at all. A cost is that HTML pages have to link to ~150Kb of javascript and .swf on a web server. The rendering performance is bound by javascript + Flash performance. The user experience, after a lag, and sometimes a blink, on load, is pretty good. For IE 6, 7, and 8 we include the SVG Web library to perform SVG rendering, since those browsers don't support any SVG. The user must have the Flash runtime installed. IE 9 renders our SVG correctly unless the content includes SMIL animation or SVG fonts, neither of which are supported by IE 9, but are supported by SVG Web. So we include the SVG Web library for IE 9 too. SVG Web does not support WOFF, so if we change to publishing WOFF instead of SVG fonts today, the text won't render on IE 6 - 9 through SVG Web. Currently, FireFox users get a similar experience to IE 9 users. SVG has to be rendered by SVG Web if it includes SVG fonts because FireFox's native rendering doesn't support SVG fonts. Example 1 definition4001.svg (128,139 bytes) rendered natively by the browser http://www.svgmaker.com/gallery/d4001.html Example 2 definition4001.svg (128,139 bytes) rendered by SVG Web (requires Flash) http://www.svgmaker.com/gallery/d4001svgw.html The library is not selective, so sadly, FireFox users get zero native SVG rendering for those cases; the whole graphic is rendered by SVG Web. Or if we don't include the SVG Web library, as in Example 1 above, FireFox users see a partial rendering that doesn't include WYSIWYG typography. We are proposing to implement SVG fonts in Mozilla so that FireFox users can experience FireFox's superb native SVG rendering instead of going through SVG Web and the Flash runtime. We want FireFox users to have seamless, high fidelity experiences viewing open standard content on the web, including WYSIWYG typography that works on all device types. Our customers, which include federal governments, local governments, militaries, manufacturing companies, services companies, ISVs and professionals, want to do this kind of publishing with open standards. They need WYSIWYG typography. They need ~100% audience reach. We deliver today with SVG fonts. The open question is whether FireFox users experience SVG natively or through SVG Web. If the latter is the only choice, the FireFox user isn't really having a FireFox experience; she's having an Adobe experience inside of an orphan rectangle inside of a browser. If FireFox were to implement SVG fonts, there would be only one major browser that didn't have it. That family of browser users would be isolated from best practice. They will still be functioning consumers of information published by our customers, because they'll see the content rendered by SVG Web, but they are also a clear target for upgrading to a more capable modern browser that delivers a better experience. For FireFox in government, enterprise and education, this is a relevant technology and an opportunity for Mozilla to drive adoption and gain market share. Do you know people in marketing, public relations or business management at Mozilla who deal with government, enterprise or education? Let's invite them out somewhere we can talk. > Also, is there a reason why you can't serve both WOFF and SVG fonts, like > Typekit does? I'd need you to explain what you mean by "like Typekit does", and consult with colleagues in the context of our product engineering before I could give you a properly considered response. But I don't want to take us off topic here. This is [Bug 119490] Implement SVG fonts. We propose to make FireFox a more capable browser by resolving it. An engineering group is available now. How do you feel about having this bug resolved?

(In reply to comment #123) > > Also, is there a reason why you can't serve both WOFF and SVG fonts, like > > Typekit does? > > > I'd need you to explain what you mean by "like Typekit does", and consult with > colleagues in the context of our product engineering before I could give you a > properly considered response. OK. Typekit takes Truetype fonts and generates SVG and WOFF versions of the font, so that a browser with SVG Fonts support OR WOFF support will work. Whether that makes sense for you depends on how your fonts are generated. > This is [Bug 119490] Implement SVG fonts. We propose to make FireFox a more > capable browser by resolving it. An engineering group is available now. > > How do you feel about having this bug resolved? It's certainly very tempting to just bang out SVG Tiny fonts to get the final Acid3 points and make the whiners go away. However, as I have explained above, a large set of Web authors need something better, and I really don't want to land a bunch of code that we then break or throw away. If you think https://wiki.mozilla.org/SVGOpenTypeFonts makes sense and are willing to implement whatever subset of SVG Fonts you need in the manner described in that page (i.e., convert from the SVG font DOM to an OpenType font used for shaping, override the glyph drawing path to draw SVG content), then I think we could take that. I'd want John and Jonathan to sign off on the approach too though. Then we'd need to discuss how the code would actually work.

(In reply to comment #124) > It's certainly very tempting to just bang out SVG Tiny fonts to > get the final Acid3 points and make the whiners go away. We haven't mentioned Acid3. I detailed our customer requirements for SVG fonts in my previous post, comment #123 above. Did you read it? Would you care to respond to its substance? Are you satisfied with the way FireFox 4 renders this valid SVG fonts example: http://www.svgmaker.com/gallery/d4001.html > I really don't want to land a bunch of code that we then break or > throw away. Why would Mozilla throw away support for SVG fonts after implementing it? > If you think https://wiki.mozilla.org/SVGOpenTypeFonts makes sense and > are willing to implement... We are offering to implement SVGT 1.2 SVG fonts according to the standard, which has been a W3C recommendation since 22 December 2008. Are you saying Mozilla corp will not accept a patch to resolve this bug unless it also implements your own proprietary concepts which (a) have not been fully specified, and (b) do not have consensus support within Mozilla?

(In reply to comment #125) > (In reply to comment #124) > > If you think https://wiki.mozilla.org/SVGOpenTypeFonts makes sense and > > are willing to implement... > > We are offering to implement SVGT 1.2 SVG fonts according to the standard, > which has been a W3C recommendation since 22 December 2008. If you're only interested in SVG Tiny fonts it may be worth just writing javascript to convert the SVG font to WOFF.

(In reply to comment #126) > If you're only interested in SVG Tiny fonts it may be worth just writing > javascript to convert the SVG font to WOFF. Yeah, if we're going to implement SVG fonts for FireFox, we'd rather implement it in the most effective way - native code - so that everybody gets it, deployment is a no-brainer, and the user experience is maximally superb. I didn't say we're only interested in SVG Tiny fonts. I only said we have identified SVGT 1.2 SVG fonts as the first stage of the project which we are already prepared to fully resource. We understand the business case for SVGT 1.2 SVG fonts and we know some things about how to implement it efficiently without burning bridges. Further stages are open. It makes sense to think of the bigger picture and the longer journey too, as roc is clearly doing.

(In reply to comment #125) > I detailed our customer requirements for SVG fonts in my previous post, comment > #123 above. Did you read it? Would you care to respond to its substance? I don't want to nitpick you, but OK. You said "high fidelity experiences viewing open standard content on the web, including WYSIWYG typography that works on all device types." Sounds to me like you'd get the best results by shipping fonts in both WOFF and SVG formats. No browser, and only one or two standalone SVG players, supports subpixel rendering of SVG fonts. SVG fonts don't support hinting and only the most basic shaping. In practice the quality of WOFF/OpenType rendering is much higher than for SVG fonts: http://www.zeldman.com/2010/11/26/web-type-news-iphone-and-ipad-now-support-truetype-font-embedding-this-is-huge/ So if you want a high-fidelity experience that matches the rendering quality of other fonts the user sees, you need to offer WOFF/Opentype format. > Are you satisfied with the way FireFox 4 renders this valid SVG fonts example: > > http://www.svgmaker.com/gallery/d4001.html There are a lot of things about Firefox 4 that I'm not satisfied with and this is pretty low on the list to be honest. > > I really don't want to land a bunch of code that we then break or > > throw away. > > Why would Mozilla throw away support for SVG fonts after implementing it? If the implementation approach can't be extended to support languages that require complex shaping. > Are you saying Mozilla corp will not accept a patch to resolve this bug unless > it also implements your own proprietary concepts which (a) have not been fully > specified, and (b) do not have consensus support within Mozilla? I'm saying we won't accept a patch which deliberately ignores the requirements of a large chunk of the world's population, and does not even offer a roadmap to eventually addressing those requirements. As for "my own proprietary concepts", that's how standards improve: people come up with useful concepts and we build consensus around them. I'm considering bringing this up at the WG but before I go there I'd like to have a proof-of-concept prototype to test feasibility.

I agree that WOFF font rendering is likely to be better than SVG font rendering. However, there are a large number of legal considerations when it comes to WOFF fonts. Our legal department will not let us create WOFF fonts for HTML content automatically. But SVG fonts are 'acceptable' because we don't emit things like kerning pairs, etc so the end results is a dumbed down version of the original font. Therefore I believe there is a real case for wanting to support SVG fonts.

(In reply to comment #131) > I agree that WOFF font rendering is likely to be better than SVG font > rendering. However, there are a large number of legal considerations when it > comes to WOFF fonts. > > Our legal department will not let us create WOFF fonts for HTML content > automatically. But SVG fonts are 'acceptable' because we don't emit things like > kerning pairs, etc so the end results is a dumbed down version of the original > font. > > Therefore I believe there is a real case for wanting to support SVG fonts. Can't this be achieved just as easily by subsetting an existing font and droping the kerning pairs and other information explicitly?

Just to note Google Labs' Swiffy (http://swiffy.googlelabs.com/ - converts SWFs into SVG) makes use of SVG fonts, so rendering isn't as nice in Firefox. e.g. http://swiffy.googlelabs.com/gallery/example1.html

Any progress concerning Mike Kidson's awesome proposal and kindly offer made in comment #113 and stressed several times in comment #121, #123, #125 and #127 ? What a unique offer! What a unique chance! Being any reluctant to such a great and surprising offer -- it would be silly, _not_ saying "Yes"! Take that hand Mike Kidson puts forth without further hesitating and bury the ball in the net, so that this longtime existing bug can be finally closed! You would make many people happy.

Agreed, sounds like an excellent opportunity. Could "someone in authority at Mozilla corp" please get contacted so this project can get underway? I'm sure we'd all appreciate it! Thanks a heap Mike Kidson &co :]

Adding kev. We should absolutely talk about comment #133.

Since the discussions earlier in this bug, Adam Twardoch raised the idea of adding SVG glyphs to OpenType fonts with standards groups, and it was (mostly) positively received: http://lists.w3.org/Archives/Public/www-font/2011AprJun/0144.html Adobe has been thinking along the same lines: http://lists.w3.org/Archives/Public/www-font/2011AprJun/0170.html I think that direction has far more potential than anything using SVG 1.2 Fonts syntax. It would be easier to implement and far more powerful in terms of supporting advanced font features and script shaping requirements for all the world's languages. I would far rather invest in a prototype implementation and spec proposal for that approach than support for SVG 1.2 Tiny Fonts, which are a dead end.

Reply to #138 : The advantage of SVG is to be XML and can be easily parsed by XML technologies so as to generate complex animations. This proposal is clearly a disingenuous idea of ​​Adobe to prevent the SVG to compete with its products.

SVG is a standard to keep and protect. Please let somobody work on this bug.

Not to mention the PR impact of being the *last* major browser to still fail Acid3 due to this bug.

Acid3 no longer requires SVG Fonts to pass. https://plus.google.com/107429617152575897589/posts/JdHnqpuUER4 Furthermore, constant spamming of this bug is NOT going to move it along, so please show some courtesy to the 128 people CCed to this bug that don't care about every Joe, Mary, and Tom's opinion on this matter.

Referencing my question on comment #135, I ask again: What is the current status of Mike Kidson's unique and awesome offer in comment #113, stressed several times in comment #121, comment #123, comment #125 and comment #127 ? Any progress? Completely abandoned? Is this work done by Mike Kidson's company anyway, despite of Mozillas decision? Will Mozilla use their results (code), or will Mozilla not use their results (code), if they decide to work out a fundamental solution for SVG Fonts in Firefox? What's the decision so far of Mike Kidson's company he works for, what's the decision of Mozilla concerning their offer & decision?

(In reply to Ryan VanderMeulen from comment #142) > Acid3 no longer requires SVG Fonts to pass. > https://plus.google.com/107429617152575897589/posts/JdHnqpuUER4 > > Furthermore, constant spamming of this bug is NOT going to move it along, so > please show some courtesy to the 128 people CCed to this bug that don't care > about every Joe, Mary, and Tom's opinion on this matter. This bug is rigged. Mr O'Callahan made ​​the misinformation for the benefit of the Adobe company against the interests of open source. He is a dishonest man and those who support him as well. There is a problem in the Mozilla corporation. Spoofing of ACID3 tests is a disgrace. Why no answer to #113? Why when Flash cough it is a major problem : https://bugzilla.mozilla.org/show_bug.cgi?id=644832? Why when SVG dies, it a "brave choice" : http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html? Please come back down to earth!

(In reply to Philippe from comment #144) > This bug is rigged. Mr O'Callahan made ​​the misinformation for the benefit > of the Adobe company against the interests of open source. He is a dishonest > man and those who support him as well. There is a problem in the Mozilla > corporation. This isn't reasoned, careful argument. This isn't merely accusing someone of being wrong. This is making an accusation of bad faith, and it is an attack on a person, not on a thing. See 1.3 in Bugzilla Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html There are ways to argue, and there are ways not to argue. This is one way you shouldn't use. And as a practical matter, accusing someone in a position of power (in a sense) of bad faith is not the way to convince him to change his mind, or to win friends and influence people more generally. Even if it were not forbidden by the etiquette guidelines, this style of argumentation will get you less than nowhere.

(In reply to roger64 from comment #140) > SVG is a standard to keep and protect. Please let somobody work on this bug. May I repeat comment #52 and state that nothing, I repeat, *nothing* is stopping anyone from creating a patch to implement SVG fonts. If anyone does create a patch, it may likely be reviewed and, if a reviewer approves the patch, will be checked in. Of course, this will only hold as long as this bug is not resolved as WONTFIX. If you wish to implement SVG fonts, please do so. However, I'm not entirely sure if anyone will actually put in the effort to implement SVG fonts in Firefox, but we shall see :)

(In reply to Jeff Walden (remove +bmo to email) from comment #145) > (In reply to Philippe from comment #144) > > This bug is rigged. Mr O'Callahan made ​​the misinformation for the benefit > > of the Adobe company against the interests of open source. He is a dishonest > > man and those who support him as well. There is a problem in the Mozilla > > corporation. > > This isn't reasoned, careful argument. Would this be a "reasoned, careful argument"? Mister O'Callahan wrote: > SVG Fonts --- at least the subset implemented in Opera and Webkit > --- don't offer anything significant over downloadable Opentype > (or WOFF) fonts ... except the last three points of the Acid3 test :-(. > And people keep asking for it "because it's in SVG 1.1". But I don't think > those are good enough reasons on their own to make SVG Fonts > an essential part of the Web platform. Dear Mister O'Callahan, did you ever think about the fact that SVG might not only be used on web pages but also as a self contained interchange format for vector graphics? For such a format is supporting embedded fonts essentially so a single file can contain all of the graphics and doesn't need to be exchanged in company with a bunch of supporting files (the fonts). The Mozilla Corporation is actively sabotaging this purpose of SVG by not implementing SVG-Fonts in its viewer applications (might it be the web browser or the Mailing client). Please think about this issue one more time! regards, Lars

(In reply to Lars Sonchocky-Helldorf from comment #147) > For such a format is supporting embedded fonts essentially so a single file > can contain all of the graphics (as already noted in this bug (beginning of comment 101, probably elsewhere too): you can already embed external fonts into your content using a data URI.)

I agree with Philippe from comment #144, The entire situation is wrong on the most important levels. There is one reason to implement this feature. IT IS IN THE SVG STANDARD. forgot other browsers, and what they have done. Forgot other technical solutions, and how much better they may be. Simply put, roc will stop any progress on this front. Even if said progress has been pledged by other programmers. He has made his position clear, his reasons are 100% irrelevant. That is why I would suspect him of bad faith. He does not believe Firefox should have support for this standard, and it should not be his choice. If he has technical criticism, towards this SVG standard, he should present it to the w3c. He should not get in the way, of other people willing to donate their own resources. Following standards is what made Firefox what it is today, diverting from that path is a terrible idea. I also don't believe any argument from anyone, will change roc's mind. He is hostile even towards other people taking on SVG font support. This is not about technical merit, or finding solutions, this is about supporting SVG as best as possible.

(In reply to auscompgeek from comment #146) > May I repeat comment #52 and state that nothing, I repeat, *nothing* is > stopping anyone from creating a patch to implement SVG fonts. If anyone does > create a patch, it may likely be reviewed and, if a reviewer approves the > patch, will be checked in. Actually, if you look a bit at what happened around comment #113 to comment #128, Mike Kidson offered that his company dealt with this issue, but was gently told to (basically) sod off. Without that response, maybe (probably?) the feature would have been graciously donated by this company by now. If you also have a look at roc's blog post cited in comment #144 (http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html), here's the essence: "SVG Fonts and WebSQLDatabase would actually be very easy for us to implement. [...] It's certainly tempting to just cave in, implement these features, and move on. [...] But I honestly think we're doing the Web a service by resisting these things." So I have to agree with comment #144, comment #147 (yes, stand-alone SVGs do exist) and comment #149: that's purposeful (but, to be fair, open) sabotage. Firefox getting a reputation of getting the Acid 3 test changed in order to pass it was a brilliant move, too.

Hi all, Any news on the "SVG OpenType Fonts" proposal at the time of SVG 2 feature requirement revue ? I can't see anything about fonts here : http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input Have you discussed anything with the SVG working group to improve the SVG Font situation ? Thanks in advance for your answers

If anything, it will be a separate spec from SVG 2, so I don't think it's necessary to consider it as part of the SVG 2 Requirements Input.

I've been following this discussion for years, hoping for Mozilla to see the light at some point. It is ludicrous that due to this issue Firefox is losing relevance as a browser. WOFF is nice, but it's not SVG. I cannot create WOFF characters dynamically and turn them into Glyphs that I can then use as editable text. There are plenty of things you can do with SVG fonts, you cannot do with a high quality, full fledged, designed by corporations, typeface that pay some people handsome sums of money to kill technology that may damage their monopolies. And no,.. I somehow don't expect ROC to be one of them. He just doesn't get the idea of using inferior technology to create superior user interfaces for part of the community that uses only a limited set of characters. The just 50% of the world population or so,.. And anybody that happens to be able to read their languages. Mozilla,... wake up. You have put Firefox on a dead end yourselves by not supporting this technology. It gives power to the font designer just like youtube did for video.

(In reply to Jelle Mulder from comment #153) > I've been following this discussion for years, hoping for Mozilla to see the > light at some point. It is ludicrous that due to this issue Firefox is > losing relevance as a browser. WOFF is nice, but it's not SVG. I cannot > create WOFF characters dynamically and turn them into Glyphs that I can then > use as editable text. There are plenty of things you can do with SVG fonts, > you cannot do with a high quality, full fledged, designed by corporations, > typeface that pay some people handsome sums of money to kill technology that > may damage their monopolies. > > And no,.. I somehow don't expect ROC to be one of them. He just doesn't get > the idea of using inferior technology to create superior user interfaces for > part of the community that uses only a limited set of characters. The just > 50% of the world population or so,.. And anybody that happens to be able to > read their languages. > > Mozilla,... wake up. You have put Firefox on a dead end yourselves by not > supporting this technology. It gives power to the font designer just like > youtube did for video. Jelle, You are not alone in this. I write php that dynamically generates svg images, and I would love to use svg fonts in my dynamically generated svg files.

I'm coming off of being a Flash developer - I've been embracing HTML5 and SVG for years now. I desperately need SVG fonts to be fully supported in Firefox. I am in a position now where I have to redirect FF users to a separate page where all the type is rendered as outlines - a change which makes the SVG file 10x larger. SVG 1.1 is a simple standard and it should be an embarrassment that it is unimplemented in Firefox. It amazes me that Firefox is now in last place among browsers for it's implementation of SVG. You guys used to be the gold standard for standards compliance.

FYI, progress has been made on this topic, see http://robert.ocallahan.org/2013/02/svg-in-opentype-new-approach-to-svg.html I think it is safe to close this bug as wontfix.

Good point. Implementation of SVG Fonts has been superseded by the implementation of support for SVG glyphs within OpenType font packages. See bug 719286.

> Good point. Implementation of SVG Fonts has been superseded by the > implementation of support for SVG glyphs within OpenType font packages. See > bug 719286. which use the sfnt format and some other of it’s limitations. The sfnt format is alos used by eot woff2 ttf otf. The current problem I have is that I need to use a font for text using more than 65,5536 glyphs. SVG seems to be the right choice here. see also http://graphicdesign.stackexchange.com/q/58518/32932.

The font I chose for this is currently installed on my system in the pcf format.

no ps type1 one sorry (wrong extension)