Re: Standard paper size too big

[Federico Bruni via bug-lilypond]

Il giorno ven 3 mar 2023 alle 11:45:08 +0100, Jean Abou Samra 
 ha scritto:

Le vendredi 03 mars 2023 à 11:26 +0100, Ruben du Pon a écrit :
 That may be the case, but as I said when I print straight from 
Frescobaldi the score doesn't fit the page (the bottom staff is 
mostly missing) and when I open it in acrobat reader it fits at 89%, 
so something is off about the paper size.



I don't think so. Try printing any A4 document from Acrobat or 
Frescobaldi and seeing if you get the same behavior. Pretty sure you 
will. Then you should either find the proper settings in Acrobat (I 
don't have it), or in Frescobaldi, or write a bug report to 
Frescobaldi. From LilyPond's point of view, I don't see anything 
wrong here.


I remember old discussions about this issue in Frescobaldi. IIRC 
Frescobaldi simply relies on some default linux printing command. 
Probably printer settings and drivers are playing a role.

Let's follow up here:
https://github.com/frescobaldi/frescobaldi/issues/1365

Re: musicxml2ly

[Federico Bruni via bug-lilypond]

Il giorno mer 9 nov 2022 alle 09:14:44 +0100, Denis Penard 
 ha scritto:

So I use your program musixml2py. It works very well.

I would like to have no repetition of note duration, for example if I
have four c8, I would like to get c8 c c c in lily.

I have studied the python code, but I am not very skilled in Python. 
It is

complicated to have this possibility?


I don't think that musicxml2ly has an option for this.

The easiest option is fixing the input afterwards in Frescobaldi: 
select the music, then Tools>Musical transformation>Rhythm>Make 
implicit.

Maybe python-ly has a command to do this on the command line:
https://python-ly.readthedocs.io/en/latest/




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

Re: make info fails without preceding make doc

[Federico Bruni]

Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup 
 ha scritto:
"make doc-clean" appears to work better.  I find it somewhat 
surprising

that it should not have been implied by "make clean".


IIRC it's implied by make distclean




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

wrong string extraction in python/musicxml.py

[Federico Bruni]

While translating the PO file I saw what I thought it was a typo 
(butthe), but it's something else.


$ git grep -n -B2 -A2 butthe po/lilypond.pot
po/lilypond.pot-847-#: musicxml.py:116
po/lilypond.pot-848-#, python-format
po/lilypond.pot:849:msgid "more than one child of class %s, all butthe 
first will be ignored"

po/lilypond.pot-850-msgstr ""
po/lilypond.pot-851-

$ git grep -n -A2 'all but' python/*
python/musicxml.py:116: warnings.warn(_('more than one child of class 
%s, all but'

python/musicxml.py-117- 'the first will be ignored') % klass.__name__)
python/musicxml.py-118- return cn[0]




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

Re: info-lilypond mailing list

[Federico Bruni]

Il giorno mer, dic 23 2020 at 15:05:57 +0100, Malte Meyn 
 ha scritto:

Hi list,

someone asked me whether LilyPond could have a feature that announces 
new released versions. I don’t think that this is desirable but 
what about the info-lilypond mailing list promoted at 
https://lilypond.org/contact.html ? According to the archives, 
2.19.13 has been the last version announced at the list, so it should 
be reactivated or the website should be updated.





Hi Malte

The problem with the info-lilypond list is that requires a person 
(Phil) to remember to make the announcement, (besides the long list of 
steps to make a new release). I think Phil made the announcements on 
lilypond-user only.


In the tracker you can find some ideas about how to automate this 
communication:

https://gitlab.com/lilypond/lilypond/-/issues/1719
https://gitlab.com/lilypond/lilypond/-/issues/940

I don't know what should be write on the website...

Personally, I would use Gitlab to get release notifications:
https://docs.gitlab.com/ee/user/project/releases/#get-notified-when-a-release-is-created



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

Re: Crash from embedded comment

[Federico Bruni]

Il giorno gio, nov 19 2020 at 16:58:31 -0500, Trevor Bača 
 ha scritto:

(minimum-distance . 12) % errant comment causes crash


You should use `;` to add a comment in a Scheme block, so it doesn't 
look like a bug to me.


v2.20 did not produce an error, but the documentation already warned 
against using % in a Scheme block:


"Note that LilyPond comments (% and %{ %}) cannot be used within Scheme 
code, even in a LilyPond input file, because the Guile interpreter, not 
the LilyPond lexer, is reading the Scheme expression."


from:
http://lilypond.org/doc/v2.20/Documentation/extending/lilypond-scheme-syntax




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

Re: Files not saved before printng

[Federico Bruni]

This is not a LilyPond bug.
If Frescobaldi doesn't warn you before closing an unsaved file, then 
this is a Frescobaldi bug. But I can't reproduce it on Linux. Are you 
really sure that no warning appears? It would be a serious bug.



On Fri, 10 Jul, 2020 at 14:18, JH Austin  wrote:

I'm not sure you would call this is bug or just a user error,
but I have lost a couple files recently.
Using Frescobaldi and Lilypond, after composing and printing a file 
correctly,

the saved file is still back-level to the printed copy.



Here you say: printed copy is up-to-date, file is out-of-date. It seems 
impossible. I wouldn't say "back-level". I would just say they are 
different.

What you write after seems to contradict this statement.


Having a "good" printout and thinking I was finished, I exited the 
program, apparently without saving, and all my revisions disappeared.


Stupid me!  Guess I've gotten so used to modern programs that do 
auto-save that I've developed sloppy habits.


But it would be helpful to warn the user before printing if the file 
has not been saved.




This makes more sense maybe, if I understand correctly.
But I won't try to interpret your words. Please try to reformulate 
better what happened.


I have the feeling that setting the preference "save file before 
compiling" would solve your issues.
I think this should be the default, as new users are often confused 
about this Frescobaldi behaviour.



I'm running:
Frescobaldi 3.1.2
Lilypond 2.20.0-1
Mac OS 10.13.4 High Sierra









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

Re: 2.20 Manuals search box

[Federico Bruni]

Il giorno sab 2 mag 2020 alle 09:40, Pierre Perol-Schneider 
 ha scritto:

Hi Bug squad,
Search boxes included in the manuals re-direct to the v2.19 manuals 
instead

of the v2.20.
Cheers,
Pierre



Last month Valentin wrote that v2.20 was not indexed by Google yet:
https://lists.gnu.org/archive/html/lilypond-devel/2020-04/msg00101.html

I think this is not true anymore.
I've tried several searches and all return v2.20, so I think that we 
can change it.





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

Re: No Mac OS 64-bit link of Lilypond in non-English Download section

[Federico Bruni]

Il giorno gio 30 apr 2020 alle 16:12, Caio Barros 
 ha scritto:

Hello!

The link to the Unofficial 64-bit app for Mac OS is not present in
non-English versions of the website. See, for instance:

https://lilypond.org/macos-x.de.html
https://lilypond.org/macos-x.pt.html
https://lilypond.org/macos-x.es.html




It's normal, as it's up to translators to update their files.

The italian and french pages are up-to-date. I guess that spanish (and 
maybe catalan) will follow soon.

AFAIK the other languages are not maintained, unfortunately.


PS
If we used gettext, we might force the english for fuzzy or new 
strings, so any page would be always up-to-date but possibly with a mix 
of translated paragraphs and untranslated (english) paragraphs.

But we are not using gettext :-)




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

Learning Manual: wrong reference to NR manual

[Federico Bruni]

@ruser{Engraving ties manually} in Learning Manual is incorrect, as 
such a node doesn't exist.

It's the title of a snippet:

$ git grep -n 'Engraving ties manually'
learning/tweaks.itely:3192:See @ruser{Engraving ties manually} for the 
difference between
snippets/engraving-ties-manually.ly:27: doctitle = "Engraving ties 
manually"


Perhaps there's a way to use a index link?
Here's what I see in the HTML:






 Engraving ties manually

but I don't know how to make such a link - 
index-manual-engraving-of-ties - in Texinfo.





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

Re: hide issue

[Federico Bruni]

Il giorno gio 9 apr 2020 alle 09:28, dfleu...@free.fr ha scritto:


Hi,
in this code sample :



\relative c' { c d \hide r4. f8 }


I expect that the hide command will hide the dot for r4.



Regards,
PS: Now, I use s4 instead.




s (spacer rest) is what you should use in this case.

\hide is a shorthand to make only the NoteHead grob transparent, as 
explained here:

http://lilypond.org/doc/v2.20/Documentation/notation/visibility-of-objects#making-objects-transparent

If you want to hide every grob related to a note (stem, flag, dots, 
...), you should use \hideNotes:


\relative c' { c d \once \hideNotes r4. f8 }

See 
http://lilypond.org/doc/v2.20/Documentation/notation/inside-the-staff#hidden-notes





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

Re: Segfault when using specific symbol combination

[Federico Bruni]

Il giorno ven 6 mar 2020 alle 11:38, Mathias Bockwoldt 
 ha scritto:

Dear Lilypond team,

I found a symbol combination that triggers a segfault in Lilypond 
2.18.2 on Linux (Linux subsystem for Windows 10). I did not have the 
chance to reproduce on other machines or with other versions.
I tried looking for the bug in the database and I am 98% sure that it 
is not there, yet.
More information about the actual circumstances for the bug is in the 
attached file.


Thank you for this great product!
Mathias




Can you paste lilypond output here?

I cannot reproduce it using "native" Linux and lilypond 2.20.
Your example compiles without errors.




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

Re: Broken URL / Documentation Help

[Federico Bruni]

Hi Ben

I've uploaded a patch here:
https://sourceforge.net/p/testlilyissues/issues/5549/

Currently I cannot send it for review.
I hope someone reading this list can do it for me or just push the 
patch to staging, as it's a trivial patch.


BTW, you don't need to know the inner workings of texi2html. All you 
need is 'git grep' and sed to replace strings.


Best
Federico


Il giorno gio 30 mag 2019 alle 16:01, SoundsFromSound 
 ha scritto:

Hi everyone,

I just wanted to let you know that there are still some 404 errors in 
the
LilyPond documentation from my previous email to the list. I checked 
just

now on the LilyPond.org source and I noticed this:

/"Created on May 14, 2019"/

I am unfamiliar with the inner workings of how to update 
documentation via
"texi2html" as well as the timetable for such a process, so please 
forgive
me if this is a silly question. But I've been receiving some emails 
from new
users who eventually find their way to my tutorials and want to thank 
me,
and ask if I knew about the 404 errors, or if there was something 
wrong with

their browser, etc. - trying to be helpful, of course.

So I thought I would post just once more and see if there was a way 
to fix

them for the community, and especially new users.

Thanks all.

-
Current 404 error
___

*source: http://lilypond.org/text-input.html*

http://benlemon.me/blog/music/lilypond/operation-lilypond/

* should become *

https://benl.xyz/lilypond/operation-lilypond

---
Out-of-date URL


*source: http://lilypond.org/manuals.html*

("Video tutorials" section "other material")

http://bit.ly/LilyPondBeginners

* should ideally become *

https://bit.ly/LearnLilyPond






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

NR 2.9 Ancient Notation

[Federico Bruni]

Hi folks

I think this chapter in general would need some review from someone who 
knows well the best practices for writing docs in LilyPond.


This snippet here should have the verbatim option:
http://lilypond.org/doc/v2.19/Documentation/notation/ancient-notation_002d_002dcommon-features#custodes





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

empty predefined commands block in NR 2.6 Wind Instruments

[Federico Bruni]

I guess this should be either commented out or filled with some 
commands?


$ git grep -n -A3 '@predefined' Documentation/notation/wind.itely
Documentation/notation/wind.itely:403:@predefined
Documentation/notation/wind.itely-404-@endpredefined
Documentation/notation/wind.itely-405-
Documentation/notation/wind.itely-406-@snippets


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

Re: fontforge version detection during build

[Federico Bruni]

Il giorno mer 8 mag 2019 alle 17:35, Daniel Johnson 
 ha scritto:

On 5/8/19 11:30 AM, Federico Bruni wrote:

It seems your fontforge installation is not found.
Does it occur when you run configure?

Which distro are you using?

I have encountered this error when Fontforge was built from 
git-master rather than from a release tarball.




This should have been fixed years  ago, see:
https://lists.gnu.org/archive/html/bug-lilypond/2015-08/msg00069.html

Anyway, the output shown by Kyrylo has an empty git hash.


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

Re: fontforge version detection during build

[Federico Bruni]

Il giorno mer 1 mag 2019 alle 16:14, Kyrylo Shpytsya 
 ha scritto:

Build fails with:

ERROR: Please install required programs:  /usr/bin/fontforge >= 
20110222

(installed: )



It seems your fontforge installation is not found.
Does it occur when you run configure?

Which distro are you using?



$ /usr/bin/fontforge --version
Copyright (c) 2000-2018 by George Williams. See AUTHORS for 
Contributors.

 License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
 with many parts BSD . Please read
LICENSE.
 Based on sources from 14:22 UTC  8-Apr-2019-ML-D.
 Based on source from git with hash:
fontforge 14:22 UTC  8-Apr-2019
libfontforge 20190408





I can build without any problem in Fedora 30.
But I have a slightly older version.

$ fontforge --version
Copyright (c) 2000-2014 by George Williams. See AUTHORS for 
Contributors.
License GPLv3+: GNU GPL version 3 or later 

with many parts BSD . Please read 
LICENSE.

Based on sources from 08:50 UTC 17-Feb-2019-ML-D.
Based on source from git with hash:
no xdefs_filename!
TESTING: getPixmapDir:/usr/share/fontforge/pixmaps
TESTING: getShareDir:/usr/share/fontforge
TESTING: GResourceProgramDir:/usr/bin
trying default theme:/usr/share/fontforge/pixmaps/resources
fontforge 08:50 UTC 17-Feb-2019
libfontforge 20190217






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

Re: bug-lilypond Digest, Vol 197, Issue 11

[Federico Bruni]

Il giorno gio 25 apr 2019 alle 23:40, Thomas Morley 
 ha scritto:
Probably one could think of making `\tabChordRepeats´ the default 
for TabStaff.


Opinions?


I'm in favour  of making it the default for TabStaff.


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

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

[Federico Bruni]

Hi Florian

I can't see your attachments.
Can you send them again?

Il giorno mar 23 apr 2019 alle 18:54, Florian Grundig 
 ha scritto:

Hi all,

I’ve encountered a strange behaviour when converting a musicXml 
document (exported from MuseScore 3.0.5) with two or more voices per 
staff in combination with dynamics or hairpins -> the ly file 
contains the dynamics and the hairpins for each voice so they are 
also rendered several times which looks buggy.




I don't see this bug listed in the tracker:
https://sourceforge.net/p/testlilyissues/issues/search/?q=%22musicxml2ly%22+%26%26+%21status%3AVerified+%26%26+%21status%3AInvalid+%26%26+%21status%3ADuplicate+%26%26+%21status%3AFixed

but we must test the files first...

As a workaround, do you know that in Frescobaldi you can select a voice 
and automatically remove all the dynamics?



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

Re: gs version error in latest GUB build

[Federico Bruni]

Il giorno dom 31 mar 2019 alle 17:22, Valentin Villenave 
 ha scritto:

On 3/31/19, Valentin Villenave  wrote:
 I couldn’t reproduce (but then again I’m not running Ubuntu). I 
also
 find it odd that only some scores are reported to fail while 
other’s

 aren’t.


OK, as I suspected *all* scores do indeed fail for this user.

Further information just in case: LilyPond 2.19.83 has been
decompressed to /usr/local, and there’s gs 9.26 installed in 
/usr/bin

(as a dependency for the distro-provided LilyPond 2.18, I’d guess).



So where "gs revision 9.21" comes from?

As far as I can see from my installations, gs distributed in 
lilypond.org recent installers is version 9.26.


Even if in the GUB spec I read 9.21:
https://github.com/gperciva/gub/blob/master/gub/specs/ghostscript.py#L22

On Fedora 29, both system's and lilypond's gs are 9.26:

$ gs --version
9.26

$ .local/lilypond/usr/bin/gs --version
9.26





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

Re: Dispositioned notehead in chord when staffsize=14 and clef=bass

[Federico Bruni]

Il giorno dom 24 mar 2019 alle 14:22, Martin Tarenskeen 
 ha scritto:


Hi,

A bumped into a strange bug with a dispositioned notehead.

See attached example "staffsize14.ly" and "staffsize14.pdf" output.
Using lilypond 2.19.82 on Linux Fedora.

What's happening here?



I confirm it. Same problem with a lilypond binary built from the 
translation branch.


Version 2.18.2 works correctly.




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

Re: Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur

[Federico Bruni]

Il giorno ven 15 mar 2019 alle 20:20, Edward McGuire  
ha scritto:

The full work from which the tiny example is taken generates both
printed output and MIDI output. The structure of the full work is
something like:

\include "articulate.ly"
stringpart = { [music] }
\book {
% generated printed output
\bookpart {
\score { \stringpart }
\layout { }
}
% using articulate, generate MIDI output
\bookpart {
\score { \unfoldRepeats \articulate \stringpart }
\midi { }
}
}

(When I say "something like" I mean that this is still a
simplification of the structure of the full work, which actually
contains more parts, i.e., multiple staves, multiple voices.)


A workaround is moving the include of articulate.ly after the "PDF 
score" and just before the "MIDI score", so that it won't affect the 
former. This might be possible or not depending on the structure of 
your input files.
If you omit the \book block in above example and place the include 
between the two bookparts, it should work fine.





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

Re: git-cl upload to existing Allura Thread generates 404

[Federico Bruni]

Il giorno sab 9 mar 2019 alle 11:40, James  ha 
scritto:
I can create a new case with git-cl but trying to update an existing 
ticket always results in a 404


I saw that John Mandereau had also reported this a week or so back.

I don't have the skills to understand what to do in the git-cl python 
files - else I'd have a go at fixing it myself :) I am guessing that 
the URL/API to post to a new thread has changed recently.





Not so recently.
I think Harm was the first to report this bug, then I confirmed the 
problem some weeks after.





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

Re: slashedGrace and acciaccatura missing slash for multiple notes

[Federico Bruni]

Il giorno dom 17 feb 2019 alle 19:42, Vanessa Sabino 
 ha scritto:
I could get the slash to show up for a single grace note, but the 
music I'm
trying to reproduce contains a group with two grace notes and in that 
case

the slash didn't show up. Here is an example:

\version "2.18.2"
\relative c' {
  g' ( \slashedGrace {a16 g} f4) g
}



Ciao Vanessa, thanks for the report.

As far as I can see, it's a known limitation.
See:
https://sourceforge.net/p/testlilyissues/issues/1333/
http://lsr.di.unimi.it/LSR/Snippet?id=721

Best
Federico




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

Re: Double backslash typos in the german documentation

[Federico Bruni]

Il giorno mar 29 gen 2019 alle 12:40, Pierre Perol-Schneider 
 ha scritto:

Hi BugSquad,
At least those paragraphs have backslashes typos:
-

-

-





Hi Pierre

No need to create an issue in the tracker.
This is an easy fix and I've just pushed it to the translation branch.

$ git grep -n -A2 '^@node The tweak command' Documentation/notation/
Documentation/notation/changing-defaults.itely:2257:@node The tweak 
command
Documentation/notation/changing-defaults.itely-2258-@subsection The 
@code{\tweak} command

Documentation/notation/changing-defaults.itely-2259-

$ git grep -n 'tweak' Documentation/de/
Documentation/de/notation/changing-defaults.itely:2086:@subsection Der 
@code{\\tweak}-Befehl





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

Doc: NR 4.2.2 layout-set-staff-size warning

[Federico Bruni]

Hi

In the Notation Reference, chapter 4.2.2, there's this warning:

layout-set-staff-size does not change the distance between the staff 
lines.


What does it mean with "distance between the staff lines"?
Isn't it the staff height? (as the distance between the staff lines is 
equal)


layout-set-staff-size does print the correct staff height, so I don't 
understand what this warning is about.

I'm missing something? Or documentation is not up-to-date?
I suspect the latter, since `git log --grep layout-set-staff-size` 
shows some comments which suggest it didn't use to work fine. For 
example:


commit b38989c86d64ef41025672f9bd2d2fcfd6cd700e
Author: David Kastrup <...>
Date: Thu Nov 13 23:29:10 2014 +0100

Issue 216/2: Adapt repeat-sign-* regtests
Since layout-set-staff-size now gets staffsize right, the regtests
should no longer compensate for bad staffsize.







Minimal example:

\version "2.19.82"

mus = \relative {
c'4. d8 e2
}

% Default is 20pt.
\score {
\new Staff \mus
\layout { }
}

% Explicit 20pt.
\score {
\new Staff \mus
\layout {
#(layout-set-staff-size 20)
}
}

% 14 pt
\score {
\new Staff \mus
\layout {
#(layout-set-staff-size 14)
}
}

% 25pt
\score {
\new Staff \mus
\layout {
#(layout-set-staff-size 25.2)
}
}





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

Re: Broken links on the website

[Federico Bruni]

Il giorno gio 22 nov 2018 alle 2:46, David Kastrup  ha 
scritto:

Urs Liska  writes:


 Am 22.11.18 um 00:24 schrieb Barbara Mroczek:

 Hi,

 on site http://lilypond.org/help-us.html, in sections Simple tasks
 and Advanced tasks all links are broken.



 For some reason they all point to a not-yet-existent 2.21 
documentation.


That would be broken.  The VERSION file currently reads:

PACKAGE_NAME=LilyPond
MAJOR_VERSION=2
MINOR_VERSION=21
PATCH_LEVEL=0
MY_PATCH_LEVEL=
VERSION_STABLE=2.18.2
VERSION_DEVEL=2.19.82

and VERSION_STABLE and VERSION_DEVEL are the versions that should 
refer

to installed web sites.  Can someone figure out where
MAJOR_VERSION/MINOR_VERSION gets into generated links?




It should be explained here:
http://lilypond.org/doc/v2.19/Documentation/contributor/website-build

"create-version-itexi.py parses the file VERSION in the top source dir. 
It contains:"


etc.

BTW, see also this recent discussion:
http://lists.gnu.org/archive/html/lilypond-user/2018-07/msg00323.html




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

Doc: typo in keyboards.itely

[Federico Bruni]

$ git grep -n tremelo
Documentation/notation/keyboards.itely:644:@item A 
@notation{bisbigliando} is written as a tremelo @ref{Tremolo


tremelo > tremolo

Can anybody push a fix?

Thanks
Federico


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

snippet "Accordion register symbols"

[Federico Bruni]

http://lsr.di.unimi.it/LSR/Item?id=929

This snippet contains a typo and a wrong link to NR:

 texidoc = "
Accordion register symbols are available as @code{\\markup} as well as
as standalone music events (as register changes tend to occur between
actual music events. Bass registers are not overly standardized. The
available commands can be found in 'Accordion Registers' in the
Notation Reference.

"

1. typo: there's a missing closing bracket after "music events".

2. There's no 'Accordion Registers' node anymore in the NR:

$ git grep '@node Accordion' Documentation/notation
Documentation/notation/keyboards.itely:586:@node Accordion
Documentation/notation/notation-appendices.itely:1152:@node Accordion 
glyphs


Also, shouldn't we use a cross-ref to link from Snippet to NR manual? 
So it should be:


 available commands can be found in @ruser{Discant symbols}

BTW, even if not used anymore in the documentation, wrong node name is 
also in this obsolete snippet:

http://lsr.di.unimi.it/LSR/Item?id=194

No need to open an issue, I think, since these changes must be made on 
the LSR.


Thanks
Federico


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

Re: obstacles to installation

[Federico Bruni]

Il giorno sab 6 ott 2018 alle 21:12, James Lowe  ha 
scritto:

Hello Devon.

On Sat, 6 Oct 2018 14:31:23 -0400, Devon Sean McCullough 
 wrote:



 These instructions lead nowhere, making it hard to install:

 http://lilypond.org/doc/v2.19/Documentation/topdocs/INSTALL.html
 
	404	http://lilypond.org/doc/v2.19/Documentation/topdocs/web#download


 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 
	404	http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs


Peace
--Devon


That's not really much information for me to be of any help to you.




James, 404 is page not found.
In fact if you go to the first link and click on Download under 1.1 
paragraph, you'll get to the second link, which is not found.


BTW, if you google "lilypond install", that is the second page listed 
after downloads page.


The file Documentation/topdocs/INSTALL.texi includes 
Documentation/included/compile.itexi, where you can see:


   Pre-compiled binaries are available on the @rweb{Download} page.

so the @rweb{Download} is expanding to web#download relative to current 
directory (Documentation/topdocs). I don't know why it's not using the 
correct path...


$ git grep "@*{Download}"
Documentation/included/compile.itexi:31:are available on the 
@rweb{Download} page.

Documentation/web/news-old.itexi:3199:@ref{Download}.




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

Re: Feature request: paper variable for odd-only or even-only pagination

[Federico Bruni]

Il giorno mer 12 set 2018 alle 11:54, Aaron Hill 
 ha scritto:


P.S.  My Italian is rather lacking, so I only just realized I have 
been saying "primo/secondo" as opposed to "prima/seconda".  Is this a 
case of grammatical gender, or have I been using the wrong part of 
speech?




I guess it's related to part, which in italian is "parte" (female 
noun). Female adjectives ends with -a as in "prima/seconda".





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

[LSR] multi-measure-rest-length-control.ly snippet should not use \compressFullBarRests

[Federico Bruni]

Hi folks

Bug Squad, this does not require a new issue in the tracker, but just 
someone who can fix the snippet on the LSR website.


There's a recent snippet file imported from LSR which contains 
\compressFullBarRests.


$ git grep \compressFullBarRests Documentation/snippets
Documentation/snippets/multi-measure-rest-length-control.ly:25: 
\compressFullBarRests
Documentation/snippets/new/multi-measure-rest-length-control.ly:17: 
\compressFullBarRests



Given this commit:

commit ba9a8dc730bb3a681455150bc0a3eef0976523af
Author: Trevor Daniels 
Date: Fri May 1 22:56:47 2015 +0100

   Issue 3687 (part 2): Amend docs to use \compressMMRests

 Amend the examples in the LM and NR to use the \compressMMRests
 music function rather than the predefs \compressFullBarRests and
 \expandFullBarRests to avoid advocating the use of techniques
 which may have undesirable side effects.


we should replace it with \compressMMRests.
Who can do this change in the LSR?

Thanks
Federico

PS Frescobaldi auto-completion is currently suggesting only 
\compressFullBarRests.

I've opened a new issue in the python-ly package:
https://github.com/wbsoft/python-ly/issues/130




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

Re: musicxml2ly produces unexpected EOF in .ly file

[Federico Bruni]

Il giorno dom 26 ago 2018 alle 16:12, David Kastrup  ha 
scritto:

Victor Rouanet  writes:


 Le 26/08/2018 à 15:15, Victor Rouanet a écrit :

 Same result for me. According to Phil Homes in the lilypond-user
 topic, the shlex module (used by musicxml2ly in utilities.py) 
didn't

 support unicode input prior to Python 2.7.3.

 According to David Wright*
 I misread.


So we should upgrade Python in GUB?



https://github.com/gperciva/gub/pull/6

I hope more people will be able to run GUB successfully. Only Phil can 
run it at the moment?

I look forward to Knut's patch.




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

Re: musicxml2ly produces unexpected EOF in .ly file

[Federico Bruni]

Victor, please keep the list in Cc.

I was using lilypond packaged by Fedora, which uses python2 installed 
on the system (currently 2.7.15).
I've now installed 2.19.82 from lilypond.org, which uses the bundled 
python .

There's something wrong:

$ file jafanosumu.ly
jafanosumu.ly: data

There's some bad encoding. See attached file.

$ ls -lh ~/.local/lilypond/usr/bin/python*
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python2.4


It's just my installation?
This release had also some problems in the PDF manuals...

Il giorno ven 24 ago 2018 alle 13:19, Victor Rouanet 
<"victor.rouanet"@gmx.fr> ha scritto:
I use debian 9 (stretch). I tried to redownload the raw XML from the 
link I provided (with wget) and got the same error.


Do you know what python version were used by musicxml2ly when you 
tried?


Yes, I was initially planning to report an issue about this wrong 
output, but I upgraded lilypond before and had to edit the 
musicexp.py again



Le 24/08/2018 à 12:02, Federico Bruni a écrit :



Il giorno ven 24 ago 2018 alle 11:33, Victor Rouanet 
<"victor.rouanet"@gmx.fr> ha scritto:

Good morning,

I'm having an issue with musicxml2ly, installed with a manually 
downloaded version on lilypond 2.19.82.


I exported a musicxml file from Musescore, then converted it to 
lilypond source with musicxml2ly without error. However, when I 
try to compile it with lilypond, I get the following error: 
"syntax error, unexpected end of input, expecting \header". Here 
is the full output: https://hastebin.com/raw/navufewufu


And the musicxml file content: https://hastebin.com/jafanosumu.xml

This error happened with any musicxml file I tried to convert from 
Musescore.


After some research, I found this topic on the lilypond-user list 
http://lilypond.1069038.n5.nabble.com/XML-to-ly-and-Lilypond-again-td203101.html 
which looks like exactly the same.
The suggested workaround (replacing 
split_string_and_preserve_doublequoted_substrings by string.split 
in musicexp.py:139) makes it work, but I'm wondering if I'm doing 
something wrong.





Which operating system are you using?

On Linux, I don't get any EOF error.
Find attached the .ly file generated by musicxml2ly version 2.19.82.
There's a wrong input though:

$ /usr/bin/lilypond jafanosumu.ly
GNU LilyPond 2.19.82
Processing `jafanosumu.ly'
Parsing...
jafanosumu.ly:30:17: error: syntax error, unexpected '^'
   \tempo 4=80
   ^\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:30:18: error: markup outside of text script or 
\lyricmode

   \tempo 4=80 ^
\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:32:34: error: syntax error, unexpected '_'
   \mark \markup { \box { A } }
_\markup{ \italic {sempre forte} } | 
% 2
jafanosumu.ly:32:35: error: markup outside of text script or 
\lyricmode

   \mark \markup { \box { A } } _
 \markup{ \italic {sempre forte} } | 
% 2

jafanosumu.ly:33:51: error: syntax error, unexpected '^'
   \stemDown e4 \stemDown c4 \stemUp g2 \breathe
 ^\markup{ \italic
jafanosumu.ly:33:52: error: markup outside of text script or 
\lyricmode

   \stemDown e4 \stemDown c4 \stemUp g2 \breathe ^
  \markup{ \italic
jafanosumu.ly:41:5: error: errors found, ignoring music expression

   <<
fatal error: failed files: "jafanosumu.ly"





\version "2.19.82"
% automatically converted by musicxml2ly from jafanosumu.xml
\pointAndClickOff

\header {
encodingsoftware =  "MuseScore 2.3.2" 
encodingdate =  "2018-08-24" 
title =  Testing
}

#(set-global-staff-size 20.1587428571)
\paper {

paper-width = 21.01\cm
paper-height = 29.69\cm
top-margin = 1.0\cm
bottom-margin = 2.0\cm
left-margin = 1.0\cm
right-margin = 1.0\cm
indent = 1.61615384615\cm
short-indent = 1.29292307692\cm
}
\layout {
\context { \Score
autoBeaming = ##f
}
}
PartPOneVoiceOne =  \relative c' {
\clef "treble" \key c \major \numericTimeSignature\time 4/4 | % 1
\tempo 4=80 ^\markup{ \bold {Moderato} }
| % 1
\stemUp c4 _\f \stemUp e4 \stemUp g4 \stemDown c4 | % 2
\mark \markup { \box { A } } _\markup{ \italic
{sempre forte} } | % 2
\stemDown e4 \stemDown c4 \stemUp g2 \breathe ^\markup{
\italic {rit.} } | % 3
\stemUp c,4 r4 r2 \bar "|."
}


% The score definition
\score {
<<

\new Staff
<<
\set Staff.instrumentName = "Piano"
\set Staff.shortInst

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Federico Bruni]

Il giorno dom 26 ago 2018 alle 11:43, Thomas Morley 
 ha scritto:


Agreed. Also, why not delete some of the superfluous brackets in the
markup? Only keeping the surrounding ones for better viewable
structure. I.e.
\markup { \italic \fontsize #-2 "harm. 12" }

Could you provide a patch?



Pierre, if you want to send a patch, here's the issue:
https://sourceforge.net/p/testlilyissues/issues/5404/

Thanks
Federico




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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Federico Bruni]

Il giorno dom 26 ago 2018 alle 11:14, Pierre Perol-Schneider 
<"pierre.schneider.paris"@gmail.com> ha scritto:

Hi Bug Squad,
See:
http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
And:
http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes

1. I don't understand the reason to put the NoteHead defs at a Staff 
level.


I guess there isn't any reason, since Note_heads_engraver is part of 
the Voice context.


2. Maybe a whole note is not the best example to show the 
'harmonic-mixed

result.



Why? Because the diamond shape is more clear when the head is all black?


How about changing this snieppet:

\relative c' {
  \clef "treble_8"
  \override Staff.NoteHead.style = #'harmonic-mixed
  d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
}

To:

\relative c' {
  \clef "treble_8"
  \override NoteHead.style = #'harmonic-mixed
  d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
}

Cheers,
Pierre
___



I agree. I will add an issue to the tracker.




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

Re: musicxml2ly produces unexpected EOF in .ly file

[Federico Bruni]

Il giorno ven 24 ago 2018 alle 12:11, Paul Hodges  ha 
scritto:
I was planning to report this.  What's happening is that strings are 
being converted to 16-bit Unicode instead of UTF8, and so they are 
interspersed with nulls.  If you remove the nulls with a capable 
editor, then that issue goes away (you can do it with Frescobaldi, 
but it's non-intuitive - copy part of a string into the replace 
dialogue, the nulls appear as spaces, delete everything except one 
null then replace with nothing throughout the file).




Please let us know your operating system and LilyPond version.
Can you also attach the problematic .ly file?
Thanks




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

Re: musicxml2ly produces unexpected EOF in .ly file

[Federico Bruni]

Il giorno ven 24 ago 2018 alle 11:33, Victor Rouanet 
<"victor.rouanet"@gmx.fr> ha scritto:

Good morning,

I'm having an issue with musicxml2ly, installed with a manually 
downloaded version on lilypond 2.19.82.


I exported a musicxml file from Musescore, then converted it to 
lilypond source with musicxml2ly without error. However, when I try 
to compile it with lilypond, I get the following error: "syntax 
error, unexpected end of input, expecting \header". Here is the full 
output: https://hastebin.com/raw/navufewufu


And the musicxml file content: https://hastebin.com/jafanosumu.xml

This error happened with any musicxml file I tried to convert from 
Musescore.


After some research, I found this topic on the lilypond-user list 
http://lilypond.1069038.n5.nabble.com/XML-to-ly-and-Lilypond-again-td203101.html 
which looks like exactly the same.
The suggested workaround (replacing 
split_string_and_preserve_doublequoted_substrings by string.split in 
musicexp.py:139) makes it work, but I'm wondering if I'm doing 
something wrong.





Which operating system are you using?

On Linux, I don't get any EOF error.
Find attached the .ly file generated by musicxml2ly version 2.19.82.
There's a wrong input though:

$ /usr/bin/lilypond jafanosumu.ly
GNU LilyPond 2.19.82
Processing `jafanosumu.ly'
Parsing...
jafanosumu.ly:30:17: error: syntax error, unexpected '^'
   \tempo 4=80
   ^\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:30:18: error: markup outside of text script or \lyricmode
   \tempo 4=80 ^
\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:32:34: error: syntax error, unexpected '_'
   \mark \markup { \box { A } }
_\markup{ \italic {sempre forte} } | % 
2

jafanosumu.ly:32:35: error: markup outside of text script or \lyricmode
   \mark \markup { \box { A } } _
 \markup{ \italic {sempre forte} } | % 
2

jafanosumu.ly:33:51: error: syntax error, unexpected '^'
   \stemDown e4 \stemDown c4 \stemUp g2 \breathe
 ^\markup{ \italic
jafanosumu.ly:33:52: error: markup outside of text script or \lyricmode
   \stemDown e4 \stemDown c4 \stemUp g2 \breathe ^
  \markup{ \italic
jafanosumu.ly:41:5: error: errors found, ignoring music expression

   <<
fatal error: failed files: "jafanosumu.ly"



\version "2.19.82"
% automatically converted by musicxml2ly from jafanosumu.xml
\pointAndClickOff

\header {
encodingsoftware =  "MuseScore 2.3.2"
encodingdate =  "2018-08-24"
title =  Testing
}

#(set-global-staff-size 20.1587428571)
\paper {

paper-width = 21.01\cm
paper-height = 29.69\cm
top-margin = 1.0\cm
bottom-margin = 2.0\cm
left-margin = 1.0\cm
right-margin = 1.0\cm
indent = 1.61615384615\cm
short-indent = 1.29292307692\cm
}
\layout {
\context { \Score
autoBeaming = ##f
}
}
PartPOneVoiceOne =  \relative c' {
\clef "treble" \key c \major \numericTimeSignature\time 4/4 | % 1
\tempo 4=80 ^\markup{ \bold {Moderato} } | % 1
\stemUp c4 _\f \stemUp e4 \stemUp g4 \stemDown c4 | % 2
\mark \markup { \box { A } } _\markup{ \italic {sempre forte} } | % 2
\stemDown e4 \stemDown c4 \stemUp g2 \breathe ^\markup{ \italic
{rit.} } | % 3
\stemUp c,4 r4 r2 \bar "|."
}


% The score definition
\score {
<<

\new Staff
<<
\set Staff.instrumentName = "Piano"
\set Staff.shortInstrumentName = "Pno."

\context Staff << 
\mergeDifferentlyDottedOn\mergeDifferentlyHeadedOn
\context Voice = "PartPOneVoiceOne" {  \PartPOneVoiceOne }
>>
>>

>>
\layout {}
% To create MIDI output, uncomment the following line:
%  \midi {\tempo 4 = 79.9998 }
}

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

Re: Freedom page links kernel.org as GNU/Linux

[Federico Bruni]

Il giorno ven 17 ago 2018 alle 2:14, Rafael Fontenelle 
 ha scritto:

Hello, Federico

Em sex, 27 de jul de 2018 às 01:57, Federico Bruni
 escreveu:


 https://sourceforge.net/p/testlilyissues/issues/5392/

 Rafael, let me know if you find other issues while translating the
 website and I'll add them to issue #5392.



My translation was already committed. Maybe it is time to apply
changes of #5392 ?



I will do it next week




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

Re: http://lilypond.org/contact.html

[Federico Bruni]

   I think the current 'Portuguese group" - related to the language - is
   more inclusive of "Brazilian portuguese group", which may seem limited
   to the portuguese spoken in Brazil?
   When we say "French group" we don't have to specify all the countries
   where french is spoken. Same for spanish.
   I wouldn't change it.
   Il 03 ago 2018 10:38, Rafael Fontenelle  ha
   scritto:

 Hello,
 When listing contact for "Other languages", the "Portuguese group"
 is
 listed, however the URL leads to a Google Groups named
 "LilyPond-Brasil". "Portuguese group" seems like it is an European
 Portuguese group.
 So, "Portuguese group" should be "Brazilian Portuguese group"
 (related
 to the language) or "Brazilian group" (related to the people).
 Best regards,
 Rafael Fontenelle
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lilypond-invoke-editor runs twice (2.19.82)

[Federico Bruni]

Il giorno mer 1 ago 2018 alle 17:21, Federico Bruni 
 ha scritto:


The first of below files is actually a symlink to another file:
lilypond-invoke-editor -> /usr/local/bin/lilypond-wrapper.guile

I made a backup copy of that file, then removed "-e main" from the 
original and now lilypond-invoke-editor is run only once. Good catch!


I'll wait for comments from developers and then add an issue to the 
tracker.

I guess it's a GUB issue.



I've added it to the tracker:
https://sourceforge.net/p/testlilyissues/issues/5396/




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

Re: lilypond-invoke-editor runs twice (2.19.82)

[Federico Bruni]

Hey Aaron

I've just tried using nano as editor and I see that indeed I have to 
close it twice:


$ lilypond-invoke-editor textedit:///home/myfile.ily:1:3:4
lilypond-invoke-editor (GNU LilyPond) 2.19.82
lilypond-invoke-editor (GNU LilyPond) 2.19.82

When I use gedit, it's the same: I close one window and then another 
one pops up.


The first of below files is actually a symlink to another file:
lilypond-invoke-editor -> /usr/local/bin/lilypond-wrapper.guile

I made a backup copy of that file, then removed "-e main" from the 
original and now lilypond-invoke-editor is run only once. Good catch!


I'll wait for comments from developers and then add an issue to the 
tracker.

I guess it's a GUB issue.

PS
I've just realized that the bash script is what I needed to make 
lilypond-invoke-editor work on Mac and Windows. Tested successfully on 
Mac only so far.
I'll try to write a blog post about this before I go in vacation (next 
Monday).


Thanks
Federico


Il giorno mer 11 lug 2018 alle 0:35, Aaron Hill 
 ha scritto:
While getting point-and-click working in my setup, I ran across this 
minor issue.


After installation, there are two `lilypond-invoke-editor` files:

/usr/local/bin/lilypond-invoke-editor
/usr/local/lilypond/usr/bin/lilypond-invoke-editor

The first is a simple script that sets some environment and invokes 
the LilyPond version of Guile with the second file, which is the 
actual Scheme program.  The script uses the `-e main` option which 
causes Guile to invoke the named function; however, there is already 
an explicit invocation of `main` at the end of the Scheme program.  
This results in the functionality running twice.


I suppose that, depending on how you have your EDITOR or LYEDITOR 
variables configured, you might not notice a double launch; but I was 
certainly confused at first why I was getting repeated behavior.


-- Aaron Hill

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



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

Re: http://lilypond.org/productions.html

[Federico Bruni]

Il giorno mar 31 lug 2018 alle 14:06, Simon Albrecht 
<"simon.albrecht"@mail.de> ha scritto:

On 31.07.2018 13:07, Rafael Fontenelle wrote:

1-  In this page there is the following snippet of paragraph:

"He has also worked on the score and parts for an arrangement of
Moussurgsky’s Boris Godounov for wind quartet"

On the other side, a few paragraphs below we find:

"Mussorgsky’s Pictures at an exhibition[...]"

Searching the web, I found "Mussorgsky" and "Godunov" (without 'o'
from 'ou') in pages like e.g. Wikipedia[1], but found no occurrence
"Moussurgsky" and "Godounov". So, just checking: is the spelling
correct?

[1]https://en.wikipedia.org/wiki/Modest_Mussorgsky


Cyrillic transliteration is always subject to discussion. The 
versions with ‘ou’ hint French transliteration, traditional 
English transliteration is always ‘Mussorgsky’ and ‘Godunov’, 
the former is scientifically transliterated as ‘Musorgskiy’ or 
‘Musorgskij’. The only thing that’s completely uncontroversial 
is that the second ‘u’ in ‘Moussurgsky’ is a typo.
Like most of the time, Wikipedia follows a very well-established 
policy and it’s perfectly OK to follow them.




Mutopia uses the same form:
http://www.mutopiaproject.org/cgibin/make-table.cgi?Composer=MussorgskyM

Rafael, I'll add this as part of issue 5392:
https://sourceforge.net/p/testlilyissues/issues/5392/

Thanks
Federico




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

Re: Freedom page links kernel.org as GNU/Linux

[Federico Bruni]

Il giorno gio 26 lug 2018 alle 18:37, Rafael Fontenelle 
 ha scritto:

Em qui, 26 de jul de 2018 às 12:41, Federico Bruni
 escreveu:


 I'd rather link to a page which is about GNU/Linux distros. As 
LilyPond

 is a GNU project, I would use
 [GNU/Linux](https://www.gnu.org/distros/distros.html).

 What do you think?



Looks good to me!



https://sourceforge.net/p/testlilyissues/issues/5392/

Rafael, let me know if you find other issues while translating the 
website and I'll add them to issue #5392.


Thanks
Federico




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

Re: Freedom page links kernel.org as GNU/Linux

[Federico Bruni]

Il giorno gio 26 lug 2018 alle 8:20, Rafael Fontenelle 
 ha scritto:

In the below paragraph of http://lilypond.org/freedom.html

" “Gift culture”: the Free Software movement has created many 
great

software projects, such as GNU/Linux, Mozilla Firefox, and Battle for
Wesnoth. Having benefitted from these projects, some developers want
to “give back” to the community. "

"GNU/Linux" is a link to http://kernel.org, which is not correct
because GNU is the system and Linux is the kernel (more info[1]). How
about have "GNU" as a link to http://www.gnu.org and "Linux" as a link
to http://kernel.org?

[1] https://www.gnu.org/gnu/linux-and-gnu.html




I agree that the link should be changed.

However, [GNU](gnu.org) is already linked in that page.
kernel.org is a "technical" page.

I'd rather link to a page which is about GNU/Linux distros. As LilyPond 
is a GNU project, I would use 
[GNU/Linux](https://www.gnu.org/distros/distros.html).


What do you think?




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

Re: mac os x page: example block is cut off

[Federico Bruni]

Il giorno sab 7 lug 2018 alle 14:33, Federico Bruni 
 ha scritto:

[...]

I think we can safely remove it.

The fixed width was introduced with below commit by Trevor in 2010.
I don't know how browsers behaved 8 years ago, but I can see now that 
Firefox and Chrome will add a scrollbar automatically if the example 
doesn't fit the space available.
If there's no objection and I'm not missing anything, I would send a 
patch to remove the width from that CSS class.



Author: Trevor Daniels 
Date:   Fri Aug 6 12:51:03 2010 +0100

   Web: Issue 958 (partial) Scroll wide examples

- Examples on web pages which are divided into two columns
  run off the right-hand edge when the width of the browser
  window is reduced.  This patch adds a horizontal scroll
  bar to examples which do this.

diff --git a/Documentation/css/lilypond-web.css 
b/Documentation/css/lilypond-web.css

index fd883b5b51..c101fd15ee 100644
--- a/Documentation/css/lilypond-web.css
+++ b/Documentation/css/lilypond-web.css
@@ -891,6 +891,18 @@ div.color4 h3 {
  line-height: 0.8;
}

+.example {
+  position: relative;
+  left: -3em;
+}
+
+.h-scroll-auto {
+  position: relative;
+  left: 1em;
+  width: 240px;
+  overflow: auto;
+}
+



It's `overflow: auto` which cured the problem and adds the scrollbar 
when the text does not fit the window anymore.

I don't see any reason for a fixed width.




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

mac os x page: example block is cut off

[Federico Bruni]

Hi all

See this page: http://lilypond.org/macos-x.html

In the second column, second item of the ordered list, there's a quite 
long line of code block. Same for the last code block in that column.


The width of the code block is too short. This happens on all browsers, 
of course. But you can scroll horizontally using the scrollbar.
The problem is that certain browsers hide the horizontal bar, for 
example Epiphany on Linux, Safari on Mac and Adblock Browser on Android 
(see attached screenshot). This is annoying because Mac Os X users will 
likely visit that page using Safari and feel confused about that short 
line. This just occurred to me (I happened to use a Mac laptop).


The width is fixed and set to 250px in the class `.h-scroll-auto` of 
lilypond-website.css

The class is used only in that page:


$ git grep .h-scroll-auto Documentation/web
Documentation/web/download.itexi:316:@divClass{h-scroll-auto}
Documentation/web/download.itexi:364:@divClass{h-scroll-auto}


I think we can safely remove it.

The fixed width was introduced with below commit by Trevor in 2010.
I don't know how browsers behaved 8 years ago, but I can see now that 
Firefox and Chrome will add a scrollbar automatically if the example 
doesn't fit the space available.
If there's no objection and I'm not missing anything, I would send a 
patch to remove the width from that CSS class.



Author: Trevor Daniels 
Date:   Fri Aug 6 12:51:03 2010 +0100

   Web: Issue 958 (partial) Scroll wide examples

- Examples on web pages which are divided into two columns
  run off the right-hand edge when the width of the browser
  window is reduced.  This patch adds a horizontal scroll
  bar to examples which do this.

diff --git a/Documentation/css/lilypond-web.css 
b/Documentation/css/lilypond-web.css

index fd883b5b51..c101fd15ee 100644
--- a/Documentation/css/lilypond-web.css
+++ b/Documentation/css/lilypond-web.css
@@ -891,6 +891,18 @@ div.color4 h3 {
  line-height: 0.8;
}

+.example {
+  position: relative;
+  left: -3em;
+}
+
+.h-scroll-auto {
+  position: relative;
+  left: 1em;
+  width: 240px;
+  overflow: auto;
+}
+




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

Re: Documentation Error? set-global-staff-size vs layout-set-staff-size

[Federico Bruni]

Hi Aaron


Il giorno gio 24 mag 2018 alle 22:30, Aaron Laws  
ha scritto:



The documentation at
http://lilypond.org/doc/v2.19/Documentation/notation/setting-the-staff-size
makes it sound like set-global-staff-size and layout-set-staff-size 
only
differ in their scope (the former affects the whole book, and the 
latter

only the score pertaining to a particular layout). Attached is a Tiny
Example using set-global-staff-size. Reproduction steps:
1. Compile the example to "global.pdf".
2. Move the comment from line 4 to line 2
3. Compile the modified example to "layout.pdf"
If the documentation is correct, I would expect set-global-staff-size 
and

layout-set-staff-size to work the same when there is only one staff.
Comparing the resulting global.pdf and layout.pdf shows that this is 
not

the case.

I have a book with two \scores in it, and would like one to have a 
larger
set-global-staff-size than the other. I'll continue experimenting and 
see
if I can get what I want, but I thought I would drop a note about 
this.


I can reproduce your problem in 2.18.2 but not in 2.19.81.
So it seems it's been fixed. Can you confirm?

Latest development release is here:
http://lilypond.org/downloads/binaries/




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

Re: point-and-click to "other" editors

[Federico Bruni]

Il giorno gio 14 giu 2018 alle 6:52, Federico Bruni 
 ha scritto:



2. Configure other editors
IIUC, lilypond-invoke editors is set up to work well with emacs, gvim 
and nedit, in that I can simply write:


LYEDITOR=emacsclient

and this will be translated to:

emacsclient --no-wait +%(line)s:%(column)s %(file)s

Now what if I want to use a different editor?
I did it in the past with Frescobaldi (to get point-and-clcik from an 
external PDF), but I cannot remember how.
I'm now trying gedit, which does support  opening a file in a certain 
point.


I've tried the following but none works:

LYEDITOR=gedit # this will open gedit but not in the desired 
line:column
LYEDITOR=`gedit +%(line)s:%(column)s %(file)s` # this is not correct 
syntax, as 'source ~/.bashrc' complains




I was using the wrong syntax. I should have wrapped the command in "". 
I'll add an explicit example in the documentation.


Here's an editor I'm testing now:

export LYEDITOR="geany --line %(line)s --column %(column)s %(file)s"





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

Re: point-and-click to "other" editors

[Federico Bruni]

Il giorno ven 15 giu 2018 alle 9:39, Knut Petersen 
 ha scritto:

Hi Federico

So I'm using:

("gedit" . "gedit --wait +%(line)s:%(column)s %(file)s")

but I'm still getting multiple windows.
Any idea?



I'll try asking to gedit developers.


With the following entries I don't see any problem for gedit and kate 
on an openSuSE Tumbleweed system.


("gedit" . "gedit --wait +%(line)s:%(column)s %(file)s")
("kate" . "kate -b -l%(line)s -c%(column)s %(file)s")




I've tried it in GNOME Classic (instead of gnome shell) and it works, 
even if I see a new window overlapping and replacing the old window. 
Not nice, but only one window remains after several clicks on the PDF.

I've asked for explanations here:
https://gitlab.gnome.org/GNOME/gedit/issues/45




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

Re: point-and-click to "other" editors

[Federico Bruni]

Il giorno gio 14 giu 2018 alle 7:48, Federico Bruni 
 ha scritto:



Il giorno gio 14 giu 2018 alle 7:15, Federico Bruni 
 ha scritto:


I've now found this in scm/editor.scm

(define editor-command-template-alist
 '(("emacs" .  "emacsclient --no-wait +%(line)s:%(column)s %(file)s 
|| (emacs +%(line)s:%(column)s %(file)s&)")

   ("gvim" . "gvim --remote +:%(line)s:norm%(column)s %(file)s")
   ("uedit32" . "uedit32 %(file)s -l%(line)s -c%(char)s")
   ("nedit" . "nc -noask +%(line)s %(file)s")
   ("gedit" . "gedit +%(line)s %(file)s")
   ("jedit" . "jedit -reuseview %(file)s +line:%(line)s")
   ("syn" . "syn -line %(line)s -col %(char)s %(file)s")
   ("lilypad" . "lilypad +%(line)s:%(char)s %(file)s")))

So this should be sufficient:

LYEDITOR=gedit

But it doesn't work, as it always jump to the first line of music, 
no matter what you click on PDF. And it launches a new gedit window 
every time you click on the PDF.

Also, it should be rewritten to specify the column as well:

("gedit" . "gedit +%(line)s:%(column)s %(file)s")



The command above works, I've built the source and tested it.
I'm trying also to keep only one window open, even if I click on the 
PDF multiple times. gedit has the --wait option,  which would seem to 
be what I need:


-w, --wait
 Open files and block the gedit process.

So I'm using:

("gedit" . "gedit --wait +%(line)s:%(column)s %(file)s")

but I'm still getting multiple windows.
Any idea?



I'll try asking to gedit developers.

Next week I'll send a patch to fix gedit command, add a couple of 
editors (Atom and Visual Studio Code) and improve the documentation.
It's not clear to me if these commands can only be "hard-coded" in 
lilypond source or if I may add in LYEDITOR, using a special syntax, 
the command of an editor not listed in scm/editor.scm.


I'll be offline until Wednesday.




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

Re: point-and-click to "other" editors

[Federico Bruni]

Il giorno gio 14 giu 2018 alle 7:15, Federico Bruni 
 ha scritto:


I've now found this in scm/editor.scm

(define editor-command-template-alist
 '(("emacs" .  "emacsclient --no-wait +%(line)s:%(column)s %(file)s 
|| (emacs +%(line)s:%(column)s %(file)s&)")

   ("gvim" . "gvim --remote +:%(line)s:norm%(column)s %(file)s")
   ("uedit32" . "uedit32 %(file)s -l%(line)s -c%(char)s")
   ("nedit" . "nc -noask +%(line)s %(file)s")
   ("gedit" . "gedit +%(line)s %(file)s")
   ("jedit" . "jedit -reuseview %(file)s +line:%(line)s")
   ("syn" . "syn -line %(line)s -col %(char)s %(file)s")
   ("lilypad" . "lilypad +%(line)s:%(char)s %(file)s")))

So this should be sufficient:

LYEDITOR=gedit

But it doesn't work, as it always jump to the first line of music, no 
matter what you click on PDF. And it launches a new gedit window 
every time you click on the PDF.

Also, it should be rewritten to specify the column as well:

("gedit" . "gedit +%(line)s:%(column)s %(file)s")



The command above works, I've built the source and tested it.
I'm trying also to keep only one window open, even if I click on the 
PDF multiple times. gedit has the --wait option,  which would seem to 
be what I need:


-w, --wait
 Open files and block the gedit process.

So I'm using:

("gedit" . "gedit --wait +%(line)s:%(column)s %(file)s")

but I'm still getting multiple windows.
Any idea?




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

Re: point-and-click to "other" editors

[Federico Bruni]

Il giorno gio 14 giu 2018 alle 6:52, Federico Bruni 
 ha scritto:



2. Configure other editors
IIUC, lilypond-invoke editors is set up to work well with emacs, gvim 
and nedit, in that I can simply write:


LYEDITOR=emacsclient

and this will be translated to:

emacsclient --no-wait +%(line)s:%(column)s %(file)s

Now what if I want to use a different editor?
I did it in the past with Frescobaldi (to get point-and-clcik from an 
external PDF), but I cannot remember how.
I'm now trying gedit, which does support  opening a file in a certain 
point.


I've tried the following but none works:

LYEDITOR=gedit # this will open gedit but not in the desired 
line:column
LYEDITOR=`gedit +%(line)s:%(column)s %(file)s` # this is not correct 
syntax, as 'source ~/.bashrc' complains




I've now found this in scm/editor.scm

(define editor-command-template-alist
 '(("emacs" .  "emacsclient --no-wait +%(line)s:%(column)s %(file)s || 
(emacs +%(line)s:%(column)s %(file)s&)")

   ("gvim" . "gvim --remote +:%(line)s:norm%(column)s %(file)s")
   ("uedit32" . "uedit32 %(file)s -l%(line)s -c%(char)s")
   ("nedit" . "nc -noask +%(line)s %(file)s")
   ("gedit" . "gedit +%(line)s %(file)s")
   ("jedit" . "jedit -reuseview %(file)s +line:%(line)s")
   ("syn" . "syn -line %(line)s -col %(char)s %(file)s")
   ("lilypad" . "lilypad +%(line)s:%(char)s %(file)s")))

So this should be sufficient:

LYEDITOR=gedit

But it doesn't work, as it always jump to the first line of music, no 
matter what you click on PDF. And it launches a new gedit window every 
time you click on the PDF.

Also, it should be rewritten to specify the column as well:

("gedit" . "gedit +%(line)s:%(column)s %(file)s")

If I want to use another editor it should be added in that file?
Or can I set the LYEDITOR variable somehow?




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

point-and-click to "other" editors

[Federico Bruni]

I'd like to suggest some changes in this page of the documentation:
http://lilypond.org/doc/v2.19/Documentation/usage/configuring-the-system-for-point-and-click.html


1. Emacs
I would write that you must add (server-start) to ~/.emacs, otherwise 
you'll get a new Emacs window each time you click on an object in the 
PDF. See this discussion:

https://lists.gnu.org/archive/html/lilypond-user/2013-12/msg01396.html


2. Configure other editors
IIUC, lilypond-invoke editors is set up to work well with emacs, gvim 
and nedit, in that I can simply write:


LYEDITOR=emacsclient

and this will be translated to:

emacsclient --no-wait +%(line)s:%(column)s %(file)s

Now what if I want to use a different editor?
I did it in the past with Frescobaldi (to get point-and-clcik from an 
external PDF), but I cannot remember how.
I'm now trying gedit, which does support  opening a file in a certain 
point.


I've tried the following but none works:

LYEDITOR=gedit # this will open gedit but not in the desired line:column
LYEDITOR=`gedit +%(line)s:%(column)s %(file)s` # this is not correct 
syntax, as 'source ~/.bashrc' complains


Thanks
Federico




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

Re: Bug concerning website's language

[Federico Bruni]

Il giorno gio 31 mag 2018 alle 16:21, Arthur Milchior 
<"arthur.milchior"@ulb.ac.be> ha scritto:

Hi

I do live in Belgium, my computer is configured with French language 
as default. However, I do want to see your website in English.


On each page, I click on «other languages: english»

And each time I click on a link, it opens a page in French.

Which makes me waste a lot of time, since the beginning of the 
tutorial have really small pages.



Can anything be done to correct this, please.

Regards,

Arthur Milchior



Hi Arthur

It's a known problem, see:
https://sourceforge.net/p/testlilyissues/issues/2273/

The workarounds I know of are:

1. set english as first language for the browser you use to read 
LilyPond documentation
2. use a "local documentation", either downloaded from the website or 
from a linux repository or compiled by yourself






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

Re: correction to documentation

[Federico Bruni]

Thanks, added to the tracker:
https://sourceforge.net/p/testlilyissues/issues/5298/


Il giorno mer 28 mar 2018 alle 16:47, "Bradley J. Plohr" 
 ha scritto:
In LM 2.7.2 Displaying chords / Customizing chord names / See also, 
which

is in the file

/usr/share/doc/lilypond-doc/share/doc/lilypond/html/Documentation/notation/displaying-chords.html

​​
the line

Installed Files: ‘scm/chords-ignatzek.scm’, 
‘scm/chord-entry.scm’, ‘ly/

chord-modifier-init.ly’.

should be

Installed Files: ‘scm/chords-ignatzek-names.scm’, 
‘scm/chord-entry.scm’, ‘

ly/chord-modifiers-init.ly’.

​
(Note that there are two additions in this line, "-names" and "s")​
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond



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

Re: lilypond --output=directory is not working

[Federico Bruni]

Il giorno sab 10 mar 2018 alle 19:06, Federico Bruni 
<f...@inventati.org> ha scritto:



Il giorno sab 10 mar 2018 alle 18:18, David Wright 
<lily...@lionunicorn.co.uk> ha scritto:

On Sat 10 Mar 2018 at 16:58:37 (+0100), Federico Bruni wrote:



 Il giorno sab 10 mar 2018 alle 16:26, David Wright
 <lily...@lionunicorn.co.uk> ha scritto:
 >On Sat 10 Mar 2018 at 09:18:59 (+0100), Federico Bruni wrote:
 >> [...]
 >
 >> The documentation in Usage 1,2 is pretty clear:
 >>
 >> -o, --output=FILE or FOLDER
 >
 >I don't recognise this. What is Usage 1,2?

 It's chapter 1.2 of Usage manual.
 Sorry, a typo.. and I should have put a link instead.


Interesting, so the manual and the man page disagree with each other.



Good catch, I've added an issue in the tracker:
https://sourceforge.net/p/testlilyissues/issues/5288/




 No, it's not this.
 See my last email. The problem occurs only in the /tmp directory. 
It

 happens on Debian as well (not only in Fedora).


That helps. Now we can make comparisons. It isn't just the source 
file

whose path is forgotten. When LP changes directory to the output
directory, it loses the / at the beginning of the previous working
directory.

[...]


Waiting for comments from developers here.
I've added bug-lilypond in Cc.



Here's another example of how --output may give unexpected results.
I wonder if this should be better documented or the feature improved...

[output-option]$ tree .
.
|-- Makefile
|-- out
`-- pieces
   |-- hello.ily
   `-- hello.ly

2 directories, 3 files
[output-option]$
[output-option]$ cat pieces/hello.ily
\version "2.18.2"

music = \relative {
 c' d e f
}

myScore = \score {
 \new Staff {
   \music
 }
}
[output-option]$
[output-option]$ cat pieces/hello.ly
\version "2.18.2"

\include "hello.ily"

\header {
 title = "Hello"
}

\myScore



Here's the error:

[output-option]$ lilypond --output=out pieces/hello.ly
GNU LilyPond 2.19.81
Changing working directory to: `out'
Processing `pieces/hello.ly'
Parsing...
/home/fede/tmp/lilypond/output-option/pieces/hello.ly:3:10: error: 
cannot find file: `hello.ily'
(search path: 
`pieces:/home/fede/tmp/lilypond/output-option:/usr/share/lilypond/2.19.81/fonts/svg/:/usr/share/lilypond/2.19.81/fonts/type1/:/usr/share/lilypond/2.19.81/fonts/otf/:/usr/share/lilypond/2.19.81/scm:/usr/share/lilypond/2.19.81/ps:/usr/share/lilypond/2.19.81/ly:')

\include
"hello.ily"
/home/fede/tmp/lilypond/output-option/pieces/hello.ly:9:1: error: 
unknown escaped string: `\myScore'


\myScore
/home/fede/tmp/lilypond/output-option/pieces/hello.ly:9:9: error: 
syntax error, unexpected end of input, expecting '.' or '=' or ','

\myScore

fatal error: failed files: "pieces/hello.ly"


You see that there's pieces in the search path, but it's not the full 
path.

So this is a possible workaround:

[output-option]$ lilypond --output=out `pwd`/pieces/hello.ly
GNU LilyPond 2.19.81
Changing working directory to: `out'
Processing `/home/fede/tmp/lilypond/output-option/pieces/hello.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-bs9QAF'...
Converting to `hello.pdf'...
Deleting `/tmp/lilypond-bs9QAF'...
Success: compilation successfully completed


Another possible workaround (but I prefer the former):

[output-option]$ lilypond --include=`pwd`/pieces --output=out 
pieces/hello.ly

GNU LilyPond 2.19.81
Changing working directory to: `out'
Processing `pieces/hello.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-8YRlv9'...
Converting to `hello.pdf'...
Deleting `/tmp/lilypond-8YRlv9'...
Success: compilation successfully completed














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

Re: lilypond --output=directory is not working

[Federico Bruni]

Il giorno sab 10 mar 2018 alle 18:18, David Wright 
<lily...@lionunicorn.co.uk> ha scritto:

On Sat 10 Mar 2018 at 16:58:37 (+0100), Federico Bruni wrote:



 Il giorno sab 10 mar 2018 alle 16:26, David Wright
 <lily...@lionunicorn.co.uk> ha scritto:
 >On Sat 10 Mar 2018 at 09:18:59 (+0100), Federico Bruni wrote:
 >> [...]
 >
 >> The documentation in Usage 1,2 is pretty clear:
 >>
 >> -o, --output=FILE or FOLDER
 >
 >I don't recognise this. What is Usage 1,2?

 It's chapter 1.2 of Usage manual.
 Sorry, a typo.. and I should have put a link instead.


Interesting, so the manual and the man page disagree with each other.



Good catch, I've added an issue in the tracker:
https://sourceforge.net/p/testlilyissues/issues/5288/




 No, it's not this.
 See my last email. The problem occurs only in the /tmp directory. It
 happens on Debian as well (not only in Fedora).


That helps. Now we can make comparisons. It isn't just the source file
whose path is forgotten. When LP changes directory to the output
directory, it loses the / at the beginning of the previous working
directory.

[...]


Waiting for comments from developers here.
I've added bug-lilypond in Cc.

Thanks
Federico




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

Re: bad description of -dcrop

[Federico Bruni]

I've added the issue:
https://sourceforge.net/p/testlilyissues/issues/5286/

Il giorno mar 27 feb 2018 alle 16:44, 
=?iso-8859-1?q?=C9tienne_Beaul=E9?=  ha 
scritto:
"all the music in a single page output file" is correct, as it is the 
cropped eps/pdf files that we're talking about, which is not 
separated by page.


2018-02-27 3:25 GMT-04:00 Knut Petersen :

Hi Federico, Étienne!

This is perfect!




I suggest this description:
Compress all the music in a single page output file. Margins, 
page numbers and tagline are removed from the output.


It's not perfect, its wrong.

An example: zzztest.ly contains one score that results in a pdf with 
two pages if "lilypond zzztest" is used to compile the source. But 
other backends give different results:

knut@golem:~/test> lilypond --eps --pdf -dcrop zzztest.ly
GNU LilyPond 2.21.0
Processing `zzztest.ly'
[]
Layout output to `zzztest.eps'...
Converting to `zzztest.pdf'...
Layout output to `zzztest-1.eps'...
Layout output to `zzztest-2.eps'...
Converting to `./zzztest-1.pdf'...
Converting to `./zzztest-2.pdf'...
Layout output to `zzztest.cropped.eps'...
Converting to `zzztest.cropped.pdf'...
Converting to PNG...
Success: compilation successfully completed
You see that "all the music in a single page output file" is wrong 
as here also cropped eps/pdf images of every page are produced.


I remember that it is necessary to note that a bit of white space 
introduced by e.g. an empty *Markup and a minimum-distance/padding 
etc might remain.


This can be fixed with e.g.

\paper {
[...]
oddHeaderMarkup  = ##f
evenHeaderMarkup = ##f
oddFooterMarkup  = ##f
evenFooterMarkup = ##f
bookTitleMarkup  = ##f
scoreTitleMarkup = ##f
}
(I know that some but not all of those settings are necessary for 
the described purpose, but I don't have the time to test that now.)


Knut





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

patch for the 2.20 branch (Changes manual)

[Federico Bruni]

Hi

I don't think these changes need a full review and I don't have time to 
go through it anyway.
So find attached a patch to fix two minor issues. It applies to the 
stable/2.20  branch.


Best
Federico
>From 60901cc59247ac856b4458b43e8d153a73b30d36 Mon Sep 17 00:00:00 2001
From: Federico Bruni <f...@inventati.org>
Date: Wed, 28 Feb 2018 08:07:57 +0100
Subject: [PATCH] Doc: add crossref and fix line break

---
 Documentation/changes.tely | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index adc5b22926..2a79614254 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -95,6 +95,7 @@ contexts.
 Two new accidental rules have been added.  Both combine the
 characteristics of @code{modern-voice}, @code{piano} and their
 equivalents:
+
 @code{choral}
 
 @lilypond[quote]
@@ -225,7 +226,7 @@ Output
 @end multitable
 
 @noindent
-Also see @emph{Clef styles}.
+Also see @ruser{Clef styles}.
 
 @item
 French note names are now explicitly defined -- previously they were
-- 
2.14.3

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

Re: bad description of -dcrop

[Federico Bruni]

This is perfect!

Il giorno lun 26 feb 2018 alle 21:27, 
=?iso-8859-1?q?=C9tienne_Beaul=E9?= <beauleetien...@gmail.com> ha 
scritto:
Good suggestion; perhaps "page numbers" should not be included in the 
list of removed elements. How about "Compress all the music and 
headers in a single-page output file without margins."?


Étienne

2018-02-26 14:47 GMT-04:00 Federico Bruni <f...@inventati.org>:



Il giorno lun 26 feb 2018 alle 19:31, Federico Bruni 
<f...@inventati.org> ha scritto:

Hi

In 1.2, Advanced command line options for LilyPond

While updating the italian Usage manual I found this new option:

@item @code{crop}
@tab @code{#f}
@tab Match the size of the normal output to the typeset image.

The description is quite blurry and I can't come up with a good 
translation (unless I change the words completely).
What is "normal output"? I know you mean the actual content, 
without margins or tagline.
Then I would just say that it crops the margins and tagline (while 
title is kept).




Further to above, page numbers are removed as well.
Basically, the whole page formatting is ignored, as the purpose is 
getting all the music in a single document (the cropped PDF is 
always one page).


"Typeset image" might implicitly suggest that only image output is 
possible, while this works for PDF as well.


I suggest this description:
Compress all the music in a single page output file. Margins, page 
numbers and tagline are removed from the output.






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





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

Re: bad description of -dcrop

[Federico Bruni]

Il giorno lun 26 feb 2018 alle 19:31, Federico Bruni 
<f...@inventati.org> ha scritto:

Hi

In 1.2, Advanced command line options for LilyPond

While updating the italian Usage manual I found this new option:

@item @code{crop}
@tab @code{#f}
@tab Match the size of the normal output to the typeset image.

The description is quite blurry and I can't come up with a good 
translation (unless I change the words completely).
What is "normal output"? I know you mean the actual content, without 
margins or tagline.
Then I would just say that it crops the margins and tagline (while 
title is kept).




Further to above, page numbers are removed as well.
Basically, the whole page formatting is ignored, as the purpose is 
getting all the music in a single document (the cropped PDF is always 
one page).


"Typeset image" might implicitly suggest that only image output is 
possible, while this works for PDF as well.


I suggest this description:
Compress all the music in a single page output file. Margins, page 
numbers and tagline are removed from the output.





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

bad description of -dcrop

[Federico Bruni]

Hi

In 1.2, Advanced command line options for LilyPond

While updating the italian Usage manual I found this new option:

@item @code{crop}
@tab @code{#f}
@tab Match the size of the normal output to the typeset image.

The description is quite blurry and I can't come up with a good 
translation (unless I change the words completely).
What is "normal output"? I know you mean the actual content, without 
margins or tagline.
Then I would just say that it crops the margins and tagline (while 
title is kept).





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

Re: dead link in http://lilypond.org/doc/v2.18/Documentation/

[Federico Bruni]

https://sourceforge.net/p/testlilyissues/issues/2266/


Il 29 ottobre 2017 16:51:27 CET, Malte Meyn <lilyp...@maltemeyn.de> ha scritto:
>Where? I cannot find it …
>
>Am 29.10.2017 um 16:41 schrieb Federico Bruni:
>> It's a known problem, already in the tracker
>> 
>> 
>> Il 29 ottobre 2017 15:46:47 CET, Malte Meyn <lilyp...@maltemeyn.de>
>ha 
>> scritto:
>> 
>> Am 29.10.2017 um 15:33 schrieb bb:
>> 
>>
>http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-percussion
>> the link
>> Schnipsel: Percussion.
>>
>http://lilypond.org/doc/v2.18/Documentation/snippets/schlagzeug
>> -> not
>> found
>> In the english version it's active
>>
>http://lilypond.org/doc/v2.18/Documentation/snippets/percussion
>> 
>> 
>> Forwarding to bug-lilypond. This bug report is about the German
>version
>> of the documentation (“Schnipsel” = snippets) but it’s the same
>f. e. in
>> Spanish.
>> 
>> Same for 2.19.
>> Same for other links to the snippets.
>> 
>>
>
>> 
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>> 
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: dead link in http://lilypond.org/doc/v2.18/Documentation/

[Federico Bruni]

It's a known problem, already in the tracker


Il 29 ottobre 2017 15:46:47 CET, Malte Meyn  ha scritto:
>Am 29.10.2017 um 15:33 schrieb bb:
>>
>http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-percussion
>> the link
>> Schnipsel: Percussion.
>> http://lilypond.org/doc/v2.18/Documentation/snippets/schlagzeug ->
>not
>> found
>> In the english version it's active
>> http://lilypond.org/doc/v2.18/Documentation/snippets/percussion
>
>Forwarding to bug-lilypond. This bug report is about the German version
>
>of the documentation (“Schnipsel” = snippets) but it’s the same f. e.
>in 
>Spanish.
>
>Same for 2.19.
>Same for other links to the snippets.
>
>___
>bug-lilypond mailing list
>bug-lilypond@gnu.org
>https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Tablature: duplicated note as part of tied chord not correctly hiding

[Federico Bruni]

Hi Bart

If you try the latest 2.19 you'll see that this issue has been fixed.


Il giorno lun 9 ott 2017 alle 6:32, Bart Nagel  ha 
scritto:

Here's a chord (the same note played at the same time on two different
strings) tied over two bars. This example shows all four combinations
of repeating the chord with q vs spelling the full chord out again,
and using or not using \tabChordRepeats.

Each one prints the repeated note in the second bar of the pair. This
note shouldn't be visible.

\version "2.18.2"

notes = {
1~ q
1~ 
}

<<
\new Staff {
\notes
\notes
}
\new TabStaff {
\notes
\tabChordRepeats \notes
}
>>

If there's a workaround I'd like to hear it. I'd rather it didn't
involve duplicating all the notes (one with a workaround for
tablature, the other as it is now for standard notation), since this
would make my source rather unwieldy.

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



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

Re: \repeatTie does not hide TabNoteHead of tied note

[Federico Bruni]

Ok, apparently I forgot \hideSplitTiedTabNotes.
The thing is: I associate this name only with ties split over a line 
break.

However, an alias named \hideRepeatedTiedTabNotes sounds too long?

Anyway, documentation is clear. I just need to memorize it.

"Ties over a line break are parenthesized by default. The same holds 
for the second alternative of a repeat."
"The command \hideSplitTiedTabNotes cancels the behavior of engraving 
fret numbers in parentheses:"


Il giorno mar 1 ago 2017 alle 16:14, Federico Bruni 
<f...@inventati.org> ha scritto:

Hi

Can't remember/find if I've made this answer before.
In the following example, you see that \repeatTie does not hide 
TabNoteHead, while the TabNoteHead in the first volta is hidden.

Don't know if this is intended...


\version "2.19.46"

mus = \relative c' {
 \repeat volta 2 {
   c2 d~ |
 }
 \alternative {
   { d2 e }
   {
 % Inconsistent (?) behaviour unless you uncomment the following 
line

 %\once\hide TabNoteHead
 d2\repeatTie c
   }
 }
}

\score {
 \new StaffGroup <<
   \new Staff { \clef "treble_8" \mus }
   \new TabStaff \mus
 >>
 \layout { }
}


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



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

\repeatTie does not hide TabNoteHead of tied note

[Federico Bruni]

Hi

Can't remember/find if I've made this answer before.
In the following example, you see that \repeatTie does not hide 
TabNoteHead, while the TabNoteHead in the first volta is hidden.

Don't know if this is intended...


\version "2.19.46"

mus = \relative c' {
 \repeat volta 2 {
   c2 d~ |
 }
 \alternative {
   { d2 e }
   {
 % Inconsistent (?) behaviour unless you uncomment the following 
line

 %\once\hide TabNoteHead
 d2\repeatTie c
   }
 }
}

\score {
 \new StaffGroup <<
   \new Staff { \clef "treble_8" \mus }
   \new TabStaff \mus
 >>
 \layout { }
}


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

Re: NR 4.2.2, table column should be called "glyph name"?

[Federico Bruni]

Il giorno sab 10 giu 2017 alle 2:54, Carl Sorensen <c_soren...@byu.edu> 
ha scritto:

On 6/8/17 10:26 AM, "Federico Bruni" <f...@inventati.org> wrote:


http://lilypond.org/doc/v2.19/Documentation/notation/setting-the-staff-siz
e.html

"""
Automatic font weight at different sizes

The Emmentaler font provides the set of Feta musical glyphs in eight
different sizes; each one tuned for a different staff size. The 
smaller

the glyph size, the ³heavier² it becomes, so as to match the
relatively thicker staff lines. Recommended glyphs sizes are listed 
in

the following table:

font name   staff height (pt)   staff height (mm)   use
feta11  11.22   3.9 pocket scores
feta13  12.60   4.4
[...]
"""

Should "font name" be replaced with "glyph name"?


Not in my opinion.  The font is feta11 (the font family is feta).  The
staff height is 11.22 pt.  The staff height is 3.9 mm.




Hi Carl, are you sure?
The context of my report was:

commit 18d03fa6a724b0102ccc47d194209802cea02f2e
Author: James Lowe
Date: Sun Mar 5 16:34:39 2017 +

   Doc - NR + CG: Clarify Emmentaler is the 'font' and Feta/Parmesan 
are glyphs


   Issue 4966

   Distinguish between Emmentaler
   the 'font' and Feta/Parmesan
   glyphs that make up the
   Emmentaler font family.




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

NR 4.2.2, table column should be called "glyph name"?

[Federico Bruni]

http://lilypond.org/doc/v2.19/Documentation/notation/setting-the-staff-size.html

"""
Automatic font weight at different sizes

The Emmentaler font provides the set of Feta musical glyphs in eight 
different sizes; each one tuned for a different staff size. The smaller 
the glyph size, the “heavier” it becomes, so as to match the 
relatively thicker staff lines. Recommended glyphs sizes are listed in 
the following table:


font name   staff height (pt)   staff height (mm)   use
feta11  11.22   3.9 pocket scores
feta13  12.60   4.4
[...]
"""

Should "font name" be replaced with "glyph name"?




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

Re: NR 5.3.6 The \offset command: confusion in describing the examples

[Federico Bruni]

Il giorno mer 7 giu 2017 alle 15:57, David Nalesnik 
 ha scritto:
Ah, OK -- that too!! (Maybe I ought to make this clearer in the 
explanation: the default value is 2.0, so the effect of the offset 
command would to be raise the bracket 2 + 3 = 5 staff spaces.)


Actually, this is clear in the doc. In my mind it was +3 _from the 
default_ (2).



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

Re: Unofficial MusicXML test suite access problem

[Federico Bruni]

Il giorno ven 26 mag 2017 alle 12:16, Phil Holmes  
ha scritto:
- Original Message - From: "Thomas Morley" 


To: "Phil Holmes" 
Cc: "bug-lilypond" 
Sent: Friday, May 26, 2017 11:01 AM
Subject: Re: Unofficial MusicXML test suite access problem



Clicking on p.e. the first file-name i.e. 
‘01a-Pitches-Pitches.xml’

I get
The requested URL
/doc/v2.19/input/regression/musicxml/42/lily-db220724.xml was not
found on this server.
Apache/1.3.34 Server at lilypond.org Port 80
for both: Firefox and Chromium

Cheers,
 Harm



I agree with that - it's been like that for a _long_ time, but I 
can't find a bug report.  It's nothing to do with the OP's report, 
though.





Here's the issue:
https://sourceforge.net/p/testlilyissues/issues/3607/




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

Re: change music font not documented?

[Federico Bruni]

Il giorno mer 10 mag 2017 alle 23:26, tisimst 
 ha scritto:
I think that's a good idea, perhaps the right time to update the 
entry for replacing the notation font? 
http://lilypond.org/doc/v2.19/Documentation/notation/replacing-the-notation-font


I think that it's the right place. I've added an issue to the tracker:
https://sourceforge.net/p/testlilyissues/issues/5137/




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

Re: fontconfig dpi issue

[Federico Bruni]

Eventually I've added an issue to the tracker:
https://sourceforge.net/p/testlilyissues/issues/5136/


Il giorno gio 23 feb 2017 alle 7:11, Werner LEMBERG  ha 
scritto:



 I hope that some font guru (Werner?) can step in and give some
 feedback.


I've seen this a few days ago but no time to reply, sorry.


 I ran into an issue with font rendering in Lilypond where text
 characters are far too large. This issue also affected several
 other users and is described here
 .  It turns out
 that if the dpi setting is manually set in the fontconfig
 fonts.conf file, Lilypond will adopt that dpi setting (rather than
 the standard setting used in Lilypond, which is 1200) and render
 all text too large.


 Before I create an issue on the tracker, some developer should say
 if LilyPond or LXQT must be fixed.  I have no idea about it.


I think it's a lilypond bug, since setting a DPI value is for stuff
that goes to the screen and/or a selected printer, but lilypond should
produce stuff that does not depend on the DPI.


 I also have a proposed patch that fixes the problem described,
 although I don't know if this is the proper way to fix it: [...]


Me neither, unfortunately, since I have never worked with Pango.
However, your patch looks reasonable.


 I also created a minimal Pango example that reproduces the bug here
 
.


Have you already reported the problem to the fontconfig people?  Maybe
they can give more advice.


Werner



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

change music font not documented?

[Federico Bruni]

Hi all

I think that set-global-fonts is not properly documented, especially 
for music font changes.


$ cd Documentation
$ git grep -n set-global-fonts notation/
notation/ancient.itely:2414:(set-global-fonts
notation/ancient.itely:2594:(set-global-fonts
notation/input.itely:2526:(set-global-fonts

Best resource is the blog:
http://lilypondblog.org/2015/03/managing-alternative-fonts-with-lilypond/

Should I open an issue for this?




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

Re: LM 2.4.1: errors in variable definitions

[Federico Bruni]

Eventually I've added an issue in the tracker:
https://sourceforge.net/p/testlilyissues/issues/5132/


Il giorno dom 17 lug 2016 alle 12:18, David Kastrup <d...@gnu.org> ha 
scritto:

Federico Bruni <f...@inventati.org> writes:


 Il giorno dom 17 lug 2016 alle 11:44, David Kastrup <d...@gnu.org> ha
 scritto:

  Of course, but this is the standard \paper property and the whole
  point of the example in the documentation is defining variables.

  We may omit the unit and use the default one (millimeters). But I
  wonder if this is a bug or there's a better way to define such a
  variable.


 I thought the default unit was staff spaces?  Don't quote me on 
that

 but
 I thought that the main mess was that the definition of \cm changed
 when
 one changed the default staff size.


 Perhaps the default unit of \paper properties is millimeters? That
 would make sense. While staff spaces make sense for elements of the
 notation.

 I just made a test. A 208 line-width spans almost all the 210x210
 document:

 \version "2.19.45"

 width = 208
 stringName = "Wendy"
 aFivePaper = \paper { paper-height = 210 }

 \paper {
  \aFivePaper
  line-width = \width
  ragged-last = ##f
  indent = 0
 }

 {
  c4^\stringName
 }


Well, I have no actual idea here.  I just know that stuff gets scaled
around in paper and/or layout blocks and I had a hard time figuring 
out
how or why.  Maybe it's different in \paper and \layout (and I think 
at

the very least in the \layout block of a \score markup), and maybe I
just haven't got the hang of it at all.

--
David Kastrup



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

Re: bugs in web.pdf

[Federico Bruni]

Il giorno dom 16 apr 2017 alle 8:46, Federico Bruni 
<f...@inventati.org> ha scritto:

If you give a look at this PDF:
http://lilypond.org/doc/v2.19/Documentation/web.pdf

you'll see some bugs:

- the images not generated by LilyPond have often a poor quality and 
some of them run out of the page


Well, this is not a new issue and depends on the quality of the images 
used.

I guess that we can ignore it.

- PDF page 10 is in landscape (while the document is a regular A4 of 
course)






This is the actual bug. I've investigated...
If you replace v2.19 with previous versions you can see that previous 
builds used PdfTex instead of Xetex and the image was compressed to fit 
on the vertical A4 sheet.


What's interesting is that my locally compiled web.pdf (with Xetex 
version 2017.03.30:1237) displays page 10 almost correctly, in that the 
page stays A4 vertical but the image is rotated 90° counter-clockwise. 
See attached the extracted page.

web.pdf on lilypond.org was built with a more recent version of Xetex.

Masamichi, any idea of what's going on?




web-page10.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

bugs in web.pdf

[Federico Bruni]

If you give a look at this PDF:
http://lilypond.org/doc/v2.19/Documentation/web.pdf

you'll see some bugs:

- the images not generated by LilyPond have often a poor quality and 
some of them run out of the page
- PDF page 10 is in landscape (while the document is a regular A4 of 
course)





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

Re: Problem with make website

[Federico Bruni]

Il giorno lun 13 mar 2017 alle 16:32, Phil Holmes <m...@philholmes.net> 
ha scritto:
"Federico Bruni" <f...@inventati.org> wrote in message 
news:1489416450.2197...@smtp.autistici.org...



Il giorno lun 13 mar 2017 alle 14:52, Phil Holmes 
<m...@philholmes.net> ha scritto:
I've sent this to -devel a few hours ago, but it's not appeared 
there - I frequently get problems getting mail started there.


It's not something we test with patchy, so not impossible - make 
website is

now failing so the new release is not showing on the home page.

make: *** No rule to make target
'/home/graham/lilypond/lilypond-git//Documentation/web/news-front.itexi',
needed by 'out-website/web.xref-map'. Stop.

Not sure I understand this - I think news-front has been deleted? 
Perhaps a

remnant pointer to it in another file?





I could reproduce your issue. Then I deleted the out-website dir and 
re-run 'make website'.

And the build completed successfully.


Thanks for your help.

I renamed out-website and then ran this command:

make -f website.make WEBSITE_ONLY_BUILD=1 website

After a period of processing, I got this error:

BSTINPUTS=/home/graham/lilypond/lilypond-git//Documentation/web \
python /home/graham/lilypond/trusted-scripts/bib2texi.py -s web \
-s /home/graham/lilypond/lilypond-git//Documentation/lily-bib \
-o out-website/others-did.itexi \
-q \
/home/graham/lilypond/lilypond-git//Documentation/web/others-did.bib
sh: bibtex: command not found
Bibtex exited with nonzero exit status!website.make:225: recipe for 
target 'out-website/others-did.itexi' failed

make: *** [out-website/others-did.itexi] Error 1

I'm now assuming there's something on the server that's needed but 
not there but a full build has only been done so long ago that it's 
not been needed for a long time.  Does that sound possible?  Further 
suggestions?





What you get from:

which bibtex

In Debian testing I see that bibtex is a symlink which ultimately ends 
up in bibtex.original:


# ls -l /usr/bin/bibtex
lrwxrwxrwx 1 root root 24 feb 28 17:40 /usr/bin/bibtex -> 
/etc/alternatives/bibtex

# ls -l /etc/alternatives/bibtex
lrwxrwxrwx 1 root root 24 feb 28 17:40 /etc/alternatives/bibtex -> 
/usr/bin/bibtex.original

# ls -l /usr/bin/bibtex.original
-rwxr-xr-x 1 root root 128704 gen 11 14:45 /usr/bin/bibtex.original

The package you need is:
# dpkg -S /usr/bin/bibtex.original
texlive-binaries: /usr/bin/bibtex.original

but I would wait for Graham's comments...




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

Re: Problem with make website

[Federico Bruni]

Il giorno lun 13 mar 2017 alle 14:52, Phil Holmes  
ha scritto:
I've sent this to -devel a few hours ago, but it's not appeared there 
- I frequently get problems getting mail started there.


It's not something we test with patchy, so not impossible - make 
website is

now failing so the new release is not showing on the home page.

make: *** No rule to make target
'/home/graham/lilypond/lilypond-git//Documentation/web/news-front.itexi',
needed by 'out-website/web.xref-map'. Stop.

Not sure I understand this - I think news-front has been deleted? 
Perhaps a

remnant pointer to it in another file?





I could reproduce your issue. Then I deleted the out-website dir and 
re-run 'make website'.

And the build completed successfully.




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

Re: Patch (from Debian) for buildling LilyPond 2.18.2 and 2.19.53 on GNU Hurd

[Federico Bruni]

Hi Anthony

Thanks for the report! I've added it to the tracker:
https://sourceforge.net/p/testlilyissues/issues/5077/

We have a procedure for proposing patches. In a nutshell, you need to 
apply the patch to the master branch and upload it to Google Rietveld 
with a script called git-cl (available on github).


All information is here:
http://lilypond.org/doc/v2.19/Documentation/contributor/index.html

Can you take care of it?
Let me know, thanks
Federico


Il giorno ven 27 gen 2017 alle 8:40, Anthony Fok  ha 
scritto:

Hello,

LilyPond failed to build on GNU Hurd because Hurd does not have 
PATH_MAX.
Fortunately, a workaround is available thanks to the combined effort 
of
Debian developers Don Armstrong (Debian package maintainer for 
LilyPond)

and Petter Reinholdtsen (Debian Hurd guru).

Petter expressed his wish to send this patch upstream to be included 
in
future releases of LilyPond, hence this bug report with the attached 
patch!

 :-)

A little bit of history:

2013-05-13, Don Armstrong :

  Changelog for LilyPond Debian package version 2.16.2-2:

  * Patch around using PATH_MAX in flower/file-name.cc to have builds 
work

on hurd (hopefully).

2014-09-10, Petter Reinholdtsen , debian.org>:


  https://bugs.debian.org/761036

  Hi.  The lilypond package do not build on hurd, even with a hurd 
patch

  in place.  The cause seem to be a typo in the file
  debian/patches/hurd_file_name_support, checking for _GNU_SOURCE_
  instead of _GNU_SOURCE (at least that is what the getcwd() manual 
page

  claim to look for).

  Attached is an updated patch, fixing that bug, a memory leak
  forgetting to release the memory allocated by 
get_current_dir_name(),

  and adding the same code in the test code.

  Please replace the patch in the current source with this new one, 
and

  consider sending it upstream. :)

2016-07-18, Dr. Tobias Quathamer :

  Reviewed and committed the patch to the debian-experimental branch
  (intended for an experiment with LilyPond 2.19.x and Guile-2.x)
  in the LilyPond deb packaging git repository:


https://anonscm.debian.org/git/collab-maint/lilypond.git/commit/?h=debian-experimental=e56df084666dbf9905d90c062b1f462aeb6f5f4a

2017-01-27, me:

  Discovered the above, and cherry-picked Dr. Tobias's commit onto the
  "debian" (stable) branch with 2.18.2.

Many thanks!

Anthony
foka AT debian.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond



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

Re: fontconfig dpi issue

[Federico Bruni]

Hey Tim

It seems that nobody replied to you.
I hope that some font guru (Werner?) can step in and give some feedback.

I'm interested in this problem, because LilyDev recently switched to 
LXQT.

In which version of LXQT they changed this setting?
I cannot find it on current debian testing:

root@lilydev:~# grep -i dpi /etc/fonts/fonts.conf
root@lilydev:~#


Il giorno mer 25 gen 2017 alle 23:43, Tim Schellenberg 
 ha scritto:

Hi everyone,

I ran into an issue with font rendering in Lilypond where text 
characters

are far too large. This issue also affected several other users and is
described here .

It turns out that if the dpi setting is manually set in the fontconfig
fonts.conf file, Lilypond will adopt that dpi setting (rather than the
standard setting used in Lilypond, which is 1200) and render all text 
too

large.

The desktop environment LXQT sets this to 96 dpi automatically, which 
is
what triggered the bug for me. This may not a good idea on their 
part, but

I imagine some users may want to or need to adjust this setting and it
doesn't seem right that this should affect rendering in Lilypond.

To reproduce this bug, edit the following file (or create the file, 
if it

doesn't exist):
$XDG_CONFIG_HOME/fontconfig/fonts.conf

Paste this as the contents of the file (or just add the  block 
with

the dpi setting):



  

  96

  


Next, compile any .ly file that includes text, for example:
\version "2.19.49"
\header {
  title = "Title"
}
\relative c''{
c
}



Yep, if I paste that content in ~/.config/fontconfig/fonts.conf I can 
reproduce the problem on my Fedora 25 system.


Before I create an issue on the tracker, some developer should say if 
LilyPond or LXQT must be fixed.

I have no idea about it.


I also have a proposed patch that fixes the problem described, 
although I

don't know if this is the proper way to fix it:
--- lilypond-2.19.49.orig/lily/pango-font.cc 2016-10-16 
07:16:18.0

-0400
+++ lilypond-2.19.49.new/lily/pango-font.cc 2016-10-29 
22:39:02.921622080

-0400
@@ -317,7 +317,7 @@
   pango_fc_font_unlock_face (fcfont);
   pango_glyph_string_free (pgs);
   pgs = 0;
-  PangoFontDescription *descr = pango_font_describe (pa->font);
+  PangoFontDescription *descr = pango_context_get_font_description
(context_);
   Real size = pango_font_description_get_size (descr)
   / (Real (PANGO_SCALE));


I also created a minimal Pango example that reproduces the bug here
.
Thanks!

Tim Schellenberg
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond



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

Re: [translations] Re: Problem with documentation download

[Federico Bruni]

Il giorno gio 2 feb 2017 alle 12:52, David Kastrup  ha 
scritto:
At the current point of time, building the Czech PDF file is not just 
a waste of time but also not helpful to the Czech users of LilyPond. 
If we can sensibly link to the English documentation, we should 
likely do that. Maybe we should offer an additional link to the 
English versions for _all_ languages knowing to have an outdated 
translation, including German and Dutch.


Ok, then I'll make sure that it will point to the English PDF file.

Some months ago I suggested using a warning for out-of-date translated 
pages:

https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00736.html

I've now added an issue on the tracker:
https://sourceforge.net/p/testlilyissues/issues/5048/

I'm going to label as "translations" the issues related with 
translation. Because searching in Sourceforge is a pain.



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

Re: [translations] Re: Problem with documentation download

[Federico Bruni]

Il giorno gio 2 feb 2017 alle 12:23, Francisco Vila 
<paconet@gmail.com> ha scritto:

2017-02-01 17:08 GMT+01:00 Federico Bruni <f...@inventati.org>:
 @TRANSLATORS: ok if I comment that line and push to translation 
branch?


I don't oppose but those PDFs were not built for a reason.




My change proposal was only for the czech documentation, which does not 
have an active maintainer AFAIK (not japanese or chinese).


What's the reason for blocking the build of PDF files?
If there's a good reason not to build the czech PDF file, then we 
should change it to link to the english PDF. File not found is not nice.





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

Re: Problem with documentation download

[Federico Bruni]

Il giorno mer 1 feb 2017 alle 11:16, zdenek.so...@seznam.cz ha scritto:
I'm trying to download this document: Uceni.pdf from 
http://lilypond.org/learning.cs.html but I get a message: Not found 
The requested URL /doc/v2.18/Documentation/learning.cs.pdf was not 
found on this server. Can you fix this bug please?


Hi Zdenek

As far as I can see in the git log, the last update to czech 
documentation dates back to August 2012.
The information may be inaccurate or incomplete for the current stable 
(2.18).
If you feel like working on updating the translation of this manual, 
let us know :-)


I'm Cc-ing the translation list.
It seems that PDF files are disabled for your language:

$ cat Documentation/cs/GNUmakefile
ISOLANG = cs
depth = ../..
STEPMAKE_TEMPLATES = documentation texinfo
LOCALSTEPMAKE_TEMPLATES = lilypond ly doc-i18n-root
NO_PDF_FILES = 1

If I comment the last line I get the PDF file (I'll send it privately 
to you in the next mail).


@TRANSLATORS: ok if I comment that line and push to translation branch?

Same for japanese and chinese languages:
$ git grep -n NO_PDF_FILES
Documentation/cs/GNUmakefile:5:NO_PDF_FILES = 1
Documentation/ja/GNUmakefile:5:NO_PDF_FILES = 1
Documentation/nl/GNUmakefile:5:# NO_PDF_FILES = 1
Documentation/zh/GNUmakefile:5:NO_PDF_FILES = 1
make/doc-i18n-root-targets.make:4:ifneq ($(NO_PDF_FILES),)
make/doc-i18n-root-targets.make:7:ifeq ($(NO_PDF_FILES),)

These two languages still have a correct link to a PDF file, but in 
english (this depends on texinfo source).

Don't know what's the purpose of this though.




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

Re: ghostscript error in version 2.19.53

[Federico Bruni]

Il giorno mar 3 gen 2017 alle 1:04, Graham Percival 
 ha scritto:

It looks like this was noticed a year ago but there was no
resolution:
https://lists.gnu.org/archive/html/bug-lilypond/2015-12/msg00014.html

Does
locate Fontmap.local
produce anything?


$ locate Fontmap.local
/etc/ghostscript/9.20/Fontmap.local

it's an empty file.. it shouldn't be?

$ find ~ -name Fontmap*
/home/fede/.local/lilypond/usr/share/ghostscript/9.20/Resource/Init/Fontmap
/home/fede/.local/lilypond/usr/share/ghostscript/9.20/Resource/Init/Fontmap.GS




Have you tried deleting your lilypond font cache and re-running?
The first time I ran 2.19.53, I thought that it had crashed, so I
made sure I didn't have any user font-related files and tried
again.


Ok, I did:

$ rm -rf ~/.lilypond-fonts.cache-2/

but I still get the same error.

I used to have installed the lilypond fedora package (same version 
2.19.53). Perhaps a conflict with some system package? Centos, the 
linux distro of the above report, is based on Red Hat..
I disinstalled the fedora package because I wanted to have version 2.19 
in a path with higher priority than version 2.18.2 (installed in 
/usr/local). I'll move 2.18.2 in ~/.local and put it down in the PATH.





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

ghostscript error in version 2.19.53

[Federico Bruni]

Hi all

I cannot compile any file with version 2.19.53 downloaded from 
lilypond.org and installed using the --prefix option in ~/.local (I've 
done this before and it worked).

It seems a Ghostscript problem?


Verbose log:

$ lilypond -V 
/home/fede/.local/lilypond/usr/share/lilypond/current/ly/Welcome_to_LilyPond.ly

Log level set to 287
GNU LilyPond 2.19.53
Relocation: is absolute: 
argv0=/home/fede/.local/lilypond/usr/bin/lilypond

PATH=/home/fede/.local/lilypond/usr/bin (prepend)
Setting PATH to 
/home/fede/.local/lilypond/usr/bin:/home/fede/.local/bin:/home/fede/src/git-cl:/usr/lib64/qt5/bin/:/usr/lib/qtchooser:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
Relocation: compile datadir=, new 
datadir=/home/fede/.local/lilypond/usr/share/lilypond//current

Relocation: framework_prefix=/home/fede/.local/lilypond/usr/bin/..
Setting INSTALLER_PREFIX to /home/fede/.local/lilypond/usr/bin/..
Relocation file: 
/home/fede/.local/lilypond/usr/bin/../etc/relocate//guile.reloc
GUILE_LOAD_PATH=/home/fede/.local/lilypond/usr/bin/../share/guile/1.8 
(prepend)
Setting GUILE_LOAD_PATH to 
/home/fede/.local/lilypond/usr/bin/../share/guile/1.8
Relocation file: 
/home/fede/.local/lilypond/usr/bin/../etc/relocate//fontconfig.reloc
Setting FONTCONFIG_FILE to 
/home/fede/.local/lilypond/usr/bin/../etc/fonts/fonts.conf
Setting FONTCONFIG_PATH to 
/home/fede/.local/lilypond/usr/bin/../etc/fonts
Relocation file: 
/home/fede/.local/lilypond/usr/bin/../etc/relocate//gs.reloc
warning: no such directory: 
/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/fonts for 
GS_FONTPATH
warning: no such directory: 
/home/fede/.local/lilypond/usr/bin/../share/gs/fonts for GS_FONTPATH
GS_LIB=/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource 
(prepend)
Setting GS_LIB to 
/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource
GS_LIB=/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource/Init 
(prepend)
Setting GS_LIB to 
/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource/Init:/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource

PATH=/home/fede/.local/lilypond/usr/bin/../bin (prepend)
Setting PATH to 
/home/fede/.local/lilypond/usr/bin/../bin:/home/fede/.local/lilypond/usr/bin:/home/fede/.local/bin:/home/fede/src/git-cl:/usr/lib64/qt5/bin/:/usr/lib/qtchooser:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR="/usr/share/lilypond/2.19.53"
LOCALEDIR="/usr/share/locale"

Effective prefix: 
"/home/fede/.local/lilypond/usr/share/lilypond/current"

FONTCONFIG_FILE="/home/fede/.local/lilypond/usr/bin/../etc/fonts/fonts.conf"
FONTCONFIG_PATH="/home/fede/.local/lilypond/usr/bin/../etc/fonts"
GS_LIB="/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource/Init:/home/fede/.local/lilypond/usr/bin/../share/ghostscript/9.20/Resource"
GUILE_LOAD_PATH="/home/fede/.local/lilypond/usr/bin/../share/guile/1.8"
PATH="/home/fede/.local/lilypond/usr/bin/../bin:/home/fede/.local/lilypond/usr/bin:/home/fede/.local/bin:/home/fede/src/git-cl:/usr/lib64/qt5/bin/:/usr/lib/qtchooser:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin"
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/lily.scm]
Guile 1.8
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/lily-library.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/output-lib.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/markup-macros.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/parser-ly-from-scheme.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/file-cache.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/define-event-classes.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/define-music-callbacks.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/define-music-types.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/define-note-names.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/c++.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/chord-entry.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/skyline.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/markup.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/define-markup-commands.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/stencil.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/modal-transforms.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/chord-generic-names.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/chord-ignatzek-names.scm]
[/home/fede/.local/lilypond/usr/share/lilypond/current/scm/music-functions.scm

Re: broken link in info docs

[Federico Bruni]

Il giorno dom 13 nov 2016 alle 18:10, Sylvius Pold 
 ha scritto:

Hi all,

I'm new to this list and LilyPond.  Thank you for this wonderful 
software!


I have encountered a weird link in the info docs.  I'm reading the 
info docs from within Emacs.  When I type "d" to go to the Info 
Directory and click on the node/menu item "LilyPond" the LilyPond 
Notation Reference comes up and everything works as expected.  But 
when I type "m" in the Info Directory to choose the node/menu item 
"LilyPond" in the mini buffer ("mLilyPond" or 
"mLily") then the Application Usage Reference opens up.  
I'd rather expect the Notation Reference to show up in this case. All 
the other nodes/menu items work as expected. Is this a bug or a 
rather strange feature or am I missing something?


Thanks for your help!

Sylvius


Hi Sylvius

You didn't get any reply, did you?
I don't use Emacs so I cannot verify, but I've opened a new issue:
https://sourceforge.net/p/testlilyissues/issues/5008/

Thanks for your report
Federico




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

new italian translator

[Federico Bruni]

Hi folks

Please add to Documentation/included/authors.itexi a new contributor, 
who recently translated the whole Essay manual in italian:


http://git.savannah.gnu.org/cgit/lilypond.git/commit/?h=translation=c72179ccf41124936a43bb7279d92c6cb6266b7b

His name is Tommaso Gordini. He made an excellent work. I think that he 
will continue contributing and will help me with finishing and 
reviewing the Notation Reference.


Cheers
Federico




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

Re: probably an oversight in a link on the home page

[Federico Bruni]

Il giorno sab 15 ott 2016 alle 21:20, Jean-Charles Malahieude 
 ha scritto:

Nevertheless, when I replace
  @uref{examples.html#g_t_53e4_697d, 古楽}
with
  @uref{examples.html#Gu-Le-, 古楽}
as mentioned in out-www/web/
  
  古楽
I still only reach the top of examples.ja.html.

The only one that works is Schenker graphs (the only "non encoded" 
anchor).


I just tried the same:

-@uref{examples.html#g_t_53e4_697d, 古楽}、
+@uref{examples.html#Gu-Le-, 古楽}、

and it works here. I tested it with "make && make website".

Here's the link which works (jumps to the example):
out-website/website/examples.ja.html#Gu-Le-




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

Re: probably an oversight in a link on the home page

[Federico Bruni]

Il giorno sab 15 ott 2016 alle 15:01, Jean-Charles Malahieude 
<lily...@orange.fr> ha scritto:

Le 15/10/2016 à 05:00, Paul a écrit :

On 10/14/2016 07:31 AM, Federico Bruni wrote:


Hi Paul

I think that you forgot to remove the absolute URL here. Or I'm
missing something?

+LilyPond is a powerful and flexible tool for engraving tasks of
+all kinds, for example
+@uref{http://lilypond.org/examples.html#Classical-Music, classical
music}
+(like the example above by J.S. Bach),
+@uref{examples.html#Complex-Notation, complex notation},

The first link should be relative, like all the others:

@uref{examples.html#Classical-Music, classical music}.


BTW, this comment:

@c anchor links, link to individual examples by their  tag

may be more informative (for translators also):

@c Translators should use the localized URLs, followed by their
translated anchor name (e.g. examples.it.html#Musica-Antica)



You're right, that was an oversight on my part.  Good catch, thanks!
Those edits all make sense to me.  Should I do them or would you like
to?  Either way is fine with me.



If you don't mind, and as I'm about to merge 
master->translation->staging, I'll take care of it.
I'll also take care of the Japanese and French versions as Federico 
mentioned on the translation list.


Ok, go ahead.
Don't forget what Masamichi pointed out (in the translation mailing 
list): 'make doc' (and 'make website', I guess) adds .it/.fr/.ja/etc to 
the relative links of translated manuals. So the recommendation to 
translators should be to keep the URL as is and change only the anchor 
(after checking the anchor name created by texinfo in the localized 
HTML manual).


I didn't have the time to test it yet, but I trust Masamichi.


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

Re: probably an oversight in a link on the home page

[Federico Bruni]

Il giorno ven 14 ott 2016 alle 13:31, Federico Bruni 
<f...@inventati.org> ha scritto:

BTW, this comment:

@c anchor links, link to individual examples by their  tag

may be more informative (for translators also):

@c Translators should use the localized URLs, followed by their 
translated anchor name (e.g. examples.it.html#Musica-Antica)


I cannot test it right now, as 'make website' is failing here right 
now, but I believe that it should work.


Well, no need to test it locally. It works:
http://lilypond.org/examples.it.html#Musica-Antica




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

probably an oversight in a link on the home page

[Federico Bruni]

Hi Paul

I think that you forgot to remove the absolute URL here. Or I'm missing 
something?


+LilyPond is a powerful and flexible tool for engraving tasks of
+all kinds, for example
+@uref{http://lilypond.org/examples.html#Classical-Music, classical 
music}

+(like the example above by J.S. Bach),
+@uref{examples.html#Complex-Notation, complex notation},

The first link should be relative, like all the others:

@uref{examples.html#Classical-Music, classical music}.

So, in case someone uses a documentation locally installed, it will 
work even without an Internet connection.


I think that this can be fixed and pushed straight away, as long as you 
confirm that it's ok.




BTW, this comment:

@c anchor links, link to individual examples by their  tag

may be more informative (for translators also):

@c Translators should use the localized URLs, followed by their 
translated anchor name (e.g. examples.it.html#Musica-Antica)


I cannot test it right now, as 'make website' is failing here right 
now, but I believe that it should work.


Thanks
Federico


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

Re: Junk string in ly -> midi -> ly conversion

[Federico Bruni]

Il giorno mer 20 lug 2016 alle 16:50, Mojca Miklavec 
 ha scritto:

If this is a platform-specific problem, can you please:
- send your midi file for comparison (mine is attached)
- test whether UTF-8 characters are handled properly during conversion
(I initially thought the problem was in non-ascii characters, but then
I removed the non-ascii ones and the problem persisted)


Converting from your MIDI file triggers the problem here as well:

$ file test-midi-mac.ly
test-midi-mac.ly: data

See attached file.

I attach also my MIDI file so you can double-check midi2ly on your mac.




test.midi
Description: MIDI audio
% Lily was here -- automatically converted by /home/fede/.local/lilypond/usr/bin/midi2ly from test-mac.midi
\version "2.14.0"

\layout {
  \context {
\Voice
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\remove "Rest_engraver"
\consists "Completion_rest_engraver"
  }
}

trackAchannelA = {
  
  \set Staff.instrumentName = "þÿ
a

urek"
  
  % [TEXT_EVENT] creator: 
  
  % [TEXT_EVENT] GNU LilyPond 2.19.44  
  
  \time 4/4 
  
  \tempo 4 = 100 
  
}

trackA = <<
  \context Voice = voiceA \trackAchannelA
>>


trackBchannelA = {
  
  \set Staff.instrumentName = "\new:melody"
  
}

trackBchannelB = \relative c {
  c'4 a' c, a' 
  | % 2
  
}

trackB = <<
  \context Voice = voiceA \trackBchannelA
  \context Voice = voiceB \trackBchannelB
>>


\score {
  <<
\context Staff=trackB \trackA
\context Staff=trackB \trackB
  >>
  \layout {}
  \midi {}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Junk string in ly -> midi -> ly conversion

[Federico Bruni]

Il giorno mer 20 lug 2016 alle 16:14, Mojca Miklavec 
 ha scritto:

I wanted to test the conversion from midi to Lilypond. I took a midi
file generated with LilyPond, converted it to LilyPond with


arch -32 
/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python

/Applications/LilyPond.app/Contents/Resources/bin/midi2ly test.midi

(I didn't find any more intuitive way to do the conversion)

But then lilypond failed to process the generated ly file:


 lilypond test-midi.ly

GNU LilyPond 2.19.44
Processing `test-midi.ly'
Parsing...
test-midi.ly:16:32: warning: non-UTF-8 input
  \set Staff.instrumentName = "
   ??a
test-midi.ly:16:33: warning: non-UTF-8 input
  \set Staff.instrumentName = "?
?a
test-midi.ly:16:32: error: EOF found inside string
  \set Staff.instrumentName = "
   ??a
test-midi.ly:16:32: error: syntax error, unexpected end of input
  \set Staff.instrumentName = "
   ??a
fatal error: failed files: "test-midi.ly"


This is easy to work around by deleting / manually changing the
instrument name, but it's weird enough that LilyPond cannot process
its own files.


Hi Mojca

It's an issue with your system.
The file format of test-midi.ly is wrong:

$ file tmp/test.ly
tmp/test.ly: ASCII text

$ file tmp/test-midi.ly
tmp/test-midi.ly: data

in particular this line:

\set Staff.instrumentName = "\FE\FF
a

\00u\00r\00e\00k"

Find attached my (correct) .ly file generated from the MIDI file.


% Lily was here -- automatically converted by /home/fede/.local/lilypond/usr/bin/midi2ly from test.midi
\version "2.14.0"

\layout {
  \context {
\Voice
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\remove "Rest_engraver"
\consists "Completion_rest_engraver"
  }
}

trackAchannelA = {
  
  \set Staff.instrumentName = "urek"
  
  % [TEXT_EVENT] creator: 
  
  % [TEXT_EVENT] GNU LilyPond 2.19.44  
  
  \time 4/4 
  
  \tempo 4 = 100 
  
}

trackA = <<
  \context Voice = voiceA \trackAchannelA
>>


trackBchannelA = {
  
  \set Staff.instrumentName = "\new:melody"
  
}

trackBchannelB = \relative c {
  c'4 a' c, a' 
  | % 2
  
}

trackB = <<
  \context Voice = voiceA \trackBchannelA
  \context Voice = voiceB \trackBchannelB
>>


\score {
  <<
\context Staff=trackB \trackA
\context Staff=trackB \trackB
  >>
  \layout {}
  \midi {}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: CG 11.5 Notes on builds with GUB

[Federico Bruni]

Il giorno gio 30 giu 2016 alle 17:51, Federico Bruni 
<f...@inventati.org> ha scritto:

I'm using gub for the first time, just to find which packages might
need to be added to LilyDev.
So far I found only gcc-multilib, needed to compile some 386 packages
when running 'make bootstrap'.

I want to report two problems:

1. Ghostscript download page has changed:
http://downloads.ghostscript.com/public/

This is the change to be made on gub on github:
[...]


I've created a pull request:
https://github.com/gperciva/gub/pull/24




2. The path in this paragraph is misleading:


"""
Copy the tarball into ‘gub/regtests/’, and tell the build system
that you have done this:

touch regtests/ignore
"""

It should say "Copy the tarball into 'regtests/', and...'



Added an issue here:
https://sourceforge.net/p/testlilyissues/issues/4933/




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

Re: LM 2.4.1: errors in variable definitions

[Federico Bruni]

Il giorno dom 17 lug 2016 alle 11:44, David Kastrup  ha 
scritto:

 Of course, but this is the standard \paper property and the whole
 point of the example in the documentation is defining variables.

 We may omit the unit and use the default one (millimeters). But I
 wonder if this is a bug or there's a better way to define such a
 variable.


I thought the default unit was staff spaces?  Don't quote me on that 
but
I thought that the main mess was that the definition of \cm changed 
when

one changed the default staff size.


Perhaps the default unit of \paper properties is millimeters? That 
would make sense. While staff spaces make sense for elements of the 
notation.


I just made a test. A 208 line-width spans almost all the 210x210 
document:


\version "2.19.45"

width = 208
stringName = "Wendy"
aFivePaper = \paper { paper-height = 210 }

\paper {
 \aFivePaper
 line-width = \width
 ragged-last = ##f
 indent = 0
}

{
 c4^\stringName
}




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

Re: LM 2.4.1: errors in variable definitions

[Federico Bruni]

Il giorno dom 17 lug 2016 alle 10:45, Malte Meyn 
<lilyp...@maltemeyn.de> ha scritto:



Am 17.07.2016 um 09:16 schrieb Federico Bruni:


3. width variable triggers this error:
error: unknown escaped string: `\cm'

I don't know how to fix this,


Put the definition of width into an \paper block. cm seems to be 
unknown outside.


\paper {
  width = 4.5\cm
}


Of course, but this is the standard \paper property and the whole point 
of the example in the documentation is defining variables.


We may omit the unit and use the default one (millimeters). But I 
wonder if this is a bug or there's a better way to define such a 
variable.





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

Re: PDF metadata missing if \header is within a \bookpart block

[Federico Bruni]

Il giorno ven 15 lug 2016 alle 10:47, David Kastrup <d...@gnu.org> ha 
scritto:

Federico Bruni <f...@inventati.org> writes:


 Il giorno dom 3 lug 2016 alle 14:57, Simon Albrecht
 <simon.albre...@mail.de> ha scritto:

 Let me explain better.
 In a directory I have single files for each song. I want to 
compile

 each of them as a standalone PDF. But I also want to include them
 in a master file which acts as an anthology book.
 So the master file already works fine, because the \header is in
 the top level.
 The problem is with each single song, because the songs use
 \bookpart.


 Well, I suppose you need to find a clever way of setting pdftitle 
in

 the wrapper files for the single songs. This kind of things can be
 really annoying and convoluted…


 This is going to cause me headaches. I've always fought with this 
sort

 of things in LilyPond.
 The problem is that I cannot include music variables within a
 \bookpart block.


Come again?  Why wouldn't you be able to do that?


If you try to compile the file John-Doe-Anthology.ly in the _first_ set 
of files I sent yesterday you get the error:


composition-1.ily:2:1: errore: syntax error, unexpected STRING

myMusic = \relative {


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

Re: PDF metadata missing if \header is within a \bookpart block

[Federico Bruni]

Il giorno gio 14 lug 2016 alle 10:58, Federico Bruni 
<f...@inventati.org> ha scritto:
Il giorno dom 3 lug 2016 alle 14:57, Simon Albrecht 
<simon.albre...@mail.de> ha scritto:

Let me explain better.
In a directory I have single files for each song. I want to compile 
each of them as a standalone PDF. But I also want to include them 
in a master file which acts as an anthology book.
So the master file already works fine, because the \header is in 
the top level.
The problem is with each single song, because the songs use 
\bookpart.


Well, I suppose you need to find a clever way of setting pdftitle in 
the wrapper files for the single songs. This kind of things can be 
really annoying and convoluted…


This is going to cause me headaches. I've always fought with this 
sort of things in LilyPond.
The problem is that I cannot include music variables within a 
\bookpart block.

I suspect that what I want to achieve is not possible.

See attached examples.
The -part.ly files compile fine, but the Anthology will fail. I see 
why it's failing but I cannot find other ways.

___


Ok, I found a solution:

I use named variables specific for each piece (compositionOneMusic, 
compositionTwoMusic), so that I can include the .ily files at top 
level, in the anthology book file, without any clashing (I was used to 
set the same variable names, e.g. upper and lower, because my file 
structure avoided this clashing).


Attached files explain better than my words.


\version "2.19.45"

\header {
  title = "Composition 2"
  composer = "John Doe"
  pdfauthor = "John Doe"
}

\include "composition-2.ily"
\compositionTwoScore
\version "2.19.45"
compositionOneMusic = \relative {
  c4 d e2 |
}

compositionOneScore = \score {
  \new StaffGroup <<
\new Staff { \clef "treble_8" \compositionOneMusic }
\new TabStaff { \clef "moderntab" \new TabVoice \compositionOneMusic }
  >>
  \layout { indent = 0 }
}
\version "2.19.45"
compositionTwoMusic = \relative {
  d'4 e g2 |
}

compositionTwoScore = \score {
  \new StaffGroup <<
\new Staff { \clef "treble_8" \compositionTwoMusic }
\new TabStaff { \clef "moderntab" \new TabVoice \compositionTwoMusic }
  >>
  \layout { indent = 0 }
}
\version "2.19.45"
\include "composition-1.ily"
\include "composition-2.ily"

\book {
  \header {
composer = "John Doe"
pdfauthor = "John Doe"
title = "John Doe Anthology"
  }
  \bookpart {
\header {
  title = "Composition 1"
  composer = "John Doe"
}
\compositionOneScore
  }
  \bookpart {
\header {
  title = "Composition 2"
  composer = "John Doe"
}
\compositionTwoScore
  }
}\version "2.19.45"

\header {
  title = "Composition 1"
  composer = "John Doe"
  pdfauthor = "John Doe"
}

\include "composition-1.ily"

\compositionOneScore
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond