GNOME Bugzilla – Bug 525023
Text rendered at the wrong position
Last modified: 2017-12-13 17:32:21 UTC
In the attached svg all text is rendered with an x position of about 0 which is wrong. The y position seems to be ok. The svg was exported from open office draw (2.3.0). Other svg capable programs (e.g. Inkscape or XEP) can render it correctly.
Created attachment 108238 [details] the svg with the text rendering problems
Created attachment 108239 [details] the ooo-draw source of the svg
I confirm this important bug for librsvg version 2.22.2-2 on Debian testing (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502502 for more details of my system). I have just finished debugging the SVG device for PLplot, and it produces SVG-1.1 results that validate at http://validator.w3.org/check and which view fine (i.e. have perfect text positioning and good graphics) on firefox and konqueror. I also have reports that inkscape and karbon14 imports these files with no problems. The same reporter says the latest stable release of scribus imports them fine but with text that is misplaced by various small amounts. However, along with that second-hand report came the information that scribus has a much improved svg import facility in their svn version. Therefore, I built the most recent svn snapshot of scribus-ng, and that imports PLplot SVG results with exact text positioning and good graphics just like viewed by firefox and konqueror. So the conclusion is that the PLplot SVG results are a high-quality set of validated SVG files that are rendered correctly by most viewers and SVG editors. The rsvg-viewer application is an exception to these good results. The PLplot SVG results are displayed with a variety of small but annoying shifts to the text positions. The original reporter has given you one complex case, and I have plenty of those as well, but to help you debug this librsvg issue, I will shortly attach a simple svg file example consisting of a long vertical line, a horizontal line marking the exact midpoint of that line, and the text string "HHHHHHH" written parallel to the long vertical line and centred on its midpoint using the text-anchor="middle" attribute for the text tag. If you view that SVG file with firefox or konqueror, the "HHHHHHH" string is centred perfectly. But not so for rsvg-view which shows a text shift of about a third of a character. If you hand-edit the file to change "HHHHHHH" to "H" the result is centred perfectly for all viewers (including rsvg-view). A change from 7 identical characters to 1 should not change the position of the middle of the string so this is clear evidence independent of all other viewers that there is an important text positioning bug in librsvg. Once you have a fix for this simple example, I would be glad to check how well the fix works for all my many complex cases as well.
Created attachment 120797 [details] Simple test case SVG file which shows mispositioning of text in rsvg-view
http://bugs.debian.org/500725 might be the same issue as well.
Created attachment 121249 [details] Another SVG picture with text rendered at an incorrect position
Comment on attachment 120797 [details] Simple test case SVG file which shows mispositioning of text in rsvg-view correct mime type
Any news of his bug? Regards Bastien
This is a clear and obvious bug in librsvg that affects all viewing of SVG results both within GNOME and also for some non-GNOME applications (e.g., the Image Magick display application) that use librsvg. The bug has been reported for more than 9 months now, but as far as I know the GNOME developers are unaware of it because it has not even been triaged yet (STATUS is still UNCONFIRMED). So in this case the bug triaging process is getting in the way of fixing this bug. If you know any GNOME developers personally, it would be good to let them know about this bad situation.
librsvg doesn't have any developers. And since its primary purpose (as far as most gnome developers are concerned) is to render icons without any text in them, this bug isn't considered to be hugely important to them. Image Magick has its own SVG code. It doesn't use librsvg. I welcome any patches that fix this and other librsvg bugs. I welcome you to encourage other developers to take over librsvg's reigns. But please - quit the drama queen spiel. It's not helping...
On my Debian testing box, ImageMagick has two svg modes. The default one depends on librsvg to render. As a result, the "display" application gives exactly the same bad text positioning results as eog or rsvg-view. There is also an experimental ImageMagick SVG mode (which produces results even worse than librsvg). You may have access to a different version of ImageMagick that only has access to the experimental version of SVG support, but do not assume that is the case for everybody. I was concerned that no GNOME developer had even heard of this bug because of its status which indicates nobody has triaged it yet so I don't think you should be taking offense at my concern. I am definitely glad to hear that you (as the only official developer of librsvg mentioned at http://bugzilla.gnome.org/browse.cgi?product=librsvg) are aware of this bug despite its untriaged status. I have given you a really simple SVG example above which illustrates the problem if you want to fix librsvg. Others have given you examples as well. OTOH if you have no interest in fixing librsvg, shouldn't you change the status of librsvg to unmaintained and remove yourself as the official developer? Perhaps that move would inspire someone else with more interest to take over. I have no interest in doing that myself, but librsvg is widely used so I am pretty sure somebody will step forward if that library becomes officially unmaintained.
Any news ??? regards
I have heard nothing, and I also would be interested in any news about this bug.
Created attachment 158343 [details] [review] Fix for attachment 120797 [details] This patch fixes only attachment 12097 [details] [review], no effect on other images since those images have different issues.
attachment 120797 [details] is a same type image of bug 581108.
(In reply to comment #15) > attachment 120797 [details] is a same type image of bug 581108. Sorry, I meant attachment 121249 [details].
attachment 120797 [details] is a same type image of bug 524690. :-p
(In reply to comment #6 by Josselin Mouette) > Created an attachment (id=121249) [details] > Another SVG picture with text rendered at an incorrect position This is an instance of bug #624158 which I just filed. That bug doesn't cover all the examples given here, though, so it's a more special case.
This is an instance of bug 666477. That bug doesn't cover all the examples given here, which are all fixed (with the exception of the first) All in all this bug report here is very unclear I propose to close this as fixed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/18.