On Mon, Sep 21, 2009 at 04:35:58PM -0400, bulia byak wrote:
On Mon, Sep 21, 2009 at 4:24 PM, Richard Hughes <cyreve@...400...> wrote:
In any case, it seems very unlikely that any kind of fix is going to be suitable for 0.47.
That's too bad... but in any case, why don't we push them on this a little harder...
We have enough trouble with other SVG renderers doing basic things like coloured text, let alone language-sensitive soft-hyphen handling.
Librsvg and a Webkit-based browser I have do the same as current inkscape, while firefox 3.0 and batik svn render all soft hyphen characters the same as hyphen characters, even when they occur in the middle of a line.
Accordingly, I don't think we should encourage use of soft hyphens in SVG, and I think we should implement basic features like underlines before trying to implement behaviour that hasn't even been codified in any standard yet.
More important would be to facilitate nesting SVG inside of xhtml documents as supported by Firefox (and Amaya, I'm told).
To a lesser extent, it may be good to support xhtml foreignObject's inside SVG; though this isn't usually as good as SVG in a textual document, which is better at moving graphics around in response to changing text length.
(If it's useful, I can provide either a library to render (simple) XHTML to a cairo surface, or a program to take XHTML on stdin and write SVG on stdout.)
By delegating hyphenation to software designed for text rendering, we have more chance of getting good hyphenation not just in SVG documents (which pretty much never use body text, let alone hyphenation) but in text documents where hyphenation is more valuable. As has already been noted, hyphenation is difficult: both in choosing where hyphens may be placed (which itself is an unsolved problem for some languages), and in choosing how to render those hyphenations (choice of hyphen glyph if any, respelling), and in choosing line breaks to avoid hyphenating when possible. Hyphenation is usually used in the context of justification, and that too is difficult to do well. (Think kashidas, alternate glyphs, choosing the trade off between word spacing, glyph stretching, letter spacing, and at what point one should simply have space at the end of the line.)
pjrm.