Re: GSoC Proposal - SVG Export

[Étienne Beaulé]

To re-open this thread:

Sorry if I wasn’t clear enough about LY’s export formats. I thought I was clear 
with the distinction I drew between my terminology of « application » and « 
program » from my first message. Sadly Ghostscript has deprecated its SVG 
capabilities.

I was sadly unavailable last year for GSoC, but I have submitted my proposal 
for this year, with the addition of improving SVG WOFF through SMuFL.

I seem to recall another student post here with initiative for that part, and 
would be glad to work with them, or focus on how to get his work on the SVG 
backend.

Cordially,
Étienne

> Le 4 déc. 2018 à 09:39, Paul Morris  a écrit :
> 
> 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  tags with a color property, like so:
> 
> 
>   
> 
> 
> 
> Would probably be better if it did this instead:
> 
> 
> 
Precisely. I’ve already stated that: « […] In terms of colour, it currently 
wraps objects of a colour in a 

Re: GSoC Proposal - SVG Export

[Paul Morris]

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  tags with a color property, like so:


  



Would probably be better if it did this instead:




Cheers,
-Paul


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[David Kastrup]

Andrew Bernard  writes:

>> On Sat, 1 Dec 2018 at 14:39, Étienne Beaulé  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Urs Liska]

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é 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[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!

Andrew


On Sat, 1 Dec 2018 at 14:39, Étienne Beaulé 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Richard Shann]

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Carl Sorensen]

On 12/2/18, 1:30 PM, "Étienne Beaulé"  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Étienne Beaulé]

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  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Étienne Beaulé]

> Le 2 déc. 2018 à 11:25, Carl Sorensen  a écrit :
> 
> On 11/30/18, 8:40 PM, "lilypond-devel on behalf of Étienne Beaulé" 
>   on behalf of 
> beauleetien...@gmail.com > 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 `` 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Richard Shann]

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Carl Sorensen]

On 11/30/18, 8:40 PM, "lilypond-devel on behalf of É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

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 `` 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Carl Sorensen]

On 12/1/18, 9:21 PM, "É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. 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 https://lists.gnu.org/mailman/listinfo/lilypond-devel

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  Le 1 déc. 2018 à 23:07, Carl Sorensen  a écrit :
> 
> 
> 
> On 12/1/18, 1:22 AM, "lilypond-devel on behalf of Richard Shann" 
>  rich...@rshann.plus.com> 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 
>To:lilypond-devel@gnu.org
>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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Carl Sorensen]

On 12/1/18, 1:22 AM, "lilypond-devel on behalf of Richard Shann" 
 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 
To: lilypond-devel@gnu.org
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Urs Liska]

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 `` 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

[Richard Shann]

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 `` 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 
To: lilypond-devel@gnu.org
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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 `` 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel