Maciej,
I have first-hand experience implementing both SVG text and CSS layout
model and I had no troubles building a combined engine that can do both
SVG and CSS text layout in the same module. (Text is a pain in general,
but SVG does not make it any more painful). Yes, the rules are slightly
different and that forces you to have some mark-up-specific logic
sometimes, but there are far more similarities than differences.
Line-height incompatibility by itself is actually not all that hard.
Whitespace handling is even simpler. In my opinion, vertical alignment
(and all baseline-related stuff) is much worse (and vertical alignment
affects line height calculation, so maybe that's where your troubles are
coming from?). But this particular conflict actually comes from the
differences between CSS2 and XSL:FO, not SVG itself, and, as far as I
remember, SVG 1.0 had no choice by to accept XSL:FO way of doing it,
because it addressed internationalization problems that CSS2 had in that
area. I bet as soon as you try to handle FO in your code, you'll get
into the same (if not worse) troubles.
Of course, I was writing text layout module from scratch, so it was much
easier for me to plan on handling both SVG and CSS from the start.
Taking existing HTML text engine and making it to handle SVG text may or
may not work out very well, but if it does not, this does not
necessarily tell us that combined engine is impossible or even much
harder to produce than HTML-only engine, as you seem to claim. At least
my experience is to the contrary.
Speaking for myself, not for the group here,
Peter
-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Maciej Stachowiak
Sent: Tuesday, August 22, 2006 2:30 PM
To: Andrew Emmons
Cc: Chris Lilley; www-svg@w3.org
Subject: Re: SVG Tiny 1.2 is now a Candidate Recommendation
On Aug 22, 2006, at 5:29 AM, Andrew Emmons wrote:
>
> 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.
Yes, and this has the result of creating two incompatible models for
wrapped text for SVG and CSS-styled text, with different but
overlapping sets of capabilities, which is precisely the point to
which I formally objected. Just to cite one of the many problems with
this plan, in an XHTML+SVG CDI user agent, you could have some text
that is marked up semantically, and some that is wrapped to a shape,
but none that does both. This seems clearly not in the AWWW spirit of
"orthogonal specifications", adds major complexity for implementors
of full-featured browsers (as opposed to SVG-only limited device
clients[*]), and a pain for authors by creating two incompatible
categories of wrapped text. However, the SVG WG and The Director
apparently do not see this as a problem.
Regards,
Maciej
* I think this is better terminology than "Desktop" and "Mobile Web",
now that more and more full-featured browsers that properly support
the existing web are available on mobile devices.