Re: svg font issue(bug?): can't change TimeSignature font (but markup fonts can be changed)
On Apr 28, 2015, at 13:37 , padovani wrote: > > Hi, > > But the code below one gives me an error if I compile with -dbackend=svg [snip] > (I'm using 2.19.19 on OSX 10.9.5.) > PDF output doesn’t even work for me on OSX 10.10.3: GNU LilyPond 2.19.19 Processing `time-signature-font.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `time-signature-font.ps'... warning: `(fondu -force /System/Library/Fonts/Helvetica.dfont)' failed (5) fatal error: failed files: "time-signature-font.ly” — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Just some short feedback
Paul Morris writes:
>> On Apr 27, 2015, at 6:20 PM, Trevor Daniels wrote:
>>
>> I'd like to second everything that Carl writes below,
>> and add my thanks to you, David.
>
> Let me add my +1 as well. Thank you David for all your good work and
> for the update. Here’s to more maintainable code and first-class
> scheme engravers!
Well, currently I am just going through the "more maintainable code"
phase. Reorganizing the Listener stuff (and leaving a lot related
material alone for now) shows the statistics
dak@lola:/usr/local/tmp/lilypond$ git diff -w --stat origin issue4357
lily/context.cc | 20 ++--
lily/dispatcher-scheme.cc | 13 ++-
lily/dispatcher.cc | 26 +++--
lily/engraver-group.cc | 10 +-
lily/global-context.cc | 5 +-
lily/grace-engraver.cc | 7 +-
lily/include/context.hh | 12 +--
lily/include/dispatcher.hh | 5 +-
lily/include/engraver-group.hh | 4 +-
lily/include/global-context.hh | 2 +-
lily/include/listener.hh| 158 ---
lily/include/scheme-listener.hh | 41
lily/include/score-engraver.hh | 6 +-
lily/include/score-performer.hh | 6 +-
lily/include/smobs.hh | 19 +++-
lily/include/translator-group.hh| 2 +-
lily/include/translator.hh | 2 +-
lily/include/translator.icc | 3 +-
lily/listener.cc| 41
lily/lyric-combine-music-iterator.cc| 12 +--
lily/midi-control-function-performer.cc | 8 +-
lily/part-combine-iterator.cc | 7 +-
lily/scheme-engraver.cc | 33 +--
lily/scheme-listener-scheme.cc | 34 ---
lily/scheme-listener.cc | 54 ---
lily/score-engraver.cc | 15 ++-
lily/score-performer.cc | 15 ++-
lily/smobs.cc | 7 ++
lily/translator-group.cc| 5 +-
scm/part-combiner.scm | 14 ++-
scm/scheme-engravers.scm| 6 ++
31 files changed, 222 insertions(+), 370 deletions(-)
And I might add that the number of comment lines has probably increased
significantly. Of the macros GET_LISTENER, DECLARE_LISTENER,
IMPLEMENT_LISTENER only GET_LISTENER remains and it's straightforward to
use (and a one-liner).
All of the following ad_hoc macro stuff is just gone. And there is no
mucking about with void * anymore: the stuff is type-safe.
-#define IMPLEMENT_LISTENER(cl, method) \
-void\
-cl :: method ## _callback (void *self, SCM ev) \
-{ \
- cl *s = (cl *)self; \
- s->method (ev); \
-} \
-void\
-cl :: method ## _mark (void *self) \
-{ \
- cl *s = (cl *)self; \
- scm_gc_mark (s->self_scm ()); \
-} \
-bool\
-cl :: method ## _is_equal (void *a, void *b)\
-{ \
- return a == b;\
-} \
-Listener\
-cl :: method ## _listener () const \
-{ \
- static Listener_function_table callbacks; \
- callbacks.listen_callback = &cl::method ## _callback; \
- callbacks.mark_callback = &cl::method ## _mark; \
- callbacks.equal_callback = &cl::method ## _is_equal; \
- return Listener (this, &callbacks); \
A Listener was created from some this-pointer cast to void* and a
pointer to a Listener_callback table. Set up fresh every time.
Now a listener is created from a function taking two Scheme arguments,
the first being a function with two arguments, and the second being the
first argument to use for calling this function. And the resulting
Listener is employed as a Scheme function with a single argument.
There is a comment
+// A listener is essentially any procedure accepting a single argument
+// (namely an event). The class Listener (or rather a smobbed_copy of
+// it) behaves like such a procedure and is composed of a generic
+// callback function accepting two arguments, namely a "target"
+// (usually an engraver instance) and the event. Its Scheme
+// equivalent would be
+//
+// (define (make-listener callback tar
Re: I'm back.
Hi Janek, > On Apr 27, 2015, at 4:46 PM, Janek Warchoł wrote: > > I'd like to "officially announce" that I'm active again. I will > probably start by focusing on Contributor's Guide, trying to make it > easier for new people to get involved with the project. I already > have a few ideas regarding LilyDev. Welcome back! I have some notes I’ve made in recent months while working my way through the Contributor’s Guide as a relative newbie. I’ll post them in another thread when I get a chance… -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Just some short feedback
> On Apr 27, 2015, at 6:20 PM, Trevor Daniels wrote: > > I'd like to second everything that Carl writes below, > and add my thanks to you, David. Let me add my +1 as well. Thank you David for all your good work and for the update. Here’s to more maintainable code and first-class scheme engravers! -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
svg font issue(bug?): can't change TimeSignature font (but markup fonts can be changed)
Hi,
This code compiles on .ps /.svg backends without problems:
%code 1
\score {
\new Staff {
\time 2/4
c2_\markup {
\override #'(font-name . "Helvetica")
"here it works"
}
}
}
%end code 1
But the code below one gives me an error if I compile with -dbackend=svg
%code2
\score {
\new Staff {
\override Staff.TimeSignature.font-name = #'"Helvetica"
\time 2/4
c2_\markup {
\override #'(font-name . "Helvetica")
"here it works"
}
}
}
% end code 2
here is the error:
%%error begin
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `teste.svg'...
warning: cannot find SVG font #f
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:558:7:
In procedure string-null? in expression (string-null? expr):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:558:7:
Wrong type argument in position 1 (expecting string): #
%%error end
(I'm using 2.19.19 on OSX 10.9.5.)
Is this a bug? It seems that something need to be changes in
output-svg.scm... any idea?
Thank you!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
Am 28.04.2015 um 16:31 schrieb David Kastrup: pkx1...@gmail.com writes: author Masamichi Hosoda Tue, 28 Apr 2015 13:29:52 + (14:29 +0100) committer James Lowe Tue, 28 Apr 2015 14:02:06 + (15:02 +0100) commit 8dd74d9902782edbd3a1f0dddcaeca29759b7be1 https://codereview.appspot.com/232850043/ Well, I have just given Masamichi-san push access so that he could take care of this himself, but it would appear that he'll have to wait for the next patch now... Now if that isn't an incentive ... ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
pkx1...@gmail.com writes: > authorMasamichi Hosoda > Tue, 28 Apr 2015 13:29:52 + (14:29 +0100) > committer James Lowe > Tue, 28 Apr 2015 14:02:06 + (15:02 +0100) > commit8dd74d9902782edbd3a1f0dddcaeca29759b7be1 > > https://codereview.appspot.com/232850043/ Well, I have just given Masamichi-san push access so that he could take care of this himself, but it would appear that he'll have to wait for the next patch now... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
author Masamichi Hosoda Tue, 28 Apr 2015 13:29:52 + (14:29 +0100) committer James Lowe Tue, 28 Apr 2015 14:02:06 + (15:02 +0100) commit 8dd74d9902782edbd3a1f0dddcaeca29759b7be1 https://codereview.appspot.com/232850043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
I will push this, but if you want to get push access you can apply for it, see here: http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#commit-access James On 28/04/15 12:32, Masamichi HOSODA wrote: Patch counted down - please push https://codereview.appspot.com/232850043/ I don't have git account. I've attached the patch file to this mail. Would you push it? ___ 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
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
Am 28.04.2015 um 13:38 schrieb Werner LEMBERG: Patch counted down - please push https://codereview.appspot.com/232850043/ I don't have git account. David, please change that :-) Werner IIRC one has to go to the Savannah page and request to be included in the project. This request will then be passed to *someone* who should then accept it. HTH Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
>> Patch counted down - please push >> >> https://codereview.appspot.com/232850043/ > > I don't have git account. David, please change that :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename makefile variable TMP (issue 232850043 by truer...@gmail.com)
> Patch counted down - please push
>
> https://codereview.appspot.com/232850043/
I don't have git account.
I've attached the patch file to this mail.
Would you push it?
>From aab1bada37a741025f0710842702da3eed0cf027 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda
Date: Tue, 14 Apr 2015 23:36:35 +0900
Subject: [PATCH] Rename makefile variable TMP
Windows (cygwin and mingw) system uses
environment variable TMP for a special purpose.
It can not be used for other purpose like makefile variable.
---
input/regression/abc2ly/GNUmakefile | 4 ++--
input/regression/midi/GNUmakefile | 4 ++--
stepmake/stepmake/metafont-rules.make | 8
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/input/regression/abc2ly/GNUmakefile b/input/regression/abc2ly/GNUmakefile
index 7356f99..438deba 100644
--- a/input/regression/abc2ly/GNUmakefile
+++ b/input/regression/abc2ly/GNUmakefile
@@ -5,8 +5,8 @@ LOCALSTEPMAKE_TEMPLATES=lilypond ly lysdoc abc
TEXI2HTML_FLAGS += --nomenu
-TMP = $(sort $(ABC_FILES) $(TEXINFO_SOURCES) )
-COLLATED_FILES = ${TMP:%.abc=$(outdir)/%.ly}
+TMP_FILES = $(sort $(ABC_FILES) $(TEXINFO_SOURCES) )
+COLLATED_FILES = ${TMP_FILES:%.abc=$(outdir)/%.ly}
include $(depth)/make/stepmake.make
diff --git a/input/regression/midi/GNUmakefile b/input/regression/midi/GNUmakefile
index 682bf82..d6be6f6 100644
--- a/input/regression/midi/GNUmakefile
+++ b/input/regression/midi/GNUmakefile
@@ -5,8 +5,8 @@ LOCALSTEPMAKE_TEMPLATES=lilypond ly lysdoc midi
TEXI2HTML_FLAGS += --nomenu
-TMP = $(sort $(LY_FILES) $(TEXINFO_SOURCES) )
-COLLATED_FILES = ${TMP:%.ly=$(outdir)/%-midi.ly}
+TMP_FILES = $(sort $(LY_FILES) $(TEXINFO_SOURCES) )
+COLLATED_FILES = ${TMP_FILES:%.ly=$(outdir)/%-midi.ly}
include $(depth)/make/stepmake.make
diff --git a/stepmake/stepmake/metafont-rules.make b/stepmake/stepmake/metafont-rules.make
index 1db7974..45ff320 100644
--- a/stepmake/stepmake/metafont-rules.make
+++ b/stepmake/stepmake/metafont-rules.make
@@ -19,15 +19,15 @@ $(outdir)/%.tfm $(outdir)/%.log: %.mf
# the soft link for mf2pt1.mp is for recent mpost versions
# which no longer dump a .mem file
$(outdir)/%.pfb: %.mf $(outdir)/mf2pt1.mem $(outdir)/%.log
- $(DO_MF_DEP) TMP=`mktemp -d $(outdir)/pfbtemp.$*.X` \
- && ( cd $$TMP \
+ $(DO_MF_DEP) TMP_DIR=`mktemp -d $(outdir)/pfbtemp.$*.X` \
+ && ( cd $$TMP_DIR \
&& ln -s ../mf2pt1.mem . \
&& ln -s ../../mf2pt1.mp . \
&& MFINPUTS=$(abs-src-dir):..:: \
FONTFORGE=$(FONTFORGE) \
$(buildscript-dir)/mf2pt1 $(MF2PT1_OPTIONS) $< $(METAFONT_QUIET)) \
- && mv $$TMP/*pfb $(outdir); \
- rm -rf $$TMP
+ && mv $$TMP_DIR/*pfb $(outdir); \
+ rm -rf $$TMP_DIR
# since recent mpost versions no longer create a mem file, we create a dummy
# file to satisfy the dependency (which gets overwritten in case an older
--
2.1.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I'm back.
Janek Warchoł writes: > Hello everyone :-) > > I'd like to "officially announce" that I'm active again. Great to hear. Here's to you managing a good balance between invested time and fun and results you like! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Understanding and modifying font nodes
On 2015-04-26 01:05, Urs Liska wrote: I have wrapped around about anything I could think of, but I'm stuck and would greatly benefit of some help now. I'm working on the font interface and will (hopefully soon) present a patch that may improve font handling (with the new alternative fonts provided by Abraham) significantly. The last big obstacle is modifying the add-font procedure in font.scm to an "add-or-replace-font" behaviour. The idea is removing the annoying limitation that fonts can only be set once and not reset. In order to change anything one has to recreate the complete font-tree. Hi Urs, I agree that this is highly cumbersome. Not that it helps, but let me remark that some time ago I tried to achieve the same, and have not been successful. On a different note, at least it looks as if by now we can remove that annoying manual font scaling for non-default global staff sizes by setting (/ (* staff-height pt) 2.5) as a default factor. This remedies one of the potential user problems. It boils down that I simply don't understand what's going on inside the font nodes and how many of them are processed in the iterations, regardless how much debug printing I use to get to grips with it. +1 from me... :-/ Best, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Just some short feedback
Am 28.04.2015 um 00:20 schrieb Trevor Daniels: I'd like to second everything that Carl writes below, and add my thanks to you, David. +1 Marc Trevor Carl Sorensen wrote Monday, April 27, 2015 11:07 PM On 4/27/15 3:09 AM, "David Kastrup" wrote: As things currently stand, I suspect that the current mechanism for creating Scheme engravers with their own variables (namely providing a function creating an engraver description) does not have likable performance characteristics and, more importantly, does not really work reasonably at all with regard to registering Scheme engravers like C++ engravers so that they can be called by name and documented in the same manner. I'm totally supportive of developing a way to register Scheme engravers so they can be documented and be full members of the LilyPond family. I'll probably come up with something GOOPS-related eventually and the closure mechanism for creating Scheme engravers will be deprecated. At any rate, I am starting over _again_ but I think that I am now at the stage where my plan of execution is nicely streamlined and "Listeners" >from both C++ and Scheme level (as well as their creation from the bowels of the respective engraver types) are quite straightforward to deploy and debug and don't rely on all the C level macro hackery. That sounds like a great thing. Like so much of your work, it makes a huge difference in maintainability and future development. Maybe not so much difference in the current function (perhaps none at all), but a huge difference in going forward. We are so fortunate to have you working on this kind of thing. So in short, I've been tending the most important resource a good programmer should have in his possession: the wastebasket. And I expect people to ultimately be glad about all the code I have thrown away once I get to throwing away the current code we work with. I'm looking forward to having you throw away some code and replace it with much more easily-maintained and -extended code. Thanks for your hard work! Carl ___ 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
