Robert O'Callahan (:roc) (email my personal email if necessary) Reporter
	Description • 14 years ago

I can't find a bug already on file about this.

This might not be hard. Microsoft has a test
http://samples.msdn.microsoft.com/ietestcenter/html5/svg_html/SVG_HTML_TagName_014.html
that depends on altGlyphItem and altGlyphDef being SVGElements.

	Robert Longson [:longsonr]
	Comment 1 • 14 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Reporter
	Comment 2 • 14 years ago

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.

	John Hewson
	Comment 3 • 11 years ago

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 http://www.w3.org/Graphics/SVG/WG/track/actions/3073 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.

	Cameron McCormack (:heycam)
	Comment 7 • 8 years ago

altGlyph was removed from SVG 2, and given it's tied to SVG Fonts, I don't think we want to implement it.