On Saturday, June 16, 2007, 3:57:13 PM, Gail wrote:
GB> I may be doing something that would help. Have a look at my GB> Summer of Code proposal found on this page GB> http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm. The GB> suggested order of attack for the items in my proposal has UI GB> Redesign at the top and Font Family Variants next. I am currently GB> working on a bug (making <tref> work) but will be moving to the UI GB> when that's done. Maybe I will get to the font family stuff GB> before the end of the summer, but maybe not - even if I do not, I GB> intend to work on it during school, too. GB> GB> Let me know if that's the kind of work you're looking for.
Gail, I hope you don't mind my commenting on some aspects of your proposal here. You write
http://www.scs.carleton.ca/~gbanaszk/code/soc07/TextImprovements.pdf
Implementation issues to consider include the limitations of CSS itself. The CSS fontstyle property only takes values of normal, italic, and oblique. The weight property allows for bold fonts. The only values available for the font-variant property are normal and small-caps. Therefore, to support variants like outline and swash, a workaround is required.
To clarify, the weight property allows for up to nine weights, 100 to 900, as well as the convenience keywords normal and bold: http://www.w3.org/TR/CSS21/fonts.html#font-boldness and these are the same numbers as you will find in a truetype or opentype font to denote the weight. So light and black weights are already covered.
You are right that there is no support for swash and outline variants; a new attribute in an inkscape namespace that is like font-variant but also allows for swash and outline is exactly the right way to do this.
Note though that if a font provides multiple swash variants for a given character, that needs to be handled in the actual text element, using altGlyph.