RE: reply to CSS WG comments on SVG 1.2

Hi, Dean and Chris-

Thanks for the quick and reassuring replies.

Great to hear we've still got arbitrary flow. I guess, though, due to
unforeseen complexity, that the flowing mechanism detailed in the Spec will
only be a guideline, and not normative? Not ideal for interop, but if that
seems like an unattainable goal, then so be it.

Regards-
Doug

doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.
 
Dean Jackson wrote:
| 
| 
| Hey Doug,
| 
| On 1 Mar 2005, at 12:23, Doug Schepers wrote:
| 
| >
| > Dear SVG-WG-
| >
| > The wording here seems to indicate that text-flow to 
| arbitrary shapes 
| > may have been dropped. I hope that this is not the case. I 
| feel that 
| > that is a well-designed and useful feature,
| 
| It hasn't been dropped. It certainly will not be in SVG Tiny 
| 1.2, but it will most probably be in the next draft of the 
| full specification.
| 
| >  and fail to see how it intersects with CSS's text layout 
| properties, 
| > which can do no such thing.
| 
| Right.
| 
| >
| > It has been suggested on this list that most authors do not want 
| > pixel-level control over appearance and that specifying a mandatory 
| > algorithm in the Spec restricts UA implementors from using custom 
| > solutions to achieve the desired end (thus reducing a possible 
| > competitive advantage). Most SVG authors (and Web authors 
| in general) 
| > I know are more interested in control and consistency of 
| performance 
| > and appearance between implementations than in proprietary 
| performance 
| > gains. I think it is crucial that authors know what to 
| expect across 
| > various UA and Oses; otherwise authoring is a nightmare (as in the 
| > Browser Wars).
| 
| The problem we face is that it is extremely difficult to 
| define an algorithm that does automatic line-breaking in a 
| well-internationalized manner. We had long discussions with 
| the W3C I18N Working Group who suggested a pretty simple 
| algorithm (fairly similar to what was already in SVG 1.2) but 
| with the warning that it was completely unsuitable for a lot 
| of scripts. They, and others on this list, said we needed to 
| make it possible for the user agent to implement its own 
| algorithm (or use the platform). Leaving this out was an 
| oversight on our behalf.
| 
| It would be nice to have a specification of good line 
| breaking, but I've been told that it is an extremely hard 
| thing to do, and is only mastered by a handful of people at 
| large companies that do lots of text work (eg. Microsoft with 
| Word, Adobe with InDesign, etc).
| 
| > Please do keep textflow in arbitrary shapes, and do mandate a 
| > particular algorithm to do so. If a UA implementor wishes to add an 
| > additional algorithm, allow them to do so using an explicit 
| attribute 
| > value like text-breaking='custom', or somesuch.
| 
| That's the current plan.
| 
|  > If I'm being paranoid and jumping to wrong conclusions, 
| um... Never mind,
| > then. As you were.
| 
| Just because you are paranoid doesn't mean we're not out to get you.
| 
| Dean


Chris Lilley wrote:
| 
| On Monday, February 28, 2005, 8:23:25 PM, Doug wrote:
| 
| DS> Please do keep textflow in arbitrary shapes, and do mandate a 
| DS> particular algorithm to do so. If a UA implementor wishes 
| to add an 
| DS> additional algorithm, allow them to do so using an explicit 
| DS> attribute value like text-breaking='custom', or somesuch.
| 
| DS> If I'm being paranoid and jumping to wrong conclusions, 
| um... Never 
| DS> mind, then. As you were.
| 
| Tiny 1.2 has flowing text in rectangles, as it did before.
| 
| Full 1.2 has flowing text in arbitrary shapes, as it did before.
| 
| User agents are allowed to pick the best line break 
| opportunities for any language, for example a Thai SVG 
| implementation is allowed to use a Thai dictionary to do line 
| breaking between words (Thai has no spaces between words, and 
| only breaks between words). They were forbidden to do that 
| before, in an attempt to get consistency between implementations.
| However it didn't actually give that consistency. So we 
| changed it. In particular, an implementation that already has 
| a CSS line layout engine can re-use that and be conformant.
| 
| Algorithms will be provided, to help implementors. But better 
| ones can also be used, if available.
| 
| -- 
|  Chris Lilley                    mailto:chris@xxxxxx
|  Chair, W3C SVG Working Group
|  W3C Graphics Activity Lead