W3C home > Mailing lists > Public > www-svg@w3.org > August 2006

RE: SVG Tiny 1.2 is now a Candidate Recommendation

From: Andrew Emmons <aemmons@opentext.com>
Date: Tue, 22 Aug 2006 08:29:49 -0400
Message-ID: <BEF1FB69553AF14BBC63700F25699A1305CB452E@OTWATMX01.opentext.net>
To: "Maciej Stachowiak" <mjs@apple.com>, "Chris Lilley" <chris@w3.org>
Cc: <www-svg@w3.org>

Hello Maciej,

This is my personal opinion, and not necessarily that of the Working
Group, but it is my understanding that textArea is meant to be quite
different than any existing line-wrapping specifications. For Tiny, it's
a lightweight algorithm so that the whole CSS box model does not have to
be implemented on a mobile device. This addresses the needs we had for
Tiny, but it also scales to Full, where I believe powerful new features
will be added like wrapping within shapes.

All the best,

> On Aug 10, 2006, at 7:17 AM, Chris Lilley wrote:
> >
> > Formal Objections
> > =================
> >
> > 1. Maciej Stachowiak registered a Formal Objection on 22 March 2006
> >    regarding the provision of a text wrapping facility.
> >
> > SVG 1.1 already has a mechanism for text breaks (the tspan
> > element) but requires that the author choose the position of the
> > break in advance.
> >
> > For SVG which is generated automatically, or includes strings of
> > unknown length drawn from a database, or where the font to be
> > used is not known, it is desirable to allow the line break
> > positions to be calculated at display time. A common use case is
> > text callouts on a diagram, which must fit into a rectangle of a
> > given size and where part numbers etc. are drawn from a database.
> >
> > Given that this is a popular and much-requested feature, and
> > given that a critical mass of content authors and implementors
> > have stated that they want this feature, the SVG Working Group
> > declined to remove it, over the objection of Maciej
> > Stachowiak. However, the line wrapping requirements were softened
> > so that an existing engine (e.g., a CSS or XSL engine) could be
> > used to perform the wrapping and still be compliant to the SVG
> > specification. The Director agreed with the Working Group's
> > approach.
> I have implemented SVG text in a browser that supports HTML/CSS CDI,
> using the existing text layout engine. I disagree with the working
> group's assertion that an existing CSS text layout engine could be
> used to implement textArea. To cite two examples, the set of CSS
> properties that must or must not be respected when determining line
> height or line spacing is incompatible, and the whitespace processing
> model is incompatible.
> SVG text as currently designed is not at all well suited for
> implementation in an HTML/SVG compound document user agent, whatever
> the Director may think of the matter. I ask the SVG WG not to make
> misleading claims to the contrary.
> I would also like to note that I am not the only one who objected to
> inclusion of this facility. Others may not have used the magic words
> "Formal Objection", but they objected just the same. I ask the SVG WG
> not to imply that wrapped text was left in over my objection alone.
> Given the working group's relative disinterest in interoperability
> with HTML/CSS, and its willingness to repeatedly violate the W3C
> process with no explanation, I don't think it makes sense for vendors
> of browser-hosted implementations to continue to participate. Instead
> we should work out amongst ourselves what makes sense to implement in
> a web browser.
> Regards,
> Maciej
Received on Tuesday, 22 August 2006 12:30:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:14 UTC