Re: Fwd: Two questions on flowed text in 1.2

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