use <switch> to add <text> alternative to <flowRoot>

[Bug Importer]

Since <flowRoot> is not standard, Inkscape should put
it in a separate namespace, not in the SVG namespace,
otherwise the SVG files are non-conforming. And since
it affects rendering, it would be best to enclose it in
a <foreignObject> element and use a <switch> to provide
an alternative for viewers that don't understand it.

[Buliabyak-users (buliabyak-users)]

It is part of a draft of SVG 1.2. Lately the W3C seems to
have decided to change that part of 1.2 using different
element names and semantics. Until a new draft is available,
we will be using flowRoot. When the final spec is out, we
will switch to it. I don't think we need to remove flowRoot
into a different namespace, simply because svg:flowRoot is
documented at least in an obsolete W3C draft and has been
implemented by some other SVG software already, whereas
inkscape:flowRoot is not documented anywhere.

For guaranteed rendering, convert flowed text to path or to
text before saving.

[Bug Importer (bug-importer)]

bulia byak writes:

> When the final spec is out, we will switch to it.

But it could be years before the final SVG 1.2 spec is out.
Inkscape should not continue to write non-conforming SVG
until that time.

> I don't think we need to remove flowRoot into a different
> namespace, simply because svg:flowRoot is documented at
> least in an obsolete W3C draft

Lots of strange things are documented in obsolete W3C
drafts. The drafts are provided for information and to get
feedback from the public. They should not be used as an
excuse for producing non-conforming SVG in end-user
applications.

> and has been implemented by some other SVG software already,
> whereas inkscape:flowRoot is not documented anywhere.

But if you use the <switch> like I suggested then it will
render correctly in those applications anyway, and will also
render correctly in the far more numberous applications that
haven't implemented <flowRoot>.

> For guaranteed rendering, convert flowed text to path or
> to text before saving.

But users won't know that they need to do that - no warning
of any kind is produced to tell the user that the SVG file
that has been written is non-conforming, and that there is a
way to make it conforming. Besides, converting the flowed
text means that Inkscape can no longer edit the text as
flowed text. In effect (though most users won't know it) the
user has to choose between non-conforming SVG and non-flowed
text. If you do as I suggested, they would always get
conforming SVG and Inkscape would still be able to edit the
text as flowed text.

[Richard Hughes (cyreve)]

I agree with Bulia that the svg namespace is the least worst
place for flowRoot to be. The main purpose of namespaces
is to prevent tags invented by disparate teams from
conflicting when they are in the same document. Since
flowRoot was designated by the w3c SVG working group,
they know of it and understand that it would be a bad idea to
create a future tag with the same name but different
semantics. Furthermore, we know approximately what
flowtext is going to look like in the future due to the SVG Tiny
work, and it doesn't conflict with our use of flowRoot. Finally,
Batik (the closest thing there is to an official w3c SVG
viewer) supports svg:flowRoot since 1.6.

However, your suggestion to use switch sounds like a good
idea, so I would propose that this bug is moved onto the
feature tracker and renamed.

[Buliabyak-users (buliabyak-users)]

Agree with Cyreve, moving over & renaming