Re: GSoC Proposal - SVG Export

[Étienne Beaulé]

Having glyph styling through CSS is one of the goals of this project. In the 
use of « currentColor, » it does seem to follow specifications. If an object 
does not have a colour associated with it, it should leave the colour to the 
viewer. However, the current SVG backend should be able to use CSS more 
effectively with classes and ids. In terms of colour, it currently wraps 
objects of a colour in a <g tag to change the current colour of sub-elements. 
Thus, there should be better use of SVG styling with some modifications on the 
use of currentColor (when it should be overwritten) but as a whole should 
remain.

Étienne

> Le 1 déc. 2018 à 23:07, Carl Sorensen <address@hidden> a écrit :
> 
> 
> 
> On 12/1/18, 1:22 AM, "lilypond-devel on behalf of Richard Shann" 
> <address@hidden on behalf of address@hidden> wrote:
> 
>    It is probably a very small thing, but it would be good if you could
>    improve the SVG output with regard to the use of "current color" which
>    Lily outputs as the default foreground color rather than black. There
>    was a plea recently for this:
>       
>    From:      d_l <address@hidden>
>    To:        address@hidden
>    Subject:   Request PATCH to ensure LilyPond SVG compatibility with
>    Scribus
>    Date:      Thu, 11 Oct 2018 06:56:34 -0700 (MST) (11/10/18 14:56:34)
> 
>    and others earlier. Denemo has to work around this quirk - the problem
>    being the "current color" is frequently white, the same as the
>    background...
> 
> I hope he will not change the use of current color in SVG.  That is exactly 
> according to the SVG spec.  The SVG viewer, not the SVG creator, is 
> responsible for setting current color in CSS, according to the spec that I 
> read. Thus, the color is inherited.  This means that LilyPond output plays 
> nice with CSS -- I can choose to set my website up with purple text if I want 
> to, and the music will be purple too.  Of course, if I want the music to be 
> black, I can do it just by changing the CSS -- no need to regenerate the SVG. 
>  In my opinion, this is how SVG should behave.
> 
> The problem should be fixed in the SVG viewer, IMO.  
> 
> Thanks,
> 
> Carl
> 
>