GSoC Proposal - SVG Export

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC Proposal - SVG Export

Étienne Beaulé
Hello all!

I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I am also the maintainer of the MediaWiki Score extension which allows embedded LilyPond on Wikipedia. I’m currently a bachelor student at the Université de Montréal studying computer science and mathematics, and Google Summer of Code caught my eye. I’d be interested in doing a project if a mentor is available.

# Improving SVG score output

## Summary

Scalable Vector Graphics (SVG) is a vector graphics format designed for use on the internet. LilyPond (LY) is a program which translates musical notation syntax into a graphics format, such as SVG. This format is important for web publishing, and as a vector format, is advantageous over Portable Network Graphics (PNG) file, of which is _de facto_ used in this application.

LY already has SVG output, yet is somewhat broken in many factors. Namely in font handling with broken sky-lining #3778 and the use of musical symbols as text. Development in fixing these problems may offer changes in other backends. This project will focus on the use of musical symbols in SVG files and the positioning of text. I have previously submitted patches for text-positioning bugs.

## Deliverables

* Self-contained musical SVG files
* Functioning text sky-lining in SVG
* Grouping of text for better placement in SVG

## Timeline

_This is the hard part… Non-comprehensive_

* Analysis of incompatibilities between PostScript (PS) and SVG output
  Important to have a grip on this to not introduce bugs and to keep commonalities between backends
* Deprecation of SVG fonts - embed font into SVG

— —

* Reduce size of SVG by enumerating used glyphs
* Merge glyph functions for text and symbols

— —

* Implement use of `<tspan>` tags and Cascading Style Sheets (CSS) for text handling
  * Will require modification of PS backends
  * Fix Horizontal Spacing of text
* Fix SVG text sky-lining in conjunction with character size / spacing calculations

Thoughts?

Étienne
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Werner LEMBERG

> I’m Étienne Beaulé and I’ve been making some changes to LilyPond.  I
> am also the maintainer of the MediaWiki Score extension which allows
> embedded LilyPond on Wikipedia.  I’m currently a bachelor student at
> the Université de Montréal studying computer science and
> mathematics, and Google Summer of Code caught my eye.  I’d be
> interested in doing a project if a mentor is available.

Nice idea!  I can certainly mentor the font side of your project.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Richard Shann-2
In reply to this post by Étienne Beaulé
On Fri, 2018-11-30 at 22:39 -0500, Étienne Beaulé wrote:

> Hello all!
>
> I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I
> am also the maintainer of the MediaWiki Score extension which allows
> embedded LilyPond on Wikipedia. I’m currently a bachelor student at
> the Université de Montréal studying computer science and mathematics,
> and Google Summer of Code caught my eye. I’d be interested in doing a
> project if a mentor is available.
>
> # Improving SVG score output
>
> ## Summary
>
> Scalable Vector Graphics (SVG) is a vector graphics format designed
> for use on the internet. LilyPond (LY) is a program which translates
> musical notation syntax into a graphics format, such as SVG. This
> format is important for web publishing, and as a vector format, is
> advantageous over Portable Network Graphics (PNG) file, of which is
> _de facto_ used in this application.
>
> LY already has SVG output, yet is somewhat broken in many factors.
> Namely in font handling with broken sky-lining #3778 and the use of
> musical symbols as text. Development in fixing these problems may
> offer changes in other backends. This project will focus on the use
> of musical symbols in SVG files and the positioning of text. I have
> previously submitted patches for text-positioning bugs.
>
> ## Deliverables
>
> * Self-contained musical SVG files
> * Functioning text sky-lining in SVG
> * Grouping of text for better placement in SVG
>
> ## Timeline
>
> _This is the hard part… Non-comprehensive_
>
> * Analysis of incompatibilities between PostScript (PS) and SVG
> output
>   Important to have a grip on this to not introduce bugs and to keep
> commonalities between backends
> * Deprecation of SVG fonts - embed font into SVG
>
> — —
>
> * Reduce size of SVG by enumerating used glyphs
> * Merge glyph functions for text and symbols
>
> — —
>
> * Implement use of `<tspan>` tags and Cascading Style Sheets (CSS)
> for text handling
>   * Will require modification of PS backends
>   * Fix Horizontal Spacing of text
> * Fix SVG text sky-lining in conjunction with character size /
> spacing calculations
>
> Thoughts?
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 <[hidden email]>
To: [hidden email]
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...

Richard


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Urs Liska-3
In reply to this post by Étienne Beaulé
Hello Étienne,

I too think this would be a very promising proposal, and if it would get
closer to an actual application I will surely have some more thoughts on
it too.

Right now it is of course premature to discuss because not even the
*organization* application period has started. So as every year we can't
say yet whether there actually will be LilyPond at GSoC 2019. But as
every year we are quite confident it will work out.

Best
Urs

Am 01.12.18 um 04:39 schrieb Étienne Beaulé:

> Hello all!
>
> I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I am also the maintainer of the MediaWiki Score extension which allows embedded LilyPond on Wikipedia. I’m currently a bachelor student at the Université de Montréal studying computer science and mathematics, and Google Summer of Code caught my eye. I’d be interested in doing a project if a mentor is available.
>
> # Improving SVG score output
>
> ## Summary
>
> Scalable Vector Graphics (SVG) is a vector graphics format designed for use on the internet. LilyPond (LY) is a program which translates musical notation syntax into a graphics format, such as SVG. This format is important for web publishing, and as a vector format, is advantageous over Portable Network Graphics (PNG) file, of which is _de facto_ used in this application.
>
> LY already has SVG output, yet is somewhat broken in many factors. Namely in font handling with broken sky-lining #3778 and the use of musical symbols as text. Development in fixing these problems may offer changes in other backends. This project will focus on the use of musical symbols in SVG files and the positioning of text. I have previously submitted patches for text-positioning bugs.
>
> ## Deliverables
>
> * Self-contained musical SVG files
> * Functioning text sky-lining in SVG
> * Grouping of text for better placement in SVG
>
> ## Timeline
>
> _This is the hard part… Non-comprehensive_
>
> * Analysis of incompatibilities between PostScript (PS) and SVG output
>    Important to have a grip on this to not introduce bugs and to keep commonalities between backends
> * Deprecation of SVG fonts - embed font into SVG
>
> — —
>
> * Reduce size of SVG by enumerating used glyphs
> * Merge glyph functions for text and symbols
>
> — —
>
> * Implement use of `<tspan>` tags and Cascading Style Sheets (CSS) for text handling
>    * Will require modification of PS backends
>    * Fix Horizontal Spacing of text
> * Fix SVG text sky-lining in conjunction with character size / spacing calculations
>
> Thoughts?
>
> Étienne
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Carl Sorensen-3
In reply to this post by Richard Shann-2


On 12/1/18, 1:22 AM, "lilypond-devel on behalf of Richard Shann" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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 <[hidden email]>
    To: [hidden email]
    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
 

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> a écrit :
>
>
>
> On 12/1/18, 1:22 AM, "lilypond-devel on behalf of Richard Shann" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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 <[hidden email]>
>    To: [hidden email]
>    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
>
>


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Carl Sorensen-3


On 12/1/18, 9:21 PM, "Étienne Beaulé" <[hidden email]> wrote:

    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.


Carl adds:

This sounds good to me.

Thanks,

Carl

 

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Carl Sorensen-3
In reply to this post by Étienne Beaulé
On 11/30/18, 8:40 PM, "lilypond-devel on behalf of Étienne Beaulé" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> wrote:

    Hello all!
   
    I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I am also the maintainer of the MediaWiki Score extension which allows embedded LilyPond on Wikipedia. I’m currently a bachelor student at the Université de Montréal studying computer science and mathematics, and Google Summer of Code caught my eye. I’d be interested in doing a project if a mentor is available.
   
    # Improving SVG score output

I think this is a great idea!
   
    ## Summary
   
    Scalable Vector Graphics (SVG) is a vector graphics format designed for use on the internet. LilyPond (LY) is a program which translates musical notation syntax into a graphics format, such as SVG. This format is important for web publishing, and as a vector format, is advantageous over Portable Network Graphics (PNG) file, of which is _de facto_ used in this application.

PNG is only used for snippets.  The real _de facto_ output of LilyPond is ps/pdf.  I would hate to lose that.
   
    LY already has SVG output, yet is somewhat broken in many factors. Namely in font handling with broken sky-lining #3778 and the use of musical symbols as text. Development in fixing these problems may offer changes in other backends. This project will focus on the use of musical symbols in SVG files and the positioning of text. I have previously submitted patches for text-positioning bugs.

I think this sounds like a great idea!
   
    ## Deliverables
   
    * Self-contained musical SVG files
    * Functioning text sky-lining in SVG
    * Grouping of text for better placement in SVG
   
    ## Timeline
   
    _This is the hard part… Non-comprehensive_
   
    * Analysis of incompatibilities between PostScript (PS) and SVG output
      Important to have a grip on this to not introduce bugs and to keep commonalities between backends
    * Deprecation of SVG fonts - embed font into SVG
   
    — —
   
    * Reduce size of SVG by enumerating used glyphs
    * Merge glyph functions for text and symbols
   
    — —
   
    * Implement use of `<tspan>` tags and Cascading Style Sheets (CSS) for text handling
      * Will require modification of PS backends

This causes me concern.  In general, I think the PS backend works well, and I would prefer not to have it changed to be consistent with some functionality that only affects the SVG backend.  But until I see more concrete proposals, I don't know whether I would be in favor of or opposed to the PS backend modifications.

      * Fix Horizontal Spacing of text
    * Fix SVG text sky-lining in conjunction with character size / spacing calculations

This is great!

I think that I would like to continue to have LilyPond use Pango.  I don't know how Pango would integrate with SVG, but I think that's the right approach.  I would not be in favor of creating and maintaining our own text spacing engine.

Thanks,

Carl
 

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Richard Shann-2
In reply to this post by Étienne Beaulé
On Sat, 2018-12-01 at 23:21 -0500, Étienne Beaulé wrote:
> Having glyph styling through CSS is one of the goals of this project.
> In the use of « currentColor, » it does seem to follow
> specifications.

Hmm, these specs would seem to allow the SVG to be rendered onto a
background of the same color as currentColor - in my case I use the GDK
Pixbuf library to render the SVG and it seems to choose currentColor to
be white - I can't see any reference in the documentation to changing
this. I don't know what the other people raising this issue were using,
but there seems to be quite a widespread problem...

Richard

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Étienne Beaulé
In reply to this post by Carl Sorensen-3


> Le 2 déc. 2018 à 11:25, Carl Sorensen <[hidden email]> a écrit :
>
> On 11/30/18, 8:40 PM, "lilypond-devel on behalf of Étienne Beaulé" <lilypond-devel-bounces+c_sorensen=[hidden email] <mailto:lilypond-devel-bounces+c_sorensen=[hidden email]> on behalf of [hidden email] <mailto:[hidden email]>> wrote:
>
>    Hello all!
>
>    I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I am also the maintainer of the MediaWiki Score extension which allows embedded LilyPond on Wikipedia. I’m currently a bachelor student at the Université de Montréal studying computer science and mathematics, and Google Summer of Code caught my eye. I’d be interested in doing a project if a mentor is available.
>
>    # Improving SVG score output
>
> I think this is a great idea!
>
>    ## Summary
>
>    Scalable Vector Graphics (SVG) is a vector graphics format designed for use on the internet. LilyPond (LY) is a program which translates musical notation syntax into a graphics format, such as SVG. This format is important for web publishing, and as a vector format, is advantageous over Portable Network Graphics (PNG) file, of which is _de facto_ used in this application.
>
> PNG is only used for snippets.  The real _de facto_ output of LilyPond is ps/pdf.  I would hate to lose that.
Of course I am not advocating to remove any functionality of LY. I am saying that when embedding LY in webpages, PNG is used (in the manuals, etc.), while SVG would be superior.

>
>    LY already has SVG output, yet is somewhat broken in many factors. Namely in font handling with broken sky-lining #3778 and the use of musical symbols as text. Development in fixing these problems may offer changes in other backends. This project will focus on the use of musical symbols in SVG files and the positioning of text. I have previously submitted patches for text-positioning bugs.
>
> I think this sounds like a great idea!
>
>    ## Deliverables
>
>    * Self-contained musical SVG files
>    * Functioning text sky-lining in SVG
>    * Grouping of text for better placement in SVG
I should also add a line about adding a suite of tests of SVG output (like done with PS) to visualize changes.

>
>    ## Timeline
>
>    _This is the hard part… Non-comprehensive_
>
>    * Analysis of incompatibilities between PostScript (PS) and SVG output
>      Important to have a grip on this to not introduce bugs and to keep commonalities between backends
>    * Deprecation of SVG fonts - embed font into SVG
>
>    — —
>
>    * Reduce size of SVG by enumerating used glyphs
>    * Merge glyph functions for text and symbols
>
>    — —
>
>    * Implement use of `<tspan>` tags and Cascading Style Sheets (CSS) for text handling
>      * Will require modification of PS backends
>
> This causes me concern.  In general, I think the PS backend works well, and I would prefer not to have it changed to be consistent with some functionality that only affects the SVG backend.  But until I see more concrete proposals, I don't know whether I would be in favor of or opposed to the PS backend modifications.
Changes to other backends may not be necessary, but I think it is important to keep a high level of abstraction between these various backends to keep the output generation generalizable before choosing a specific format.
>
>      * Fix Horizontal Spacing of text
>    * Fix SVG text sky-lining in conjunction with character size / spacing calculations
>
> This is great!
>
> I think that I would like to continue to have LilyPond use Pango.  I don't know how Pango would integrate with SVG, but I think that's the right approach.  I would not be in favor of creating and maintaining our own text spacing engine.
I hope Pango integrates well with SVG, don’t know (yet). Creating our own text-spacing engine would be out-of-scope and a massive undertaking… We are in agreement here.
>
> Thanks,
>
> Carl

Étienne
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Étienne Beaulé
In reply to this post by Richard Shann-2
That is more of a problem with Pixbuf (similar problem was fixed in librsvg). However, a case could be made to specify black for glyphs instead of currentColor, and I would be open to it (leaning against it though)

However, changing its use in LilyPond is non-trivial (if we wanted to do it), as the use of currentColor allows for colours to be changed in response to LY syntax.

Étienne

> Le 2 déc. 2018 à 11:35, Richard Shann <[hidden email]> a écrit :
>
> On Sat, 2018-12-01 at 23:21 -0500, Étienne Beaulé wrote:
>> Having glyph styling through CSS is one of the goals of this project.
>> In the use of « currentColor, » it does seem to follow
>> specifications.
>
> Hmm, these specs would seem to allow the SVG to be rendered onto a
> background of the same color as currentColor - in my case I use the GDK
> Pixbuf library to render the SVG and it seems to choose currentColor to
> be white - I can't see any reference in the documentation to changing
> this. I don't know what the other people raising this issue were using,
> but there seems to be quite a widespread problem...
>
> Richard


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Carl Sorensen-3


On 12/2/18, 1:30 PM, "Étienne Beaulé" <[hidden email]> wrote:

    That is more of a problem with Pixbuf (similar problem was fixed in librsvg). However, a case could be made to specify black for glyphs instead of currentColor, and I would be open to it (leaning against it though)
   
    However, changing its use in LilyPond is non-trivial (if we wanted to do it), as the use of currentColor allows for colours to be changed in response to LY syntax.

We used to have black be the color of the glyphs.  We made a very specific and intentional move from black to currentColor.  And it was an improvement, IMO.  That is why I feel strongly about moving away from currentColor.

Thanks,

Carl
 

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Paul Morris
Hi Carl and everyone,

On 12/2/18 8:02 PM, Carl Sorensen wrote:

> We used to have black be the color of the glyphs.  We made a very specific and intentional move from black to currentColor.  And it was an improvement, IMO.  That is why I feel strongly about moving away from currentColor.

currentColor sounds like the right default.  It also seems reasonable to
allow the user to override that default and set it to black or another
color, depending on their use case.  Maybe that's already possible? 
Maybe it's even already possible from the command line?  If not, giving
users the option should address the concerns, and would make sense in
this kind of GSOC proposal.

Étienne, I really like your proposal.  I'd love to see improvements to
SVG, moving towards giving it first-class support in LilyPond.  And
kudos for planning ahead.

Cheers,
-Paul


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Richard Shann-2
On Mon, 2018-12-03 at 09:22 -0500, Paul Morris wrote:

> Hi Carl and everyone,
>
> On 12/2/18 8:02 PM, Carl Sorensen wrote:
>
> > We used to have black be the color of the glyphs.  We made a very
> > specific and intentional move from black to currentColor.  And it
> > was an improvement, IMO.  That is why I feel strongly about moving
> > away from currentColor.
>
> currentColor sounds like the right default.
what seems strange is that there seems to be no concept of "backgound
color" in SVG (logical in a way as SVG is about things you can draw)
allowing for the possibility of drawing white on white.
>   It also seems reasonable to 
> allow the user to override that default and set it to black or
> another 
> color, depending on their use case.  Maybe that's already possible?  
yes, you add stuff to the LilyPond input to color everything explicitly
black. IIRC you can specify extra stuff to be included from the command
line too.

Richard


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Andrew Bernard
In reply to this post by Étienne Beaulé
Hi  Étienne ,

The default is PDF, not PNG.

I applaud your desire to improve the SVG output, but do get the premise
right. Thanks!

Andrew


On Sat, 1 Dec 2018 at 14:39, Étienne Beaulé <[hidden email]>
wrote:

>
> Scalable Vector Graphics (SVG) is a vector graphics format designed for
> use on the internet. LilyPond (LY) is a program which translates musical
> notation syntax into a graphics format, such as SVG. This format is
> important for web publishing, and as a vector format, is advantageous over
> Portable Network Graphics (PNG) file, of which is _de facto_ used in this
> application.
>
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Urs Liska-3

Am 04.12.18 um 11:56 schrieb Andrew Bernard:
> Hi  Étienne ,
>
> The default is PDF, not PNG.
>
> I applaud your desire to improve the SVG output, but do get the premise
> right. Thanks!


Étienne has already clarified this. I assume it's that with "this
application" he was not refering to LilyPond as an application but "web
display" as a use case.

Urs


> Andrew
>
>
> On Sat, 1 Dec 2018 at 14:39, Étienne Beaulé <[hidden email]>
> wrote:
>
>> Scalable Vector Graphics (SVG) is a vector graphics format designed for
>> use on the internet. LilyPond (LY) is a program which translates musical
>> notation syntax into a graphics format, such as SVG. This format is
>> important for web publishing, and as a vector format, is advantageous over
>> Portable Network Graphics (PNG) file, of which is _de facto_ used in this
>> application.
>>
>>
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

David Kastrup
In reply to this post by Andrew Bernard
Andrew Bernard <[hidden email]> writes:

>> On Sat, 1 Dec 2018 at 14:39, Étienne Beaulé <[hidden email]> wrote:
>>
>>>
>>> Scalable Vector Graphics (SVG) is a vector graphics format designed
>>> for use on the internet. LilyPond (LY) is a program which translates
>>> musical notation syntax into a graphics format, such as SVG. This
>>> format is important for web publishing, and as a vector format, is
>>> advantageous over Portable Network Graphics (PNG) file, of which is
>>> _de facto_ used in this application.
>>>
>
> Hi  Étienne ,
>
> The default is PDF, not PNG.

LilyPond itself does not output PDF or any raster graphics format but
PostScript and uses Ghostscript to convert from there.  SVG is almost
unusual in that LilyPond has a "native" backend producing SVG without
using Ghostscript.

> I applaud your desire to improve the SVG output, but do get the
> premise right. Thanks!

Or at least get the premise to look superficially right.  Saves a lot of
discussion.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Proposal - SVG Export

Paul Morris
In reply to this post by Richard Shann-2
On 12/3/18 10:07 AM, Richard Shann wrote:

> what seems strange is that there seems to be no concept of "backgound
> color" in SVG (logical in a way as SVG is about things you can draw)
> allowing for the possibility of drawing white on white.


Easily setting a background color would be a nice option to have. 
There's this snippet, and it works for SVG (but there's room for
improvement):

http://lsr.di.unimi.it/LSR/Item?id=699


> yes, you add stuff to the LilyPond input to color everything explicitly
> black. IIRC you can specify extra stuff to be included from the command
> line too.


Ah, right, like this: http://lsr.di.unimi.it/LSR/Item?id=443

That wraps everything in <g> tags with a color property, like so:

<g color="rgb(0%, 0%, 100%)">
   <rect fill="currentColor" />
</g>


Would probably be better if it did this instead:

<rect fill="rgb(0%, 0%, 100%)" />


Cheers,
-Paul


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel