- From: Patrick Dengler <patd@microsoft.com>
- Date: Thu, 3 Jun 2010 13:59:03 +0000
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "robert@ocallahan.org" <robert@ocallahan.org>, "www-svg@w3.org" <www-svg@w3.org>
What a gret discussion this is! I love hearing from the community on these issues. For SVG Fonts, we identified the following use case (though we recognized others) As a web page header: a) Have a user select the header b) Have the header be indexable c) Accessibility SVG Selection is an issue in general and needs to be solved independent of fonts. Indexing a header for search engines based upon some text on a page isn't as compelling. You can use <title> to index just as well or even better Accessibility is best solved with <title> <desc> or ARIA. We all agreed that SVG Fonts would not be used for document text, so we are only talking about large print, header like info. <use> is a very powerful and nice feature and allows me "use" an svgdocument just like a font for the vast majority of use cases. <use .. xlink:href="svg.font#f"> <use .. xlink:href="svg.font#o"> <use .. xlink:href="svg.font#n"> <use .. xlink:href="svg.font#t"> But frankly, I don't see developers going this far, I see developers, if they want to use SVG as a header simply referencing it inline <html> <img src="header.svg"> or <g id="myheader"> ... </g> As mentioned previously, when we look at the future of SVG, especially as it relates to HTML, in order to succeed at delivering the real "vector graphic" core values to the web, I submit we must let go of some of these, in my mind, edge cases. It took six years (?) to push out SVG 1.1 2nd edition into almost editors rec. There is a high cost to every module: testing, writing, implementing, maintaining. Any area where we in the SVG spec can trim back and focus on the primary use cases for SVG, I see as an opportunity. And note, that Chris from the working group didn't propose to eliminate the Fonts module, but rather make it optional. Essentially, instead of having the SVG Working Group define the expected standards (as in the previous approach of Tiny, Basic and Full), the intent was to allow customer demand drive features. As far as I know, no vendor has implemented SVG Fonts in full, and there are interoperability issues. SVG Fonts are useful for devices, and other scenarios. I would love for someone to point me to more than 100 web pages that use them. This same issue goes back to other features such as animations for example. The SVG group did a great job leading the effort in integrating SMIL; while this is not my favorite choice for animation (declarative) it is more toolable. Yet regardless of my opinion and consistent with the group's opinion, whether or not SMIL moves forward is irrelevant. We need a consistent story with HTML and CSS on animation. That should be the animation story for SVG. I believe the same goes for Fonts. How much legacy are we going to support (or in some cases, build)? If I were spend my dollars on the SVG working group's investments and resources for browser implementors would you spend them on: HTML/SVG/CSS convergence for properties, attributes, elements and features such as animations, fonts, transforms and filters. Investigations into new, powerful features (such that were shared with us on diffusion curves, parameters, etc) Fix the SVG DOM I would like to see SVG 2.0 get back to core values, and get to the community in a short amount of time. ________________________________________ From: www-svg-request@w3.org [www-svg-request@w3.org] on behalf of Dr. Olaf Hoffmann [Dr.O.Hoffmann@gmx.de] Sent: Thursday, June 03, 2010 5:27 AM To: robert@ocallahan.org; www-svg@w3.org Subject: Re: SVG Fonts [...] Robert O'Callahan: > 2010/6/3 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> > > > I think, these are pretty different use cases, to provide a font > > for reading a larger amount of text or to provide some specific glyphs > > within > > the same document for reasons like corporate design, advertisement, > > design etc. > > For the latter use-case, why not just insert the graphic inline or use > <use> to include the graphic? If you want the text available for searching > or accessibility, it'd be trivial to extend SVG so you can associate > Unicode text with particular graphic objects. Something like > <g> > <textContent>Mozilla</textContent> > ... Mozilla wordmark here ... > </g> You mean something like: <g ...> <title>Mozilla ...</title> <desc> Path representation of the text: ... (including corporate design intentions) </desc> <path d="... lot of data ..." /> <path d="... lot of data ..." /> <path d="... lot of data ..." /> ... </g> Sure, this is possible and using title and desc is always a good option to provide more information about the intented interpretation of graphics (if the viewer of each user provides some comfortable access to this additional/alternative information). However modifying the text (fixing bugs, other language for example at wikimedia) is difficult - ok, if you only provide the SVG-glyphs for the characters needed, modifying might be difficult as well, but if this is predictable, the author can provide already some more glyphs to cover such common changes. Maybe with such an application you will end up with a font of 50 to 100 glyphs, even if in one language version only 20 glyphs are used. However, many glyphs of this font will share several path segments, what reduces the work again dramatically. And there is a simple option as well to add some missing glyphs (for example Umlaute for a translation from english to german or some accents for english to french, spanish etc) This option to apply minor changes to the content without touching the design - or to add a previously missing glyph in the same style for another language - is an important aspect as well, because in such communities as wikipedia, wikimedia, wikibooks authors are changing and the use cases for the graphics may change as well. To be able to modify or to fix something with a simple tool like a text editor provides the interesting option, that more authors are able to contribute relevant content and with better quality. >From this point of view, it is always more favourable to have as much as possible in the same XML format, in this case to have the relevant graphics in one file in the format SVG. I have seen HTML-webpages with one GIF per glyph. This can be the result, if nothing works properly in typical viewers or the alternatives are too complex for the author. If this WOFF really works in many viewers and there are a lot of those fonts without licensing problems if republished by common authors or some organisations provide open font servers with the possibility for any author to link such fonts, this will be a good option to avoid this nonsense for HTML-webpages in the future. SVG-fonts are a good option to avoid something similar within graphics and for the requirement, that the graphical document must contain the used font itself. This is not either-or, both solves or avoids problems if used properly. > That's far easier to implement than full SVG 1.1 Fonts. In fact, viewers > need not implement anything at all. It's more flexible since you can > include absolutely anything in the graphic content. It's probably also > easier to author in most cases; the author just designs the graphic > in-place, and then annotates it with the underlying text. Sure, in the past 10 or 15 years I have seen a huge amount of 'simple solutions' for problems, that would have not occured, if the author had the knowledge and capabilties and interest to do it properly - and the specified effect can be really achieved in all major viewers. Typically these 'simple solutions' are rubbish, if modifications are required or the author changes or there is a longer time until the same author has a need to change something ;o) > With SVG Fonts > the author has to design the graphic, then break it up into individual > glyphs and move them out into a font. I think, typically one starts to create each single glyph (maybe even better to start with some characteristic path segments found in the same way in several glyphs), puts all in the font and uses this as a font, but I'm no designer and no font expert. Indeed it would not be very effective to paint for example 1kb of text manually, separate it in 1000 glyphs, putting this in a font and use this to represent the text ;o) But no doubt, not all authors will prefer readable text content over path-soup. As can be seen at many places, several people believe more in pictograms than in the written word, even if only a minority can identify, what each pictogram means ;o) Some have to provide text due to some social pressure. And some might want to do it as best as possible just for fun or because they can or want to show, that they really can write and read ;o) > > IMHO a "font" only makes sense if you're going to combine character glyphs > in more than one way. Otherwise it's just an inconvenient way to reference > images. > This happens, if you have to change the language or if you have not just a simple 5-or-6-glyph-logo (Mozilla with one ligature for 'll' or 'ill'), but some more words. Olaf
Received on Thursday, 3 June 2010 13:59:42 UTC