I just committed another exciting patch from Fred: support for flowing text!
http://www.w3.org/TR/SVG12/#flow
So far it's pretty much read-only, i.e. there's no UI yet for creating flow objects. But they are rendered already, and you can partially edit the envelope shape. Load share/examples/flowtext.svg from CVS, select the object, switch to node tool. and node-edit the envelope - the text will reflow into whatever shape you give it, preserving all the paragraph divisions and applied styles. Really exciting.
There are two flow shapes in that example; when the text does not fit entirely in the first one, the rest will go to the second shape (to the right). There's also an "excluded" shape in the middle that the text flows around. You can only edit the first shape so far. You also cannot yet edit the flowed text by text tool - this is yet to be done.
Note that this is a feature from SVG 1.2, which itself is not final yet and may change. This means that Batik or Adobe can't yet render that example. And yes, I know, we don't support all of 1.1 yet :) Now with Pango and this new patch, I hope to find time for rewriting the rest of the text system for the next version, to finally make it usable.
Nice to see!
I take it it's using the greedy algorithm from the draft spec?
Problems found so far:
- Bad bounding box calculation: see where the selection cue is. One result is that exporing as bitmap with size set to Drawing can result in truncation.
- In some cases when editing the curve, glyphs are getting too squashed together, e.g. overlapping each other by more than a stroke width. Could be a problem with "auto-kerning" having bad settings.
- When exporting to postscript using postscript operators, the fonts are broken: the roman text gets rendered in a typewriter font, and the arabic text is rendered in punctuation characters. Limited testing suggests that the problem doesn't occur with a plain text box.
(Test applied: Create a new document. Use the text tool to add the word `hello'. Close the file, open it in a text editor, copy the arabic from flowsample.svg to the hello document. Re-open in inkscape. Add a line break. Print, change printer to `>/tmp/hello.ps', view result with gv. Looks correct: roman text in a sans-serif font, arabic looking arabic.)
An example file showing these problems is at http://bowman.csse.monash.edu.au/~pmoulder/bad-kern/
pjrm.
- In some cases when editing the curve, glyphs are getting too squashed together, e.g. overlapping each other by more than a stroke width. Could be a problem with "auto-kerning" having bad settings.
Actually for this we must support two parameters: minimum and maximum allowed letterspacing, measured in % to the neutral letterspacing. If CSS does not support these (I'm pretty sure it does not), they are a prime candidate for including into inkscape:layoutOptions.
Two more problems illustrated by the attached file (compare http://www.w3.org/TR/SVG12/#textflow-example):
1 When going from one region to the next, the text must start filling the new region independently of the previous. Instead, Inkscape stretches long lines across all three regions as if they were one region.
2 Uncomment the flowSpan with Chinese text in the middle of the example. The flowRoot object does not show, but is selectable, and when you try to move it, it says "oversmall solution?"
- layout algorithms: 3 different algo are available through the layoutAlgo prop in the inkscape:LayoutOptions. The SVG greedy one is "default" and indeed is the default algo; "simple" is a finer greedy which stuff one line with text closest to the line length (ie it allows text to be compressed, which the SVG algo forbids); "better" is the knuth plass algo, like the one nathan implemented, and works at the paragraph level. - flowLine and flowRegionBreak are not yet implemented, so the tutorials should wait a bit (or make several flow elements) - (for bulia) selecting is a problem when "glyphs n to m" has to be matched with several intervals in the original text. - postcript output: the text element probably converts text to paths by default, which flowxtext does not (yet). the postcript output of text is rudimentary to say the least... i'm afraid ps files are not encoded in utf-8, so the current code cannot produce these glyphs - in the flow-go, all the path of the 'regions' are in the same flowRegion. i probably misread the spec, and understood "one flowReqion = one flow region" so this cannot work. for the current implementation, just put each path in a separate flowRegion. - since the chinese flowspan renders correctly here, i suppose it's a font problem again; "oversmall" means the code was able to make a word of text that has a zero length when rendered.
for gtkmm2.4, even though i have an unstable up to date fink tree here, it still show gtkmm2.2 as only solution (and the package page on fink.sourceforge.net does too). am i missing something? on the other hand, the boehm gc is present, just didn't notice it before
Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com
- layout algorithms: 3 different algo are available
through the layoutAlgo prop in the inkscape:LayoutOptions. The SVG greedy one is "default" and indeed is the default algo; "simple" is a finer greedy which stuff one line with text closest to the line length (ie it allows text to be compressed, which the SVG algo forbids); "better" is the knuth plass algo, like the one nathan implemented, and works at the paragraph level.
Fantastic! :)
- flowLine and flowRegionBreak are not yet
implemented, so the tutorials should wait a bit (or make several flow elements)
Actually for tutorials, these are not necessary, unless you want to place the entire text into one flow object. But generally, yes, these are needed, especially flowLine.
- (for bulia) selecting is a problem when "glyphs n to
m" has to be matched with several intervals in the original text.
Well, each single glyph is not broken across any intervals, right? So for selection, just return a list of coordinates or any other properties of the specified glyphs - these properties do not have to be continuous.
- postcript output: the text element probably converts
text to paths by default, which flowxtext does not (yet). the postcript output of text is rudimentary to say the least... i'm afraid ps files are not encoded in utf-8, so the current code cannot produce these glyphs
Yes, converting to paths is the best we can do for PS imho. PS is not supposed to be editable format anyway.
- in the flow-go, all the path of the 'regions' are in
the same flowRegion. i probably misread the spec, and understood "one flowReqion = one flow region" so this cannot work. for the current implementation, just put each path in a separate flowRegion.
Yes, you are right, sorry I did not check this more carefully (the consequences of relying on a draft spec - its example code does not match neither the rendition nor the spec itself!).
But I found another bug: the first word after a flowSpan is eaten and lost. The source has "styled differently</flowSpan> as well as" but Inkscape shows "styled differently well as" (see attached file).
- since the chinese flowspan renders correctly here, i
suppose it's a font problem again; "oversmall" means the code was able to make a word of text that has a zero length when rendered.
That is, my system probably misses the font. But then it should still show what it can show, the entire object disappearing is wrong.
for gtkmm2.4, even though i have an unstable up to date fink tree here, it still show gtkmm2.2 as only solution (and the package page on fink.sourceforge.net does too). am i missing something? on the other hand, the boehm gc is present, just didn't notice it before
Yes, http://fink.sourceforge.net/pdb/package.php/gtkmm2 shows 2.2 for both branches. Jon, can you contact them again to clarify this?
On Mon, Aug 02, 2004 at 08:57:44AM -0300, bulia byak wrote:
Yes, converting to paths is the best we can do for PS imho. PS is not supposed to be editable format anyway.
It's nice if txt2ps can work if by chance we can get this for free. We'd also get smaller postscript files. However, correct output is more important (in most cases).
pjrm.
participants (3)
-
bulia byak -
fred -
Peter Moulder