Re: Fwd: Two questions on flowed text in 1.2

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