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

RE: SVG Tiny 1.2 is now a Candidate Recommendation

From: Peter Sorotokin <psorotok@adobe.com>
Date: Tue, 22 Aug 2006 17:15:40 -0700
Message-ID: <40CE68F1F8CAFB48B998C328517EA92AE28A45@namail2.corp.adobe.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: <www-svg@w3.org>

> From: Maciej Stachowiak [mailto:mjs@apple.com] 
> Sent: Tuesday, August 22, 2006 4:51 PM
> To: Peter Sorotokin
> Cc: www-svg@w3.org
> Subject: Re: SVG Tiny 1.2 is now a Candidate Recommendation
>
> On Aug 22, 2006, at 4:04 PM, Peter Sorotokin wrote:
> 
> > 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?).
> 
> Great, is there any way I can try the code and see how well it works? 

Not yet, put hopefully it will be possible at some point.

> Or do you have stats on how much of the CSS 2.1 test suite it passes  
> or how well it works for real-world web browsing?

It certainly does not work for real-world browsing, being XHTML/CSS, not
"street HTML" engine. If it helps to convince you, I can run files and
send you back PNGs. There are certainly bugs in it, but I am absolutely
confident at this point that all inline layout issues can be resolved
without any redesign.

> 
> 
> 
> > 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.
> 
> I don't think the Working Group has made the claim that any of the  
> design decisions for textArea date back to SVG 1.0 or are meant to  
> align with XSL:FO. It would be pretty unusual to make this claim  
> since textArea is new in 1.2.

SVG had text since 1.0 and a lot of text properties were taken from
XSL:FO. We have to be compatible with existing SVG text, would not you
agree?

> 
> > [... snip ...] this does not necessarily tell us that combined  
> > engine is impossible
> 
> I would not claim it is impossible. I do think it is more complicated

> to implement, and more complicated conceptually for authors working  
> in both formats.

It is unfortunate that you chose to cut it at that particular point.
What I wrote was: "this does not necessarily tell us that combined
engine is impossible or even much harder to produce". In my experience,
it is not much harder. It is certainly much, much easier than to write
separate CSS and SVG engines (for instance, combined XSL:FO and CSS
engine would be far more complex to produce).

Peter

> 
> Regards,
> Maciej
>
Received on Wednesday, 23 August 2006 00:16:13 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:35 GMT