Re: reply to CSS WG comments on SVG 1.2

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


>
> Regards-
> Doug
>
> doug . schepers  @ vectoreal.com
> www.vectoreal.com ...for scalable solutions.
>
>
> Dean Jackson wrote:
> |
>   [snip]
> |
> |  > a) We are concerned that section 4, Flowing text and graphics,
> | overlaps
> |  > directly with CSS. We feel that instead of adding line
> | layout to SVG,
> |  > it would be wiser to add a way to specify a fill shape to CSS.
> |
> | We have the requirement to provide a simple method for automatic line
> | breaking in an environment without CSS. This continues to be the most
> | commonly requested feature from the days before SVG 1.0 REC, and is a
> | standard feature in nearly all graphical authoring tools.
> |
> | Our next draft of SVG will have an revised method for this feature. 
> It
> | aligns more closely with the existing SVG 1.0+ text features - only
> | adding automatic line breaking (with an option to allow the User 
> Agent
> | to choose the break points). The end result can be easily expressed
> | using the SVG 1.0+ text elements. We also believe it has less overlap
> | with CSS layout. As a graphical language, we're replicating standard
> | graphic features and avoiding many text-layout features.
> |
> |
>   [snip]
> |
> |
> |  > a) It is unclear how the margin and indent properties apply to the
> | flowed
> |  > text feature. Both properties are mentioned in passing but
> | the model
> |  > is never fully explained. In particular, it appears to be
> | different to
> |  > the CSS model in important ways, although exactly how different is
> |  > unclear due to the ambiguity of the description.
> |
> | We've modified the flowed text feature to align it closely with the
> | standard text features of graphics systems and in the process removed
> | the need for layout properties. Therefore margin and indent no longer
> | apply.
> |
> |
>

Received on Tuesday, 1 March 2005 02:54:00 UTC