- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Mon, 08 Nov 2004 02:14:48 -0800
- To: Ian Hickson <ian@hixie.ch>, Doug Schepers <doug@schepers.cc>
- Cc: "'David Woolley'" <david@djwhome.demon.co.uk>, www-svg@w3.org
Ian, At 04:00 PM 11/7/2004, Ian Hickson wrote: >On Sun, 7 Nov 2004, Doug Schepers wrote: > > > > Thanks for the reply. I understand that there may be many ways to > > achieve the effect of line-wrapping, but the one that the SVG WG has > > proposed seems logical and doesn't look like it would be very > > computationally expensive. What do we lose by having the explicitly > > defined algorithm? > >The ability for UAs to achieve better line-breaking than is described in >the spec. It is effectively forcing a lowest-common-denominator >implementation (i.e. it is forcing desktop UAs to do no better than mobile >phone UAs). Actually, the SVG language has run into this sort of a problem in other areas of the language before. For example, for text-on-a-path, the SVG language provides an explicit, absolute, precise algorithm for how glyphs should be placed, but Adobe and others explained that there are other, more sophisticated algorithms for laying out text along a path. For SVG's various rendering hints, there are explicit options (e.g., geometric precision, optimize speed, optimize quality), but in most cases you also want to allow the user agent to make appropriate tradeoffs and do its own best job. For color management's rendering intent, there are explicit options (perceptual, colormetric, saturation), but often you want the user agent to do its own best job. In the situations, the SVG language usually includes an 'auto' keyword or something like that which indicates that the user agent is allowed to use algorithms which (hopefully) achieve better results at the expense of precise interoperability. In the case of text wrapping, it seems to me that an 'auto' keyword should be introduced (or something like it) which tells user agents it is OK to apply better algorithms. In Adobe's case, we have some advanced layout algorithms from our high-end publishing products, particularly InDesign, which we might want to offer within our SVG viewing products. I consider it an oversight that we don't have such a keyword today for text-in-a-shape since we already have the keyword for text-on-a-path. > > One reason to have it is that if authors can understand exactly how it > > works, they will know what to expect on every client, and it may even > > help them with authoring. And again, I don't understand what harm it > > does to have it explicitly defined. > >In addition to the above, it also is incompatible with CSS (which doesnÃ't >specify an algorithm specifically so that UAs can compete over who has the >best algorithm, thus raising the bar for all implementations without >forcing low-spec devices to implement high-spec algorithms), which means >UAs that support both the CSS and SVG inline box models have to have extra >bloat -- two implementations of essentially the same feature. Regarding of whether there is an 'auto' keyword or not, Adobe's implementation experience is that there is no incompatibility issue. We have a single text engine that does both CSS box model and SVG 1.2 flows. The text engine does indeed have a couple of features which are only used in the CSS box model case and a couple of features which are only used in the SVG 1.2 flow case, but we have found no incompatibilities where SVG 1.2 flows collided with CSS. On the contrary, we have found the single engine approach works very well. We started off with code which was originally CSS box model and adapted it to support SVG 1.2 text. Jon >-- >Ian Hickson U+1047E )\._.,--....,'``. fL >http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 8 November 2004 11:27:57 UTC