i will reuse a lot of it for flowtext stuff, that's a given. the purpose of the SPTypeset object, though, was to be a testbed for flowtext stuff, and an object to which you would give marked-up text like LaTeX source or RTF and get a nice layout of it. this last part is a huge amount of work... i advise for a removal for simplification of the codebase, and to avoid confusions with SVG flowtext.

OK, that makes sense.

that is also a big amount of work, unless some parts of it can be lifted from a preexisting text editor. i feel sorry for the guy who will have to do it.

It's not really that bad, imho. I thought about how to do it, and I'm definitely willing to give it a try when I have more free time. Just a child of text-context holding the start and end character positions of the selection in the text object, and a list of canvas items, each being an inversion rectangle overlaying one character. The tricky part is how to make it so that when you choose a color (by whatever means) it gets applied to the text selection instead of the entire selected text object, but there is now a solution for that: desktop issues _style_signal for any style change, and the text selection would intercept that signal and apply the style to the text selection (creating tspan(s) as needed); and when the signal is intercepted, the style is not applied to the selected objects (see sp_desktop_set_style in desktop.cpp). So it's doable.

wrt mathematical markup, i was more thinking to stuff like indices/exponents: dx/dy give you the possibility to do either exponent or indices, not both. Not to mention the cases where you want the text to be stacked below some other piece of text. this is where latex shines. the simplest solution is probably to do some sort of "Equation Service" (http://www.esm.psu.edu/mac-tex/EquationService/) with the scripting possibilities of inkscape, and insert the complex stuff as images in the flowtext.

Yes, it would be cool. Just build a robust chain of tools to do TeX -> PS -> SVG conversion, and automatically run it and import into a <g> with an inkscape: attribute storing the source TeX code, with a command to edit it. Worth an RFE, and would not be very difficult to implement. Except that such "embedded TeX" will not be able to be part of an SVG text object, but only an independent object.

the problem on osx is having several trees with unix software cohabitating with each other. since i have a fink tree with all my gnome stuff, installing gtkmm2.4 and friends requires me to either package it myself (no thanks) or to mess with the install and header search paths (my previous attempts were complete failures). in any case it's simpler and safer to just wait for fink to get up to date.

I really hope they will get up to date soon. We need you :)

regarding my flowtext work, here is a patch made against the 0.39 release.

Thanks, I will apply it ASAP.

flowtref, flowlinebreak and flowimage are missing, but it's already able to eat styled text and handle bidirectionality. it would be good for me if someone could put it in the CVS tree and give it some exercise, so that bugs get apparent. since flowtext has the same text/tspan structure, parts of this patch can also have some use for the current text implementation.

Great, I will test it and report what I find.