Re: Can we refactor output-svg.scm to avoid regexp?

[Étienne Beaulé]

Svg-woff is not only broken with that old bug, but also that SVG fonts are 
deprecated. The hope is that the work on SMUFL done this summer could be used 
in the SVG backend, and with that, embedding musical symbols directly could be 
avoided to reduce regex use.

Étienne

> Le 28 oct. 2020 à 22:27, K.L.  a écrit :
> 
> Hello guys.
> 
> I ran a profiling for SVG backend engraving, I saw the most time cost
> (95%+) is taken by regexp execution.
> 
> It seems the usage of regexps in output-svg.scm is to extract vector font
> content fragments from font svg assets. Can we refactor this work by an XML
> parser, maybe in C++?
> 
> I saw there is another alternate option, svg-woff. But I encountered the
> scm error:
> 
>> output-svg.scm:448:16: Unbound variable: paper
>> 
> 
> It seems an unresolved old bug for some years after googling it.
> 
> This may be the biggest performance bottleneck of SVG backend at present,
> once fixed, we will get huge improvement.
> 
> Any ideas?
> 
> [image: image.png]
> [image: image.png]
> 

Re: LilyPond disabled on Wikimedia

[Étienne Beaulé]

Hello, I’m the maintainer of the Score extension.

There is also https://nvd.nist.gov/vuln/detail/CVE-2020-17353 
 which affects LilyPond 
through PostScript code injection. We’ve also done a security audit. I’ve CC’d 
Tim Starling who performed the audit to this thread, and he’s be in a better 
position to responsibly disclose problems.

We hope to get LilyPond back on the Wikis, and that vulnerabilities get fixed 
well for a safer LilyPond!

Étienne

> Le 15 oct. 2020 à 19:05, Carl Sorensen  a écrit :
> 
> Unfortunately, there's not enough information on that thread to understand 
> what the issues are.
> 
> I know that in the past there have been significant security concerns which 
> had a core concern related to Guile programming, since Guile is a 
> turing-complete language.
> 
> I don't know how we can contribute until we are made aware of the challenges 
> here.
> 
> Carl
> 
> 
> On 10/15/20, 4:14 PM, "lilypond-devel on behalf of Daniel Benjamin Miller" 
>  dbmil...@dbmiller.org> wrote:
> 
> Not of direct relevance to us as end users, but can someone shed light 
> on this and/or resolve the concern of the Wikimedia people? In the 
> meantime Lilypond support has been disabled on Wikipedia. 
> https://phabricator.wikimedia.org/T257066
> 
> 
> 

Re: [trial] current status

[Étienne Beaulé]

A little consideration to take in account is how comments are numbered in tasks 
in Sourceforge. If they are directly imported, the comment numbers will become 
task links and would spam the tasks with those numbers.

Étienne

> Le 3 mai 2020 à 08:00, Jonas Hahnfeld  a écrit :
> 
> Hi all,
> 
> for those not following very closely, a few updates for GitLab:
> 1) We now have access over https://gitlab.com/lilypond, thanks Jan!
> 2) There's a webhook that automatically (re)sets the patch status when
> opening a MR or pushing new commits. It's currently on my server (which
> makes it easy for me to experiment), but I'm open to putting this on
> lilypond.org eventually. Not a blocker for the migration though.
> 3) I wrote a small script to track the status of all patches for James'
> countdown emails. The same information is already available in the list
> of all merge requests, but not easily pasteable as text.
> 
> As the last two points involve some (short) scripts and I already have
> two more for the migration, I'd like to put them into a new repository;
> maybe https://gitlab.com/lilypond/infrastructure ? (I think they're
> sufficiently orthogonal to LilyPond itself that they deserve their own
> place to live.)
> 
> Other than that, Trevor mentioned that the migration script creates
> very many labels, in the order of 600. Most of them are "Fixed_x_y_z"
> (or variations). I propose to transform them into milestones which can
> be closed and are the GitLab way of grouping issues and patches
> contained in a release. This is likely a semi-manual process that I
> volunteer to handle after the final migration.
> 
> Thoughts or other observations that would block us from using GitLab?
> 
> Jonas

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: development stalled

[Étienne Beaulé]

Hello,

Don’t worry, there is still active development. I understand not having any 
recent stable updates is frustrating, and having a stable release made is a 
priority due to the length of time it has been. For now, we are holding off to 
fix a few problems before release.

In anticipation of the release, we had skipped numbers 65->80 of 2.19.x and 
started making a selection of features to include. The developers also want a 
new stable release just like you; we're working on it!

Étienne

> Le 13 août 2019 à 18:15, Frank Bryce  a écrit :
> 
> Hello,
> 
> my name is Frank and I have now used Lilypond for quite a long time, I enjoy 
> it for some years but I dont like that there is no current improvements which 
> a normal user can use. See the following list that shows that it has been 
> more then 5 1/2 years since the last major version and even almost two years 
> for the prerelease stage. That makes me sad. Unfortunately Im not a 
> programmer so I dont know how to help. Should I  change to Musescore or 
> Dorico?
> 
> version   release datedays since last release
> 2.0.0 2003/09/24
> 2.2.0 2004/04/01  190
> 2.4.2 2004/11/08  221
> 2.6.0 2005/06/27  231
> 2.8.0 2006/03/22  268
> 2.10.02006/11/15  238
> 2.12.02008/12/22  768
> 2.14.02011/06/06  896
> 2.16.02012/08/24  445
> 2.18.02013/12/29  492
> 2.19.80   2017/10/16  1387
> today 2019/08/13  666
> 
> ___
> 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

[É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é" 
>  <mailto:lilypond-devel-bounces+c_sorensen=byu@gnu.org> on behalf of 
> beauleetien...@gmail.com <mailto: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

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

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

Re: GitHub has been acquired by Microsoft

[Étienne Beaulé]

Le lun. 4 juin 2018, à 15 h 17, Wols Lists  a
écrit :

> On 04/06/18 17:58, David Kastrup wrote:
> >> Looking at GitLab's features, their "labels" for status tracking,
> >> > single-checkbox "squash merge" setting, and "resolvable discussions"
> >> > would at least have a chance of meeting those expectations.
>
> > Frankly, I'd expect most systems to work better than our current split
> > between SourceForge as an issue tracker and Rietveld (a
> > Subversion-centric platform) for git commit reviews.
> >
> LibreOffice uses gerrit, but I get the impression that's not that user
> friendly. And LO has the resources to put in to ironing out at least
> some of the rough edges.
>
> Gerrit does not include a bug tracker, and that does seem like the main
focus here. I must agree that Gerrit is not quite user-friendly, but it is
currently going under a redesign (PolyGerrit,
https://gitenterprise.me/category/polygerrit/) which is much more friendly.

Wikimedia currently uses a combination of Phabricator (
https://www.phacility.com/) and Gerrit. Phabricator is a suite of
applications, including for code review and an issue tracker, which
includes tags and the like. It is much more user friendly, but is somewhat
heavy. Importing tasks and code could be done.

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

Re: -dcrop not included in 2.20?

[Étienne Beaulé]

What is the status of this? It is possible to include by running "git
merge dcb458c225" in the stable branch. I know I'd like it included in the
next stable :)

Thank you!

Étienne Beaulé

2017-11-21 13:00 GMT-04:00 Étienne Beaulé <beauleetien...@gmail.com>:

> As author, I'd strongly like it to be included in the stable, especially
> that it is blocking another of my changes: https://phabricator.w
> ikimedia.org/T49578.
>
> On the other hand, it may be important to fix more bugs with the SVG
> backend before making making SVG wider. Some still serious yet unresolved
> issues that are only found in SVG include the skylining, bizarre
> text-spacing, and woff-fonts. However, issues with the backend should not
> preclude the extension of working features.
>
> Étienne
>
> 2017-11-21 11:06 GMT-04:00 Tomohiro Tatejima <t.stripe.0...@gmail.com>:
>
>> Personally I strongly desire this feature to be included in next stable.
>> I am working on a lily-embedded web document, which requires cropped svg
>> output.
>> Currently I am using eps backend and pdf2svg (external program) to
>> automatically obtain cropped output.
>> This new feature will be very useful to simplify the work.
>>
>> Tomohiro Tatejima
>>
>> 2017-11-21 23:43 GMT+09:00 Lukas-Fabian Moser <l...@gmx.de>:
>> >>
>> >> Not including it would be a pity. I am only one user and of course the
>> >> developers know better why or why not they would accept this -dcrop
>> change.
>> >>
>> >> But from a user’s perspective: this change is the only way (to my
>> >> knowledge) to create vector graphics snippets for inclusion in other
>> >> documents like the open document format (via ooolilypond) and html. So
>> >> for me it is a big step forward for which I was waiting for years.
>> >>
>> >
>> > +1 here!
>> >
>> > Best
>> > Lukas
>> > ___
>> > 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: -dcrop not included in 2.20?

[Étienne Beaulé]

As author, I'd strongly like it to be included in the stable, especially
that it is blocking another of my changes: https://phabricator.w
ikimedia.org/T49578.

On the other hand, it may be important to fix more bugs with the SVG
backend before making making SVG wider. Some still serious yet unresolved
issues that are only found in SVG include the skylining, bizarre
text-spacing, and woff-fonts. However, issues with the backend should not
preclude the extension of working features.

Étienne

2017-11-21 11:06 GMT-04:00 Tomohiro Tatejima :

> Personally I strongly desire this feature to be included in next stable.
> I am working on a lily-embedded web document, which requires cropped svg
> output.
> Currently I am using eps backend and pdf2svg (external program) to
> automatically obtain cropped output.
> This new feature will be very useful to simplify the work.
>
> Tomohiro Tatejima
>
> 2017-11-21 23:43 GMT+09:00 Lukas-Fabian Moser :
> >>
> >> Not including it would be a pity. I am only one user and of course the
> >> developers know better why or why not they would accept this -dcrop
> change.
> >>
> >> But from a user’s perspective: this change is the only way (to my
> >> knowledge) to create vector graphics snippets for inclusion in other
> >> documents like the open document format (via ooolilypond) and html. So
> >> for me it is a big step forward for which I was waiting for years.
> >>
> >
> > +1 here!
> >
> > Best
> > Lukas
> > ___
> > 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: -dcrop not included in 2.20?

[Étienne Beaulé]

There isn't anything else to the option that I can think of; it does
exactly what I intended it to do, nothing more or less. So, I'd keep it in
the current form. I can't really see how else it could fit in the code
without problems arising.

Étienne

2017-11-13 4:54 GMT-04:00 David Kastrup :

> Tomohiro Tatejima  writes:
>
> > Hello,
> >
> > I found that the -dcrop option (Issue 5165) is not included in
> > stable/2.20 branch although the feature is listed in the changes
> > document.
> >
> > Will it be included in 2.20? or upcoming 2.21 (and therefore the entry
> > of the documentation should be removed)?
>
> I've taken a look.  Currently I am undecided.  The code is separated
> well enough and clearly does not get exercised without specifying the
> option.  So it's not going to harm existing functionality.  I am not
> sure it will stay around in exactly this form.  But, well, that's a weak
> argument against it.
>
> --
> David Kastrup
>
> ___
> 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: Propose Commit access for Étienne Beaulé

[Étienne Beaulé]

The Contributor guide just says "Project Manager" without any other
instance of the phrase. David should be able to, as he is a Project
Administrator, the same as the other three on the Savannah member list
. Don't
know, just assuming here though.

Étienne

2017-09-07 17:03 GMT-03:00 Trevor Daniels :

>
> James wrote Thursday, September 07, 2017 4:19 PM
>
> > Étienne has pushed couple of patches now and I wondered if we could
> > perhaps give him full commit access to git?
>
> Who now has the authority to do this?  I don't, and I've lost track of who
> does
> now that Han-Wen, Jan and Graham are rarely seen on the lists.
>
> Trevor
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> ___
> 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: Propose Commit access for Étienne Beaulé

[Étienne Beaulé]

I have just made a request for inclusion on Savannah with the 'ebeaule'
username. Thank you!

2017-09-07 13:07 GMT-03:00 David Kastrup :

> James  writes:
>
> > Hello,
> >
> > Étienne has pushed couple of patches now and I wondered if we could
> > perhaps give him full commit access to git?
> >
> > http://git.savannah.gnu.org/gitweb/?p=lilypond.git=search=
> 4785a3ed7ce03c950f4f1f90ef6f412d038cedc7=author=%C3%89tienne
>
> Well, our vetting activity is of rather spotty quality and his focus is
> quite narrowed on SVG.  But that does not really change whether he is
> pushing his patches himself after running the review course or others do
> it for him.
>
> So with the understanding that he'll make himself acquainted with the
> pushing procedures (in particular our policy of never pushing to master,
> of rebasing your feature branches before pushing and so on), I see
> nothing to be gained from not letting him cater for pushing his patches
> himself at this stage.
>
> --
> David Kastrup
>
> ___
> 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: No more releases from master branch...

[Étienne Beaulé]

2017-08-16 18:31 GMT-03:00 David Kastrup <d...@gnu.org>:

> Étienne Beaulé <beauleetien...@gmail.com> writes:
>
> > Maybe my next patch, https://codereview.appspot.com/323420043/ when
> > it's released. It's a simple patch for a minor bug that was reported
> > in 2015.
>
> It newly uses non-ASCII markups.

In fact, the patch remarks that non-ASCII markup has been already in use
with the thin space (U+2009) for ranges. I only newly use unbreaking spaces
(U+00A0).

>
> > Perhaps more controversial, but I'd like to have dcb458c225 (-dcrop
> > option) in the 2.20 release for its integration in other
> > projects. There is an entry in changes.tely though.
>
> Too invasive for a last-minute inclusion.
>
I get that.

>
> There will likely be at least 2.20.1 at some point of time.  2.20 has
> been branched off recently.  Mostly eligible for inclusion into 2.20.0
> are regression and documentation fixes and the completion (or more
> likely reversal) of half-finished business.
>
> This is filtered through my personal judgment, of course.  Feel free to
> volunteer as release manager for 2.22 if you are unhappy about that.
>
Wow. The inclusions I have suggested were merely that; suggestions. It is a
bit harsh in my view to go straight to assuming I'm unhappy at the level
you are suggesting. :)

Étienne

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

Re: No more releases from master branch...

[Étienne Beaulé]

Maybe my next patch, https://codereview.appspot.com/323420043/ when it's
released. It's a simple patch for a minor bug that was reported in 2015.

Perhaps more controversial, but I'd like to have dcb458c225 (-dcrop option)
in the 2.20 release for its integration in other projects. There is an
entry in changes.tely though.

Étienne

2017-08-16 17:25 GMT-03:00 David Kastrup :

>
> Ok, I've started sorting out stable and master branch and pushed some
> 2.21-change on top of some already 2.21-only changes in master.
>
> The next changes I'd want to push require convert-ly rules.  Those rules
> have to be for 2.21.0 to avoid clashing with any work/fixes we may still
> be making on the stable branch.  This means that we should stop
> releasing from master until 2.20.0 has been released from the
> stable/2.20 branch.  The stable/2.20 branch is currently wired for
> making the next release as 2.19.80.  I don't know how many 2.19 releases
> we will actually need.  I hope not more than a few until we are
> reasonably sure 2.20 can be released without major backlash.
>
> What should be done in stable/2.20?
>
> Documentation/changes.tely should be reorganized: it is currently in
> chronological order which does not make sense for the stable release.
> It should be organized topically.  We want some assurance that recent
> changes did not come with big followup problems.  And we want the
> translation teams to have a chance of catching up to the current state.
>
> --
> David Kastrup
>
> ___
> 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: Issues write access

[Étienne Beaulé]

I plan to contribute patches related to SVG rendering.

Thank you!

Étienne

2017-08-10 6:15 GMT-03:00 Trevor Daniels <t.dani...@treda.co.uk>:

>
> Étienne Beaulé wrote Thursday, August 10, 2017 2:51 AM
>
>
> > Hello. May I be granted write access on our issue tracker? My username is
> > ebe123. Thank you!
>
> Added.  Welcome!
>
> Trevor
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Issues write access

[Étienne Beaulé]

Hello. May I be granted write access on our issue tracker? My username is
ebe123. Thank you!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Enhance the -dpreview method for SVG output (issue 326960043 by pkx1...@gmail.com)

[Étienne Beaulé]

Hit send too soon...

With the fix, there's still the run-time error:
/home/ubuntu/lilypond/build/out/share/lilypond/current/scm/backend-library.scm:245:18:
In procedure ly:paper-book-systems in expression (ly:paper-book-systems
book):

/home/ubuntu/lilypond/build/out/share/lilypond/current/scm/backend-library.scm:245:18:
Wrong type argument in position 1 (expecting Paper_book): (#)
(staff-refpoint-extent -9.77475935531354 . -9.77475935531354)
(last-in-score . #t) (page-turn-penalty) (page-break-penalty)
(page-turn-permission . allow) (page-break-permission . allow)
(vertical-skylines . #) (stencil . #))() >

What would be the best way to approach this feature?

Thank you.
Étienne

2017-08-01 16:25 GMT-03:00 Étienne Beaulé <beauleetien...@gmail.com>:

> Now that solves half of the issue. The other half is with the width, as my
> patch would (should) also adjust the width to fit the music, leaving no
> whitespace on any side.
>
> This feature is basically only available when using \includes "
> lilypond-book-preamble.ly" of which only works with the eps backend. My
> change would allow the use of "lilypond-book-preamble.ly" with the svg
> backend (which is already available in 'eps' so I wouldn't add it there
> too), but without the additional system by system output. Do you understand
> well now? I'm sorry if I wasn't clear.
>
> A bit embarrassing to have made a typo in a patch though, but it wouldn't
> work anyway. Maybe the way to go would be to implement crop-systems first
> for SVG. A worry for me is that it isn't lilypond "cropping" but
> GhostScript in the eps backend. Then, it would be worth continuing the plan
> of adding a variant of -dpreview.
>
> I'll be working more on this patch
>
> 2017-08-01 10:02 GMT-03:00 Paul <p...@paulwmorris.com>:
>
>> On 07/27/2017 03:21 AM, pkx1...@gmail.com wrote:
>>
>> This is a first attempt to merge the
>>> dump-page and dump-preview methods
>>> so that there is an option for
>>> cropping pages that are not just
>>> previews.
>>>
>>
>> I wonder... is the desired functionality already provided by
>> one-page-breaking and/or one-line-auto-height-breaking?
>>
>> http://lilypond.org/doc/v2.19/Documentation/notation/page-br
>> eaking#one_002dpage-page-breaking
>>
>> http://lilypond.org/doc/v2.19/Documentation/notation/page-br
>> eaking#one_002dline_002dauto_002dheight-page-breaking
>>
>> I haven't had time to look at the patch, and I'm still not sure exactly
>> what it's trying to do.
>>
>> -Paul
>>
>> ___
>> 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: Enhance the -dpreview method for SVG output (issue 326960043 by pkx1...@gmail.com)

[Étienne Beaulé]

Now that solves half of the issue. The other half is with the width, as my
patch would (should) also adjust the width to fit the music, leaving no
whitespace on any side.

This feature is basically only available when using \includes "
lilypond-book-preamble.ly" of which only works with the eps backend. My
change would allow the use of "lilypond-book-preamble.ly" with the svg
backend (which is already available in 'eps' so I wouldn't add it there
too), but without the additional system by system output. Do you understand
well now? I'm sorry if I wasn't clear.

A bit embarrassing to have made a typo in a patch though, but it wouldn't
work anyway. Maybe the way to go would be to implement crop-systems first
for SVG. A worry for me is that it isn't lilypond "cropping" but
GhostScript in the eps backend. Then, it would be worth continuing the plan
of adding a variant of -dpreview.

I'll be working more on this patch

2017-08-01 10:02 GMT-03:00 Paul :

> On 07/27/2017 03:21 AM, pkx1...@gmail.com wrote:
>
> This is a first attempt to merge the
>> dump-page and dump-preview methods
>> so that there is an option for
>> cropping pages that are not just
>> previews.
>>
>
> I wonder... is the desired functionality already provided by
> one-page-breaking and/or one-line-auto-height-breaking?
>
> http://lilypond.org/doc/v2.19/Documentation/notation/page-br
> eaking#one_002dpage-page-breaking
>
> http://lilypond.org/doc/v2.19/Documentation/notation/page-br
> eaking#one_002dline_002dauto_002dheight-page-breaking
>
> I haven't had time to look at the patch, and I'm still not sure exactly
> what it's trying to do.
>
> -Paul
>
> ___
> 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

[Feature Request]: More flexible SVG snippet cropping

[Étienne Beaulé]

I might have posted my request to the wrong mailing list. The original
message is below, but is not quite relevant with some new developments.

I have found the -dpreview option, but has a big limitation as it only
outputs the first line.

Looking through the code, my feature seems like in between the two existing
methods dump-page and dump-preview, found in scm/framework-svg.scm. The
little stumbling block is how both methods are invoked
separately: output-framework or output-preview-framework, both supplying
different arguments, the main difference being "stensil" that is required
for calculating the viewbox, but is not in dump-page.

Would it be possible for the two methods to be merged, so that there's an
option for cropping on pages that are not just previews (and on multi-page
scores)? (Or if a third method could be made...)

If someone could add this feature, it would be very useful for my work, and
for Lilypond's prominence on Wikipedia.

Cordially,

Étienne Beaulé (Ebe123 <https://phabricator.wikimedia.org/p/Ebe123/>)
beauleetien...@gmail.com

The original message is below:

-

Hello! I use lilypond quite often to illustrate and show snippets of music
on the web, both using lilypond-book and other tools (such as MediaWiki
<https://www.mediawiki.org/wiki/MediaWiki>'s Score extension
<https://www.mediawiki.org/wiki/Extension:Score>). Looking at the process
for lilypond-book, I see that the snippets are in a .png format and are cropped
using "gs", not natively.

As a feature, my final objective would be the ability to typeset the
snippets into a vector format, as the resolution's better and it takes up
less space.

In order for the goal to be eventually reached, cropping would have to be
native to lilypond. Right now, there is no cropping for SVGs. Each
generated SVG is the size of the page, through the height, width, and
viewBox="0
0 119.5016 169.0094" attributes.

With individual snippets I've typeset into SVG, I've been taking the
bounding box and using that as the viewBox; modifying the snippets with
this js:

var svg = document.getElementsByTagName("svg")[0];
var box = svg.getBBox();
var viewBox = [box.x, box.y, box.width, box.height].join(" ");

console.log(svg.getAttribute(viewBox));
svg.setAttribute("viewBox", viewBox);
svg.removeAttribute("height");
svg.removeAttribute("width");
console.log(viewBox);

However, I don't think it's a very good solution; finding that such
functionality should be built-in to lilypond, and not require the use of
user javascript (of which would be unusable anyway with img tags used with
PNGs.

In the MediaWiki extension, I've been trying to find a way, and the feature
request is being tracked: https://phabricator.wikimedia.org/T49578. Making
the extension output SVG is no problem (just change the backend on the
lilypond command), but cropping is. I believe that the Lilypond project
would be more suited to handle and incorporate this proposed feature, and
could potentially be useful when outputting PNG too. A flag could be added
to the command if cropping is desired.

Thank you for considering my feature request. This would not only help me,
but make Lilypond more flexible for typesetting music.

Cordially,

Étienne Beaulé (Ebe123 <https://phabricator.wikimedia.org/p/Ebe123/>)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[Feature Request]: More flexible SVG snippet cropping

[Étienne Beaulé]

I might have posted my request to the wrong mailing list. The original
message is below, but is not quite relevant with some new developments.

I have found the -dpreview option, but has a big limitation as it only
outputs the first line.

Looking through the code, my feature seems like in between the two existing
methods dump-page and dump-preview, found in scm/framework-svg.scm. The
little stumbling block is how both methods are invoked
separately: output-framework or output-preview-framework, both supplying
different arguments, the main difference being "stensil" that is required
for calculating the viewbox, but is not in dump-page.

Would it be possible for the two methods to be merged, so that there's an
option for cropping on pages that are not just previews (and on multi-page
scores)? (Or if a third method could be made...)

If someone could add this feature, it would be very useful for my work, and
for Lilypond's prominence on Wikipedia.

Cordially,

Étienne Beaulé (Ebe123 <https://phabricator.wikimedia.org/p/Ebe123/>)
beauleetien...@gmail.com

The original message is below:

-

Hello! I use lilypond quite often to illustrate and show snippets of music
on the web, both using lilypond-book and other tools (such as MediaWiki
<https://www.mediawiki.org/wiki/MediaWiki>'s Score extension
<https://www.mediawiki.org/wiki/Extension:Score>). Looking at the process
for lilypond-book, I see that the snippets are in a .png format and are cropped
using "gs", not natively.

As a feature, my final objective would be the ability to typeset the
snippets into a vector format, as the resolution's better and it takes up
less space.

In order for the goal to be eventually reached, cropping would have to be
native to lilypond. Right now, there is no cropping for SVGs. Each
generated SVG is the size of the page, through the height, width, and
viewBox="0
0 119.5016 169.0094" attributes.

With individual snippets I've typeset into SVG, I've been taking the
bounding box and using that as the viewBox; modifying the snippets with
this js:

var svg = document.getElementsByTagName("svg")[0];
var box = svg.getBBox();
var viewBox = [box.x, box.y, box.width, box.height].join(" ");

console.log(svg.getAttribute(viewBox));
svg.setAttribute("viewBox", viewBox);
svg.removeAttribute("height");
svg.removeAttribute("width");
console.log(viewBox);

However, I don't think it's a very good solution; finding that such
functionality should be built-in to lilypond, and not require the use of
user javascript (of which would be unusable anyway with img tags used with
PNGs.

In the MediaWiki extension, I've been trying to find a way, and the feature
request is being tracked: https://phabricator.wikimedia.org/T49578. Making
the extension output SVG is no problem (just change the backend on the
lilypond command), but cropping is. I believe that the Lilypond project
would be more suited to handle and incorporate this proposed feature, and
could potentially be useful when outputting PNG too. A flag could be added
to the command if cropping is desired.

Thank you for considering my feature request. This would not only help me,
but make Lilypond more flexible for typesetting music.

Cordially,

Étienne Beaulé (Ebe123 <https://phabricator.wikimedia.org/p/Ebe123/>)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel