My take on hyphenation:
- It absolutely needs to be a core feature (because then we can add other nice things like fit text to frame), and it's a high priority one since it's very useful for scientific posters. This "market" is more important than it looks since it is often the first exposure to vector drawing apps for college students, and thus a valuable entry point.
- We should use libhyphen instead of creating our own library, and use OO.o hyphenation patterns that are installed on the system - in the same way we use Aspell. For Windows we can make them downloadable at install if they are big (though it will require some NSIS wizardry).
- It could be a vector effect in theory, but in practice it shouldn't be more complicated than a checkbox option in the text tool that defaults to "on"
- At the XML level, we should insert soft hyphens only at line ends, instead of everywhere a break is possible. We can recover the original text by removing all soft hyphens. (This might conflict with custom hyphenation though.) While rendering, we feed Pango with a string that has the soft hyphens replaced with normal ones for the time being.
- Language selection: there should be a context menu item that lets you select the language for the given text or a set of them, and a document-wide default for new texts, which in turn defaults to LANG. I think it's sufficient to provide object-level granularity using xml:lang - higher granularity would require XML and UI kludges. Asking email clients and browsers about language information is totally wrong, because hyphenation is supposed to be an edit-only feature: the SVG contains information about whether the text is hyphenated or not, a 'rendering' of hyphenated text, and maybe the original unhyphenated text (but we should try to avoid that extra copy of minimally altered text).
- XHTML foreign objects in SVG: bad idea. We wander into browser-land and it would destroy our compatibility with e.g. librsvg, which will never handle such things.
Regards, Krzysztof