- 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?
