Hans Aikema <hans.aik...@aikebah.net> writes: >> On 3 Dec 2016, at 13:52, Hans Aikema <hans.aik...@aikebah.net> wrote:
>>> I spotted a horrible output for a score I created for beamer in our >>> church service and upon futher inspection it appears caused by only >>> partial coloring of the score from black to white: some barlines / >>> stems were still in black and from the looks of it the ouline of >>> the Lyric font is consistently black (filling is white; in 2.19.49 >>> both appear to be white at first glance) >>> >>> For recoloring the score I use the following LSR snippet: >>> http://lsr.di.unimi.it/LSR/Item?id=443 >>> >>> I’ll try to compose a minimal example showing the erratice >>> behavior, but am curious if others are seeing the same. >> >> Tracked down the issue to be related to PNG alpha-transparency… The PNG >> alpha transparency no longer uses the actual color of the grobs, but black >> for generating the partially transparent pixels >> >> Modify the LSR snippet by adding >> >> #(ly:set-option 'pixmap-format "pngalpha") % set PNG background to use Alpha >> transparency >> >> and the partial transparent blue pixels will become partial transparent >> black pixels >> >> >> The modified LSR snippet showing the issue, using white, which makes the >> sympoms even clearer (as there should be no hint of darkness in a partially >> transparent white line): >> >> >> % PNG partially transparent pixels should be in grob-color (white) >> % but in 2.19.51 they are in black >> #(define (override-color-for-all-grobs color) >> (lambda (context) >> (let loop ((x all-grob-descriptions)) >> (if (not (null? x)) >> (let ((grob-name (caar x))) >> (ly:context-pushpop-property context grob-name 'color color) >> (loop (cdr x))))))) >> >> #(ly:set-option 'pixmap-format "pngalpha") % set PNG background to use Alpha >> transparency >> >> \relative c' { >> \applyContext #(override-color-for-all-grobs (x11-color ‘white)) >> c4\pp\< d e f >> \grace { g16[( a g fis]) } g1\ff\! >> } >> > > Did a validation on 2.19.50…. there it was still fine, so the issue > surfaced in between 2.19.50 and 2.19.51 releases. My gut-feel is that > this is an undetected side-effect of David Kastrups changes to > properly initialize with a pre-init as the other commits from there > message seem to me to be unrelated to the issue at hand. The pre-init stuff is very much concerned about the distinction between potential memory corruption and no memory corruption. If the patch is actually _responsible_ for the change, this is not a side-effect but a bug. My guess is rather that this is an error occuring semi-randomly and the pre-init changes, as something with a significant effect on allocation order, cause enough changes in allocation that they are more likely to make a difference for the trigger of such random errors than changes with less of an impact on object allocation. But if you are working with our binary distributions, I consider it most likely that a change in Gub is responsible: quite a bit in terms of font changes and Ghostscript were done recently. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond