bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is


From: David Kastrup
Subject: Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is broken)
Date: Sat, 03 Dec 2016 15:18:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Hans Aikema <address@hidden> writes:

>> On 3 Dec 2016, at 13:52, Hans Aikema <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]