Issue 5180: Require \version statement in main file (issue 325640043 by d...@gnu.org)

[Carl . D . Sorensen]

LGTM

https://codereview.appspot.com/325640043/

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

Add regtest for issue 5181 (issue 327470043 by d...@gnu.org)

[Carl . D . Sorensen]

LGTM

https://codereview.appspot.com/327470043/

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

Don't let event-chord-reduce bomb on empty chords (issue 327480043 by d...@gnu.org)

[Carl . D . Sorensen]

LGTM

https://codereview.appspot.com/327480043/

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

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[Carl . D . Sorensen]

On 2017/09/24 14:32:02, trueroad wrote:


* -dgs-neverembed-fonts



Add behavior



Current behavior
- For PDF output, It does not embed fonts except TrueType fonts.



Added behavior
- Define and use some encodings for Emmentaler. (Also using "show"

instead of

"glyphshow")
- For PDF output, It does not embed fonts except TrueType fonts.



This option is for non-embedded font intermediate PDFs, and later uses
Ghostscript to embed missing fonts.



This method needs to pass the missing fonts to Ghostscript.
In other words, it is for specialists.
However, if it is used properly, it works even with the current

Ghostscript.

So if I understand this correctly, properly using -dgs-neverembed-fonts
as part of our manual build process will give us *both* smaller
intermediate files and a small final file?  That sounds perfect to me!

Carl




https://codereview.appspot.com/325630043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[pkx166h]

On 2017/09/24 15:34:15, Jean-Charles wrote:

On 2017/09/24 14:20:08, pkx166h wrote:
> Corrected the Note styles. Added more formatting changes.



Would you mind formatting the "Standard clefs" as well, which would

then "group"

G, C and F-clefs and have a more pleasant layout?


Pas de problème!

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[pkx166h]

On 2017/09/24 18:02:11, benko.pal wrote:

Hello James,



> I took a bit of time to educate myself with Ancient notation and

have,

> hopefully, picked the correct note styles now.
>
> Should I use the red 4-line-staff for the rest of the examples or

just

> for the Gregorian clefs?



Just for the Gregorian clefs.  Mensural clefs, as the C-clefs witness,
assume five line staves.



> https://cloud.woelkli.com/s/dBGXat0NEGVoy5C



The modified link is almost perfect, just two nits to pick:
- hufnagel-do-fa is misaligned (both the c and f should be on line, as
if hufnagel-do3-fa1) -- this may be a bug elsewhere.


Well I wonder if it is because I used 4 lines - I have now used, as per
Werner's suggestion, used 5 lines. See if this works.


- petrucci-f5 is duplicated.


Oh yes. Fixed. Thanks.



Thanks,
Pal




https://codereview.appspot.com/324420043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[pkx166h]

On 2017/09/24 14:52:07, lemzwerg wrote:

> Should I use the red 4-line-staff for the rest
> of the examples or just for the Gregorian clefs?



Red four-line staves should be probably used for Gregorian only.

However, I'm

not an expert, so maybe others have a more educated opinion.



Two other problems.



* For Hufnagel clefs you should also use Hufnagel note heads.


Thanks, now done, these are not documented (at least I could not find
them) in the NR.



* The hufnagel-do-fa clef doesn't make sense for four lines.  Either

set this

clef one line lower, or use a five-line staff, cf.


5 lines it is. Thanks.




http://www.schoyencollection.com/media/djcatalog2/images/hufnagel-notation-5-line-staff-ms-1589_f.jpg



https://codereview.appspot.com/324420043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[Benkő Pál]

Hello James,

> I took a bit of time to educate myself with Ancient notation and have,
> hopefully, picked the correct note styles now.
>
> Should I use the red 4-line-staff for the rest of the examples or just
> for the Gregorian clefs?

Just for the Gregorian clefs.  Mensural clefs, as the C-clefs witness,
assume five line staves.

> https://cloud.woelkli.com/s/dBGXat0NEGVoy5C

The modified link is almost perfect, just two nits to pick:
- hufnagel-do-fa is misaligned (both the c and f should be on line, as
if hufnagel-do3-fa1) -- this may be a bug elsewhere.
- petrucci-f5 is duplicated.

Thanks,
Pal

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

Re: How to locate all layout-property values for a particularLayoutObject in the source files?

[Thomas Morley]

2017-09-24 17:59 GMT+02:00 Trevor Daniels :
>
> Simon Albrecht wrote Sunday, September 24, 2017 4:34 PM
>
>
>> On 24.09.2017 14:30, James wrote:
>>> Where would I go to see the 'complete list' of all possible NoteHead.style 
>>> values
>>
>> 
>> – the description of the style property isn’t helpful (since it
>> summarises the use of that property in any grob), but at the top of the
>> page there is a link to all the styles.
>>
>
> This links to Appendix A.9 which seems to be incomplete.
> For example, it doesn't contain semipetrucci or blackpetrucci,
> which differ from petrucci in the longer note values.  Kievan is
> missing too.
>
> So part of James' work might be to extend this table too.
>
> Trevor

For clefs we have supported-clefs in parser-clef.scm, but nothing for
note-head-styles.
The best list I know of is in
input/regression/markup-note-styles.ly

Both maintained manually, though.

Cheers,
  Harm

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

Re: How to locate all layout-property values for a particularLayoutObject in the source files?

[Trevor Daniels]

Simon Albrecht wrote Sunday, September 24, 2017 4:34 PM


> On 24.09.2017 14:30, James wrote:
>> Where would I go to see the 'complete list' of all possible NoteHead.style 
>> values
> 
> 
>  
> – the description of the style property isn’t helpful (since it 
> summarises the use of that property in any grob), but at the top of the 
> page there is a link to all the styles.
> 

This links to Appendix A.9 which seems to be incomplete.
For example, it doesn't contain semipetrucci or blackpetrucci,
which differ from petrucci in the longer note values.  Kievan is
missing too.

So part of James' work might be to extend this table too.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to locate all layout-property values for a particular LayoutObject in the source files?

[Simon Albrecht]

On 24.09.2017 14:30, James wrote:

Where would I go to see the 'complete list' of all possible NoteHead.style 
values


 
– the description of the style property isn’t helpful (since it 
summarises the use of that property in any grob), but at the top of the 
page there is a link to all the styles.


Best, Simon

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[lilyfan]

On 2017/09/24 14:20:08, pkx166h wrote:

Corrected the Note styles. Added more formatting changes.


Would you mind formatting the "Standard clefs" as well, which would then
"group" G, C and F-clefs and have a more pleasant layout?

https://codereview.appspot.com/324420043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[lemzwerg]

Should I use the red 4-line-staff for the rest
of the examples or just for the Gregorian clefs?


Red four-line staves should be probably used for Gregorian only.
However, I'm not an expert, so maybe others have a more educated
opinion.

Two other problems.

* For Hufnagel clefs you should also use Hufnagel note heads.

* The hufnagel-do-fa clef doesn't make sense for four lines.  Either set
this clef one line lower, or use a five-line staff, cf.


http://www.schoyencollection.com/media/djcatalog2/images/hufnagel-notation-5-line-staff-ms-1589_f.jpg

https://codereview.appspot.com/324420043/

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

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[trueroad]

On 2017/09/24 11:03:26, dak wrote:

In my opinion, -b/--bigpdf should be simple to use for

lilypond-book-like

applications.  lilypond-book should likely call lilypond using options

leading

to good results by default.  For generating our own documentation, I

find 3-4GB

of disk space excessive: using special additional options might be

suitable if

that helps.  If the additional options work at least as well under all
conceivable circumstances, they should likely be the default.



-dxxx are options appealing more to specialists (well, there are

things like

-dpreview not particularly specialist, but when in doubt, people are

more likely

to see/consider "normal" options).



I'm not into the whole font mess enough to make a really qualified

suggestion

here.


To make the options simple, what about doing as follows?



* --bigpdfs / -b

Keep its behavior

i.e.
- Define and use some encodings for Emmentaler. (Also using "show"
instead of "glyphshow")
- For PDF output, embed full set (non-subset) font (if there is no bugs
in Ghostscript)

This option is for full set (non-subset) embedded font intermediate
PDFs, and later uses MuPDF etc. to remove duplicate the fonts.

This method is simple and easy to understand.
However, the size of the intermediate PDF increases.
Also, the current Ghostscript does not work properly because there seems
to be a bug in which full set of fonts can not be embedded.



* -dgs-neverembed-fonts

Add behavior

Current behavior
- For PDF output, It does not embed fonts except TrueType fonts.

Added behavior
- Define and use some encodings for Emmentaler. (Also using "show"
instead of "glyphshow")
- For PDF output, It does not embed fonts except TrueType fonts.

This option is for non-embedded font intermediate PDFs, and later uses
Ghostscript to embed missing fonts.

This method needs to pass the missing fonts to Ghostscript.
In other words, it is for specialists.
However, if it is used properly, it works even with the current
Ghostscript.


https://codereview.appspot.com/325630043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[pkx166h]

On 2017/09/24 14:27:05, pkx166h wrote:

@Phil @Benko



I took a bit of time to educate myself with Ancient notation and have,
hopefully, picked the correct note styles now.



Should I use the red 4-line-staff for the rest of the examples or just

for the

Gregorian clefs?


https://cloud.woelkli.com/s/RohlvM7Gcj5G0yy (new link)


This is a 300kb PDF of the Ancient Clefs as they will appear in the

notation

appendix.


https://codereview.appspot.com/324420043/

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[Werner LEMBERG]

> https://cloud.woelkli.com/s/dBGXat0NEGVoy5C

This link doesn't work (`Invalid PDF structure').


Werner

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

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

[pkx166h]

@Phil @Benko

I took a bit of time to educate myself with Ancient notation and have,
hopefully, picked the correct note styles now.

Should I use the red 4-line-staff for the rest of the examples or just
for the Gregorian clefs?

https://cloud.woelkli.com/s/dBGXat0NEGVoy5C

This is a 300kb PDF of the Ancient Clefs as they will appear in the
notation appendix.


https://codereview.appspot.com/324420043/diff/40001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (left):

https://codereview.appspot.com/324420043/diff/40001/Documentation/notation/notation-appendices.itely#oldcode1484
Documentation/notation/notation-appendices.itely:1484:
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
On 2017/09/12 14:47:04, pkx166h wrote:

Note to self - this @item needs to be an @tab


Done.

https://codereview.appspot.com/324420043/diff/40001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):

https://codereview.appspot.com/324420043/diff/40001/Documentation/notation/notation-appendices.itely#newcode1542
Documentation/notation/notation-appendices.itely:1542: @code{\clef
varpercussion}
On 2017/09/12 14:47:04, pkx166h wrote:

Note to self - this @item needs to be an @tab


Done.

https://codereview.appspot.com/324420043/

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

Re: How to locate all layout-property values for a particularLayoutObject in the source files?

[Phil Holmes]

Don't know if this helps, but _one_ way would be to go to build/mf/out and 
then enter


fontforge parmesan-noteheads11.pfb

This will give you a display of all the ancient noteheads and their names.

--
Phil Holmes


- Original Message - 
From: "James" 

To: "Dev" 
Sent: Sunday, September 24, 2017 1:30 PM
Subject: How to locate all layout-property values for a 
particularLayoutObject in the source files?




Hello,

I apologise in advance if I ask this question in a less-than-meaningful 
way, simply because I don't know what the correct terms for some these 
LilyPond-specific things are (or I mix them up), but I hope you will get 
what it is I am asking for anyway.


If I take this example of an @lilypond example in the Ancient Music 
section:


---8<---

\override NoteHead.style = #'petrucci
a'\maxima a'\longa a'\breve a'1 a'2 a'4 a'8 a'16 a'
\override NoteHead.style = #'semipetrucci
a'\breve*5/6
\override NoteHead.style = #'blackpetrucci
a'8*4/3 a'

--->8---

Where would I go to see the 'complete list' of all possible NoteHead.style 
values - the 'values' (?) that come after the "#'" (I forget what they are 
called), if for example a developer added a style but hadn't put anything 
in the NR?


Let's say there was a NoteHead.style = #'semiblackpetrucci (I know there 
isn't such a thing) but which file would I see these defined?


grepping just for (say) 'blackpetrucci' get's me lots of hits in the font 
files and a few 'scm' files but all I want to see is the possible list of 
'NoteHead.styles' that can be defined within the source.


I do hope that made sense?

Thank you for your time.

James


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




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

How to locate all layout-property values for a particular LayoutObject in the source files?

[James]

Hello,

I apologise in advance if I ask this question in a less-than-meaningful way, 
simply because I don't know what the correct terms for some these 
LilyPond-specific things are (or I mix them up), but I hope you will get what 
it is I am asking for anyway.

If I take this example of an @lilypond example in the Ancient Music section:

---8<---

\override NoteHead.style = #'petrucci
a'\maxima a'\longa a'\breve a'1 a'2 a'4 a'8 a'16 a'
\override NoteHead.style = #'semipetrucci
a'\breve*5/6
\override NoteHead.style = #'blackpetrucci
a'8*4/3 a'

--->8---

Where would I go to see the 'complete list' of all possible NoteHead.style 
values - the 'values' (?) that come after the "#'" (I forget what they are 
called), if for example a developer added a style but hadn't put anything in 
the NR?

Let's say there was a NoteHead.style = #'semiblackpetrucci (I know there isn't 
such a thing) but which file would I see these defined?

grepping just for (say) 'blackpetrucci' get's me lots of hits in the font files 
and a few 'scm' files but all I want to see is the possible list of 
'NoteHead.styles' that can be defined within the source.

I do hope that made sense?

Thank you for your time.

James


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

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[dak]

On 2017/09/24 10:05:43, trueroad wrote:

On 2017/09/24 00:25:17, knupero wrote:
> > If I understand correctly, `--bigpdfs` / `-b` has two effects.
> > One is to embed full set (non-subset) font.
> > The other is to define and use some encodings for Emmentaler.
>
> It also changes the way emmentaler glyphs are printed. With

--bigpdfs we use

the
> "show" postscript operator, without it we still use "glyphshow". And

the three

> emmentaler fonts for every size in the intermediate versions of our

pdfs are

not
> 3 copies of the full emmentaler-xx font but are three different

fonts made of

> emmentaler-xx glyphs. Those subsets must not be further subsetted.



I wrote "to define and *use* the some encodings".
If I understand correctly, "glyphshow" doesn't use any encodings but

"show" uses

the encoding.
What I wrote as "use" means using "show" instead of "glyphshow".



> No, it is senseless to split -b into separate options.



Again, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are

used at the

same time, the intermediate PDFs become larger.
The disk size that `make doc` eats becomes increased.



If spliting -b, `-dgs-never-embed-fonts -duse-notation-font-encodings`

doesn't

embed full set TrueType fonts.
It embeds subset for TrueType fonts, as with only using
`-dgs-never-embed-fonts`.
The intermediate PDFs don't become larger.
The disk size that `make doc` eats doesn't become increased.
Nevertheless, the encodings for notation font is defined and "show" is

used.

In my humble opinion, this is better than `-dgs-never-embed-fonts -b`.



Of course, if we do not have to worry about the increase in disk size

required,

splitting -b is senseless as you wrote.


In my opinion, -b/--bigpdf should be simple to use for
lilypond-book-like applications.  lilypond-book should likely call
lilypond using options leading to good results by default.  For
generating our own documentation, I find 3-4GB of disk space excessive:
using special additional options might be suitable if that helps.  If
the additional options work at least as well under all conceivable
circumstances, they should likely be the default.

-dxxx are options appealing more to specialists (well, there are things
like -dpreview not particularly specialist, but when in doubt, people
are more likely to see/consider "normal" options).

I'm not into the whole font mess enough to make a really qualified
suggestion here.

https://codereview.appspot.com/325630043/

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

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[trueroad]

On 2017/09/24 00:25:17, knupero wrote:

> If I understand correctly, `--bigpdfs` / `-b` has two effects.
> One is to embed full set (non-subset) font.
> The other is to define and use some encodings for Emmentaler.



It also changes the way emmentaler glyphs are printed. With --bigpdfs

we use the

"show" postscript operator, without it we still use "glyphshow". And

the three

emmentaler fonts for every size in the intermediate versions of our

pdfs are not

3 copies of the full emmentaler-xx font but are three different fonts

made of

emmentaler-xx glyphs. Those subsets must not be further subsetted.


I wrote "to define and *use* the some encodings".
If I understand correctly, "glyphshow" doesn't use any encodings but
"show" uses the encoding.
What I wrote as "use" means using "show" instead of "glyphshow".


No, it is senseless to split -b into separate options.


Again, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are used
at the same time, the intermediate PDFs become larger.
The disk size that `make doc` eats becomes increased.

If spliting -b, `-dgs-never-embed-fonts -duse-notation-font-encodings`
doesn't embed full set TrueType fonts.
It embeds subset for TrueType fonts, as with only using
`-dgs-never-embed-fonts`.
The intermediate PDFs don't become larger.
The disk size that `make doc` eats doesn't become increased.
Nevertheless, the encodings for notation font is defined and "show" is
used.
In my humble opinion, this is better than `-dgs-never-embed-fonts -b`.

Of course, if we do not have to worry about the increase in disk size
required, splitting -b is senseless as you wrote.

https://codereview.appspot.com/325630043/

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