- From: bulia byak <buliabyak@gmail.com>
- Date: Sat, 16 Apr 2005 06:49:30 -0300
- To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Cc: www-svg@w3.org
Jon, 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. In our opinion (I'm speaking for Inkscape developers) this was a sad decision overall. I agree that SVG must not go into _semantic_ markup of text, but it does need powerful _visual_ layout facilities simply because no other open standard covers this ground. Neither HTML+CSS and XSL-FO are quite appropriate for this, if only because neither of them allows for a chain of arbitrary linked text boxes or flowing text into an arbitrary shape. So it would be a severe disappointment for us if you decided to scrap this. > 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. I agree. > 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. Now, on the other hand, the way the new textArea reuses and extends the 1.1 text elements is a good thing. I always felt that having flowSpan and tspan as separate elements was pretty silly, if only because (as I wrote in my original question) this led to flowed text losing the kerning capabilities of 1.1 text. So I would be totally happy with textArea if only it can be made as powerful as flowRoot was. If, as I understand from your message, this is what you are planning to do for Full 1.2, you have my enthusiastic support. > (For Tiny 1.2, <textArea> is restricted to a rectangle, but we assume that > for Full 1.2 we will support arbitrary shapes.) Where can we see the Full 1.2 textArea specification draft with arbitrary shapes? Will it also support shape chaining and exclusion? Also, can you please confirm that dx/dy/rotate attributes on textArea children will have the same meaning as for 1.1 text? What about the x/y attributes? We already have a pretty complete implementation of flowRoot in Inkscape and we count on it as one of the major and most user-requested features in the next release. Reworking this code from using flowRoot to using textArea is OK so long as their capabilities are mostly the same. If however we'll have to remove some of the capabilites we already have it will be a pain. > 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". Well, since textArea has tBreak, this is a tolerable regression from our viewpoint. We don't really need semantic markup for paragraphs, we only need a way to lay the text out so that it looks (almost) like paragraphs, and for this, tBreak is (barely) adequate. > 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.) It is unfortunate that this has to be delayed. I agree that duplicating effort between different standards needs to be avoided, but this kind of situation is a fertile ground for incompatible implementations and custom extensions. If we had _now_ a detailed specification of the subsets of HTML/CSS and XSL-FO that can be used, along with examples and test cases of their embedding in SVG, this would help a lot. If this is being worked on, I just want to say that we support and encourage this effort. > 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. I'm not sure I agree with this reasoning, but since line-increment is a proper subset of line-height, we're OK with this implementation-wise. Thank you, -- bulia byak Inkscape. Draw Freely. http:://www.inkscape.org
Received on Saturday, 16 April 2005 09:49:33 UTC