On Thu, 2016-06-09 at 13:23 +0200, David Kastrup wrote: > Richard Shann <rich...@rshann.plus.com> writes: > > > On Thu, 2016-06-09 at 12:57 +0200, David Kastrup wrote: > >> Werner LEMBERG <w...@gnu.org> writes: > >> > >> >>> >> However, there's still a nasty scaling bug that completely ruins > >> >>> >> text positioning at larger magnification values. Sigh. > >> >>> > > >> >>> > Is *this* a bug in librsvg, or another LilyPond output problem? > >> >>> > >> >>> It's definitely a bug in librsvg AFAICS, cf. > >> >>> > >> >>> https://phabricator.wikimedia.org/T65703 > >> >> > >> >> I see on this page that there is a mention of "Fixed in 2.40.13" > >> > > >> > I think this is only partially correct, cf. > >> > > >> > https://phabricator.wikimedia.org/T65703#1981688 > >> > > >> >> Do you happen to know if we could usefully upgrade Denemo to use > >> >> librsvg 2.40.13 (it always involves quite a bit of work upgrading > >> >> versions so I thought I'd ask first) > >> > > >> > Sorry, I can't help here. Regarding librsvg, I'm an ordinary user, > >> > not acquainted with SVG at all. > >> > >> Well, we are not in the market for SVG compliance testing. If there are > >> reasonably simple changes we can make to LilyPond in order to > >> avoid/sidestep triggering this librsvg bug, > > > > I don't know about *this* bug, but I did test out replacing currentColor > > with "black" (in quotes) in the LilyPond source code and it worked fine; > > that seems to me not only a simple but also a fairly sensible change. > > Except that it would make it impossible to draw in colors other than > black. That was the rationale for using currentColor in the first > place.
Oh, if that is the case then I'm misremembering - I thought I found that explicitly set colors over-rode the value currentColor (or "black" or whatever you put at that place in the code). Richard _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
