flowed text has no SVG 1.1-compliant fallback

I have created a drawing with inkscape and saved it as
btoh inkscape's svn and plain svg.
The following applications show rendering errors with
both files:
- firefox-1.5 (native svg)
- firefox-1.5 with adobe 3.01 svg plugin
- gqview

Batik doesn't even open the files, presenting this error:
The current document is unable to create an element of
the requested type (namespace:
http://www.w3.org/2000/svg, name: flowRoot).

I'll attach the .svg file and a screenshot of
firefox-1.5 with the rendering error.

Firefox shows a big black box over the drawing, as does
gqview and the adobe plugin.

flowRoot is a feature which was proposed for the next
version of SVG, but is not actually in the current standard.
I thought Batik supported it in recent versions (although
they may have removed that support since the SVG working
group have reconsidered its use).

Anyway, use the Text|Convert to Text menu item to simulate
flowed text with normal text. You'll lose word-wrapping
during editing so be sure to keep a copy from before you do
this.

I tested this with batik-1.6.

The batik-1.6 samples directory does contain files with the
flowRoot feature, and batik opens them just fine (while
firefox shows the big black censored box over the drawing as
expected). But this same batik doesn't open the svg file
produced by inkscape.

Inkscape also opens the batik flowRoot file just fine (I'm
attaching that one here).

So:
a) firefox doesn't open svg with flowRoot
b) batik-1.6 doesn't open inkscape's svg which uses flowRoot
c) batik-1.6 does open another svg file which uses flowRoot
(attached)
d) inkscape does open batik's svg file which uses flowRoot

Seems (b) would be of concern.

Ah, looks like Batik are using an older version of the draft
spec which used the tag <flowText> for the root node of
flowed text. Inkscape will read both, but generates
<flowRoot>. This is the trouble with draft specs.

Pretty much all spec-level development with regards to
flowed text in Inkscape has halted because the SVG working
group are being indecisive about what it's finally going to
look like (they have decided that it's definitely not going
to be either flowText or flowRoot). We're all just waiting
to see what's going to happen, and in the interim you can
expect incompatibilities like this to be widespread.

The general rule of thumb is to have two copies of your
artwork. Have a master with all of your original editing
information. But also have a copy of the master where
everything is selected and the "Path/Convert to path"
command has been executed on it. <path> is universally
displayable, even on SVGTiny.

scribus doesn't import inkscape's plain svg files either,
have to use eps

I reported this bug previously, and proposed a solution that
would allow Inkscape to produce SVG files with flowed text
that still render correctly in other viewers.

But the developers claimed it wasn't a bug(!) and renamed it
and moved it over to the feature request list:

https://sourceforge.net/tracker/index.php?func=detail&aid=1294615&group_id=93438&atid=604309

Of course it's not a bug. It's an incompatible extension
that Inkscape uses, which ended up being incompatible mostly
through the disorganized actions of the W3C. And you do have
a well-documented way to replace this extension with
conformant SVG 1.1 code fully preserving the appearance (but
losing some of the editability): the Convert to Text
command. Please use it if you want to use your files outside
of Inkscape.

And if you need a compatible SVG-standardized flowtext
implementation, please direct your comments to W3C. We will
implement whatever they standardize and as soon as they
actually do it (i.e. as soon as 1.2 is final).

There may be actual bugs with the reported SVG version in
files with flowRoot (should be 1.2, or at least not 1.1), as
well as a room for improvements such as asking the user if
he/she wants to convert all flowtext to text on save, or
doing this conversion automatically based on the SVG version
specified. However, by itself this capability is not a "bug".

I propose to close this.

You implemented something that is not standardized yet, and
only inkscape can deal with it (not any other reference svg
implementation can do it). At least you could use another
file extension for inkscape files then, since it's the only
app able to open them. Like .ink or something.
Please, don't go down the "it's not a bug, it's a feature" road.

Filename extensions are not standardized nor authoritative.
They are just a hint. The only thing that matters is the
content of the file. And of course we _must_ mark up the
files as non-1.1 by providing a corresponding version
attribute on <svg>. This is the correct way of saying "this
file uses extensions", and all conformant renderers must
understand that. The only reason I'm not yet closing this
bug is because I suspect that this version setting currently
does not work, though I remember Mental implemented it some
time ago. Mental, can you please test it and comment?

Ok, I'm fine with that. BTW, the file I uploaded has
version="1.0" in it: not sure if this is what you meant.

Does "save as plain svg" result in eliminating flowText and
flowRoot elements? We advertise this option as resulting in
files that are maximally compatible, so as long as that is
behaving as advertised, I agree with bulia that this can be
closed.

It is inevitable as Inkscape development races forward, that
we are going to end up implementing stuff in the spec that
is not implemented by most other apps. That certainly can't
be considered a bug (at least, not an _inkscape_ bug). Our
mission is to be the best SVG editor around, which implies
we may end up being the first to implement certain SVG
features, such as has happened here.

Anyway, if it can be confirmed that flowRoot/flowText aren't
breaking "save as plain svg" from producing highly
compatible SVG, then I would encourage the submitter to
report the bugs as feature requests to the non-compliant
applications.

Knocking this down to a 6 because it doesn't cause data loss
or crashes, and because the interoperability issues sound
like they're due to incompleteness in other apps rather than
in inkscape.

As I said in my initial comment, saving as plain svg does
not help: inkscape is still the only app that can render the
resulting file.

Originator: NO

Flowed text (flowRoot and friends) must be moved to inkscape namespace,
placed into a foreignObject, and added a sibling svg:text which gives an
automatically updated text equivalent. All this is placed into svg:switch,
the way Adobe Illustrator does with its text. (I can share a sample.)

Fortunately we will have a student for this task. Since Gail is not yet
given SVN access, Richard, I'm assigning it to you as her mentor :)

Has Gail's work resulted in a fix for this issue?

Updated the affected projects. Many other programs cannot preview or view Inkscape generated SVG files with text.

I think this is not so hard to do if we keep the internal structure as it is, and translate from/to the form described by Bulia when reading/writing. While it's less than ideal to have the internal structure different from the written form, this is still much better than the current situation (and in the long run we will almost certainly need to change to 'textArea' once the SVG 1.2 spec is finalized, so anything we do now is just a temporary fix anyway).

We don't run Ubuntu, but I can confirm Nautilus is unable to correctly render Inkscape specific SVGs with flowed text in it (as at Nautilus 2.22.3, on Gentoo).

AfC

FAQ states that converting code for fixing flowedText is already in place under Text->Convert to Text. So for plain SVG export all that's left is enumeration of flowed text elements and converting them on save event. I wonder if this be scripted to get a quick fix?

I have attached a PNG output from Inkscape. This is what it should look like.

Hi,

I recently downloaded the 0.47 prerelease and tried to import an inkscape drawing using the Batik java library. I got the exception as described above and it turned out to be very simple to fix it. The image exported with inkscape still had the svg version attribute set to 1.0 while the flowRoot element used is a svg 1.2 specification. So Batik rejected the element and thus the image. By manually editing the contents of the svg file in notepad and changing the version to "1.2", I managed Batik to read the file and transform it to PNG. Hope this helps the bugfix.

So how should we resolve this issue?
Simply by putting inkscape namespace before any flowText?
Pls let me know. This is a task I can do.
I nominated this issue for the new release because of the number of affected systems.
Adib.

Commenting from the Inkscape tutorial by @joncruz at SVG Open this year - can this bug please be fixed before 0.47 is released? This would really enhance the interoperability of SVG files that Inkscape produces with all other viewers.

I realize that the history of the flowX elements is complicated and I'm not pointing fingers, I just want to have interoperable SVG and I believe this is the biggest blocking bug.

I think Comment #18 describes a possible quick solution. From my perspective, if "Text->Convert to Text" can just be run automatically every time the file is saved would that be acceptable from a user's perspective?

Another possibility is that we could update scour (http://launchpad.net/scour/) to try and convert flowXXXX elements into a series of text elements. The problem is that this is a non-trivial operation, will probably be destructive, and will not be easy to implement in scour.

Comment #11 seams to bring an good solution for interopability with software that stick at SVG1.1

But if tomorrow a patch that does "Text->Convert to Text" automatically for Plain SVG save is submitted, will it be accepted ?

When creating a SVG file with a flowRoot tag, the SVG version attribute needs to 1.2 not 1.0, this causes SVG libraries (in my case batik) to fail.

If adding a version 1.2 tag then the SVG must be at least be 1.2 as well.. otherwise this is a bug. I hope to see this fixed.

The SVG's in question were created using inkscape version: 0.46

Regards,
Matt

Just my two cents but ...

Please do not remove flowRoot support from the plain output format. Just set the version to 1.2 if there are flows ( or any other 1.2 feature for that matter).

A warning on the first save an option to convert would be fine, but I for one would prefer you just stick to the spec, draft or not, since thats the only real standard theres is to follow and I tend to use most of the 1.2 features regularly.

I'd rather not have to tell my graphics artists that even though I convinced them to give up using a very expensive piece of software because Inkscape had better SVG support that the few reasons that make that so are going away.

It should be noted that flowRoot, etc are not in the SVG 1.2 spec anymore either - these were elements in a draft state of the document and the document was later refactored.

As a result - _NO_ software will be implementing support for flowRoot, etc in the future. Inkscape should fix this to use either <textArea> (flowed text) or break into individual <text> and <tspan>s

> The next draft of SVG 1.2 Full will include a very similar features set as the previous drafts. There are some changes based on feedback from the public and the working group on both SVG 1.2 specifications. It should be noted changes to features now documented in SVG 1.2 Tiny will result in corresponding changes to SVG 1.2 Full. Notable changes to the feature set that readers can expect to see in the next draft include:

> * Replacement of the previous flowing text proposal with a superset of the SVG 1.2 Tiny textArea feature.

As this is a deprecated feature, the vector editors should indeed set the SVG version attribute to "1.2" and use textArea instead of flowText and flowRoot. Scour handles flowRoot and flowText by simply not touching them, and textArea the same.

What's the status of this?

As you can see, it's still confirmed. No one is currently working on this to the best of my knowledge.

I've attached an svg which uses flow text and should be good to test this bug. When tested against David's branch, it caused a segfault when Saving As and no visible effect on the web browser.

Post-LGM 2014 note:
Converting the flowtext representation to the form proposed for SVG 2 text would give us SVG 1.1-compliant fallback for free. Basically, <text> would have width, height and shape-inside attributes determining the flowregion, and tspans would have x/y attributes determining the glyph placement. In an SVG 1.1 compliant renderer, the x/y attributes would be used. In an SVG 2 renderer, the flowregion attributes would be used to compute the placement of text.

This is a Bug/Feature-Report from 2006
Now it is 2014

I just tried an SVG with flowtext (generated with Inkscape) in Safari, Firefox and Chrome on a Mac and it does not work.

I am sure your strategy is right from some developer point of view,

But from perspective of an ordinary user, this is absolute awfull !!
Just make it work in a reasonable way....
Maybe an option to convert to normal text element on save ....

Please make Inkscape smarter (especially on Mac) !!
The X interface is awful enough. These additional incompatibly features are horrible if someone seriously tries to use the tool.

I saw that Inkscape is connected to python...
Let the "Zen of Python" shine on Inkscape
>>> import this
....
Beautiful is better than ugly.
...
If the implementation is hard to explain, it's a bad idea.
...

Good to hear this bug is confirmed once again. Would really like the option to save to an SVG option in which flowtext is converted automatically so the svg can be viewed in Firefox, Chrome, Illustrator and so on. A save as option to be added to the save options so to speak.

A proper solution for this bug would be to simple remove all flowed text (which function already Inkscape has) on saving as "Plain SVG". There is no reason anymore to keep this "flowed text" feature on not proprietary SVG and bother such much people (for example all libRSVG user as on Wikimedia).

PS: libRSVG got a fix (after 10 years of bother) to not display black rectangles for "unknown" elements anymore.

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new
bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at
http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/337
Closed by: https://gitlab.com/tmr232

Correct me if I'm wrong, but I don't think it's correct to close a bug just because it has been reported upstream. It's still a bug - a confirmed one at that - and it's not resolved. The status in launchpad should reflect that, so that if a fix is detected upstream, the ubuntu devs are alerted to its existence.

"Upstream" is our new bug tracker on GitLab.

The Inkscape project does not use LaunchPad for bugtracking anymore.