Re: True Hand-engraved Dashed Slurs

[David Kastrup]

David Kastrup  writes:

> Abraham Lee  writes:
>
>> Greetings, Devs!
>>
>> I have always wondered why dashed slurs look the way they do, especially
>> when compared to the Barenreiter snippets found in the essay. The current
>> dashes look better than they used to, but I still think they look a bit odd
>> compared to the fairly uniform thickness of the hand-engraved Barenreiter
>> ones. Is there any historical reason they don't look that way? I'd be
>> curious to know if there is because I very much like the look of the
>> hand-engraved dashed slurs over the current LP dashed slurs.
>
> Have you experimented with \slurDashPattern ?

Actually, your example looks like \slurDotted to me.

-- 
David Kastrup

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

Re: True Hand-engraved Dashed Slurs

[David Kastrup]

Abraham Lee  writes:

> Greetings, Devs!
>
> I have always wondered why dashed slurs look the way they do, especially
> when compared to the Barenreiter snippets found in the essay. The current
> dashes look better than they used to, but I still think they look a bit odd
> compared to the fairly uniform thickness of the hand-engraved Barenreiter
> ones. Is there any historical reason they don't look that way? I'd be
> curious to know if there is because I very much like the look of the
> hand-engraved dashed slurs over the current LP dashed slurs.

Have you experimented with \slurDashPattern ?

-- 
David Kastrup

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

Re: segfault with 2.18.2 from Debian 9.0 testing

[David Kastrup]

Thomas Morley  writes:

> Hi all,
>
> in the german forum a user reported a segfault.
>
> If you understand german please read:
> https://lilypondforum.de/index.php/topic,70.0.html
> It's too much to refer here in all details.
>
> In short:
> He tried to compile
> horn.ly from
> www.mutopiaproject.org/ftp/MozartWA/KV447/MozartHornConcerto3/MozartHornConcerto3-lys.zip
> with 2.18.2 which he got via apt-get from Debian 9.0 testing, "buster" i386
> Logs under the link above in the german forum
>
> In the light of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#278
> I'd recommend someone more skilled than me could have a look.

Pretty sure this would be

commit b0dce76daf27721ba157cd2ac5d7662d4c8d75f8
Author: Guido Aulisi 
Date:   Fri Jul 22 15:26:29 2016 +0200

Issue 4814: grob.cc segfaults with gcc6

From the release notes of GCC 6:

Optimizations remove null pointer checks for this

When optimizing, GCC now assumes the this pointer can never be null,
which is guaranteed by the language rules. Invalid programs which
assume it is OK to invoke a member function through a null
pointer (possibly relying on checks like this != NULL) may crash or
otherwise fail at run time if null pointer checks are optimized
away. With the -Wnull-dereference option the compiler tries to warn
when it detects such invalid code.

If the program cannot be fixed to remove the undefined behavior then
the option -fno-delete-null-pointer-checks can be used to disable
this optimization. That option also disables other optimizations
involving pointers, not only those involving this.

As a consequence, we cannot call a member function on a prospective null
pointer (which actually is a bad idea for a number of other reasons,
like when anything tries accessing the vtable) and then try sorting out
the condition in the routine itself.

This problem was first observed with Fedora 24.  The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.

Commit-message-by: David Kastrup 
Signed-off-by: David Kastrup 


-- 
David Kastrup

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

True Hand-engraved Dashed Slurs

[Abraham Lee]

Greetings, Devs!

I have always wondered why dashed slurs look the way they do, especially
when compared to the Barenreiter snippets found in the essay. The current
dashes look better than they used to, but I still think they look a bit odd
compared to the fairly uniform thickness of the hand-engraved Barenreiter
ones. Is there any historical reason they don't look that way? I'd be
curious to know if there is because I very much like the look of the
hand-engraved dashed slurs over the current LP dashed slurs.

In any case, I'm wondering what the right way to go about changing them to
look more like the Barenreiter ones is. I've cobbled together some PS code
that takes the Tie/Slur/PhrasingSlur control points and then generates a
separate stencil using those, but with a single dashed curve. This seems to
work just fine, but I'm wondering if there's a better internal way of
getting the same dashed curve without resorting to pure PS code?

You'll find my code and a comparison PDF attached.

All the best,
Abraham


old-style-dashed-slur.ly
Description: Binary data


old-style-dashed-slur.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Micro release feature list

[tisimst]

On Mon, Jun 26, 2017 at 1:52 PM, Federico Bruni-2 [via Lilypond] <
ml+s1069038n204131...@n5.nabble.com> wrote:

> Il giorno lun 26 giu 2017 alle 21:46, kieren_macmillan kieren_macmillan
> <[hidden email] >
> ha scritto:
> > I look for "Fixed__2_19_x" in the issue tracker.
>
> Another way is entering the lilypond-git directory and then launch gitk
> (or similar GUI tools, like gitg), where you'll see the tags associated
> with releases. But in this "list" of commits you'll see also commits
> from translators (usually starting with doc-xx or web-xx).
>

Thank you both. I'll take a look at those suggestions and come back if I
have further questions.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Micro-release-feature-list-tp204126p204137.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

segfault with 2.18.2 from Debian 9.0 testing

[Thomas Morley]

Hi all,

in the german forum a user reported a segfault.

If you understand german please read:
https://lilypondforum.de/index.php/topic,70.0.html
It's too much to refer here in all details.

In short:
He tried to compile
horn.ly from
www.mutopiaproject.org/ftp/MozartWA/KV447/MozartHornConcerto3/MozartHornConcerto3-lys.zip
with 2.18.2 which he got via apt-get from Debian 9.0 testing, "buster" i386
Logs under the link above in the german forum

In the light of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#278
I'd recommend someone more skilled than me could have a look.



Thanks,
  Harm

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

Re: Micro release feature list

[Federico Bruni]

Il giorno lun 26 giu 2017 alle 21:46, kieren_macmillan kieren_macmillan 
 ha scritto:

I look for "Fixed__2_19_x" in the issue tracker.


Another way is entering the lilypond-git directory and then launch gitk 
(or similar GUI tools, like gitg), where you'll see the tags associated 
with releases. But in this "list" of commits you'll see also commits 
from translators (usually starting with doc-xx or web-xx).





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

Re: Micro release feature list

[kieren_macmillan kieren_macmillan]

   Hi Abraham,

   I look for "Fixed__2_19_x" in the issue tracker.

   Hope that helps!

   Kieren.

 -- Original Message --
 From: Abraham Lee 
 Date: June 26, 2017 at 2:45 PM
 Awesome Devs,
 I'm wondering if there's a semi-convenient way to look through the
 2.19.*
 micro releases to see which features were added at which point. Any
 suggestions for getting the info this way? It's not a critical
 thing, I'm
 just curious to see when things came to be. I'm certainly aware of
 the
 Changes page, but that seems to be more of a running list without a
 connection to micro versions and doesn't account for all the
 spectacular
 updates/features since 2.19 started.
 Best and much thanks,
 Abraham
 ___
 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

Micro release feature list

[Abraham Lee]

Awesome Devs,

I'm wondering if there's a semi-convenient way to look through the 2.19.*
micro releases to see which features were added at which point. Any
suggestions for getting the info this way? It's not a critical thing, I'm
just curious to see when things came to be. I'm certainly aware of the
Changes page, but that seems to be more of a running list without a
connection to micro versions and doesn't account for all the spectacular
updates/features since 2.19 started.

Best and much thanks,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Using/requiring Cairo

[David Kastrup]

Paul  writes:

> I can't speak to the technical questions, but I see the appeal of this
> idea.  Cairo looks like a mature, well-supported, and widely-used
> library.

One side effect is that most free software PDF viewers use Cairo for
their rendering these days, so if we generally use Cairo, our bitmap
output would likely be more representative for PDF viewer output than it
is now.

-- 
David Kastrup

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

Re: Using/requiring Cairo

[David Kastrup]

Paul  writes:

> I can't speak to the technical questions, but I see the appeal of this
> idea.  Cairo looks like a mature, well-supported, and widely-used
> library.
>
> https://en.wikipedia.org/wiki/Cairo_%28graphics%29
>
> Interestingly, "Cairo uses hardware acceleration
> ^[3]
>  when
> available."

Well, to be fair this just concerns display backends.  So it might be
interesting for Denemo and Frescobaldi interfacing but will not
otherwise affect output.  I think it would be quite interesting for
creating "live" output "rolls" for editing.

> I see that it can produce Postscript as well as PDF, among its various
> backends.  "The vector graphics application Inkscape
>  uses the Cairo library for
> its outline mode display, as well as for PDF
>  and
> PostScript  export..."

Yes.  That is what suggests eventual retirement of the existing backends
to be an option that could end up reducing the amount of ongoing
developer effort for keeping the backends in uniformly coherent shape.

Cairo doesn't do stuff like skylines and page layout, so finding good
ways for fudging stuff together will still be necessary.

-- 
David Kastrup

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

Re: Using/requiring Cairo

[Paul]

I can't speak to the technical questions, but I see the appeal of this 
idea.  Cairo looks like a mature, well-supported, and widely-used library.


https://en.wikipedia.org/wiki/Cairo_%28graphics%29

Interestingly, "Cairo uses hardware acceleration 
^[3] 
 when 
available."


I see that it can produce Postscript as well as PDF, among its various 
backends.  "The vector graphics application Inkscape 
 uses the Cairo library for its 
outline mode display, as well as for PDF 
 and PostScript 
 export..."


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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi James,

>> 'Accepted'. Is that better? Or at least sufficient?
> No. I only filter on 'Started'

Okay.

>> null
> Needs to be 'New'.

Okay.

> You can always go in and change these fields yourself manually.

Okay.

Thanks for the help!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: [Issue #3947] fixing \huge et al.

[James]

On Sun, 25 Jun 2017 21:12:49 -0400
Kieren MacMillan  wrote:

> Hi James,
> 
> > I am sure you know the process  
> 
> Actually, I *don't*. This will be my first patch.
> 
> > make sure that there is a tracker issue  
> 
> 
> 
> > AND that the tracker issue is marked as 'started'  
> 
> 'Accepted'. Is that better? Or at least sufficient?

No. I only filter on 'Started'; 'Accepted' just means that the issue
has been identified as 'valid' nothing more, the Bug squad usually
change an issue to 'Accepted' once it has been entered.

> 
> > with patch 'new'  
> 
> null

Needs to be 'New'. Null is either patch has been pushed and issue is
fixed or there is no patch at all.

> 
> > git-cl should do this automatically.

You can always go in and change these fields yourself manually.

James


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

Re: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #1388 Support OpenType font features

[Xavier Scheuer]

On 26 June 2017 at 09:32, Xavier Scheuer  wrote:
>
> Hello,
>
> Sorry, I come after the push.
>
> A. In order to give this nice and long-wanted (also by users other
> than me) feature some visibility, could it be documented in the
> Notation Reference as well (NR 1.8.3 Fonts)?

It deserves also greatly a mention in the CHANGELOG for the next version.

Cheers,
Xavier

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

Re: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #1388 Support OpenType font features

[Xavier Scheuer]

Hello,

Sorry, I come after the push.

A. In order to give this nice and long-wanted (also by users other
than me) feature some visibility, could it be documented in the
Notation Reference as well (NR 1.8.3 Fonts)?

So the users will not only be able to use it, but also know how it
(finally) exists.  :D

B. Furthermore, as an advanced improvement, it would be nice if the
\smallCaps command would behave like this :

1. if the font have real small caps, \smallCaps should use them
(font-features . ("smcp")) ,
2. else : fake it (like \smallCaps nowadays).
However I do not know if it would be possible for LilyPond to
*determine* if the font used possesses real small caps.

C. Introducing an \oldstyleNumbers command would be great (with as
advanced improvement the same idea as for B.1. and 2.).

Thank you in advance again for this nice feature Jay!

Cheers,
Xavier


On 19 June 2017 at 17:01, Auto mailings of changes to Lily Issues via
Testlilyissues-auto  wrote:
>
> labels: --> Fixed_2_19_63
> status: Started --> Fixed
> Patch: push -->
> Comment:
>
> I've pushed to staging.
>
> commit 8cf69a467ad7650f5ca9da6fe2dfd4c7c088b239
> Issue 1388: Initial work to support opentype font features.
>
> Thank you.
>
> 
>
> [issues:#1388] Support OpenType font features
>
> Status: Fixed
> Labels: Fixed_2_19_63
> Created: Mon Nov 08, 2010 10:34 PM UTC by Anonymous
> Last Updated: Mon Jun 19, 2017 11:13 AM UTC
> Owner: horndude77
>
> Originally created by: *anonymous
>
> Originally created by: lemzw...@googlemail.com
>
> Currently, LilyPond doesn't support OpenType font features.  For example,
many fonts already contain glyphs for small caps letters, but lilypond
can't access such glyphs directly since OpenType fonts don't need to have
named glyphs, and you need to activate an OpenType feature (`smcp' in this
particular case) so that input character codes get properly mapped to caps
glyphs.
>
> I suggest that we implement an interface similar to the `fontspec'
package for XeTeX and luatex:
>
>   http://www.ctan.org/get/macros/xetex/latex/fontspec/fontspec.pdf
>
> 
>
> Sent from sourceforge.net because
testlilyissues-a...@lists.sourceforge.net is subscribed to
https://sourceforge.net/p/testlilyissues/issues/
>
> To unsubscribe from further messages, a project admin can change settings
at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if
this is a mailing list, you can unsubscribe from the mailing list.
>
>
>
--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Testlilyissues-auto mailing list
> testlilyissues-a...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
>



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