Fix dashed line errors (issue 320320043 by david.nales...@gmail.com)

[david . nalesnik]

Reviewers: ,

Message:
Please review.  Thanks!

Description:
Fix dashed line errors

There are two errors in lily/line-interface.cc which cause
dashed lines to be drawn inaccurately.

(1) Line-thickness is improperly subtracted from the "off"
value in Line_interface::make_dashed_line.  This was done,
presumably, to account for the line cap of each dash.  In fact,
PostScript discounts the line cap when constructing the pattern.

(2) Dashed lines are constructed so that they begin and end
with a dash.  Thus, a dashed line is built of dash + whitespace
units and a last lone dash.  Period is not adjusted in
Line_interface::line for this last dash, which can lead to a
noticeable difference in its length compared to other dashes.

Correcting these flaws ensures that dashed lines end with a
dash rather than whitespace, and that terminating dashes are
not clipped.  Also, the number of dashes drawn reflects the
number calculated.

Please review this at https://codereview.appspot.com/320320043/

Affected files (+13, -8 lines):
  M lily/line-interface.cc


Index: lily/line-interface.cc
diff --git a/lily/line-interface.cc b/lily/line-interface.cc
index  
bc0895339fea3c996e08a71891c0090cbea2e96c..9c16ece4106f956af5cb3a30cb4fc667065abab8  
100644

--- a/lily/line-interface.cc
+++ b/lily/line-interface.cc
@@ -123,8 +123,8 @@ Line_interface::make_dashed_line (Real thick, Offset  
from, Offset to,

   Real dash_period, Real dash_fraction)
 {
   dash_fraction = min (max (dash_fraction, 0.0), 1.0);
-  Real on = dash_fraction * dash_period;
-  Real off = max (0.0, dash_period - on - thick);
+  Real on = dash_fraction * dash_period;
+  Real off = max (0.0, dash_period - on);

   SCM at = scm_list_n (ly_symbol2scm ("dashed-line"),
scm_from_double (thick),
@@ -226,16 +226,21 @@ Line_interface::line (Grob *me, Offset from, Offset  
to)

 return Stencil ();

   Real len = (to - from).length ();
-
-  int n = (int) rint ((len - period * fraction) / period);
-  n = max (0, n);
-  if (n > 0)
+  /*
+Dashed lines should begin and end with a dash.  Therefore,
+there will be one more dash than complete dash + whitespace
+units (full periods).
+  */
+  int full_period_count =
+(int) rint ((len - period * fraction) / period);
+  full_period_count = max (0, full_period_count);
+  if (full_period_count > 0)
 {
   /*
 TODO: figure out something intelligent for really short
 sections.
-   */
-  period = ((to - from).length () - period * fraction) / n;
+  */
+  period = len / (fraction + full_period_count);
 }
   stencil = make_dashed_line (thick, from, to, period, fraction);
 }



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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 23:46 schrieb tisimst:
> On Mon, Mar 6, 2017 at 3:34 PM, Urs Liska [via Lilypond] <
> ml-node+s1069038n200802...@n5.nabble.com> wrote:
>
>> Of course it is good to have optical sizes - even if the vast majority
>> of LilyPond users may not even be aware of it. And it's not depending on
>> the number of different sizes in a score but already on a single staff
>> size. If you want to engrave a pocket score requiring very small staves
>> it's obviously better to have optical sizes that aren't simply scaled
>> down.
>> So we should definitely use the optical sizes equally when font handling
>> is done by SMuFL, but (as you say) should be prepared that more or less
>> any other font won't have it. (None of your fonts have it, Abraham,
>> isn't it?).
>
> At the moment, that's correct. I'm hoping to change this sometime this
> year, though, time permitting. The root of this idea though is, how to
> handle fonts that only have a single size and those that have multiple
> sizes?
>
I think this should be manageable. If we have proper access to the fonts
(see the other part of my previous post) we can rather easily redirect
non-existent files for optical sizes to the default "medium" size.

Urs

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

Re: Website upload

[Urs Liska]

Am 06.03.2017 um 23:43 schrieb Phil Holmes:
> Simple answer - I run the GUB uploader.
>
> Slightly more useful one: there are two aspects to the "website":  the
> one that is created with "make website".  This is a fairly simple
> step, and any change to any file that is part of "website" is
> automatically picked up by the website - it has a pair of cron jobs
> that pull git and run "make website" every hour.  The more complex
> parts of the site (e.g. the docs) are created by GUB with a "make
> lilypond" and then uploaded with a GUB command that rsynch's my disk
> with lilypond.org.
>
> I suspect this won't answer your question, but does move the issue
> forward. Please ask more - if I can answer, I will.

OK. The concrete question (already raised by Federico) is:
Whenever the *website* is uploaded (I don't talk about the manuals) does
this involve rsync (seems so)? And if it does is the --delete option
used? Because otherwise remainders of renamed nodes will be kept on the
website (without being properly linked).

@node GSoC 2012
will result in gsoc-2012.html, gsoc-2012.de.html etc.

When that is renamed to
@node Google Summer of Code
the generated files are google-summer-of-code.html,
google-summer-of-code.de.html etc.

In that case the gsoc-2012... files have to be purged from the website.
and somehow it looks this isn't the case, presumably leading to a huge
amount of such orphaned files on the server.

A special case (as brought up by Werner) is the fact that
http://lilypond.org/gsoc.html is completely outdated but at the same
time a prominent search result at Google. So if our assumption is
correct and there are numeorus obsolete files on the server *this* one
should note simply be deleted but redirected to
http://lilypond.org/google-summer-of-code.html.

Urs

>
> -- 
> Phil Holmes
>
>
> - Original Message - From: "Urs Liska" 
> To: 
> Sent: Monday, March 06, 2017 9:50 PM
> Subject: Website upload (was: Obsolete GSoC page)
>
>
>> Phil,
>>
>> could you tell us how you (you do that, isn't it?) how you upload the
>> website?
>>
>> Urs
>>
>>
>> Am 06.03.2017 um 11:59 schrieb Urs Liska:
>>>
>>> Am 6. März 2017 11:41:54 MEZ schrieb Federico Bruni
>>> :
 Il giorno lun 6 mar 2017 alle 11:27, Federico Bruni
  ha scritto:
> gsoc-2012.html is generated by an existing node: "@node GSoC 2012",
> as shown by the grep above.
 Sorry, you are right: the english file shouldn't be there (only
 catalan

 and chinese files).
>>> If our conclusions are correct I suspect many more obsolete files
>>> lying around pn the web server.
>>>
>>
>> -- 
>> u...@openlilylib.org
>> https://openlilylib.org
>> http://lilypondblog.org
>>
>>
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 3:34 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n200802...@n5.nabble.com> wrote:

> Of course it is good to have optical sizes - even if the vast majority
> of LilyPond users may not even be aware of it. And it's not depending on
> the number of different sizes in a score but already on a single staff
> size. If you want to engrave a pocket score requiring very small staves
> it's obviously better to have optical sizes that aren't simply scaled
> down.
> So we should definitely use the optical sizes equally when font handling
> is done by SMuFL, but (as you say) should be prepared that more or less
> any other font won't have it. (None of your fonts have it, Abraham,
> isn't it?).


At the moment, that's correct. I'm hoping to change this sometime this
year, though, time permitting. The root of this idea though is, how to
handle fonts that only have a single size and those that have multiple
sizes?




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200805.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

Re: Website upload (was: Obsolete GSoC page)

[Phil Holmes]

Simple answer - I run the GUB uploader.

Slightly more useful one: there are two aspects to the "website":  the one 
that is created with "make website".  This is a fairly simple step, and any 
change to any file that is part of "website" is automatically picked up by 
the website - it has a pair of cron jobs that pull git and run "make 
website" every hour.  The more complex parts of the site (e.g. the docs) are 
created by GUB with a "make lilypond" and then uploaded with a GUB command 
that rsynch's my disk with lilypond.org.


I suspect this won't answer your question, but does move the issue forward. 
Please ask more - if I can answer, I will.


--
Phil Holmes


- Original Message - 
From: "Urs Liska" 

To: 
Sent: Monday, March 06, 2017 9:50 PM
Subject: Website upload (was: Obsolete GSoC page)



Phil,

could you tell us how you (you do that, isn't it?) how you upload the
website?

Urs


Am 06.03.2017 um 11:59 schrieb Urs Liska:


Am 6. März 2017 11:41:54 MEZ schrieb Federico Bruni :

Il giorno lun 6 mar 2017 alle 11:27, Federico Bruni
 ha scritto:

gsoc-2012.html is generated by an existing node: "@node GSoC 2012",
as shown by the grep above.

Sorry, you are right: the english file shouldn't be there (only catalan

and chinese files).
If our conclusions are correct I suspect many more obsolete files lying 
around pn the web server.




--
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
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: [requesting guidance] GSoC LilyPond

[Urs Liska]

Hello Adeel,

I hope you are by now subscribed to this list.

[forwarding from summer-of-c...@gnu.org]


Am 06.03.2017 um 15:47 schrieb Urs Liska:
>
> Hello Adeel,
>
>
> thanks for your interest in LilyPond and GSoC.
>
>
> This message is for you as well as for the other recipients of this post.
>
> I'll get back to you later today with some more information. But the
> place to discuss a LilyPond GSoC project is the lilypond-devel mailing
> list (https://lists.gnu.org/mailman/listinfo/lilypond-devel). Please
> subscribe to that list because I will post my reply to that list.
>
>
> Best
>
> Urs
>
>
> Am 06.03.2017 um 13:14 schrieb Adeel Ahmad:
>>
>> I'm an applicant for GSoC 2017 and want to get started on the
>> "Rewrite LibreOffice LilyPond Extension with Python" project. Could
>> someone please assign me a starting point?
>>

I will give you some starting points, but not much more for today. But I
think these should be rather simple to follow.

  * First you should find resources in the LibreOffice domain on how
extensions can be written.
  * Second you should find specific resources for *Python* extensions.
They have a nice demo extension available.
  * Just yesterday the release of version 0.5.0 of the "old" extension
has been announced here:
http://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00091.html
  o Install this in LibreOffice to get an idea what the extension
does and looks like
  o Look at the current code
  * Have a look at python-ly (http://python-ly.readthedocs.io/en/latest/)
This is the Python library that powers Frescobaldi's text editing
component, and we can integrate it into the new Python LibreOffice
extension. The most obvious option is to use it to produce syntax
highlighting, but there are seemingly endless options for future
enhancements.

If you have any further or more specific questions don't hesitate to ask.


Best
Urs


>>
>> To get an idea of my skill level, please review my GitHub
>>  profile.
>>
>>
>> Thank you.
>>
>> Adeel
>>
>
> -- 
> u...@openlilylib.org
> https://openlilylib.org
> http://lilypondblog.org

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 17:32 schrieb tisimst:
> On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] <
> ml-node+s1069038n200762...@n5.nabble.com> wrote:
>
>>
>> Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
> Not yet :-)  I can only second what Urs said.
 I think we (i.e. Abraham and you) should give Matthew some more
 concrete pointers on where to start investigating.
>>> Can you send him our e-mail conversation regarding this topic?
>>> Currently, I'm abroad, not having time to do that by myself.
>> I'll see what is there - probably it's at least partially in German.
>>
> BTW, where are the current instructions to install a font compliant
> to the SMuFL layout?
 What context are you talking about here?
>>> This context:
>>>
>>>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>>>
>>> I don't know whether this is still up to date.
>> Oh, me neither.
>> Joram?
>>
> While I think this background info is helpful, I don't believe it's really
> relevant beyond seeing which SMuFL glyphs are being substituted for the
> LilyPond ones.
>
> Here's what I see needing to happen to make SMuFL _really_ work with
> LilyPond:
>
> 1. Full revamp of LilyPond's glyph naming scheme so it coincides with SMuFL
> glyph names. The Metafont files would need to be adjusted for this.
> 2. Refactor LilyPond's glyph metadata subtables into the external SMuFL
> font metadata file (thankfully there are many similarities here...)
> 3. Refactoring everywhere a glyph or the embedded metadata (LILY, LILC,
> LILF subtables) is called (thankfully, they are all called by name and not
> code point so they're easy to search for) to use the SMuFL glyph names.
> 4. Provide a mechanism to load a _single_ 3rd-party font file since I think
> most SMuFL font designers will not take the effort to create optically
> sized ones like Emmentaler. Now, SMuFL does include a dedicated set of
> codepoints for the case where the user has a smaller staff next to the
> normal sized one so the smaller staff's glyphs _are_ optically sized, but
> no application that I know of (including Dorico) utilizes this at yet. It's
> not a bad approach since an engraver isn't likely to have more than two
> staff sizes in the same score, but I'm not sure it's the _right_ approach.
> I like LilyPond's idea of this better.

Of course it is good to have optical sizes - even if the vast majority
of LilyPond users may not even be aware of it. And it's not depending on
the number of different sizes in a score but already on a single staff
size. If you want to engrave a pocket score requiring very small staves
it's obviously better to have optical sizes that aren't simply scaled down.
So we should definitely use the optical sizes equally when font handling
is done by SMuFL, but (as you say) should be prepared that more or less
any other font won't have it. (None of your fonts have it, Abraham,
isn't it?).

> 5. (Optional) Create the "_Text.otf" version of the font files. They are
> intended to make including music glyphs in text easier, but I don't see any
> reason LilyPond would need to create these files.
>
>>> For LilyPond there *are* of course no such instructions yet, and
 otherwise you can install them like regular fonts, it's then up to
 the notation application to properly use it.
>>> Well, yes.  But music fonts are handled specially in lilypond...
> They are, but SMuFL is similar enough that it should be a fairly
> straightforward transition. I have to believe that Daniel Spreadbury
> borrowed a lot of ideas from the LilyPond handles fonts. The nice thing
> about SMuFL is that there are dedicated locations on all operating systems
> (Mac, Win, Linux) where the files are expected to be located, as explained
> in the SMuFL gitbook[1], so there should be no problem pointing to them.
> SMuFL fonts are installed in the system font folder just like any normal
> text font.

Here's a caveat (but I'm not sure if that relates to the GSoC project).
Some time ago I worked on a modified system to load the notation font
from system installed fonts too, which would substantially reduce the
amount of housekeeping when using alternative notation fonts. But I got
stuck at a well-meant but nasty behaviour of fontconfig that made it
basically impossible: fontconfig *always* returns a reference to a font.
This sounds good but is a real problem with notation fonts.

The idea behind that behaviour is that when an application requests a
font it *needs* a font, and when a particular font isn't installed in
the system there has to be a fallback font. The problem is that with
notation fonts it is totally unclear what an appropriate replacement
font is. What I wanted (and what is necessary) would be the information
that a requested font (e.g. LilyJAZZ) isn't available - then LilyPond
could explicitly fall back to Emmentaler. But instead fontconfig insists
on giving back *something*, so when LilyJAZZ isn't installed you may end
up with a score trying to typeset the 

Re: GSoC 2017

[Werner LEMBERG]

> 3. IIUC, this was just a set of overrides and callback functions
>picking up the correct symbols from a smufl font, doing the
>mapping by glyph name.

I think this helps already a lot – such a mapping has to be
implemented anyway, at least in `convert-ly'.


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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 23:16 schrieb tisimst:
> On Mon, Mar 6, 2017 at 2:34 PM, Noeck [via Lilypond] <
> ml-node+s1069038n200797...@n5.nabble.com> wrote:
>
>> 3. IIUC, this was just a set of overrides and callback functions picking
>> up the correct symbols from a smufl font, doing the mapping by glyph
>> name. So pretty much all you could do without touching lilypond directly.
>> I guess for the GSoC the approach would be quite different and I hope
>> Abraham can point into the right direction.
>>
> Personally, I think there's not much more that can be done with what is
> already in OLL, but I don't think that's what we want done anyway. Full
> SMuFL integration would be a more substantial improvement, IMHO.

Indeed. We want to make that OLL approach obsolete by not only
"supporting" SMuFL natively but by switching completely to *using* it as
LilyPond's notation font encoding.

Urs

>
> Best,
> Abraham
>
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200799.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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 2:34 PM, Noeck [via Lilypond] <
ml-node+s1069038n200797...@n5.nabble.com> wrote:

> 1. Nathan was coding this, I just included this into oll and wrote the
> post.


Correct.


> 2. I guess it still works.
>

Yep. Mostly without problems, but it does have its limitations.


> 3. IIUC, this was just a set of overrides and callback functions picking
> up the correct symbols from a smufl font, doing the mapping by glyph
> name. So pretty much all you could do without touching lilypond directly.
> I guess for the GSoC the approach would be quite different and I hope
> Abraham can point into the right direction.
>

Personally, I think there's not much more that can be done with what is
already in OLL, but I don't think that's what we want done anyway. Full
SMuFL integration would be a more substantial improvement, IMHO.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200799.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

Website upload (was: Obsolete GSoC page)

[Urs Liska]

Phil,

could you tell us how you (you do that, isn't it?) how you upload the
website?

Urs


Am 06.03.2017 um 11:59 schrieb Urs Liska:
>
> Am 6. März 2017 11:41:54 MEZ schrieb Federico Bruni :
>> Il giorno lun 6 mar 2017 alle 11:27, Federico Bruni 
>>  ha scritto:
>>> gsoc-2012.html is generated by an existing node: "@node GSoC 2012", 
>>> as shown by the grep above.
>> Sorry, you are right: the english file shouldn't be there (only catalan
>>
>> and chinese files).
> If our conclusions are correct I suspect many more obsolete files lying 
> around pn the web server.
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[Noeck]

Hi,

Am 06.03.2017 um 09:41 schrieb Urs Liska:
>>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>>
>> I don't know whether this is still up to date.
> Oh, me neither.
> Joram?

1. Nathan was coding this, I just included this into oll and wrote the post.
2. I guess it still works.
3. IIUC, this was just a set of overrides and callback functions picking
up the correct symbols from a smufl font, doing the mapping by glyph
name. So pretty much all you could do without touching lilypond directly.
I guess for the GSoC the approach would be quite different and I hope
Abraham can point into the right direction.

Cheers,
Joram

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

Create Bracket class (issue 314610043 by david.nales...@gmail.com)

[david . nalesnik]

Reviewers: ,

Message:
Please review.  Thanks!

Description:
Create Bracket class

Code involving brackets suffers from two confusing
organizational issues:

(1) Tuplet_bracket::make_bracket is used to create brackets
for a number of grobs: BassFigureBracket, HorizontalBracket,
OttavaBracket, PianoPedalBracket, VoltaBracket, along with
TupletBracket

(2) Methods belonging to Horizontal_bracket are used to draw
both horizonal brackets (HorizontalBracket) and vertical
brackets (BassFigureBracket)

To remedy this, a new Bracket class is created.

This new class contains the old Tuplet_bracket::make_bracket,
Horizontal_bracket::make_bracket, and
Horizontal_bracket::make_enclosing_bracket.

These methods have been renamed to clarify their purpose.

Please review this at https://codereview.appspot.com/314610043/

Affected files (+199, -178 lines):
  A lily/bracket.cc
  M lily/enclosing-bracket.cc
  M lily/horizontal-bracket.cc
  A + lily/include/bracket.hh
  M lily/include/horizontal-bracket.hh
  M lily/include/tuplet-bracket.hh
  M lily/ottava-bracket.cc
  M lily/piano-pedal-bracket.cc
  M lily/tuplet-bracket.cc
  M lily/volta-bracket.cc



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

Re: can't upload a patch

[David Nalesnik]

On Mon, Mar 6, 2017 at 8:56 AM, David Kastrup  wrote:
> David Nalesnik  writes:
>
>> On Mon, Mar 6, 2017 at 8:29 AM, Federico Bruni  wrote:
>>>
>>>
>>> Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik
>>>  ha scritto:

 Hi Federico,

 On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni  wrote:
>
>  Do you have ca-certificates installed?


 Yes, the newest version:

 ca-certificates/now 20141019+deb8u1 all [installed,local]
>>>
>>> Ok. Even though it seems an out-of-date package. Shouldn't it be version
>>> 20160104 as shown here?
>>> http://packages.ubuntu.com/yakkety/ca-certificates
>>
>> Strange.  The package did strike me as old, but running
>>
>> sudo apt-get install ca-certificates
>>
>> gets me
>>
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> ca-certificates is already the newest version.
>> 0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
>
> Maybe it's pinned or the version number is spelled in a manner where it
> is considered newer.
>
> Try removing and reinstalling it if possible without having other
> packages removed.  Otherwise, try forcing the update.
>

The version in Ubuntu is the one from 2016; the one in the Debian
machine is the older one, from 2014.  I'm not sure what to install to
bring the Debian version more up-to-date, without screwing the system
up.

I managed to upload the patch successfully
(https://sourceforge.net/p/testlilyissues/issues/5084/) by installing
git-cl in Ubuntu -- thanks Federico!

So, I haven't verified whether the problem is the ca-certificates
version or the VM's network interface.  I'll try an Ethernet cable
instead of the wireless adapter next.

Thanks so much,
David

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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] <
ml-node+s1069038n200762...@n5.nabble.com> wrote:

>
>
> Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
> >>> Not yet :-)  I can only second what Urs said.
> >> I think we (i.e. Abraham and you) should give Matthew some more
> >> concrete pointers on where to start investigating.
> > Can you send him our e-mail conversation regarding this topic?
> > Currently, I'm abroad, not having time to do that by myself.
>
> I'll see what is there - probably it's at least partially in German.
>
> >
> >>> BTW, where are the current instructions to install a font compliant
> >>> to the SMuFL layout?
> >> What context are you talking about here?
> > This context:
> >
> >   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
> >
> > I don't know whether this is still up to date.
>
> Oh, me neither.
> Joram?
>

While I think this background info is helpful, I don't believe it's really
relevant beyond seeing which SMuFL glyphs are being substituted for the
LilyPond ones.

Here's what I see needing to happen to make SMuFL _really_ work with
LilyPond:

1. Full revamp of LilyPond's glyph naming scheme so it coincides with SMuFL
glyph names. The Metafont files would need to be adjusted for this.
2. Refactor LilyPond's glyph metadata subtables into the external SMuFL
font metadata file (thankfully there are many similarities here...)
3. Refactoring everywhere a glyph or the embedded metadata (LILY, LILC,
LILF subtables) is called (thankfully, they are all called by name and not
code point so they're easy to search for) to use the SMuFL glyph names.
4. Provide a mechanism to load a _single_ 3rd-party font file since I think
most SMuFL font designers will not take the effort to create optically
sized ones like Emmentaler. Now, SMuFL does include a dedicated set of
codepoints for the case where the user has a smaller staff next to the
normal sized one so the smaller staff's glyphs _are_ optically sized, but
no application that I know of (including Dorico) utilizes this at yet. It's
not a bad approach since an engraver isn't likely to have more than two
staff sizes in the same score, but I'm not sure it's the _right_ approach.
I like LilyPond's idea of this better.
5. (Optional) Create the "_Text.otf" version of the font files. They are
intended to make including music glyphs in text easier, but I don't see any
reason LilyPond would need to create these files.

>> For LilyPond there *are* of course no such instructions yet, and
> >> otherwise you can install them like regular fonts, it's then up to
> >> the notation application to properly use it.
> > Well, yes.  But music fonts are handled specially in lilypond...
>

They are, but SMuFL is similar enough that it should be a fairly
straightforward transition. I have to believe that Daniel Spreadbury
borrowed a lot of ideas from the LilyPond handles fonts. The nice thing
about SMuFL is that there are dedicated locations on all operating systems
(Mac, Win, Linux) where the files are expected to be located, as explained
in the SMuFL gitbook[1], so there should be no problem pointing to them.
SMuFL fonts are installed in the system font folder just like any normal
text font.

Those are just some thoughts to keep the conversation going.

Best,
Abraham

[1] https://w3c.github.io/smufl/gitbook/




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200794.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

Add making web.$(ISOLANG).pdf (issue 319450043 by truer...@gmail.com)

[lemzwerg]

LGTM

https://codereview.appspot.com/319450043/

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

Re: can't upload a patch

[David Kastrup]

David Nalesnik  writes:

> On Mon, Mar 6, 2017 at 8:29 AM, Federico Bruni  wrote:
>>
>>
>> Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik
>>  ha scritto:
>>>
>>> Hi Federico,
>>>
>>> On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni  wrote:

  Do you have ca-certificates installed?
>>>
>>>
>>> Yes, the newest version:
>>>
>>> ca-certificates/now 20141019+deb8u1 all [installed,local]
>>
>> Ok. Even though it seems an out-of-date package. Shouldn't it be version
>> 20160104 as shown here?
>> http://packages.ubuntu.com/yakkety/ca-certificates
>
> Strange.  The package did strike me as old, but running
>
> sudo apt-get install ca-certificates
>
> gets me
>
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> ca-certificates is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.

Maybe it's pinned or the version number is spelled in a manner where it
is considered newer.

Try removing and reinstalling it if possible without having other
packages removed.  Otherwise, try forcing the update.

-- 
David Kastrup

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

Re: can't upload a patch

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 15:38, David Nalesnik 
 ha scritto:
On Mon, Mar 6, 2017 at 8:29 AM, Federico Bruni  
wrote:



 Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik
  ha scritto:


 Hi Federico,

 On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni 
 wrote:


  Do you have ca-certificates installed?



 Yes, the newest version:

 ca-certificates/now 20141019+deb8u1 all [installed,local]



 Ok. Even though it seems an out-of-date package. Shouldn't it be 
version

 20160104 as shown here?
 http://packages.ubuntu.com/yakkety/ca-certificates


Strange.  The package did strike me as old, but running

sudo apt-get install ca-certificates

gets me

Reading package lists... Done
Building dependency tree
Reading state information... Done
ca-certificates is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.





Try this first:

sudo apt-get update
apt-cache policy ca-certificates
sudo apt-get upgrade

Even though I'm not sure if ca-certificates in the host matters. I 
remember that I added it to LilyDev because it was necessary in the 
guest.



 Did you try uploading the patch with git-cl from the host (ubuntu)?
 Does it work?

 If it does, I'd start debugging the network connection in the guest.



Will try this.




Ok, let us know.





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

Re: can't upload a patch

[David Nalesnik]

On Mon, Mar 6, 2017 at 8:29 AM, Federico Bruni  wrote:
>
>
> Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik
>  ha scritto:
>>
>> Hi Federico,
>>
>> On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni  wrote:
>>>
>>>  Do you have ca-certificates installed?
>>
>>
>> Yes, the newest version:
>>
>> ca-certificates/now 20141019+deb8u1 all [installed,local]
>>
>
> Ok. Even though it seems an out-of-date package. Shouldn't it be version
> 20160104 as shown here?
> http://packages.ubuntu.com/yakkety/ca-certificates

Strange.  The package did strike me as old, but running

sudo apt-get install ca-certificates

gets me

Reading package lists... Done
Building dependency tree
Reading state information... Done
ca-certificates is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.


> Did you try uploading the patch with git-cl from the host (ubuntu)?
> Does it work?
>
> If it does, I'd start debugging the network connection in the guest.
>

Will try this.

Thanks!

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

Re: can't upload a patch

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 14:50, David Nalesnik 
 ha scritto:

Hi Federico,

On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni  
wrote:

 Do you have ca-certificates installed?


Yes, the newest version:

ca-certificates/now 20141019+deb8u1 all [installed,local]



Ok. Even though it seems an out-of-date package. Shouldn't it be 
version 20160104 as shown here?

http://packages.ubuntu.com/yakkety/ca-certificates

Did you try uploading the patch with git-cl from the host (ubuntu)?
Does it work?

If it does, I'd start debugging the network connection in the guest.




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

Re: can't upload a patch

[David Nalesnik]

Hi Federico,

On Mon, Mar 6, 2017 at 1:15 AM, Federico Bruni  wrote:
> Do you have ca-certificates installed?

Yes, the newest version:

ca-certificates/now 20141019+deb8u1 all [installed,local]


>
> Il 6 marzo 2017 01:23:26 CET, David Nalesnik  ha
> scritto:
>>
>> Not too long ago, I wrote to the list about an inability to upload
>> patches.  A Rietveld tracker issue is created, but the process
>> terminates before all of the base files can be uploaded.  An Allura
>> issue is never created.
>>
>> I was using a VirtualBox VM on a Windows 10 system.
>>
>> Now, on a different machine, no Windows, with Ubuntu 16.10 and LilyDev
>> 4.1 running (also in VirtualBox), I get the same result.
>>
>> Here is what happens when I attempt to upload a patch:
>>
>> [lilypond-git (dev/bracket_reorganization)]$ git-cl upload origin/master
>>  lily/bracket.cc| 151
>> +
>>  lily/enclosing-bracket.cc  |  16 ++--
>>  lily/horizontal-bracket.cc |  73 +-
>>  lily/include/bracket.hh|  40 ++
>>  lily/include/horizontal-bracket.hh |   5 --
>>  lily/include/tuplet-bracket.hh |   4 -
>>  lily/ottava-bracket.cc |  11 ++-
>>  lily/piano-pedal-bracket.cc|  10 +--
>>  lily/tuplet-bracket.cc |  78 +++
>>  lily/volta-bracket.cc  |   9 +--
>>  10 files changed, 227 insertions(+), 170 deletions(-)
>> Upload server: codereview.appspot.com (change with -s/--server)
>> Your browser has been opened to visit:
>>
>> https://codereview.appspot.com/get-access-token?port=8001
>>
>> If your browser is on a different machine then exit and re-run
>> upload.py with the command-line parameter
>>
>>   --no_oauth2_webbrowser
>>
>> Issue created. URL: http://codereview.appspot.com/313670043
>> Uploading base file for lily/include/horizontal-bracket.hh
>> Uploading base file for lily/include/tuplet-bracket.hh
>> Traceback (most recent call last):
>>   File "/home/david/git-cl/git-cl", line 628, in 
>> sys.exit(main(sys.argv))
>>   File "/home/david/git-cl/git-cl", line 622, in main
>> return func(argv[2:])
>>   File "/home/david/git-cl/git-cl", line 335, in CmdUpload
>> issue, patchset = upload.RealMain(['upload'] + upload_args + args)
>>   File "/home/david/git-cl/upload.py", line 2693, in RealMain
>> vcs.UploadBaseFiles(issue, rpc_server, patches, patchset, options,
>> files)
>>   File "/home/david/git-cl/upload.py", line 1220, in UploadBaseFiles
>> print t.get(timeout=60)
>>   File "/usr/lib/python2.7/multiprocessing/pool.py", line 558, in get
>> raise self._value
>> urllib2.URLError: 
>> [lilypond-git (dev/bracket_reorganization)]$
>>
>> _
>>
>> Does anybody have an idea of what could be happening?  Has anybody
>> experienced this problem?
>>
>> At my wit's end :(
>>
>> David
>>
>> 
>>
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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

Re: Add capability to build Japanese PDF documents (issue 316340043 by truer...@gmail.com)

[trueroad]

Thank you for your reviewing.

On 2017/03/06 12:40:30, davide.liessi wrote:

2017-03-06 13:32 GMT+01:00  :
>


https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode24

> Documentation/ja/GNUmakefile:24: # (This package is for Chinese,

but

> can also used in Japanese.)
> s/in/for/



Also s/can also used/can also be used/



> https://codereview.appspot.com/316340043/


done.

https://codereview.appspot.com/316340043/

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

Re: Add capability to build Japanese PDF documents (issue 316340043 by truer...@gmail.com)

[trueroad]

Thank you for your reviewing.


https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile
File Documentation/ja/GNUmakefile (right):

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode7
Documentation/ja/GNUmakefile:7: # By default, Japanese PDF documents are
not builded.
On 2017/03/06 12:32:15, lemzwerg wrote:

s/builded/built/


Done.

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode11
Documentation/ja/GNUmakefile:11: # For building Japanese PDF documents
the followings are required.
On 2017/03/06 12:32:15, lemzwerg wrote:

s/followings are/following is/


Done.

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode24
Documentation/ja/GNUmakefile:24: # (This package is for Chinese, but
can also used in Japanese.)
On 2017/03/06 12:32:15, lemzwerg wrote:

s/in/for/


Done.

https://codereview.appspot.com/316340043/

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

Re: Add capability to build Japanese PDF documents (issue 316340043 by truer...@gmail.com)

[Davide Liessi]

2017-03-06 13:32 GMT+01:00  :
> https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode24
> Documentation/ja/GNUmakefile:24: # (This package is for Chinese, but
> can also used in Japanese.)
> s/in/for/

Also s/can also used/can also be used/

> https://codereview.appspot.com/316340043/

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

Add capability to build Japanese PDF documents (issue 316340043 by truer...@gmail.com)

[lemzwerg]

LGTm


https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile
File Documentation/ja/GNUmakefile (right):

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode7
Documentation/ja/GNUmakefile:7: # By default, Japanese PDF documents are
not builded.
s/builded/built/

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode11
Documentation/ja/GNUmakefile:11: # For building Japanese PDF documents
the followings are required.
s/followings are/following is/

https://codereview.appspot.com/316340043/diff/1/Documentation/ja/GNUmakefile#newcode24
Documentation/ja/GNUmakefile:24: # (This package is for Chinese, but
can also used in Japanese.)
s/in/for/

https://codereview.appspot.com/316340043/

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

Re: Obsolete GSoC page

[Urs Liska]

Am 6. März 2017 11:41:54 MEZ schrieb Federico Bruni :
>Il giorno lun 6 mar 2017 alle 11:27, Federico Bruni 
> ha scritto:
>> gsoc-2012.html is generated by an existing node: "@node GSoC 2012", 
>> as shown by the grep above.
>
>Sorry, you are right: the english file shouldn't be there (only catalan
>
>and chinese files).

If our conclusions are correct I suspect many more obsolete files lying around 
pn the web server.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: Obsolete GSoC page

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 11:27, Federico Bruni 
 ha scritto:
gsoc-2012.html is generated by an existing node: "@node GSoC 2012", 
as shown by the grep above.


Sorry, you are right: the english file shouldn't be there (only catalan 
and chinese files).



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

Re: Obsolete GSoC page

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 10:56, Urs Liska  ha 
scritto:

IIRC there's a page for every @node, so:

$ git grep -i "@node gsoc"
Documentation/ca/web/community.itexi:@node GSoC 2012
Documentation/zh/web/community.itexi:@node GSoC 2012

seems to confirm your hypothesis that the website sync didn't work 
properly.




So does that indicate that the HTML document is created because 
there's a @node remaining in two translations, or does it mean what I 
thought: that an obsolete file simply isn't removed when uploading 
the new website?


To add to that: from looking at the website with Catalan selected I 
came to the file http://lilypond.org/gsoc-2012.html which is yet 
another one than http://lilypond.org/gsoc.html.
It turns out that there's a gsoc-2012.html and a gsoc.html, both 
available in English and a number of translations and in different 
states of outdatedness


gsoc-2012.html is generated by an existing node: "@node GSoC 2012", as 
shown by the grep above.


But gsoc.html doesn't have any matching @node so it should be an 
obsolete file. I don't know how the website build process works. In 
order to remove obsolete files with rsync the option --delete must be 
used.





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

Re: Obsolete GSoC page

[Urs Liska]

Am 06.03.2017 um 10:16 schrieb Federico Bruni:
>
>
> Il giorno lun 6 mar 2017 alle 7:20, Urs Liska  ha
> scritto:
>> Am 06.03.2017 um 05:02 schrieb Werner LEMBERG:
>>
>> PS: If I do a google search for `lilypond gsoc', the first hit is
>> the old http://lilypond.org/gsoc.html and only the second hit is
>> the current http://lilypond.org/google-summer-of-code.html Any
>> chance to fix this quickly, for example, to copy the latter to
>> the former? 
>>
>> I'm very surprised and didn't even know such a page exists!
>> ~/git/lilypond/source$ git grep gsoc
>> Documentation/es/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
>> GSoC} es un
>> Documentation/es/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
>> El
>> Documentation/fr/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
>> Documentation/it/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
>> GSoC} è un programma
>> Documentation/ja/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
>> GSoC} is a global
>> Documentation/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
>> Documentation/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
>> Documentation/zh/web/news-front.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
>> This indicates that the GSoC page's translation hasn't been properly
>> updated for a number of languages, but it doesn't really show how a
>> gsoc.html should have been triggered.
> IIRC there's a page for every @node, so:
> $ git grep -i "@node gsoc"
> Documentation/ca/web/community.itexi:@node GSoC 2012
> Documentation/zh/web/community.itexi:@node GSoC 2012
> seems to confirm your hypothesis that the website sync didn't work
> properly.

So does that indicate that the HTML document is created because there's
a @node remaining in two translations, or does it mean what I thought:
that an obsolete file simply isn't removed when uploading the new website?

To add to that: from looking at the website with Catalan selected I came
to the file http://lilypond.org/gsoc-2012.html which is yet another one
than http://lilypond.org/gsoc.html.
It turns out that there's a gsoc-2012.html and a gsoc.html, both
available in English and a number of translations and in different
states of outdatedness.

Urs

>> Is it possible that the HTML file is a leftover that simply hasn't
>> been removed when uploading the updated site (how is that actually
>> done)? If so, I suggest to use a permanent redirect instead of
>> copying over the content. Anyway, this should (urgently) be looked at
>> by someone familiar with the website build process.

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: Obsolete GSoC page (was: GSoC 2017)

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 7:20, Urs Liska  ha 
scritto:



Am 06.03.2017 um 05:02 schrieb Werner LEMBERG:
 PS: If I do a google search for `lilypond gsoc', the first hit is 
the

 old

   http://lilypond.org/gsoc.html

 and only the second hit is the current

   http://lilypond.org/google-summer-of-code.html

 Any chance to fix this quickly, for example, to copy the latter 
to

 the former?


I'm very surprised and didn't even know such a page exists!

~/git/lilypond/source$ git grep gsoc
Documentation/es/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} es un
Documentation/es/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012, 
El

Documentation/fr/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/it/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} è un programma
Documentation/ja/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} is a global

Documentation/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
Documentation/zh/web/news-front.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,


This indicates that the GSoC page's translation hasn't been properly
updated for a number of languages, but it doesn't really show how a
gsoc.html should have been triggered.



IIRC there's a page for every @node, so:

$ git grep -i "@node gsoc"
Documentation/ca/web/community.itexi:@node GSoC 2012
Documentation/zh/web/community.itexi:@node GSoC 2012

seems to confirm your hypothesis that the website sync didn't work 
properly.




Is it possible that the HTML file is a leftover that simply hasn't 
been
removed when uploading the updated site (how is that actually done)? 
If

so, I suggest to use a permanent redirect instead of copying over the
content.

Anyway, this should (urgently) be looked at by someone familiar with 
the

website build process.





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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
>>> Not yet :-)  I can only second what Urs said.
>> I think we (i.e. Abraham and you) should give Matthew some more
>> concrete pointers on where to start investigating.
> Can you send him our e-mail conversation regarding this topic?
> Currently, I'm abroad, not having time to do that by myself.

I'll see what is there - probably it's at least partially in German.

>
>>> BTW, where are the current instructions to install a font compliant
>>> to the SMuFL layout?
>> What context are you talking about here?
> This context:
>
>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>
> I don't know whether this is still up to date.

Oh, me neither.
Joram?

Best
Urs

>> For LilyPond there *are* of course no such instructions yet, and
>> otherwise you can install them like regular fonts, it's then up to
>> the notation application to properly use it.
> Well, yes.  But music fonts are handled specially in lilypond...
>
>
> Werner

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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