Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

2016-06-13 Thread trueroad

I came up with another idea.

Remove `-dgs-load-fonts` from lilypond-book default.
During LilyPond and its documents are built, `-dgs-load-lily-fonts`
option instead of `-dgs-load-fonts` is used.

`-dgs-load-lily-fonts` means "Load only the LilyPond fonts via
Ghostscript."

"LilyPond fonts" mean the fonts in the LilyPond data directory.
i.e. Emmentaler, TeX Gyre Schola, TeX Gyre Heros, and TeX Gyre Cursor,
in default.

For LilyPond document building,
other font glyphs are embedded to intermediate EPSs.
But most fonts in LilyPond documents are Emmentaler and TeX Gyre.
So their glyphs are not embedded to the EPSs.

How about this?


https://codereview.appspot.com/300280043/

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


Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

2016-06-13 Thread pkx166h

On 2016/06/13 14:00:57, trueroad wrote:

I came up with another idea.



Remove `-dgs-load-fonts` from lilypond-book default.
During LilyPond and its documents are built, `-dgs-load-lily-fonts`

option

instead of `-dgs-load-fonts` is used.



`-dgs-load-lily-fonts` means "Load only the LilyPond fonts via

Ghostscript."


"LilyPond fonts" mean the fonts in the LilyPond data directory.
i.e. Emmentaler, TeX Gyre Schola, TeX Gyre Heros, and TeX Gyre Cursor,

in

default.



For LilyPond document building,
other font glyphs are embedded to intermediate EPSs.
But most fonts in LilyPond documents are Emmentaler and TeX Gyre.
So their glyphs are not embedded to the EPSs.



How about this?


We would have to be careful none of the snippets or even @lilypond
examples used other fonts - I am thinking perhaps if there are any
'Cyrillic' or 'Hebrew' type fonts. As doc building does actually build a
'snippet' document but not the entire LSR, this might cause us problems
or end up with 'missing' fonts in the snippets. I don't know how to
'quickly' check this and I am not sure if I would (when testing patches)
see any errors for missing fonts while compiling docs. I seem to recall
some fix we had a few months ago where the 'Pi' (?) Character was not
being displayed properly - or something like that.

https://codereview.appspot.com/300280043/

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


Scheme question

2016-06-13 Thread Phil Holmes
Can anyone explain why the f in the attached code is 2 octaves above where 
I would expect them?

testy = #(define-music-function (note)
  (ly:music?)
#{
  \tag #'a { #note }
  \tag #'b { #note }
#})

\score {
\keepWithTag #'a {
\new Staff
{
  \new Voice { \relative c'' { c d e \testy f } }
}
  }
}

TIA


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


Re: Scheme question

2016-06-13 Thread Urs Liska


Am 13. Juni 2016 19:51:48 MESZ, schrieb Phil Holmes :
>Can anyone explain why the f in the attached code is 2 octaves above
>where 
>I would expect them?

Where *do* you expect it?

>
>testy = #(define-music-function (note)
>  (ly:music?)
>#{
>  \tag #'a { #note }
>  \tag #'b { #note }
>#})
>
>\score {
>\keepWithTag #'a {
>\new Staff
>{
>  \new Voice { \relative c'' { c d e \testy f } }
>}
>  }
>}
>
>TIA
>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

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


Re: Scheme question

2016-06-13 Thread David Kastrup
Phil Holmes  writes:

> Can anyone explain why the f in the attached code is 2 octaves above where 
> I would expect them?
>
> testy = #(define-music-function (note)
>   (ly:music?)
> #{
>   \tag #'a { #note }
>   \tag #'b { #note }
> #})
>
> \score {
> \keepWithTag #'a {
> \new Staff
> {
>   \new Voice { \relative c'' { c d e \testy f } }
> }
>   }
> }

Because you let it be shifted two times before selecting your tag?  Your
music does not contain two _copies_ of note, but rather contains note
_itself_ two times.  So \relative is applied to the same music two times
in succession.

Use #(music-clone note) or #(ly:music-deep-copy note) or $note for your
two uses, and the note will get placed in two separate _copies_ of the
original rather than using the note object itself in two places.

-- 
David Kastrup

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


Re: Scheme question

2016-06-13 Thread David Kastrup
David Kastrup  writes:

> Phil Holmes  writes:
>
>> Can anyone explain why the f in the attached code is 2 octaves above where 
>> I would expect them?
>>
>> testy = #(define-music-function (note)
>>   (ly:music?)
>> #{
>>   \tag #'a { #note }
>>   \tag #'b { #note }
>> #})
>>
>> \score {
>> \keepWithTag #'a {
>> \new Staff
>> {
>>   \new Voice { \relative c'' { c d e \testy f } }
>> }
>>   }
>> }
>
> Because you let it be shifted two times before selecting your tag?  Your
> music does not contain two _copies_ of note, but rather contains note
> _itself_ two times.  So \relative is applied to the same music two times
> in succession.
>
> Use #(music-clone note) or #(ly:music-deep-copy note) or $note for your
> two uses, and the note will get placed in two separate _copies_ of the
> original rather than using the note object itself in two places.

By the way: since \relative is applied before \keepWithTag, the result
will still likely suck when writing

\relative c'' { c d e \testy f, c }

since in first iteration it expands to

\relative c'' { c d e \tag #'a f, \tag #'b f, c }

namely

\absolute { c'' d'' e'' \tag #'a f' \tag #'b f c }

so the subsequent c is still likely to be one octave lower than
expected.

So you probably want

testy = #(define-music-function (note)
  (ly:music?)
  (make-relative (note) note
#{
  \tag #'a { $note }
  \tag #'b { $note }
#}))

This uses just "note" as the expression affecting \relative, but places
two separate copies of the once-affected note in your tags.

Expressed differently: the whole concept of \relative sucks.

-- 
David Kastrup

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


Re: make calc-blot from bar-line.scm public (issue 299250044 by thomasmorle...@gmail.com)

2016-06-13 Thread thomasmorley65

On 2016/06/05 17:39:35, dak wrote:

On 2016/06/05 17:27:15, thomasmorley651 wrote:



> On 2016/06/05 15:51:25, dak wrote:
> > https://codereview.appspot.com/299250044/diff/1/scm/bar-line.scm
> > File scm/bar-line.scm (right):
> >
> >

https://codereview.appspot.com/299250044/diff/1/scm/bar-line.scm#newcode30

> > scm/bar-line.scm:30: (define-public (calc-blot thickness extent

grob)

> > For a public function, the name is awful.



bar-line::calc-blot would likely already fit the bill.


Done.


> > Also I don't actually see how the "commit message" relates to

making

calc-blot
> > public:
> >
> > "To facilitate defining custom-bar-lines using

ly:round-filled-box"

> >
> > Huh?  You mean, instead of having to use ly:round-filled-box

directly?

> Because
> > ly:round-filled-box should already be available anyway.  Or

something else?

>
> Ok, the message _is_ awful.
> I wanted to express:
> If a user copies p.e. `make-simple-bar-line' in order to do some

minor

> modifications to fit his personal needs, he will not also need to

c/p

> `calc-blot`, although it is used to determine the blot which is

consumed by

the
> there used ly:round-filled-box-procedure.



Is it used only there?


calc-blot is used in
 make-simple-bar-line
 make-thick-bar-line
 make-tick-bar-line


Should its define just be moved inside of the function?
Then you formally would not "also need to c/p calc-blot" because it

would

already be copied from inside.


Now the new bar-line::draw-filled-box is defined public calling renamed
bar-line::calc-blot


At any rate: are the arguments for calc-blot such that it's only

conceivably

useful inside of bar-lines?  If not, a better name would be desirable.

 If so,

try fudging "bar-line" into its name.


Only useful inside of bar-lines as far as I can tell.

Commit message is now:

Issue 4883 Implement public definition of bar-line::draw-filled-box

bar-line::draw-filled-box calls the hereby renamed procedure
bar-line::calc-blot to determine the blot diameter.
It will be used in:
  make-simple-bar-line
  make-thick-bar-line
  make-tick-bar-line
This simplifies user-customized bar-lines, which are build with
ly:round-filled-box.
No need to copy/paste the blot-calculating procedure anymore.





https://codereview.appspot.com/299250044/

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


Protected_scm warning: returning reference to temporary

2016-06-13 Thread Dan Eble
I noticed these errors building staging in lilydev 3.0:

> /home/dan/lilypond-git/lily/protected-scm.cc: In member function 
> 'Protected_scm::operator scm_unused_struct* const&() const':
> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: warning: returning 
> reference to temporary [enabled by default]
> /home/dan/lilypond-git/lily/protected-scm.cc: In member function 
> 'Protected_scm& Protected_scm::operator=(const Protected_scm&)':
> /home/dan/lilypond-git/lily/protected-scm.cc:60:16: warning: '' 
> may be used uninitialized in this function [-Wuninitialized]
> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: note: '' was 
> declared here
> ./out/parser.cc: In function 'int yyparse(Lily_parser*, scm_unused_struct**)':
> ./out/parser.cc:2999:12: warning: conversion to 'yytype_int16 {aka short 
> int}' from 'int' may alter its value [-Wconversion]

— 
Dan


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


Re: Protected_scm warning: returning reference to temporary

2016-06-13 Thread David Kastrup
Dan Eble  writes:

> I noticed these errors building staging in lilydev 3.0:
>
>> /home/dan/lilypond-git/lily/protected-scm.cc: In member function
>> 'Protected_scm::operator scm_unused_struct* const&() const':
>> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: warning:
>> returning reference to temporary [enabled by default]

That sounds bad.  The way I read the C++11 standard (but it may not
apply to lilydev 3.0) this should work out, but there is no real reason
not to use an explicit if/then instead of ? : here in order not to rely
on it.

>> /home/dan/lilypond-git/lily/protected-scm.cc: In member function
>> 'Protected_scm& Protected_scm::operator=(const Protected_scm&)':
>> /home/dan/lilypond-git/lily/protected-scm.cc:60:16: warning:
>> '' may be used uninitialized in this function
>> [-Wuninitialized]
>> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: note:
>> '' was declared here

That's current staging/master?  It would likely be issue 4873 that
caused the change.  I don't remember seeing a similar message on my
computer (native Ubuntu environment rather than lilydev 3.0).

Anyway, I'll push a fix.  Can you check again in 5 minutes?

-- 
David Kastrup

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


Re: Scheme question

2016-06-13 Thread Simon Albrecht

On 13.06.2016 20:55, David Kastrup wrote:

So you probably want

testy = #(define-music-function (note)
   (ly:music?)
   (make-relative (note) note
#{
   \tag #'a { $note }
   \tag #'b { $note }
#}))

This uses just "note" as the expression affecting \relative, but places
two separate copies of the once-affected note in your tags.

Expressed differently: the whole concept of \relative sucks.


Expressed still another way: the concept of \relative, while convenient 
for music entry in most situations, may sometimes have complex 
implications, e.g. when used in music functions.


Best, Simon

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


Re: Protected_scm warning: returning reference to temporary

2016-06-13 Thread Dan Eble
On Jun 13, 2016, at 18:37 , David Kastrup  wrote:
> 
> Anyway, I'll push a fix.  Can you check again in 5 minutes?

No more warnings from protected-scm.

Thanks,
— 
Dan


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


Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

2016-06-13 Thread Werner LEMBERG

>> Remove `-dgs-load-fonts` from lilypond-book default.  During
>> LilyPond and its documents are built, `-dgs-load-lily-fonts` option
>> instead of `-dgs-load-fonts` is used.  `-dgs-load-lily-fonts` means
>> "Load only the LilyPond fonts via Ghostscript."
>>
>> "LilyPond fonts" mean the fonts in the LilyPond data directory.
>> i.e. Emmentaler, TeX Gyre Schola, TeX Gyre Heros, and TeX Gyre
>> Cursor, in default.
>>
>> For LilyPond document building, other font glyphs are embedded to
>> intermediate EPSs.  But most fonts in LilyPond documents are
>> Emmentaler and TeX Gyre.  So their glyphs are not embedded to the
>> EPSs.
>> 
>> How about this?

Mhmm.  As James writes, this can easily break.

I can imagine another approach.  Since lilypond itself converts all
fonts to PostScript resources, why not writing those resources to a
`fontresource' directory instead of embedding?  We could add a
checksum to the resource name, just to be sure that, say, `foo.tff'
and `foo.otf' will be rejected.

Ideally, all intermediate PDFs also refer to this `fontresource'
directory, and only in the last step PDFs with subsetted, embedded
fonts are created.


Werner

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