Last Comment Bug 571808 - Implement altglyph
: Implement altglyph
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 1021752 1021802 1021858 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2010-06-13 18:28 PDT by Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
Modified: 2016-03-22 00:38 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-06-13 18:28:40 PDT
I can't find a bug already on file about this.

This might not be hard. Microsoft has a test
that depends on altGlyphItem and altGlyphDef being SVGElements.
Comment 1 Robert Longson 2010-06-13 23:00:41 PDT
You can't get very far with altGlyphItem and altGlyphDef without SVG fonts can you?

We've traditionally done content and layout for elements at the same time. One reason for that is so that svg website developers can do getElementById on an element to test whether we've implemented support for it.
Comment 2 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-06-14 01:17:06 PDT
Maybe not. I wonder why IE9 Dev Preview is making altGlyphDef and altGlyphItem SVG elements if they're not going to be implementing SVG Fonts.
Comment 3 John Hewson 2013-12-14 10:42:06 PST
Implementing this would be useful for non-SVG fonts too! From the SVG 1.1 standard:

> An ‘altGlyph’ element either references a ‘glyph’ element or an ‘altGlyphDef’ element via its ‘xlink:href’ attribute or identifies a glyph by means of font selection properties, a glyph identifier and a font format.

Fonts other than SVG fonts are clearly supported by the standard. The "font selection properties" mentioned are shared with CSS (e.g. font-family, font-size) and Firefox already allows the font and font-family attributes to reference a CSS3 @font-face. Which means Firefox is 90% of the way there. The two key attributes which need supporting are:

> format: The format of the given font. If the font is in one of the formats listed in CSS2 ([CSS2], section 15.3.5), such as TrueDoc™ Portable Font Resource or Embedded OpenType, then the <string> must contain the corresponding font format string, such as truedoc-pfr or embedded-opentype.

Easy, these format strings are already defined in the CSS standard and used in @font-face src strings, e.g. "opentype".

> glyphRef: The glyph identifier, the format of which is dependent on the ‘format’ of the given font.

The SVG 1.1 standard does not define an standard way to specify glyph identifiers and there is a WG issue for this at However, as Firefox can only display OTF and TTF fonts which both use a sequential numeric glyph id (GID) to number glyphs, it seems like a simple integer would suffice*. This seems like a really useful feature to implement, and would lead to giving the WG some feedback on standardizing the glyph identifier format.


* Footnote: 

If it becomes needed later to use postscript names to access glyphs (unlikely?) then because e.g. the integer "5" is a valid postscript name there could be an ambiguity for opentype CFF fonts where the format is 'opentype'. To resolve this the glyphRef "postscript(5)" could be used because "(" and ")" are invalid in postscript names. As it stands I'm not sure it makes sense to support postscript-named glyphs at all, so I don't think this needs to be implemented but it's worth noting for future backwards-compatibility.
Comment 4 Robert Longson 2014-06-06 08:29:13 PDT
*** Bug 1021752 has been marked as a duplicate of this bug. ***
Comment 5 Boris Zbarsky [:bz] 2014-06-06 11:32:44 PDT
*** Bug 1021858 has been marked as a duplicate of this bug. ***
Comment 6 Boris Zbarsky [:bz] 2014-06-06 11:33:39 PDT
*** Bug 1021802 has been marked as a duplicate of this bug. ***
Comment 7 Cameron McCormack (:heycam) 2016-03-17 00:18:53 PDT
altGlyph was removed from SVG 2, and given it's tied to SVG Fonts, I don't think we want to implement it.

Note You need to log in before you can comment on or make changes to this bug.