Re: funky build errors
> Here are my configuration settings for FontForge on a i586 GNU/Linux > box: [...] > > --enable-double IIRC, this option is the very one which makes the problems disappear. Hmm. Perhaps it's better to write to the various distribution packagers, urging them to compile FontForge with this option. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
>> While you are at it, please investigate why there are still >> clipping problems during the EPS->PNG conversion. For an example, >> look at the snappizzicato example image in the notation reference. > > The bounding box of the generated eps files is simply obtained from > the scencil extents plus the value of the 'eps-box-padding option on > each side. I know that. > Unfortunately, the skyline for the snappizzicato is wrong as a run of > lilypond -ddebug-skylines articulation-snappizzicato.ly > clearly shows. The vertical stroke is not counted towards the > skyline! Yes. You are probably misunderstanding me: There are *a lot * of glyphs where the skyline is incorrect -- for some, it's just the overshoot which isn't taken into account, for others it's more. In other words, the bbox as computed by lilypond currently is not suitable for clipping at all. Some time ago we have discussed this here on the list; a kind of concensus was to use FontForge for automatical computing of bbox values, adding them as additional metrics information. What I suggest is to let GhostScript completely unfold the font paths with eps2eps or something similar so that lilypond's bbox inaccuracy can be circumvented. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: funky build errors
> Hmm. I've seen these errors for a long time now (maybe a year and a > half), and I'm always using the latest fontforge tarball. > > Testing CVS, I get similar errors, first appearing with feta11: Interesting. I haven't seen them since a long time. Please report this to the FontForge list. Here are my configuration settings for FontForge on a i586 GNU/Linux box: ./configure --enable-debug-raw-points \ --enable-multilayer \ --enable-type3 \ --enable-devicetables \ --enable-pyextension \ --enable-double \ --with-freetype-bytecode \ CFLAGS="-g -O0" Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Carl Sorensen writes: > On 8/28/09 10:56 PM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux" >>> wrote: >>> According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) >>> >>> IIUC, '() is not a literal list, but a constant that represents the >>> empty list. >> >> It is a literal list in my opinion, but one that happens to have no >> unique and/or modifiable conses. Append will work just fine on it. > > It is *not* a literal list. > > Here is the proof: > > guile> (define a '(4 5)) > guile> (define b '(4 5)) > guile> (eq? a b) > #f > guile> (define c '()) > guile> (define d '()) > guile> (eq? c d) > #t > > > '(4 5) is a literal list, and thus a is not eq? to b, although it is equal? > to b Huh? What kind of argument is that supposed to be? (define a 4) (define b 4) (eq? a b) Would you claim that 4 is not a literal integer? '() is literal (namely explicitly specified) and it is a list (namely a cons or nil). '() is not a literal _cons_, and it is not unique. But it certainly is literal (a spelled out value) and a list. > On the other hand, c is eq? to d, because '() is a constant, and both c and > d are set to the same constant. I think you are just confused about the meaning of "literal". -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix base attachments for slurs at linebreaks
On Sun, Aug 23, 2009 at 10:23 AM, wrote:
>
> http://codereview.appspot.com/109071/diff/39/46
> File lily/phrasing-slur-engraver.cc (right):
>
> http://codereview.appspot.com/109071/diff/39/46#newcode147
> Line 147: if (!g->internal_has_interface (ly_symbol2scm
> ("span-bar-interface")))
> this will work in some cases, but is specific to the ordering of the
> prefatory material and the existence of the barline. It would better to
> catch an object that has references to all of the breakable items.
>
> http://codereview.appspot.com/109071/diff/39/48
> File lily/slur-scoring.cc (right):
>
> http://codereview.appspot.com/109071/diff/39/48#newcode411
> Line 411: }
> fold this code - left and right are symmetric.
>
> http://codereview.appspot.com/109071/diff/39/48#newcode577
> Line 577: x = (d == LEFT) ? (x + 0.25) : (x - 0.25);
> dont use conditional
>
> x += -d * 0.25;
>
> http://codereview.appspot.com/109071/diff/39/49
> File lily/slur.cc (right):
>
> http://codereview.appspot.com/109071/diff/39/49#newcode197
> Line 197: - Is there a better way to accomplish this?
> I think you should first make a test case that contains all combinations
> of key, slur, clef, barline etc. at linebreaks, and go from there -
> hardcoding bar lines here seems too limited
Thanks for your review, Han-Wen.
I need to rethink my whole strategy for fixing the slur endpoints.
It seems that I should not be searching through "encompass-objects",
since these objects are just used to determine the middle two control
points. I also don't need to acknowledge bar-line-interface, since
this only has an effect when 'avoid-slur is set, but 'avoid-slur is
not set for BarLine.
I'm thinking of adding a new grob object, "boundary-objects", to use
instead; this would contain all breakable objects we want to avoid at
line breaks. I could then traverse this set of objects to find the
correct x-coordinates for slur endpoints.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Creating books with Scheme
On 8/29/09 7:01 PM, "Reinhold Kainhofer" wrote: > > You mean something like this patch: >http://codereview.appspot.com/112044 LGTM. Just a question. In your regression test, you first define (add-one-score #f), then you set! it to a lambda function. Is that solely so that you can have pitch defined in the lexical scope but outside of add-one-score? Or is there more going on that I haven't figured out? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: Creating books with Scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 29. August 2009 18:09:48 schrieb Nicolas Sceaux: > After playing for a while with handlers, it seems that properly mixing > programmaticaly-generated scores and explicit scores requires some > tweaks in the parser. The hacks exposed earlier cannot deal with all > various cases. > > Proposition: > At the beginning of a \book (or \bookpart) block, the parser sets a > eg. $book (or $bookpart) parser variable, and unset it at the end of the > block. You mean something like this patch: http://codereview.appspot.com/112044 Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmc9NTqjEwhXvPN0RAqHPAKDacgvaVPWED8UYWaBETUbaVOqHxgCgk5RC X4jx5TLljIHrrO0IjRDaQMU= =bfot -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Parser variables, properties and contexts, rooky developer question.
Hi all,
I've been grubbing around, grepping my git repository and I need a bit
of steering from some of you who've been around the lilypond source
longer than me.
I'm trying to design a solution to the original request for tracker 714,
which asked to be able to specify an alternate output filename from the
code. I don't think this is completely feasible but feel we should be
able to support changing the output suffix for midi files, which are
produced on a per \score block basis, so I would need to be able to
define a property to do this for \score which would pick the value of
the output-suffix parser variable as a default and would allow it to be
user-settable for the scope of the \score. For example:
% In file VW.ly
#(define output-suffix "Five-songs")
\book {
...
\bookpart
{
...
\score \with {midi-output-suffix="Dark-Eyed-Sailor"}
{
\midi{}
\layout{}
music...
}
%above produces midi file VW-Dark-Eyed-Sailor.mid(i)
% pdf output is going to VW-Two-Songs.pdf
\bookpart {
...
\score \with {midi-output-suffix="Lovely-On-The-Water"}
{
\midi{}
\layout{}
music...
}
%above produces midi file VW-Lovely-On-The-Water.mid(i)
% pdf output is still going to VW-Two-Songs.pdf
}
The parser variable is currently scoped for each source file unit or
\book block.
The \bookpart block would need to pick up the value of output-suffix as
defined for the current \book block and store it as an internal
property. Each \score block could then pick up the \bookpart
outpt-suffix setting and copy it to its own midi-output-suffix property
which would be settable via the user interface.
So finally, here's my questions:
whereabouts in the code would I declare the new midi-output-suffix
property?
would the code to get \bookpart to inherit the output-suffix parser
variable value and \score to inherit the \bookpart value be C++ or
Scheme, and in which bits of code?
Thanks for any ideas/help in advance,
Cheers,
Ian Hulin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use our own ~s ly:format placeholder, since guile is broken with wide chars
Am Samstag, 22. August 2009 02:07:05 schrieb Reinhold Kainhofer: > Am Samstag, 22. August 2009 00:59:33 schrieb joenee...@gmail.com: > > http://codereview.appspot.com/109070/diff/1/2 > > File lily/general-scheme.cc (right): > > > > http://codereview.appspot.com/109070/diff/1/2#newcode437 > > Line 437: replace_all (&s, "\"", "\\\""); > > Don't forget to escape $. Or else use single quotes rather than double > > quotes. > > Good catch. I'm now also escaping $. Using single quotes does not work with > gs. gs requires the files to be wrapped in double quotes. > > New patch uploaded: > http://codereview.appspot.com/109070 This is now also pushed to master (with the additional escaping of % for Windows systems). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement framework for post-fix text (de)cresc spanners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 23. August 2009 19:57:26 schrieb Reinhold Kainhofer: > So,for now I would simply apply that patch so that the properties get > interpreted, but don't add a new command, which will be changed in the > next version again. Anyone who whats to use them (basically, that's me > for now),can always write our own mycresc or even overload the existing > cresc command as postfix. I have now included all your comments and pushed that patch, so that lilypond now interprets the span-* properties of (de-)crescendo music events. If you want, you can now overload \cresc, \decresc and \dim to produce text crescendo spanners in postfix notation, but their default implementation still uses prefix notation. Once, we start planning the exact syntax for 2.14, we should bring up this topic again and design a good upgrade path from prefix- to postfix-crescendi. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmYGvTqjEwhXvPN0RAugRAKCwgjOXaChr6Rt5fctPUacPjwZHkgCgnXC0 2m1v9pALdlOC7PSHxTYo3PE= =9D84 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
On 8/28/09 10:56 PM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux" >> wrote: >> >>> >>> According to R5RS, it is an error to modify a literal list. >>> If a function returns '(), the caller won't be allowed to >>> apply a modifying function on the result (eg. append!) >>> >> >> IIUC, '() is not a literal list, but a constant that represents the >> empty list. > > It is a literal list in my opinion, but one that happens to have no > unique and/or modifiable conses. Append will work just fine on it. It is *not* a literal list. Here is the proof: guile> (define a '(4 5)) guile> (define b '(4 5)) guile> (eq? a b) #f guile> (define c '()) guile> (define d '()) guile> (eq? c d) #t '(4 5) is a literal list, and thus a is not eq? to b, although it is equal? to b On the other hand, c is eq? to d, because '() is a constant, and both c and d are set to the same constant. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH for getting output-suffix to work (Trackers 714 and 404)
Besten Dank, Reinhold, Patch is now available for review on rietveld http://codereview.appspot.com/110111 Cheers, Ian Hulin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creating books with Scheme
Le 29 août 09 à 14:28, Reinhold Kainhofer a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 17. August 2009 12:05:23 schrieb Nicolas Sceaux: Le 17 août 09 à 09:23, Nicolas Sceaux a écrit : If you look at the definition of `bookpart-score-handler' in my file, you see that the book-part argument is not used. Instead, all scores are added to the toplevel-scores parser variable (even though they are not really toplevel, it does not matter). The `toplevel-bookpart-handler' then uses this variable to actually add the scores to the bookpart. This function is called by the parser when a \bookpart block is closed, so at this point the bookpart object is known. You can change the book-score-handler and toplevel-book-handler to act the same way. Here is a short example showing how that may be done. Thanks a lot, but I just realized that if you use several bookparts, the \header section of the bookparts get ignored. Also, you cannot mix explicitly written scores with computer-generated scores... After playing for a while with handlers, it seems that properly mixing programmaticaly-generated scores and explicit scores requires some tweaks in the parser. The hacks exposed earlier cannot deal with all various cases. Proposition: At the beginning of a \book (or \bookpart) block, the parser sets a eg. $book (or $bookpart) parser variable, and unset it at the end of the block. Then, scores can be programmatically added this way: (define (add-score parser score) (cond ((ly:parser-lookup parser '$bookpart) (bookpart-score-handler (ly:parser-lookup parser '$bookpart) score)) ((ly:parser-lookup parser '$book) (book-score-handler (ly:parser-lookup parser '$book) score)) (else (toplevel-score-handler parser score Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 29. August 2009 13:10:20 schrieb Reinhold Kainhofer: > Am Samstag, 29. August 2009 06:37:40 schrieb Werner LEMBERG: > > While you are at it, please investigate why there are > > still clipping problems during the EPS->PNG conversion. For an > > example, look at the snappizzicato example image in the notation > > reference. > > The bounding box of the generated eps files is simply obtained from the > scencil extents plus the value of the 'eps-box-padding option on each side. > > Unfortunately, the skyline for the snappizzicato is wrong as a run of > lilypond -ddebug-skylines articulation-snappizzicato.ly > clearly shows. The vertical stroke is not counted towards the skyline! Fix in master. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmU5GTqjEwhXvPN0RAomvAKCVoSR/EOm+A+mbNfvKpwI8e7JXxgCgt96z SB5DcGcb00UK35BKf7/Uyv4= =+mgk -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH for getting output-suffix to work (Trackers 714 and 404)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 29. August 2009 15:06:44 schrieb Ian Hulin: > Apologies for not putting this one on rietveld, but I couldn't get the > Create Issue form to accept the patch or work out what the exact set of > options and parameters was for the upload.py python script. Use the git-cl script (http://neugierig.org/software/git/?url=git-cl/): git checkout git://neugierig.org/git-cl.git Then you you use the git-cl script: git-cl upload origin/master (this will upload the diffs between your current status and the origin/master revision; If you work in a different branch, you need to give a different point to compare, obviously). Git-cl will also remember the issue for each branch, so a second upload will not create a new issue, but update the old one. Of course, for this, you need to use a separate git branch per patch. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmS1xTqjEwhXvPN0RAm02AJ9Inmieqz7eVAXDJjNF3pG6/EEx6ACfTk7D azmpoqV6JyCzr0ITEYjVR7w= =2aRv -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH for getting output-suffix to work (Trackers 714 and 404)
Apologies for not putting this one on rietveld, but I couldn't get the Create Issue form to accept the patch or work out what the exact set of options and parameters was for the upload.py python script. So I've fallen back to sending it to the list direct. If it looks OK, could someone please push it to the main git repo? Cheers, Ian >From 87504a757a98b6a5ff64c8dd67bc2f114de6acfb Mon Sep 17 00:00:00 2001 From: Ian Hulin Date: Fri, 21 Aug 2009 16:35:40 +0100 Subject: [PATCH] Issues 714 and 404: Add greater user flexibility in naming output files using output-suffix. output name handling now moved to its own procedure in lily-library.scm Amended to use ly:get-assoc to pick up initial value of parser variable output-count and remove redundant check on initial call. Accented characters now supported in output-suffix. --- scm/lily-library.scm | 36 ++-- 1 files changed, 22 insertions(+), 14 deletions(-) diff --git a/scm/lily-library.scm b/scm/lily-library.scm index e7f1d29..1b10b5b 100644 --- a/scm/lily-library.scm +++ b/scm/lily-library.scm @@ -134,27 +134,35 @@ (ly:make-score music)) + +(define (get-outfile-name parser base) +(let* +((output-suffix (ly:parser-lookup parser 'output-suffix)) + (counter-alist (ly:parser-lookup parser 'counter-alist)) + (output-count (assoc-get output-suffix counter-alist 0)) + (result base )) +;; Allow all ASCII alphanumerics, including accents +(if (string? output-suffix) +(set! result (format "~a-~a" base (string-regexp-substitute +"[^-[:alnum:]]" "_" output-suffix + +;; assoc-get call will always have returned a number +(if (> output-count 0) (set! result (format #f "~a-~a" result output-count))) + +(ly:parser-define! +parser 'counter-alist +(assoc-set! counter-alist output-suffix (1+ output-count))) +result)) + (define (print-book-with parser book process-procedure) (let* ((paper (ly:parser-lookup parser '$defaultpaper)) (layout (ly:parser-lookup parser '$defaultlayout)) (count (ly:parser-lookup parser 'output-count)) (base (ly:parser-output-name parser)) - (output-suffix (ly:parser-lookup parser 'output-suffix)) ) + (outfile-name (get-outfile-name parser base))) -(if (string? output-suffix) - (set! base (format "~a-~a" base (string-regexp-substitute - "[^a-zA-Z0-9-]" "_" output-suffix - -;; must be careful: output-count is under user control. -(if (not (integer? count)) - (set! count 0)) - -(if (> count 0) - (set! base (format #f "~a-~a" base count))) -(ly:parser-define! parser 'output-count (1+ count)) -(process-procedure book paper layout base) -)) + (process-procedure book paper layout outfile-name))) (define-public (print-book-with-defaults parser book) (print-book-with parser book ly:book-process)) -- 1.6.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creating books with Scheme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 17. August 2009 12:05:23 schrieb Nicolas Sceaux:
> Le 17 août 09 à 09:23, Nicolas Sceaux a écrit :
> > If you look at the definition of `bookpart-score-handler' in my
> > file, you see that the book-part argument is not used. Instead,
> > all scores are added to the toplevel-scores parser variable (even
> > though they are not really toplevel, it does not matter).
> > The `toplevel-bookpart-handler' then uses this variable to actually
> > add the scores to the bookpart. This function is called by the parser
> > when a \bookpart block is closed, so at this point the bookpart object
> > is known.
> >
> > You can change the book-score-handler and toplevel-book-handler to
> > act the same way.
>
> Here is a short example showing how that may be done.
Thanks a lot, but I just realized that if you use several bookparts, the
\header section of the bookparts get ignored. Also, you cannot mix explicitly
written scores with computer-generated scores...
Attached is a modified sample file:
- -) if you have explicitly written \score{..}s and computer-created ones, the
explicitly written ones will start a new book part, even if all are inside the
same \bookpart.
- -) Only the first bookpart uses the global \header for piece names
- -) The scheme-generated scores in the second and further bookparts will
ignore
all header settings!
- -) The explicitly written scores in the second bookpart will also ignore all
global header settings?!?
Do you have any idea, how I can (i) assign the correct header blocks to the
generated scores (ie. proper hierarchy: score-level header, bookpart-level
header, book-level header and finally global header block in this order) and
(ii) how I can treat generated and explicitly written scores really equal.
Thanks a lot,
Reinhold
PS: It works correctly, if I use different \book blocks instead of \bookpart
blocks, but that's not what I want.
- --
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKmR8DTqjEwhXvPN0RAoeIAJ9MLa5q7ZDVyDHr5fdOloZYnLmYkQCdGit/
MTy2oK8nz89pwbUlGgZXqoc=
=CyVk
-END PGP SIGNATURE-
\version "2.13.4"
#(define-public (add-score parser score)
(ly:parser-define! parser 'toplevel-scores
(cons score (ly:parser-lookup parser 'toplevel-scores
#(define-public (add-text parser text)
(add-score parser (list text)))
#(define-public (add-music parser music)
(collect-music-aux (lambda (score)
(add-score parser score))
parser
music))
#(define-public (toplevel-book-handler parser book)
(map (lambda (score)
(ly:book-add-score! book score))
(reverse! (ly:parser-lookup parser 'toplevel-scores)))
(ly:parser-define! parser 'toplevel-scores (list))
(print-book-with-defaults parser book))
#(define-public (book-score-handler book score)
(add-score parser score))
#(define-public (book-text-handler book text)
(add-text parser text))
#(define-public (book-music-handler parser book music)
(add-music parser music))
%%%
#(define add-one-note-score #f)
#(let ((pitch 0))
(set! add-one-note-score
(lambda (parser)
(let* ((music (make-music 'EventChord
'elements (list (make-music 'NoteEvent
'duration (ly:make-duration 2 0 1 1)
'pitch (ly:make-pitch 0 pitch 0)
(score (scorify-music music parser))
(layout (ly:output-def-clone $defaultlayout))
(note-name (case pitch
((0) "do")
((1) "ré")
((2) "mi")
((3) "fa")
((4) "sol")
((5) "la")
((6) "si")
(else "huh")))
(title (markup #:large #:line ("Score with a" note-name
(ly:score-add-output-def! score layout)
(add-text parser title)
(add-score parser score))
(set! pitch (modulo (1+ pitch) 7)
oneNoteScore =
#(define-music-function (parser location) ()
(add-one-note-score parser)
(make-music 'Music 'void #t))
%%%
\header {
title = "Main Title"
subtitle = "Main subtitle"
piece = "Piecetitle"
}
\oneNoteScore
\bookpart {
\header { title ="Title 1" subtitle="Sub1"}
\oneNoteScore
\oneNoteScore
\oneNoteScore
\score { \relative c' c1 }
}
\bookpart {
\score { \relative c' c1 }
\oneNoteScore
\oneNoteScore
\oneNoteScore
}
\bookpa
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 29. August 2009 06:37:40 schrieb Werner LEMBERG: > While you are at it, please investigate why there are > still clipping problems during the EPS->PNG conversion. For an > example, look at the snappizzicato example image in the notation > reference. The bounding box of the generated eps files is simply obtained from the scencil extents plus the value of the 'eps-box-padding option on each side. Unfortunately, the skyline for the snappizzicato is wrong as a run of lilypond -ddebug-skylines articulation-snappizzicato.ly clearly shows. The vertical stroke is not counted towards the skyline! This might also cause problems with collisions and staff spacing, since the vertical stroke is completely ignored. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmQydTqjEwhXvPN0RAvZDAJoDpihSZ9iHADcZnHwLy7LfVoiOkACgwoyx w3OWrIOXIkVZb8dtOLrE+0g= =TFsD -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 29. August 2009 03:44:04 schrieb Reinhold Kainhofer: > Here is a patch that introduces a command line option aux-files, which can > be used (-daux-files=#f, -dno-aux-files or #(ly:set-option 'no-aux-files)) > to prevent lilypond's eps backend from creating .tex(i) and .count files: [..] > I'm still looking into not creating -1.eps files for examples with only one > system (in that case, the .eps and the -1.eps files will be identical, > anyway!). I have now also included the feature to not create the *-1.eps files if there is only one system (and the .eps file would be identical to the -1.eps file) and the aux-files option is set to #f. http://codereview.appspot.com/110107 In the default case, there should be no difference to the current behavior, though (or shall we adjust the default case to create those aux files only if explicitly requested?) Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKmQfTTqjEwhXvPN0RAhs1AJ9LoK4kkmcQUK+kzji8daxMlqlo8QCglfRW ONkNOwi0RHSSGlD1hRX20YY= =ay1x -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Le 29 août 09 à 06:56, David Kastrup a écrit : Carl Sorensen writes: On Aug 28, 2009, at 1:16 PM, "Nicolas Sceaux" wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. It is not rhetorical since a modified literal list will actually stay modified when you call the function the next time. Can't happen with '() though. You're right on both points! thanks. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with info documentation images?
Graham Percival writes: > Let me be clear. > - are the info docs not finished? yes. > - are the pdf, html, etc. not finished? yes. > - did I completely underestimate the pain in doing ANYTHING with > the lilypond build process? yes. > - would I have completely changed almost everybody about the past > summer if I had realized how much trouble it was to change the > build system? sweet mao yes. > > That said, the info docs are a fairly minor concern at the moment, > given the mess that the rest of the system is. Defending the status quo would appear to be a waste of time, then. Regardless of the state of messiness, however, I repeat my contention that the principal project web page is not suitable as top level documentation anchor for a specific version. The current document named "lilypond.info" is the wrong choice, even after fixing all brokenness. I don't think that an info version of this, the project web page, would serve a useful purpose, so I think it sensible to completely forget about "improving" its info aspect (or even its "standalone HTML documentation" aspect). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: funky build errors
On 2009-08-28, Werner LEMBERG wrote: > > I assume that "needed" and "unneeded" aren't actually > > contradictions... or maybe they are, and that's why the internal > > error is printed. > > They are contradictions, thus the internal error. It's a rounding > issue in FontForge. > > > Executable based on sources from 00:29 GMT 29-Apr-2008. > > Library based on sources from 20:49 GMT 30-Apr-2008. > > This is ooold. I've compiled the current CVS of FontForge by myself, > and I don't see this (and I haven't seen such errors since almost a > year). George has fixed a bunch of such problems later in 2008, IIRC. > > Please update FontForge. Hmm. I've seen these errors for a long time now (maybe a year and a half), and I'm always using the latest fontforge tarball. Testing CVS, I get similar errors, first appearing with feta11: Invoking "fontforge -script feta11.pe feta11.pfb"... Copyright (c) 2000-2009 by George Williams. Executable based on sources from 01:59 GMT 17-Aug-2009. Library based on sources from 05:09 GMT 14-Aug-2009. Internal Error in accidentals.flat.arrowdown: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowdown: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowdown: Expected needed monotonic. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files
Werner LEMBERG wrote: Nice idea. While you are at it, please investigate why there are still clipping problems during the EPS->PNG conversion. [...] As a possible solution, I can imagine that we add an intermediate step to convert the fonts in an EPS file into PS paths, for example, by using the `epswrite' device (as demonstrated in the `eps2eps' script which comes with ghostscript). This should assure that the bboxes are exact. Hi, some time ago I tried to handle this problem with a little script. (Makefile attached.) However, I only dealt with PDF->PDF fixing. In short: I couldn't quite manage to get good results with a GhostScript-only version, other than tweaking the BoundingBox entries in an intermediate EPS file for myself, using the GS -sDEVICE=bbox output. Everything I tried with nothing but GS scripts either did not give the bboxes as exact as I wanted them, or actually rasterized the file. Thus I decided to use pdftops from the libpoppler utilities. Which may be a problem for Windows, but perhaps it's not needed for EPS->x conversion. Perhaps it will be useful as a template or give some ideas, but it certainly is not thoroughly tested. I have no idea what happens for multipage input files, by the way, but this problem won't come up for EPS->EPS conversion, I guess. HTH, Alexander BASENAME=frieden RESOLUTION=600 GS=gs -q -dNOPAUSE -dBATCH .PHONY: all clean all:$(BASENAME).pdf \ $(BASENAME)-trimmed.pdf \ $(BASENAME)-trimmed.png \ $(BASENAME)-trimmed-no-bg.png %-trimmed.pdf: %.pdf # $(GS) -sDEVICE=pswrite -sOutputFile=$*-fixed.ps $<; # $(GS) -sDEVICE=epswrite -sOutputFile=$*-fixed.eps $*-fixed.ps; # head -n 1 $*-fixed.eps > $*-trimmed.eps; # echo `$(GS) -sDEVICE=bbox $*-fixed.eps 2>&1` > $*.bbox; # sed -e 's/ %%HiResBoundingBox/\n%%HiResBoundingBox/' < $*.bbox >> $*-trimmed.eps; # tail -n +4 $*-fixed.eps >> $*-trimmed.eps; # epstopdf --hires $*-trimmed.eps; # rm $*-fixed.ps $*-fixed.eps $*.bbox; cp -f $< $@; pdftops $@; rm -f $*-trimmed.eps; ps2eps -l $*-trimmed.ps; epstopdf $*-trimmed.eps; rm -f $*-trimmed.ps; %.pdf: %.ly lilypond $<; #%-trimmed.png: %.png # convert -trim $< +repage $@; %-trimmed.png: %-trimmed.pdf convert -density $(RESOLUTION)x$(RESOLUTION) -units PixelsPerInch -colorspace Gray -depth 8 $< $@; %-trimmed-no-bg.png:%-trimmed.png convert -channel R $< -channel A -size 1x256 gradient:black-none -clut $@; %.png: %.ly lilypond -dresolution=$(RESOLUTION) --png $<; clean: $(BASENAME).clean %.clean: rm -f $*-fixed.ps $*-fixed.eps $*.bbox; rm -f $*.ps $*.pdf $*.png $*-trimmed.eps $*-trimmed.pdf $*-trimmed.png $*-trimmed-no-bg.png $*.midi; ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
