RE: SVG 1.2 Comment: 4 Flowing text and graphics

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