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: Let wordwrap-field and justify-field take non-strings?

[Dan Eble]

On Dec 2, 2018, at 09:38, Thomas Morley  wrote:
> 
> Currently a formated markup will be dropped entirely without any warning, see:

My two cents: at some time in the past year, I was working on a mark performer, 
and I wanted a way to turn the markup for the mark into a MIDI-compatible 
string.  I believe I chose to call markup->string at the time, as that was the 
closest thing I could find.  I think to be really compatible with MIDI, the 
markup would need to be transformed into an ASCII approximation, so maybe it 
warrants a separate implementation.

I think there are probably similar issues with markup used for lyrics, but 
these things are no longer fresh in my mind.
— 
Dan

___
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: Let wordwrap-field and justify-field take non-strings?

[Thomas Morley]

Am So., 2. Dez. 2018 um 15:09 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Am So., 2. Dez. 2018 um 14:50 Uhr schrieb David Kastrup :
> >>
> >> Thomas Morley  writes:
> >>
> >> > Hi,
> >> >
> >> > still musing about improving markup->string, I now stumbled across
> >> > \wordwrap/justify-field.
> >> >
> >> > Both have a condition to return visible output only if the catched
> >> > input is a string (using 'wordwrap/justify-string-markup' then),
> >> > whereas \fromproperty accepts markup as well.
> >> > Is this intended?
> >> >
> >> > One could go for markup? as well and use simple 'wordwrap/justify-markup
> >> > or
> >> > One could do the condition as (not (string-null? (markup->string ...))).
> >> > (Currently markup->string will not return anything else than an empty
> >> > string, as said I'm working on improvements)
> >> >
> >> > Opinions?
> >>
> >> A string is structured by spaces and newlines, a markup list has already
> >> separated elements.  How would you naturally deal with single markups?
> >
> > That should become the duty of markup->string
> > Like:
> > single-markup = \markup \line \italic { Lorem ipsum dolor sit amet }
> > #(write (markup->string single-markup))
> > =>
> > "Lorem ipsum dolor sit amet"
>
> But then any markup formatting of the fields would get lost without
> warning?

Well, indeed. This could be a feature or it could be undesired. Thus I
asked for opinions.
If we want to keep the formating we could probably do the same as in
fromproperty.

Cheers,
  Harm

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

Re: Let wordwrap-field and justify-field take non-strings?

[Thomas Morley]

Am So., 2. Dez. 2018 um 15:36 Uhr schrieb Thomas Morley
:
>
> Am So., 2. Dez. 2018 um 15:09 Uhr schrieb David Kastrup :
> >
> > Thomas Morley  writes:
> >
> > > Am So., 2. Dez. 2018 um 14:50 Uhr schrieb David Kastrup :
> > >>
> > >> Thomas Morley  writes:
> > >>
> > >> > Hi,
> > >> >
> > >> > still musing about improving markup->string, I now stumbled across
> > >> > \wordwrap/justify-field.
> > >> >
> > >> > Both have a condition to return visible output only if the catched
> > >> > input is a string (using 'wordwrap/justify-string-markup' then),
> > >> > whereas \fromproperty accepts markup as well.
> > >> > Is this intended?
> > >> >
> > >> > One could go for markup? as well and use simple 
> > >> > 'wordwrap/justify-markup
> > >> > or
> > >> > One could do the condition as (not (string-null? (markup->string 
> > >> > ...))).
> > >> > (Currently markup->string will not return anything else than an empty
> > >> > string, as said I'm working on improvements)
> > >> >
> > >> > Opinions?
> > >>
> > >> A string is structured by spaces and newlines, a markup list has already
> > >> separated elements.  How would you naturally deal with single markups?
> > >
> > > That should become the duty of markup->string
> > > Like:
> > > single-markup = \markup \line \italic { Lorem ipsum dolor sit amet }
> > > #(write (markup->string single-markup))
> > > =>
> > > "Lorem ipsum dolor sit amet"
> >
> > But then any markup formatting of the fields would get lost without
> > warning?
>
> Well, indeed. This could be a feature or it could be undesired. Thus I
> asked for opinions.
> If we want to keep the formating we could probably do the same as in
> fromproperty.

Currently a formated markup will be dropped entirely without any warning, see:
\markup
  \override #`((foo . "Lorem") (buzz . ,#{ \markup \italic "ipsum" #}))
  \column {
  "from-property"
\fromproperty #'foo
\fromproperty #'buzz
"wordwrap-field"
\wordwrap-field #'foo
\wordwrap-field #'buzz
"justify-field"
\justify-field #'foo
\justify-field #'buzz
  }

Cheers,
  Harm

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

Re: Let wordwrap-field and justify-field take non-strings?

[David Kastrup]

Thomas Morley  writes:

> Am So., 2. Dez. 2018 um 14:50 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>>
>> > Hi,
>> >
>> > still musing about improving markup->string, I now stumbled across
>> > \wordwrap/justify-field.
>> >
>> > Both have a condition to return visible output only if the catched
>> > input is a string (using 'wordwrap/justify-string-markup' then),
>> > whereas \fromproperty accepts markup as well.
>> > Is this intended?
>> >
>> > One could go for markup? as well and use simple 'wordwrap/justify-markup
>> > or
>> > One could do the condition as (not (string-null? (markup->string ...))).
>> > (Currently markup->string will not return anything else than an empty
>> > string, as said I'm working on improvements)
>> >
>> > Opinions?
>>
>> A string is structured by spaces and newlines, a markup list has already
>> separated elements.  How would you naturally deal with single markups?
>
> That should become the duty of markup->string
> Like:
> single-markup = \markup \line \italic { Lorem ipsum dolor sit amet }
> #(write (markup->string single-markup))
> =>
> "Lorem ipsum dolor sit amet"

But then any markup formatting of the fields would get lost without
warning?

-- 
David Kastrup

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

Re: Let wordwrap-field and justify-field take non-strings?

[Thomas Morley]

Am So., 2. Dez. 2018 um 14:50 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > still musing about improving markup->string, I now stumbled across
> > \wordwrap/justify-field.
> >
> > Both have a condition to return visible output only if the catched
> > input is a string (using 'wordwrap/justify-string-markup' then),
> > whereas \fromproperty accepts markup as well.
> > Is this intended?
> >
> > One could go for markup? as well and use simple 'wordwrap/justify-markup
> > or
> > One could do the condition as (not (string-null? (markup->string ...))).
> > (Currently markup->string will not return anything else than an empty
> > string, as said I'm working on improvements)
> >
> > Opinions?
>
> A string is structured by spaces and newlines, a markup list has already
> separated elements.  How would you naturally deal with single markups?

That should become the duty of markup->string
Like:
single-markup = \markup \line \italic { Lorem ipsum dolor sit amet }
#(write (markup->string single-markup))
=>
"Lorem ipsum dolor sit amet"

Cheers,
  Harm

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

Re: Let wordwrap-field and justify-field take non-strings?

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> still musing about improving markup->string, I now stumbled across
> \wordwrap/justify-field.
>
> Both have a condition to return visible output only if the catched
> input is a string (using 'wordwrap/justify-string-markup' then),
> whereas \fromproperty accepts markup as well.
> Is this intended?
>
> One could go for markup? as well and use simple 'wordwrap/justify-markup
> or
> One could do the condition as (not (string-null? (markup->string ...))).
> (Currently markup->string will not return anything else than an empty
> string, as said I'm working on improvements)
>
> Opinions?

A string is structured by spaces and newlines, a markup list has already
separated elements.  How would you naturally deal with single markups?

-- 
David Kastrup

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

Let wordwrap-field and justify-field take non-strings?

[Thomas Morley]

Hi,

still musing about improving markup->string, I now stumbled across
\wordwrap/justify-field.

Both have a condition to return visible output only if the catched
input is a string (using 'wordwrap/justify-string-markup' then),
whereas \fromproperty accepts markup as well.
Is this intended?

One could go for markup? as well and use simple 'wordwrap/justify-markup
or
One could do the condition as (not (string-null? (markup->string ...))).
(Currently markup->string will not return anything else than an empty
string, as said I'm working on improvements)

Opinions?


Thanks,
  Harmt

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