Ceci est une ancienne révision du document !
As promised last time, I’m going to continue describing the flowed text improvements in Inkscape v1.0. Previously, I showed you how to turn off the new SVG 2.0 flowed text implementation, in order to produce files that are compatible with Inkscape 0.92, but, unless you’ve got a specific reason for doing that, I strongly recommend sticking with the SVG 2.0 variety for compatibility with web browsers and future Inkscape releases. This time I’ll dig into the gory details of the new features, both from an Inkscape user’s perspective, and also with regard to the way flowed text appears in your SVG file.
First, some definitions: flowed text is the sort that will automatically wrap its lines to fill the available area. Usually that area is defined as a rectangle (though Inkscape can also flow text into arbitrary shapes), and the text will be rendered so that each line fills the width of the rectangle as fully as it can. Changing the dimensions of the rectangle causes the text to move around – to “flow” – in order to best fill the width. Ordinary (non-flowed) text refers to text objects that aren’t constrained inside a rectangle or other shape, and don’t flow to fill the space. Line breaks are explicitly entered, and have to be manually adjusted if you want the layout of the text to change. Whereas flowed text gives layout control to Inkscape, ordinary text keeps that control solely with the creator.
In earlier versions of the program, it was possible to create flowed text by dragging a rectangle with the Text tool selected, then typing your content into it. Ordinary text was created by just clicking on the canvas with the Text tool in order to position the text entry caret, and then typing. Those were your only two options: flowed or ordinary. With Inkscape v1.0, however, there are now two different varieties of flowed text to understand.
As with previous releases, you can click-drag to create a rectangular text box on the canvas when the Text tool is selected. Typing into this box will produce flowed text which, in practice, behaves the same way that flowed text did in earlier Inkscape releases, but with greater compatibility outside the program.
The image below shows a single piece of flowed text that was duplicated twice (and the text color changed). You can see that each container has a small diamond-shaped handle at the bottom-right corner: dragging this resizes the container and re-flows the text, as seen in the black and red text versions. The one with the blue text was achieved in the same way, but the handle was deliberately dragged such that the container size was too small for the text it needs to contain. You can see that Inkscape draws the container in red in this situation, as a visual indicator that the text has overflowed outside of the allowable space.
In this example, it’s pretty obvious that the text has overflowed the last container, but that’s not always the case. When dealing with large amounts of text in a bigger container, you may not notice that the border turns red when you add a word into the middle of the prose. The second flowed text type, referred to as “Column mode”, goes some way to addressing this possibility.
Column mode begins life as ordinary, non-flowed text. Just click on the canvas with the Text tool, and begin typing (or paste in some already written content). But, instead of beginning the tedious task of manually entering line breaks, look at the right-hand edge of the text box, where you’ll find a small diamond-shaped handle. Start dragging that handle and you’ll see a pair of vertical blue guides appear (representing the left and right edges of the “column”), and your text will be flowed to fit between them.
What’s important about this mode is that it sets the width of the flowed text, but doesn’t constrain the height. This has the advantage that you’ll never accidentally clip the end of your text with the flow container, but it also means that your text can flow to be taller than you intend, possibly leading to it interfering with other parts of your design. Where this type of flowed text comes into its own, therefore, is in loose designs where you want to tweak the column width dynamically to see what works best for your particular layout (think posters and leaflets), rather than designs which already have well defined areas of a specific height in which the text has to fit (such as magazines or newsletters).
Technical Details
With two different ways to create flowed text, let’s take a look at the technical details behind these new features. Feel free to skip this section if you just want to use them as an artist, and aren’t interested in what happens in the XML code.
The first thing to know about both of these approaches is that Inkscape adds an SVG 1.1 compatible fallback implementation when you save your file. This can potentially mean that Inkscape’s XML editor is a little misleading: look at it just after creating some flowed text, and you’ll see a different structure than if you’d saved it and re-loaded the file. Let’s start by looking at the structure that is used as soon as you create your content.
The click-drag type of flowed text consists of two parts: the text itself, and the rectangle that constrains it. The latter is created as a hidden object in the <defs> section of the XML, and is then referenced via the “shape-inside” CSS property, within the style attribute of the svg <text> element. In the image below, you can see the highlighted text on the right which references “rect98”, the ID of the rectangle near the top of the left-hand pane.
As you can also see on the left, the <text> element just contains a single <tspan> as a child, which contains the entire text string.
Column mode is fairly similar, but there’s no need to reference a hidden rectangle. Instead of the “shape-inside” CSS property, Inkscape inserts an “inline-size” property which defines the width of the column. Once again the text itself lives as a single line within a solitary <tspan> child element.
Unfortunately, both of these approaches are broken in web browsers today. Whilst the “inline-size” method is well supported in modern browsers, in my testing it appears to have an effect only on HTML content, and does not work for SVG files. The “shape-inside” CSS property, on the other hand, is not currently supported by any browsers. It is part of the CSS Shapes specification, but was dropped from Level 1 of the spec (the one the browsers have implemented), and moved to Level 2 (the one they haven’t, yet).
On the surface, therefore, it might seem that flowed text hasn’t really advanced much. We’ve gone from a non-standard, unsupported technique to a pair of nearly-standard, but still unsupported techniques. Yet, if you save a file with flowed text from Inkscape 1.0.x and load it into a browser, the text is visible – line breaks and all. So what’s going on?
You can see the reason for this apparent support if you examine the file via the browser’s developer tools, or if you load the same file back into Inkscape and look at the XML editor. At first all seems to be as expected: the <text> elements are present, with their corresponding “shape-inside” or “inline-size” properties, but when drilling further down to the text itself, we’re faced with a structure like this.
The single <tspan> element, containing the entire text, has been replaced with a separate <tspan> for each line in the resultant output – the same sort of structure you would expect to see if you had manually entered the line breaks. These elements are used for positioning each line, but then a second level of <tspans> is used to style the text. We’ve gone from a single child, one-level deep, to a collection of two-level children. This is the SVG 1.1 fallback content that allows the current batch of browsers to display the content as it appears in Inkscape.
This change of structure has repercussions. Because it produces the expected visible result in a browser, it will probably serve the needs of 99% of users. But it also changes the nature of the text. What was previously a single string is now broken into separate blocks: this could potentially have an effect on screen readers and search engines, depending on how they treat <tspan> elements. It would definitely have an effect on JavaScript programmers who want to dynamically find or change the text on the page, or had hoped to use code to alter the column width or rectangle size with the content flowing automatically to suit.
This does raise some questions about how these files will fare in the future. If browsers do start supporting “inline-size” on SVG text, or add support for CSS Shapes Level 2, how will they behave when faced with text that already has line-breaks? It’s possible that this could result in additional automatic line breaks being inserted which conflict with those that Inkscape has already provided, breaking the intended layout.
But these concerns are purely hypothetical at this point, whereas the problems with flowed text in v0.92 are very real. The changes in version 1.0 are a definite improvement, and make it an obvious choice if you wish to use flowed text in your designs. The details above really matter to only a minority of web developers, so shouldn’t prevent you making the switch.
If you really don’t want the SVG 1.1 fallback text included in your file, it can be turned off in the Preferences dialog (Input/Output > SVG Export pane). Note, however, that this will affect only newly created flowed text – any previously saved file that already contains multiple <tspan> elements will still maintain that structure.
Other Changes
There are a couple of other changes to mention regarding flowed text, though they’re relatively minor points.
One feature of 0.92 was the ability to convert flowed text into ordinary text via the Text > Convert to Text. This would “apply” the line-breaks by converting the content to a SVG 1.1 compatible <text> element with multiple <tspan> children. This no longer works in version 1.0, and has no effect on the structure of the XML. Saving the file will insert an SVG 1.1 compatible version of the text however (as discussed in the previous section), but it also inserts some CSS which will cause Inkscape to still treat such content as flowed.
Essentially if you actually want to convert from flowed text to fixed line breaks in a way that Inkscape will recognise, you have little choice but to manually insert the breaks, or to remove the new CSS from a saved file. As far as I can tell, this now makes the Convert to Text menu option completely redundant, as any attempt to use it simply puts a “No flowed text(s)” message in the status bar, and has no effect on the text or SVG structure.
Rather than fix the line breaks, what if you want to un-flow your words, to revert them to a single line of ordinary SVG text? In this case, the program is oddly contradictory as to the method you use. Version 0.92 offered the Text > Unflow menu option, which still works for click-drag style flowed text in version 1.0. It’s always had a nasty habit of moving the un-flowed text quite a distance from the original flowed version for some reason, so if you do use this, and your text seems to disappear entirely, try zooming out and panning around.
For reasons best known to the Inkscape developers, this approach doesn’t work for text that has been flowed via column mode. To revert this to a single line, you need to Ctrl-click on the diamond handle used for adjusting the column width. To further add to the confusion, this same technique does not work with the diamond handle at the bottom right of the rectangle used for click-drag style flowed text. Come on devs, how about a little consistency!?
The final change to mention is a small but important usability improvement. If you use the Text > Flow Into Frame option to flow text into multiple shapes on your canvas, the order in which the shapes are filled is now based on the order in which you select them. Previously it used the selection order in reverse, which is less than intuitive, so it’s good to see this change make its way into the program. It makes the behaviour more familiar to anyone who has ever used a desktop publishing program, such as Scribus – though I still maintain that Inkscape is a poor substitute for a real DTP application for anything but the most basic of page layouts.
Next time, we’ll conclude this part of the series by looking at the support that has been added for new font types in Inkscape v1.0.