NR pdf is larger with current git by 15%

2020-07-10 Thread Werner LEMBERG


Masamichi-san,


your fix for gs works fine; the resulting PDFs are small again.
Thanks a lot!

BUT: They are not as small as previously.  For example, with commit
21a20de3, the NR has 10 pages more and is now 8.3MByte (I've tested
compilation with both gs 9.21 and 9.52) instead of 7.1MByte (with gs
9.21, produced April 20th using commit f86f7705).  As far as I can
see, my used xetex binary is the same, as is `texinfo.tex` (version
2019-02-16.14), and the included fonts.

Do you have any explanation for this?  Is this expected, probably a
side effect of your latest changes?  I uncompressed the PDFs using
`pdftk` and did a comparison; unfortunately I couldn't see big
differences in the diff file, which probably hints at small but many
changes that accumulate to the 15% difference.


Werner



Re: [lilypond-book] @format environments

2020-07-10 Thread Michael Käppler

Am 09.07.2020 um 18:09 schrieb Trevor:

Michael Käppler, you wrote 09/07/2020 12:45:28


What strikes me the most is that 'addversion' is used only three times
throughout the
whole documentation, and these three occurrences are all in the LM,
fundamental.itely

What is the reason that the version string is mentioned for these
particular snippets and nowhere else?

I'm guessing, but I think these are the only examples that purport to be
"complete" LP programs. Everything else are just snippets of code.

The other possibility is that these were written by Graham, I think,
whereas I wrote most of the others.

According to the git history, you wrote it in 2007, but these days
the 'addversion' option did not exist.
See
396a1debe40aa5715cdc0cbe6cb90bc677004261

This option was added by John Mandereau in February 2008
with
f6caefb696b778cd8f49acc127583253f020248c

In April 2008, John adjusted your snippet to use the 'addversion' option.

However, the history also states that 'addversion' was removed from
two snippets in January 2016 with
8892bd951e1705e116b36cf2243c061f74e73af9
by Greg Swinford.


I don't think it would be a problem if the version strings were dropped,
though.

I would like to support this opinion.
The 'addversion' option, as it is now, is useless for end users, because
it relies on
the @version macro to be defined.

So we could either
1. Drop the support for 'addversion' in lilypond-book completely
2. Let lilypond-book prepend the version string to verbatim snippets
depending on the version it uses for compiling the snippet, not
on the @version macro. (if this is possible without a major rewrite)

IMHO, the graphical output and version string should match.
I do not know, if somebody actually compiles the documentation
with a precompiled lilypond/lilypond-book. But with the current setup
it could happen that a snippet is compiled with a
lilypond version different from the \version string and the
conclusion: "Alright, this snippets looks that particular way if compiled
with lilypond 2.x.x." would be misleading.

Please correct me if I have some wrong thinking here.

Michael





PATCHES - Countdown for July 10th

2020-07-10 Thread James

Hello,

Here is the current patch countdown list. The next countdown will be on 
July 12th.


A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!229 Various internal renaming (C++) - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/229

!228 Remove unneeded files from build artifacts - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/228

!227 doc preliminaries - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/227

!226 Fix autogen.sh CFLAGS="foo bar" - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/226

!38 GNUmakefile.in: remove remove-test-changed support - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/38


 Countdown:

!233 Emmentaler-brace: do not write temporary afm files - Michael Käppler
https://gitlab.com/lilypond/lilypond/-/merge_requests/233

!232 doc: Fix index entries with `@sortas` if used with recent 
`texinfo.tex` - Werner Lemberg

https://gitlab.com/lilypond/lilypond/-/merge_requests/232

!231 Update authors.itexi - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/231

!230 musicxml2ly: Bar check only before first note - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/230


 Review:

No patches in Review at this time.


 New:

!234 lilypond-book: Allow spaces in directory name - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/234


 Waiting:

!223 Clean up and annotate postprocess_html.py - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/223

!204 Move parallel processing to lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/204

!202 Fix xrefs in learning manual - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/202

!200 Add snippet translations - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/200


***

Regards,

James




Re: Accidentals' font

2020-07-10 Thread Urs Liska
Am Freitag, den 10.07.2020, 10:34 +0200 schrieb Jean-Julien Fleck:
> Hello Urs,
> 
> Le ven. 10 juil. 2020 à 09:03, Urs Liska  a
> écrit :
> > 
> > But I'd like to repeat that the fonts created by Abraham (including
> > 
> > Gonville) are at least partially available as free fonts, and they
> > 
> > already *can* be used in a regular LilyPond installation without
> > any
> > 
> > hassles.
> > 
> > 
> > 
> > All you need to do is copy (or better link) the font files in the
> > fonts
> > 
> > directory (Frescobaldi even offers a nice interface for handling
> > that
> > 
> > for arbitrary new LilyPond installations) and add some code to the
> > 
> > paper block of your document. 
> > 
> > If you use openLilyLib this is as easy as \useNotationFont
> > Gonville.
> > 
> > The notation-fonts package even provides (optional) default
> > stylesheets
> > 
> > for all supported fonts (to provide a good starting point regarding
> > 
> > e.g. line thicknesses).
> 
> Could you please give us a link that explains how to do that
> installation ?
> 
> 
> I've been searching (a bit) ever since the page 
> https://github.com/OpenLilyPondFonts appeared in this thread but
> couldn't find a tutorial to explain step by step what to do. I would
> have expected that such an explanation to be placed in the README.md
> file at the top of each font repository, at least pointing to a place
> explaining the generic way to do it but I couldn't find any.
> 
> Is there such a step-by-step tutorial and where can I find it ?

Unfortunately not comprehensively.
There's  https://github.com/openlilylib/oll-core/wikiwhich explains how
to obtain openLilyLib
  https://github.com/openlilylib/notation-fonts/gives a short overview
on how the notation-fonts package is used.
  
https://github.com/openlilylib/notation-fonts/tree/master/usage-examples/fontsincludes
several usage examples (along with compiled PDF files).
I'm not sure where installing additional fonts in LilyPond is
explained, but in a nutshell: you have to identify
the  /usr/share/lilypond/current/fonts/directory within a given
LilyPond installation, and drop the OTF and SVG font files in the
corresponding subdirectory (.woff files go into SVG).Best practice for
this is storing all your fonts in one central location and place links
into the LilyPond directory.
If you use a current Frescobaldi the tool Tools=>Document fonts
provides a convenient interface for manging fonts (installation and
creating the input code).
HTH
Urs
> Thanks,
> 
> --
> JJ Fleck
> Physique et Informatique
> PCSI1 Lycée Kléber


Re: Accidentals' font

2020-07-10 Thread Jean Abou Samra

Hi Jean-Julien,

Le 10/07/2020 à 10:34, Jean-Julien Fleck a écrit :

Hello Urs,


Le ven. 10 juil. 2020 à 09:03, Urs Liska > a écrit :



But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the
fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document.

The manual procedure is described at 
http://lilypond.org/doc/v2.20/Documentation/notation/replacing-the-notation-font.en.html


I guess you can also just open the dedicated Frescobaldi interface and 
follow the steps.



If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default
stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).


Could you please give us a link that explains how to do that 
installation ?


I've been searching (a bit) ever since the page 
https://github.com/OpenLilyPondFonts appeared in this thread but 
couldn't find a tutorial to explain step by step what to do. I would 
have expected that such an explanation to be placed in the README.md 
file at the top of each font repository, at least pointing to a place 
explaining the generic way to do it but I couldn't find any.


Is there such a step-by-step tutorial and where can I find it ?


What Urs describes is an openLilyLib package, so you want to get started 
with openLilyLib first. 
https://www.openlilylib.org/getstarted/install.html, perhaps?


Regards,
Jean Abou Samra



Re: Accidentals' font

2020-07-10 Thread Jean-Julien Fleck
Hello Urs,


Le ven. 10 juil. 2020 à 09:03, Urs Liska  a écrit :

>
> But I'd like to repeat that the fonts created by Abraham (including
> Gonville) are at least partially available as free fonts, and they
> already *can* be used in a regular LilyPond installation without any
> hassles.
>
> All you need to do is copy (or better link) the font files in the fonts
> directory (Frescobaldi even offers a nice interface for handling that
> for arbitrary new LilyPond installations) and add some code to the
> paper block of your document.
> If you use openLilyLib this is as easy as \useNotationFont Gonville.
> The notation-fonts package even provides (optional) default stylesheets
> for all supported fonts (to provide a good starting point regarding
> e.g. line thicknesses).
>

Could you please give us a link that explains how to do that installation ?

I've been searching (a bit) ever since the page
https://github.com/OpenLilyPondFonts appeared in this thread but couldn't
find a tutorial to explain step by step what to do. I would have expected
that such an explanation to be placed in the README.md file at the top of
each font repository, at least pointing to a place explaining the generic
way to do it but I couldn't find any.

Is there such a step-by-step tutorial and where can I find it ?

Thanks,

--
JJ Fleck
Physique et Informatique
PCSI1 Lycée Kléber


Re: Accidentals' font

2020-07-10 Thread Urs Liska
Am Donnerstag, den 09.07.2020, 21:40 +0200 schrieb Paolo Prete:
> On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra 
> wrote:
> 
> > Le 08/07/2020 à 15:31, Paolo Prete a écrit :
> > 
> > 
> > 
> > On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra  > >
> > wrote:
> > 
> > > I would like to emphasize that this is not at all simple. I agree
> > > that
> > > the technical part is reachable. Yet, this has consequences on
> > > the
> > > organization of the LilyPond ecosystem that have to be considered
> > > with care.
> > > 
> > > Fonts external to LilyPond also have development cycles that are
> > > different from LilyPond’s. If Gonville or other fonts were
> > > integrated as
> > > built-in options, we would end up receiving bug reports or
> > > feature requests
> > > from fellow users about fonts which we are incompetent about. It
> > > would
> > > force the authors of these fonts to follow LilyPond issues and
> > > make changes
> > > in parallel with Feta, for example, make it SMuFL-compliant by
> > > the end of
> > > the summer, which is very demanding. When the original author
> > > will not be
> > > available or no longer willing to support it, users will complain
> > > about the
> > > font not working and other LilyPond developers will need to fix
> > > it, and
> > > first learn its generation system, which is a custom one entirely
> > > different
> > > from Feta’s.
> > > 
> > 
> > Hello Jean,
> > 
> > I think the problem you emphasize is automatically solved with the
> > ./configure flag. Let me show a practical example.
> > ffMPEG has a native aac codec and a configure flag (--enable-
> > libfdk-aac)
> > which adds a third-party aac encoder (Fraunhofer FDK AAC).
> > 
> > Hi Paolo,
> > 
> > If I'm not mistaken, the use case for configure flags like
> > --enable-guilev2 is to influence compilation. By contrast, fonts
> > are loaded
> > dynamically at runtime. Hence, a configure flag would essentially
> > do
> > nothing but move a few files (except if it changed the default, but
> > we
> > don't want that).
> > 
> 
> Hi Jean,
> 
> I intended it exactly in the way you described. That flag would not
> influence compilation but only *linking*, preventing compatibility
> issues
> (mismatch of versions)
> 
> 
> > In fact, it's already possible and very simple to build LilyPond
> > with
> > Gonville support: just follow the usual build procedure, then copy
> > the
> > Gonville OTF files into
> > build/out/share/lilypond/current/fonts/otf/. That's
> > simple enough that I don't believe it deserves a special flag.
> > 
> 
> Yes, but this would make a *patched* build, and not a clean build.
> Note too
> that the flag should be more general than --with-gonville-font (for
> example, just an extemporary idea: --with-font=gonville,foobarfont
> etc.)
> 
> 
> 
> > Doing that, every maintainer of a *distro* (I highlight the word
> > *distro*,
> > and not the src one) can choose to create the binary with or
> > without third
> > party pieces.
> > Note that, for example, ffMPEG. There are some distros of ffMPEG
> > with
> > x264, and some distros without.
> > 
> > This nuance is not possible with LilyPond since, to my knowledge,
> > the vast
> > majority of users downloads binaries from lilypond.org.
> > 
> 
> This is true. But what if, in the future, someone wants to create,
> for
> example, a Linux Distro called LilyBuntu ? ;-)
> 
> 
> 
> > That said, I really think we ought to pause this discussion until
> > the
> > details of SMuFL support get clear.
> > 
> > 
> I agree. I pause it as well.
> 

But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document. 
If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).

So I really don't see the need for a patched compilation of LilyPond.
Urs

>  Best,
> P