Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)
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)
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
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
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
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
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)
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
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
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
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
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)
>> 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