RE: SVG 1.2 Comment: 4 Flowing text and graphics

On Mon, 8 Nov 2004, Jon Ferraiolo wrote:
> > 
> > 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. 

That's another good example of where the exact algorithm used should, 
IMHO, be left up to the UA.


> 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.

Indeed I would say that for a Web specification, you would _always_ want 
the UA to do its own best job, or at least you would want that often 
enough that the other use cases were not significant enough to warrant the 
additional specification complexity.

So I would personally recommend dropping all the rendering hint 
properties, and change explicit algorithms such as the text-on-a-path 
algorithm you mentioned from normative to informative status.

I have also noticed that the rendering hint properties are poorly 
understood by most Web authors. I have seen many SVG implementors suggest 
to authors to "try other rendering hints", e.g. to change the 
anti-aliasing from poor to good.


> 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.

Exactly. So why not allow better algorithms generally, instead of just if 
the author sets a magical property to a particular value?


> Regarding of whether there is an 'auto' keyword or not, Adobe's 
> implementation experience is that there is no incompatibility issue.

This is different to the implementation experience given by three other UA 
implementors, all three of which reported that the SVG spec overlaps with 
the CSS spec here, without it being compatible enough to mean the code 
would be shared:

   http://lists.w3.org/Archives/Public/www-svg/2004May/0019.html
   http://lists.w3.org/Archives/Member/w3c-svg-wg/2004OctDec/0701.html
   http://lists.w3.org/Archives/Public/www-svg/2004Nov/0011.html (from me)


> We have a single text engine that does both CSS box model and SVG 1.2 
> flows.

Note that all the implementations of the CSS inline box model that I have 
tested since becoming involved with CSS (Win IE, Mac IE, Mozilla, Safari, 
Opera, Amaya, and various other implementations that nobody has heard of) 
have been initially incorrect. While it would be encouraging to think that 
Adobe's implementation team is more competent than the Microsoft, 
Netscape, Apple, Opera, and W3C teams, I would be curious in seeing 
screenshots of your CSS implementation rendering XHTML versions of the 
tests I mentioned earlier:

   http://www.hixie.ch/tests/evil/mixed/lineheight1.html
   http://www.hixie.ch/tests/evil/mixed/lineheight2.html
   http://www.hixie.ch/tests/evil/mixed/lineheight3.html
   http://www.hixie.ch/tests/evil/mixed/lineheight4.html
   http://www.hixie.ch/tests/evil/mixed/lineheight5.html
   http://www.hixie.ch/tests/evil/mixed/lineheight6.html
   http://www.hixie.ch/tests/evil/mixed/lineheight7.html

...as well as the tests under this directory:

   http://www.hixie.ch/tests/adhoc/css/box/inline/

It is quite easy to create an implementation of the CSS inline box model 
which is correct to first approximation, but which, upon detailed testing, 
is found to be quite far from actually being an implementation of the 
actual CSS inline box model. I'm not aware of anyone who hasn't made that 
mistake, in fact. So while I believe you have every confidence that your 
implementation is indeed a faithful implementation of CSS's inline box 
model, I caution against claiming this without verifying it with the tests 
I mentioned above.

(If you would like help in making these tests more appropriate for SVG or 
XHTML browsers, contact me off-list.)


In any case, I still think that the proposed flow regions model is much 
too involved for simply adding the ability to do multiple lines, and would 
rather that SVG use a continuation model such as those I described here:

   http://lists.w3.org/Archives/Public/www-svg/2004Nov/0109.html

...than extending SVG as much as SVG 1.2 Last Call does.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 8 November 2004 22:09:17 UTC