Closed Bug 571808 Opened 13 years ago Closed 7 years ago

Implement altglyph


(Core :: SVG, defect)

Not set





(Reporter: roc, Unassigned)



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.
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.
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.
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.
altGlyph was removed from SVG 2, and given it's tied to SVG Fonts, I don't think we want to implement it.
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.