Talk:Librsvg bugs

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Perhaps deleted image could be still linked so that sysops can view more test cases. --Nemo 10:42, 6 November 2010 (UTC)[reply]

New Bugs[edit]

"librsvg-ERROR **: _rsvg_acquire_xlink_href_resource called for external resource: " base: (null)"

This bug appears new to in the past already correct rendered images. One reason can be a missing or incorrect marker in <def> Another reason is a &quot; (as ' ) in CSS code by Inkscape bug. (I don't work with bugzilla, this bug is not mentioned there) --Perhelion (talk) 20:15, 12 January 2011 (UTC)[reply]

Bug 620923 is fixed[edit]

librsvg bug 620923 (Gnome bugzilla), the bug concerning bad rendering when leading zeroes are omitted in the d="" attribute of <path> elements, has been fixed as of commit 5ba4343bccc7e1765f38f87490b3d6a3a500fde1. 199.102.97.114 01:46, 10 November 2014 (UTC)[reply]

File:Provinzen kastilien.svg[edit]

@Sarang: I don't understand your last edit. It seems that File:Provinzen kastilien.svg shows the correct map?  — Johannes Kalliauer - Talk | Contributions 22:24, 9 December 2017 (UTC)[reply]

The old file had the bug. Thanks to User:Perhelion [1].  — Johannes Kalliauer - Talk | Contributions 08:23, 10 December 2017 (UTC)[reply]
@Perhelion: I rendered the old file of File:Provinzen kastilien.svg in svgcheck and in CommonsSvgChecker, and both show the map correctly, maybe the bug is fixed?  — Johannes Kalliauer - Talk | Contributions 08:39, 10 December 2017 (UTC)[reply]
Hello JoKalliauer, thanks for check. No the bug is rendering size depending. Concretely on this file below 200px and for sure at 120px (actual tested in both). -- User: Perhelion 11:22, 10 December 2017 (UTC)[reply]
Hello Perhelion, how can I render an old version in particular size?  — Johannes Kalliauer - Talk | Contributions 11:34, 10 December 2017 (UTC)[reply]
You can change the pixel-size in the URL manually. For the CommonsSvgChecker you need tweak the file with an viewBox. -- User: Perhelion 11:41, 10 December 2017 (UTC)[reply]
Thank you, it took me some time to find any url-link of any rendered archive-file (to be able to change the pixel-size) https://upload.wikimedia.org/wikipedia/commons/thumb/archive/e/ea/20100415112424%21Provinzen_kastilien.svg/120px-Provinzen_kastilien.svg.png That was exactly what I searched for. Thanks! I already searched for this function already some time ago [2].  — Johannes Kalliauer - Talk | Contributions 13:46, 10 December 2017 (UTC)[reply]

flowRoot[edit]

@Glrx, Perhelion, and Sarang: Should we explain flowRoot here? flowRoot is not really a librsvg-bug but it might be the most famous svg-bug, therefore it might make sence to quote flowRoot here, but say that it is more a inkscape-feature than a librsvg-bug (librsvg Should ignore unknown elements and all sub-elements).  — Johannes Kalliauer - Talk | Contributions

I mean not, maybe we can mention the section on COM:SVG. Anyway it should be to late, as it is fixed in the next version!? -- User: Perhelion 12:05, 28 October 2018 (UTC)[reply]
With COM:SVG you mean: c:Help:SVG#Black_rectangle_(Flowed_Text_bug) or something else?
Glrx removed it today that because it is not a librsvg-bug.
phab:T193352#4458789 When do you think that it is likely that cargo will be available for debian? (spring 2019?)
 — Johannes Kalliauer - Talk | Contributions 14:40, 28 October 2018 (UTC)[reply]
I do not understand the purpose of this gallery.
We do not need a monument to past librsvg bugs. If the bug has been fixed, then it is irrelevant. I would delete Librsvg bugs#Fixed bugs. If a bug has been fixed, then it is fixed.
I consider Inkscape's continued use of flowRoot to be an Inkscape-specific bug rather than a librsvg bug. Almost no user agents support flowRoot. The bug does not belong in a list specific to librsvg. Librsvg has issues, but suggesting flowRoot is a librsvg bug violates the pillars. We are not going to find reliable sources that say flowRoot is a librsvg bug.
When Gnome has fixed a bug, then it is no longer a librsvg bug but rather a MediaWiki bug for not incorporating the bug fix. It seems unfair to continue to lay the responsibility on librsvg. Yes, I'm aware of the conversion-to-Rust quagmire. I also fear that that MediaWiki will not be able to use the current version of librsvg. But fairness suggests we stop blaming librsvg for fixed bugs.
Keeping unusable files around when they can be easily fixed is a poor idea. File:Lötschberg Höhenprofil.svg can be turned into valid SVG 1.1 and used; we do not need a separate File:Lötschberg Höhenprofil-N.svg just to preserve a font shortcut property bug. Commons should be more about usable files and less about freezing files to show librsvg bugs. If there is a simple workaround, do the workaround and move on. Files that have more difficult issues, such as those using textPath, do need some sort of workaround.
This gallery is a poor way to educate users about librsvg and other issues. That should be done at Help:SVG, Commons:Commons SVG Checker, and similar articles. Those articles can have illustrations of issues such as librsvg bugs (e.g., small font size, vertical text, and BIDI), Inkscape bugs (e.g. black boxes / flowed text), and general compatibility (e.g., using font fallbacks). Those articles are where users expect the information.
For the reasons given above, I'd delete this entire gallery.
There is a benefit in categorizing files that have current uncorrectable librsvg issues. For example, File:Manfeild Autocourse track map (New Zealand).svg has the category Category:Pictures showing a librsvg bug:Inkscape. I'd like a better category (Category:Path text SVG), but the category system seems to be the better method than a gallery. Categories can be used to find the files that need fixes rather than a gallery highlighting a few examples.
Glrx (talk) 19:38, 28 October 2018 (UTC)[reply]
Hello Glrx, I can agree to remove solved bugs and merge some example images (but in fact this is unrated information lost).
The purpose of this gallery is to give clear and concrete as possible example images with descriptions, for which are categories never suitable. Maybe I could also agree with a merge to Help:SVG. The initial intention of Help:SVG was more general , not to show a bug gallery, but now it seems to evolved to it, there is now anything about SVG. Commons:Commons SVG Checker is a place for mentioning but not necessarily for an example gallery.
After a short consideration, I disagree to merge with Help:SVG, as here can be shown in general all bugs. Also minor bugs, which are not suitable as help for an adequate overview for new users. So I also disagree with the over-proportional embellishment of phab:T207506 there. In fact such minor bugs exists all along and appearing very rarely, except for some special users like us, for which this page should be. -- User: Perhelion 20:28, 28 October 2018 (UTC) -- User: Perhelion 20:46, 28 October 2018 (UTC)[reply]
(e/c)
@Perhelion: You have a very good point about Help:SVG needing to be more about SVG files and less about problematic implementation.
There should be some simple advice somewhere about typical problems. It would be nice if Commons SVG Checker recognized all the frequent problems (e.g., font size). Then the user need not interpret the advice.
Yes, rare issues should not bother average users at Help:SVG. Users can be pointed elsewhere for esoteric issues.
Maybe this gallery is a place for those esoteric or even all the bug explanations. Alternatively, this gallery can merge into the category system. The category text can describe the bug (possibly with illustration just as here), and then files detected with particular bugs can use the category/subcategory. The intent is when bug-xyz gets fixed, one can use the category to find the files to update.
Glrx (talk) 21:06, 28 October 2018 (UTC)[reply]

today's discussion about evaluation librsvg on Wikimedia[edit]

Today 15:00 (UTC) (i.e. in 4 hours) is a Discussion if Wikimedia should still use librsvg. The description can be found at phab:T283083. The discussion is held during the Hackaton an will take place in https://meet.jit.si/WMhack2021-Room1 . I hope to see you there.  — Johannes Kalliauer - Talk | Contributions 10:54, 22 May 2021 (UTC)[reply]

Vote for better SVG-Rendering[edit]

  1. meta:Community_Wishlist_Survey_2022/Multimedia_and_Commons/Improve_SVG_rendering till February,11th
  2. w:de:Wikipedia:Umfragen/Technische_Wünsche_2022_Themenschwerpunkte, till February, 6th (German)

 — Johannes Kalliauer - Talk | Contributions 17:39, 31 January 2022 (UTC)[reply]

SVG text rendering: probable bug[edit]

Tracked in Phabricator
Task T97233
Tracked in Phabricator
Task T265549

I've discovered what is apparently an inheritance-related bug, and have arrived at a work-around. The problem concerns

  1. attributes provided in group specifications <g___></g> causing <text> rendering errors
  2. <text> and <tspan> specifications being used together, causing <text> rendering errors

The work-around is to specify the attributes in each <text> specification and not depend on inheritance from <g___></g>, or to <tspan>.

More detailed discussions:

Thanks for any attention you can give to this problem. (Let me know if I should be posting this information directly on the Gallery page and not just this Talk Page.) RCraig09 (talk) 19:58, 11 July 2023 (UTC)[reply]

Thanks for your initiative, @RCraig09: it doesn't always work, though, such as in the 06:23, 16 June version of File:Punnett_square_colour_blindness.svg – note that the strings Xc behave as if text-anchor="start" is set in https://upload.wikimedia.org/wikipedia/commons/thumb/archive/e/e9/20230616063406!Punnett_square_colour_blindness.svg/400px-Punnett_square_colour_blindness.svg.png even though I've specified 
  <switch id="c" class="gamete" transform="translate(20,0)">
   <text x="0" y="0.7ex" text-anchor="middle" systemLanguage="ro"><tspan>X</tspan><tspan dx="-0.2ex" dy="-2ex" font-size="50%">D</tspan></text>
   <text x="0" y="0.7ex" text-anchor="middle"><tspan>X</tspan><tspan dx="-0.2ex" dy="-1ex" font-size="80%">c</tspan></text>
  </switch>
Cheers,
cmɢʟee ⋅τaʟκ 20:24, 11 July 2023 (UTC)[reply]
I'm not following the details of what you're saying, w:user_talk:cmglee, and... I know it's crude and time-consuming, but avoiding <tspan> elements altogether may be the only work-around until the apparent bug is fixed. Reciting "x" and the "c" in separate <text> specifications may be the only way, for the time being. RCraig09 (talk) 20:36, 11 July 2023 (UTC)[reply]

Inheritance is not the failure mechanism and wrapping g elements is not the fix.

One failure mechanism is librsvg 2.44.10 does not calculate the width of an SVG "text chunk" correctly. Instead of the whole width, it is using the width of the last constituent. Consider 

<text text-anchor="middle">
<tspan>AAAA</tspan>
<tspan x="0" y="10">BBBB</tspan>
<tspan x="0" y="20">CCCC</tspan>
</text>

The SVG text chunks "AAAA " and "BBBB " (notice trailing space on each) will appear left-aligned rather than centered. Each of them has a following #text node that consists of one space. The renderer believes the whole string is the width of that space; it moves the (x, y) position left one-half space and then paints the whole text chunk.

The workaround is to avoid spurious #text nodes on middle- and end-anchored tspan elements. 

<text text-anchor="middle"><tspan>AAAA</tspan><tspan x="0" y="10">BBBB</tspan><tspan x="0" y="20">CCCC</tspan></text>

I fixed manually

Glrx (talk) 07:01, 12 July 2023 (UTC)[reply]

Inconsistent PNGs of the same SVG can happen because WMF is/was running two versions of Thumbor: 6.3.2 and 7.3.2. It was potluck which you got. The earlier version did not have the problem and the later version does. Glrx (talk) 07:11, 12 July 2023 (UTC)[reply]
Thanks, User:Glrx, for responding. I'm having trouble understanding, because your two syntaxhighlight quotations are the same, except for hard returns. Essentially, are you saying the workaround is to use only successive <tspan> elements within a <text> specification? (I'm not following what a text "node" is.) Separately, your manual fix of this file substantially re-organized the Japanese & English <switch>... translations; are all such translations affected? (that would be very bad) RCraig09 (talk) 13:11, 12 July 2023 (UTC)[reply]
@RCraig09:
  1. The hard returns are the issue. They add #text nodes to the SVG document tree that are then interpreted as single spaces. A #text node is where ordinary strings are stored in an XML/SVG document; it is different from a <text> element.
  2. Yes, I substantially reorganized the climate change file. I undid the groupings; they frustrate SVG Translate. Also, separately positioned items should go into their own <text> elements. That puts separate countries into separate <text> elements and avoids the hard returns.
  3. In general, translations should be broken into small units rather than large groups of unrelated text.
Glrx (talk) 15:57, 12 July 2023 (UTC)[reply]
User:Glrx: I suppose I can cope with longer lines of code, though it's harder to read. More importantly, I guess that this means we have to clean up any file (or just some files?) when someone else uses the translate tool. RCraig09 (talk) 16:26, 12 July 2023 (UTC)[reply]
@RCraig09:
I do not see things as bad. librsvg should be fixed; when it is fixed, then these problems go away.
Independent of a fix, there are many SVG files that could be made simpler and cleaner. That effort may or may not be worthwhile.
However, making SVG files more complicated to work around a bug that should be fixed is not a good approach.
Glrx (talk) 01:50, 13 July 2023 (UTC)[reply]

I believe, I ran into this bug, too. Couple of times, but with variations:

  1. File:HoloceneTemperatureOfGreenland VintherEtAl2009-en.svg (see Commons:Help_desk#SVG-Plots:_Alignment_of_Labels_changed?), this was created with gnuplot 4.4 and hasn't changed since March 2019 and had always contained text-Elements with multiple tspan-Elements separated by returns. This used to be rendered correctly. But is not any more.
  2. File:OceanHeatContent_Cheng-de.svg, re-created with gnuplot 5.4 recently. No hard returns here. The problem were tspan-Elements to switch between fonts in the text element (see source below). After I'd removed the superscript in the y-axis label (i.e. 1022 → 10^22) the label was placed correctly.

Source for second example: 

	<g transform="translate(25.60,306.61) rotate(270)" stroke="none" fill="black" font-family="Liberation Sans" font-size="16.00"  text-anchor="middle">
		<text><tspan font-family="Liberation Sans" >Anomalie des Wärmeinhalts (10</tspan><tspan font-family="Liberation Sans"  font-size="12.8" dy="-8.00px">22</tspan><tspan font-family="Liberation Sans"  font-size="16.0" dy="8.00px"> J)</tspan></text>
	</g>
Third example: y-axis label used to be centered at 10, but is not any more when re-rendered

Issue T97233 indicates that this problem has been known for many years. But then I don't understand why the first image used to be rendered correctly, until recently. It is stated in this issue, that it's priority is low since cases "seem to be very rare". But I believe, many gnuplot-images will be affected as soon as they are re-rendered. To the right is a third example from 2014.

@Glrx: You seem to be knowledgeable: I don't have access to phabricator and don't want to give away my mailadress. If what I described is the same issue: Is there a way to upvote T97233? Do you know when it will be fixed, e.g. when librsvg 2.50.2 will be out? I surely don't won't to fix many gnuplot files manually after creation. But if this bug will be open for a long time, I don't know how else to work around it. --DeWikiMan (talk) 21:08, 8 August 2023 (UTC)[reply]

@DeWikiMan:
It is the same issue, and it has been around a long time. The makers of librsvg fixed the problem in both their old C language and their newer Rust language versions. Wikimedia Foundation was using the C version of librsvg, and WMF loaded the fixed C-language version to fix the buggy version that was preinstalled on Debian. That fix was done many years ago. Now is gets confusing. WMF has been running a very old version of the Debian Unix operating system — one that did not support Rust. WMF recently upgraded to a slightly newer version of Debian that comes preinstalled with the Rust version of librsvg. The problem is the "newer" version of Debian is not recent — it is still say 4 years old. The preinstalled version of librsvg is old enough that does not have the bug fix. That is why the SVG rendering regressed.
Someone has said it is an easy fix: all WMF has to do is install a newer version of librsvg just like they did in the old version of Debian. I thought that change would occur quickly. However, WMF developers have other tasks. They may be trying to upgrade to an even more recent version of Debian (which would fix the SVG rendering issue because it preinstalls a more recent version of librsvg.
Sorry, but I have no insight into WMF developer schedules.
Glrx (talk) 15:30, 9 August 2023 (UTC)[reply]
I see. Thanks for explaining, Glrx. Installing librsvg2-bin on my machine to check if V. 2.50 fixes the above problems took less than a minute … Oh well, I know this is an entirely different story in a production environment. But I'd expect, too, that it won't take many more months to fix. So I guess I will only do the most urgent fixes manually for now. --DeWikiMan (talk) 20:01, 9 August 2023 (UTC)[reply]
Test workaround.svg
This is a manual workaround using Unicode SUBSRCIPT TWO and Calibri as one of the few fonts that have the Unicode subscripts aligned below the baseline. --Rainald62 (talk) 09:43, 15 November 2023 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:Librsvg_bugs&oldid=821990560"