GNOME Bugzilla – Bug 624158
coalesced text breaks order
Last modified: 2010-07-12 19:40:37 UTC
Created attachment 165723 [details] Example exposing the issue If a <text> or <tspan> element contains both <tspan> children and #PCDATA children, then all the #PCDATA content will be rendered at the position of the first #PCDATA node. See the attached example, which should render "abc" but renders "acb" instead, because the "a" and the "c" are coalesced. I believe that this issue was introduced by http://git.gnome.org/browse/librsvg/commit/?id=0acabfc0becefdf7c349a80b67c652613d0252bf (svn r1150) in an attempt to solve some Pango issue. I don't know what kind of issue, as I couldn't find a reference to the bug this was supposed to fix. Attachment #121249 [details] from bug #525023 comment #6 is broken for the same reason. That bug report seems to be more generic than this one here, though, as it has example images not addressed here. So perhaps you want to mark that bug depending on this one here, and fix this one here with the limited scope it has.
Created attachment 165724 [details] [review] Cautious fix This fix addressed the problem by avoiding coalescing with a CHARS node if there is a tspan node after it. I'm not sure if this is the ideal patch, or if dropping this whole coalescing thing would be better. I assume that librsvg with this patch is better than without it, but even there I'd need more info on the original Pango issue behind this coalescing idea to know if I'm correct.
Going through adjacent git commit messages, I might have found a discussion of the original issue that lead to the code in question: http://thread.gmane.org/gmane.comp.lib.cairo/12852/focus=2728 Unfortunately the example images linked to at the beginning of that thread aren't available any more, so I can't see whether my patch will introduce a regression in that case, and whether removing all that coalescing code might be feasible.
Thanks for the patch. But this issue has already opened as another bug. Please attach your patch there. *** This bug has been marked as a duplicate of bug 581108 ***