- From: Chris Lilley <chris@w3.org>
- Date: Sun, 17 Apr 2005 01:49:50 +0200
- To: bulia byak <buliabyak@gmail.com>
- Cc: Jon Ferraiolo <jon.ferraiolo@adobe.com>, www-svg@w3.org
On Saturday, April 16, 2005, 11:49:30 AM, bulia wrote: bb> Jon, bb> Thank you for a detailed response. >> After lots of feedback from the community on SVG 1.2 (Full) and its flowing >> text features. There was considerable strong feedback that SVG 1.2 was going >> too far down the road towards defining a text layout facility which >> overlapped with HTML+CSS or XSL-FO. bb> In our opinion (I'm speaking for Inkscape developers) this was a sad bb> decision overall. I agree that SVG must not go into _semantic_ markup bb> of text, but it does need powerful _visual_ layout facilities simply bb> because no other open standard covers this ground. This is an important distinction and one I agree with. bb> Neither HTML+CSS bb> and XSL-FO are quite appropriate for this, if only because neither of bb> them allows for a chain of arbitrary linked text boxes or flowing text bb> into an arbitrary shape. Yes. bb> So it would be a severe disappointment for us if you decided to bb> scrap this. Thanks for the feedback. It would be sad for us, too. We don't plan to, but we do plan to address the concerns of confusion with the slightly higher level semantics of xhtml on the one hand, and the need to allow more language-aware line wrapping on the other hand. The recently released SVG Tiny addesses those points, but its Tiny so the facilities are limited. For Full, you can expect to see the graphical richness too. >> SVG text wrapping had >> special requirements, such as text in an arbitrary shape, which is something >> that CSS and XSL-FO box models could not address. bb> I agree. And we intend to continue to allow this which, as you say, is lacking from other, less graphically-oriented specifications. >> The feedback caused the SVG Working Group to reconsider its approach to >> flowing text and as a result scaled back its flowing text features in a way >> that can be thought of as a simple extension of SVG 1.1's <text> element and >> which is conceptually parallel to SVG 1.1's <textPath> facility. bb> Now, on the other hand, the way the new textArea reuses and extends bb> the 1.1 text elements is a good thing. I always felt that having bb> flowSpan and tspan as separate elements was pretty silly, if only bb> because (as I wrote in my original question) this led to flowed text bb> losing the kerning capabilities of 1.1 text. So I would be totally bb> happy with textArea if only it can be made as powerful as flowRoot bb> was. If, as I understand from your message, this is what you are bb> planning to do for Full 1.2, you have my enthusiastic support. It is, and we are glad of the support. Perhaps it should be clear that "this feature is great and we plan to use/implement it" feedback is just as useful as "this feature is broken/hard to implement/whatever" type feedback. especially from implementors and content creatots. >> (For Tiny 1.2, <textArea> is restricted to a rectangle, but we assume that >> for Full 1.2 we will support arbitrary shapes.) bb> Where can we see the Full 1.2 textArea specification draft with bb> arbitrary shapes? Next release. The specification released with Tiny http://www.w3.org/TR/2005/WD-SVG12-20050413/ is just a placeholder in case people got worried that Full 1.2 had gone away. It hasn't, but editing work over the last few months has focused on Tiny. bb> Will it also support shape chaining and exclusion? We would expect so, yes. bb> Also, can you please confirm that dx/dy/rotate attributes on textArea bb> children will have the same meaning as for 1.1 text? What about the bb> x/y attributes? These were removed from Tiny 1.2 but are expected to be in Full 1.2 the sae as they were in Full 1.1. bb> We already have a pretty complete implementation of flowRoot in bb> Inkscape Excellent! (and sorry for making you change it). bb> and we count on it as one of the major and most bb> user-requested features in the next release. Yes, from the point of view of the SVG WG this was one of the most requested features as well. bb> Reworking this code from using flowRoot to using textArea is OK so bb> long as their capabilities are mostly the same. If however we'll bb> have to remove some of the capabilites we already have it will be a bb> pain. Understand. >> A key simplification for <textArea> versus the previous proposal >> (which used <flowRoot> or <flowText> in the previous drafts of SVG >> Full 1.2) is that we have removed the notion of block-level-like >> things such as "paragraphs". bb> Well, since textArea has tBreak, this is a tolerable regression from bb> our viewpoint. We don't really need semantic markup for paragraphs, we bb> only need a way to lay the text out so that it looks (almost) like bb> paragraphs, and for this, tBreak is (barely) adequate. So in other words, you need different sorts of breaks, one for 'next line' type breaks and one for 'next paragraph' type ones. This should be possible just by styling the line-increment differently on them (eg using classes and style rules, or formatting attributes, or a style attribute.) >> Our thinking is that if you really want a box >> model, then put HTML+CSS inside of an svg:foreignObject. (Not available >> today, but we expect the Compound Document Formats activity to enable that >> sometime in the not-too-distant future.) bb> It is unfortunate that this has to be delayed. I agree that bb> duplicating effort between different standards needs to be avoided, bb> but this kind of situation is a fertile ground for incompatible bb> implementations and custom extensions. Yes, I understand this. bb> If we had _now_ a detailed bb> specification of the subsets of HTML/CSS and XSL-FO that can be used, bb> along with examples and test cases of their embedding in SVG, this bb> would help a lot. If this is being worked on, I just want to say that bb> we support and encourage this effort. Conceptually, SVG allows you to embed any thing in a foreignObject. Thats what its for. Its an extensibility point. Other 'integrational' profiles, such as those developed by the CDF working group, are likely to constrain what can go there (as you say, picking a subset of XHTML or of XSL FO) >> In recognition that authors might want to control the distance between the >> baseline for line <n> and line <n+1>, we included a 'line-increment' >> property. We had a choice between subsetting and adapting 'line-height' or >> defining something much simpler and new, and felt it was better to define >> something new. bb> I'm not sure I agree with this reasoning, but since line-increment is bb> a proper subset of line-height, we're OK with this bb> implementation-wise. Many thanks for the detailed feedback, it is very helpful. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
Received on Saturday, 16 April 2005 23:49:54 UTC