Re: unable to make doc

[John Mandereau]

Hello Jean-Charles,
Le lundi 15 juin 2009 à 22:54 +0200, Jean-Charles Malahieude a écrit :
> It works well with a 8.64  gohstscript.   I'm still upset  because I 
> don't understand the reason why.

I had problems with gs 8.63 on Fedora 9, I followed Graham's suggestion
on upgrading it to the same Git revision as GUB does (8.65 was not out
last time I checked), and it worked for me. I don't know on Fedora 11,
because I kept gs binary in my home dir without wondering about it.

Best,
John



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

Re: RFC: new vertical layout engine

[Andrew Hawryluk]

On Tue, Jun 16, 2009 at 3:52 AM, Joe Neeman wrote:
> On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer 
> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Am Montag, 15. Juni 2009 17:25:54 schrieb Joe Neeman:
>> > I've started working on a new system for doing vertical layout in one
>> > pass
>> > (ie. positioning and stretching the systems simultaneously).
>>
>> Since I have also attempted to improve the vertical stretching of
>> orchestral
>> (choir + full orchestra) full scores (but failed, since I couldn't get the
>> springs-and-rods problem to return any useful solution), I spend a while
>> thinking about what should be done:
>
> Those are some comprehensive comments, thanks! Some remarks/questions
> below...
>>
>> - -) Being able to set stretching factors on a StaffGroup-level. In
>> particular,
>> for full scores there are staff groups for woodwind, brass, vocal voices,
>> strings etc. When the whole system is stretched vertically, there is more
>> space in printed scores between the groups than between the staves inside
>> the
>> individual groups (i.e. the instrumental staff groups use a different
>> spring
>> constant than the staff group for the whole system). See e.g. a modern
>> Bärenreiter edition:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Schubert_StabatMater_0050.pdf
>> Current bad lilypond results (with huge stretching) are:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_largestretch.pdf
>>
>> This is really necessary for full scores for the conductor to get a quick
>> overview over the instrument groups. In particular, look at the
>> stretching_oly_vocalstaves.pdf file (current results with lilypond!), hide
>> the
>> group brackets at the left and try to guess which staves belong
>> together...
>> Sample file (with hardly any stretching):
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf
>>
>> You would never guess which staves belong together..
>
> This will certainly the possible in the layout code, but I don't see how to
> make it nicely accessible through properties. Currently, the information
> about staff groups doesn't make it as far as the backend. If I can't find a
> nice way to do this, the functionality will be available anyway by setting
> 'previous-space on the first staff and 'next-space on the last staff of a
> staff group.
>
>> - -) The stretching should not be done by simply inserting the same space
>> between all the staves, since then staves with a high skyline (e.g. one
>> staff
>> has some dynamic signs, while other don't) will be spaced too much
>> compared to
>> staves with a low skyline. The stretching should rather attempt to space
>> the
>> center-line of the staves (almost) equally.
>
> This is already done (assuming it works; I haven't checked carefully).
>
>>
>> - -) For staves with lyrics it might give better results to almost ignore
>> the
>> lyrics for spacing and then squeeze in the lyrics in the remaining space.
>> Otherwise the vocal staves with lyrics will be spaced way too much
>> compared to
>> e.g. the strings section. For a hand-engraving, see e.g. the 1897
>> Breitkopf
>> edition of Schubert's Stabat mater:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Partitur_Breitkopf1897-
>> Seite2.pdf
>> Compare this to the current LilyPond output:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf
>
> Ok, I was planning anyway to divide VerticalAxisGroups into "spaceable" (eg.
> staves) and "non-spaceable"
> (eg.  dynamics in a piano staff) categories. The "spaceable" lines will
> participate in the layout algorithm (ensuring that space is reserved for the
> non-spaceable lines) and then the non-spaceable lines will be distributed
> somehow in between the spaceable ones. This is how I intend to do centered
> dynamics for piano staves; I could do something similar for lyrics (maybe
> for figured bass also?).

Could there be a property that specifies whether the non-spaceable are to be
a) centered bewteen the neighboring lines,
b) positioned as close to the upper line as possible, or
c) positioned as close to the lower line as possible?

This would cover (a) piano-centered dynamics and lyrics between choral
staves, (b) lyrics below single staves and figured bass, and (c)
chords and lyrics above single staves (rare, but seen in choral works
with divisi).

>> - -) It should be possible to keep one context (in particular FiguredBass)
>> as
>> close as possible to another staff (yes, we have that already by disabling
>> stretching above).
>>
>>
>> - -) Fixed positioning of staves/contexts should be possible, even if some
>> contexts are killed (in particular, when there are several measures where
>> a
>> vocal voice is quiet, the lyrics context is automatically killed meanwhile
>> and
>> the explicit positioning is messed up right now.
>
> I'm not

Re: translation of the doc into italian

[John Mandereau]

Hello Federico,
Le mercredi 17 juin 2009 à 17:55 +0200, Federico Bruni a écrit :
> Documentation/po/it.po is not translated yet, so I'll add it as soon 
> as I've done the translation.

This PO file is so huge that it's recommended to translate only the
entries needed in the files that are actually translated.


> Anyway, the files I committed some days ago are not present in the 
> tree on the web git repository (as far as I can see).
> I guess John Mandereau is supposed to do that, as he mentioned in a 
> previous email.
> Probably he's waiting for me to start translating some real file :-)

Yes, I am :-)  I will apply all patches to LilyPond tree for Italian
translation once you have translated all files marked with priority 1 in
the CG.  I should make this point clearer there, but I'm really too busy
right now :-/

Best,
John



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

Re: some sort of suppress-accidental?

[Mark Polesky]

Neil Puttock wrote:

> > do you think remove-accidental would be more semantically
> > accurate than hide-accidental?
> 
> Not particularly, since that implies that it exists in the
> first place.

By that logic, I would think prevent- or suppress- would be
more accurate.
- Mark



  


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

Re: some sort of suppress-accidental?

[Neil Puttock]

2009/6/17 Mark Polesky :

> do you think remove-accidental would be more semantically
> accurate than hide-accidental?

Not particularly, since that implies that it exists in the first place.

> I'm thinking that \hideNotes
> still leaves space where the notes would be, but this
> function doesn't (at least that's my understanding).

Correct. It prevents the creation of an Accidental grob.

Regards,
Neil


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

Re: [PATCH] Fix issue 778

[Neil Puttock]

2009/6/17 Han-Wen Nienhuys :
> I think this can be neater.  By tracking the 'cause property
> backwards, this could simply be a grob property callback, and the C++
> does not need to touch the
> 'dot-count property.

We already have the callback, as I pointed out in the other thread:
dots::calc-dot-count.

Patrick, all you need to do is remove this line, since the callback
will furnish the correct value for 'dot-count as required:

  d->set_property ("dot-count", scm_from_int (dur->dot_count ()));

A regression test would be useful to show that the override actually works.

Regards,
Neil


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

GUB / autoconf out-of-tree builds

[Graham Percival]

I've tracked down the srcdir vs. builddir problem to autoconf.

builddir = 
~/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master$ 

srcdir = 
~/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master$ 


builddir contains a GNUmakefile, which consists of:

depth = ./
include config$(if $(conf),-$(conf),).make
include $(configure-srcdir)/GNUmakefile.in


it obviously requires the srcdir GNUmakefile.in, but running:
  make DOCUMENTATION=YES dist
fails, because the GNUmakefile in the srcdir contains:

dist-toplevel-txt-files: top-doc
-mkdir -p $(distdir)
ln $(TOPDOC_TXT_FILES) $(distdir)/
ln $(top-src-dir)/stepmake/aclocal.m4 $(distdir)/


The $(TOPDOC_TXT_FILES) includes RELEASE-COMMIT, which is only
created in the builddir, not the srcdir.


I've never used autoconf to do an out-of-tree build before, so I'm
getting lost.  I've done this in cmake, but it's trivial to do
with cmake.  :|

I'd like to make a 2.13.3 release soon, so any advice would be
appreciated.
(actually, I suppose the easiest thing would be to remove the
RELEASE-COMMIT stuff from the normal lilypond git)

Cheers,
- Graham


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

Re: translation of the doc into italian

[Graham Percival]

On Wed, Jun 17, 2009 at 05:55:01PM +0200, Federico Bruni wrote:
> Anyway, the files I committed some days ago are not present in the tree 
> on the web git repository (as far as I can see).

I've tried to clarify this in the CG.

> I guess John Mandereau is supposed to do that, as he mentioned in a  
> previous email.

He's very busy right now, but I'm sure he'll get to it.

Cheers,
- Graham


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

Re: improving cheatsheet appearance

[Graham Percival]

Thanks, applied.  I ended up using
\hideNotes
c128

for the key signature example; it works, and that's simpler than
messing with the @lilypond[] options.

Cheers,
- Graham

On Tue, Jun 16, 2009 at 11:25:36PM -0700, Mark Polesky wrote:
> 
> In cheatsheet.itely
> 
> I propose changing line 70 (in "time signature") from
> \override Staff.Clef #'transparent = ##t
> to
> \override Staff.Clef #'stencil = #empty-stencil
> 
> Also, in "key signature" (lines 95-102), 
> the auto-generated \paper block is
> 
> \paper {
>   #(define dump-extents #t)
> 
>   indent = 0\mm
>   ragged-right = ##t
>   force-assignment = #""
>   line-width = #(- line-width (* mm  3.00))
> }
> but looks better as 
> 
> \paper {
>   #(define dump-extents #t)
>   
>   indent = 0\mm
>   left-margin = 20\mm
>   ragged-right = ##f
>   force-assignment = #""
>   line-width = 15\mm
> }
> 
> But, of course, I read this in the CG:
> If you are making an
> example demonstrating special
> \paper{} values, contact the
> Documentation Editor. 
> 
> So, I'll leave it at that. If someone wants to make
> these changes, I think the cheatsheet will look 
> nicer. I can patch a change for the first one, but
> I don't know how to touch the auto-generated \paper
> code for the second one.
> 
> HTH
> - Mark
> 
> 
> 
>   
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: some sort of suppress-accidental?

[Mark Polesky]

Neil,


do you think remove-accidental would be more semantically
accurate than hide-accidental? I'm thinking that \hideNotes
still leaves space where the notes would be, but this
function doesn't (at least that's my understanding).

- Mark



  


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

Re: translation of the doc into italian

[Carl D. Sorensen]

On 6/17/09 9:59 AM, "Federico Bruni"  wrote:

> Graham Percival wrote:
>> On Sun, Jun 14, 2009 at 01:04:13AM +0200, John Mandereau wrote:
>>> After that, it would be best translating the lilypond.org main web site
>>> before translating the rest of the documentation, as the former has much
>>> more audience than the latter.
>> 
>> Umm, I'm expecting to almost-completely rewrite the website in the
>> next few days.  I'm really not certain that starting to
>> translating the website now is a good idea.
>> 
>> 
>> Tentative new website ready (i.e. start translating): late June.
>> Tentative website "release" (i.e. hopefully finished
>> translations): late July.
>> 
> 
> Do you suggest to wait until late June, so I can translate first the
> updated website?


> 
> Or I can start right now with the Documentation?

Start right now with the Documentation.  John was suggesting that the
website would be better to translate first instead of the Docs.  But Graham
said the website is changing in a couple of weeks, so it would not be a good
use of time to do the website.

I'd suggest you just start with the documentation.

Thanks,

Carl



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

Re: translation of the doc into italian

[Francisco Vila]

2009/6/17 Federico Bruni :
> Francisco Vila wrote:
>>
>>  New files you have not told git about are not affected, see git commit
>> --help. You must to "git add" them first.
>>
>
> I did not really started the translation yet (but I'll do it soon).
> Anyway, the few changes I made should be committed now. This is my Git
> status:
>
> f...@fede-laptop:~/lilypond-translation$ git status
> # On branch lilypond/translation
> # Untracked files:
> #   (use "git add ..." to include in what will be committed)
> #
> #       Documentation/po/it.po
> nothing added to commit but untracked files present (use "git add" to track)

Clearly, it is untracked, use "git add Documentation/po/it.po" to track it.

Once it is tracked, commit the changes made to all added files with git commit.

That makes a commit _on your git history_ that should appear in the
output of "git log" at the top. It should also be at the topmost of
the graph shown by gitk.

Once the commit exists on your git history, to send these changes to
anybody else, make the patch as you know, and send the patch.

Try to learn as much as you can about git, this will facilitate your
everyday work on translation. Count on me to share the [very little] I
know about git.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org


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

Re: translation of the doc into italian

[Federico Bruni]

Graham Percival wrote:

On Sun, Jun 14, 2009 at 01:04:13AM +0200, John Mandereau wrote:
After that, it would be best translating the lilypond.org main web site  
before translating the rest of the documentation, as the former has much  
more audience than the latter.


Umm, I'm expecting to almost-completely rewrite the website in the
next few days.  I'm really not certain that starting to
translating the website now is a good idea.


Tentative new website ready (i.e. start translating): late June.
Tentative website "release" (i.e. hopefully finished
translations): late July.



Do you suggest to wait until late June, so I can translate first the 
updated website?


Or I can start right now with the Documentation?


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

Re: translation of the doc into italian

[Federico Bruni]

Francisco Vila wrote:
 
New files you have not told git about are not affected, see git commit

--help. You must to "git add" them first.



I did not really started the translation yet (but I'll do it soon).
Anyway, the few changes I made should be committed now. This is my Git 
status:


f...@fede-laptop:~/lilypond-translation$ git status
# On branch lilypond/translation
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   Documentation/po/it.po
nothing added to commit but untracked files present (use "git add" to 
track)


Documentation/po/it.po is not translated yet, so I'll add it as soon 
as I've done the translation.


Anyway, the files I committed some days ago are not present in the 
tree on the web git repository (as far as I can see).
I guess John Mandereau is supposed to do that, as he mentioned in a 
previous email.

Probably he's waiting for me to start translating some real file :-)


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

Re: RFC: new vertical layout engine

[Kieren MacMillan]

Hi Joe,

What I would *really* love are high-level commands to set intra-piece  
(section) system-count and page-count options.
For example, I'd like to say that in an ABA form piece, the B section  
must be on two pages (whereas the leading A and trailing A' sections  
can be "auto-flowed" by Lilypond


Could that be possible?

Thanks,
Kieren.


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

Re: translation of the doc into italian

[Francisco Vila]

2009/6/13 Federico Bruni :
> 1) GIT
> I did the following changes: run "make ISOLANG=it new-lang" in Documentation
> and added a line in Python/langdefs.py
>
> Is this commands sufficient to commit the changes?
> git commit -a
> git format-patch origin
>
> Or maybe I've committed only the file modified (langdefs.py) and not the new
> files also (Documentation/it/)?

New files you have not told git about are not affected, see git commit
--help. You must to "git add" them first.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org


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

Re: development on windows

[Bertalan Fodor (LilyPondTool)]

A quick update:
- tried Anjuta - couldn't import LilyPond
- tried KDevelop - there were problems with it regarding setting 
different arguments to lilypond
- tried Eclipse CDT - after some tutorial about importing the project 
(http://moblin.org/documentation/moblin-sdk/coding-tutorials/getting-started-developing-eclipse), 
it provided the best debugging experience.


Bert



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

Re: translation of the doc into italian

[Federico Bruni]

Carl D. Sorensen wrote:



On 6/9/09 10:39 AM, "Federico Bruni"  wrote:


Hi all,

as far as I can see there is not an italian documentation for lilypond.

I'd like to help with that, could you please tell me how can I contribute?
If other italians want to join, either for just proofreading or
translating also, please speak up.

I can imagine that it's a demanding work, but I'm enthusiast about
lilypond and really motivated to contribute.


Great!

John Mandereau is the translation meister.  I've copied him on this reply.

The first step toward developing a translation is to read the Translation
section of the Contributors' Guide.  You'll find that here:



It gives you the instructions necessary to start translating.  If the
instructions aren't clear, ask questions on the lilypond-devel list; this
will help us update our Contributors' Guide.



Hi Carl and all,


I've read that page and started the first steps. A couple of questions:

1) GIT
I did the following changes: run "make ISOLANG=it new-lang" in 
Documentation and added a line in Python/langdefs.py


Is this commands sufficient to commit the changes?
git commit -a
git format-patch origin

Or maybe I've committed only the file modified (langdefs.py) and not 
the new files also (Documentation/it/)?


2) langdefs.py
I've just added this line below the other languages:

it = LanguageDef ('it', 'italiano')

Is it sufficient?
(the documentation does not provide a clear example, I'm not a 
developer so I prefer asking..)


Thanks for your help.
Regards,
Federico


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

Re: Successful merge?

[Francisco Vila]

2009/6/17 Francisco Vila :
> If all is OK in this
> branch (I am trying to make doc right now), we could finally merge it
> into master.

The docs compile well on the lilypond/translation branch after the
merge, just FYI. What an additional check would be necessary to be
sure that I have not broken anything?
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org


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

Re: RFC: new vertical layout engine

[Joe Neeman]

On Tue, Jun 16, 2009 at 2:50 PM, Reinhold Kainhofer
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Dienstag, 16. Juni 2009 11:52:09 schrieb Joe Neeman:
> > On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer
>
> > This will certainly the possible in the layout code, but I don't see how
> to
> > make it nicely accessible through properties. Currently, the information
> > about staff groups doesn't make it as far as the backend.
>
> Then that's the main problem. The staff groups are the prime key to
> vertical
> spacing, since they group the score, which should also be reflected in the
> vertical layout.
>
> Would it be possible to derive appropriate properties for each staff from
> the
> grouping when the grouping is still available, so that the vertical
> alignment
> then has the correct settings derived from the grouping?


Not easily, because we don't know the line breaking (and therefore we don't
know which staves will disappear) at that point. I think it can be done,
though, by adding a new grob, StaffGrouper say, to represent the staff
grouping and preserve that information all the way through page-breaking.
I'll do this next and hopefully have something workable in a few days.

>
> > > - -) Fixed positioning of staves/contexts should be possible, even if
> > > some contexts are killed (in particular, when there are several
> measures
> > > where a vocal voice is quiet, the lyrics context is automatically
> killed
> > > meanwhile and
> > > the explicit positioning is messed up right now.
> >
> > I'm not sure exactly what you mean by this. Do you mean that
> > 'alignment-offsets in 'line-break-system-details should include the
> > position of dead staves as well as live ones?
>
> No, I'm not talking about staves, I'm talking mainly about lyrics line,
> which
> are also included in the alignment-offsets. As an example, take the
> following
> sample score, which does not have any explicit positioning yet:
>
> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics_nosetting.pdf
>
> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics_nosetting.ly
>
> Now assume that you want the staves on the exact same position (i.e. the
> exact
> same spacing, e.g. starting at 0, -15, -30 and -40. The first two staves
> have
> lyrics to be placed at -5 and -20 (but also have some lines with only rests
> and no lyrics).
> I've run into this situation when writing Vierne's Messe Sollennelle, which
> has four choir voices and two organs. I wanted the staves to be in the
> exact
> same position on every page...
> So, of course you would set the alignment-offsets to:
> \layout {
>  \context { \Score
>\override NonMusicalPaperColumn #'line-break-system-details =
> #'((alignment-offsets . (0 -5 -15 -20 -30 -40)))
>  }
> }
>
> And now look at the result:
>
> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics.pdf
>
> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics.ly
>
> The first system behaves as expected, but as soon as one staff does not
> have
> lyrics assigned in one line, the next staff will be placed where the lyrics
> should have been and the spacing is totally messed up.
> Note that there is no setting to prevent the lyrics context from vanishing,
> so
> currently the explicit positioning is useless for vocal music.


What if I made alignment-offsets only apply to "spaceable" lines (ie.
staves)? That is, the alignment-offsets list contains a number for every
staff. To space the lyrics, you would need to override some setting in the
lyrics context that specifies how to distribute lyrics between staves, which
have their position fixed by alignment-offsets. There's still the question,
though, of whether alignment-offsets should contain offsets for the
harakiri-ed staves.

Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Successful merge?

[Francisco Vila]

Hello.

If I'm not wrong, our translation branch is in sync with master again.
I still have some doubts about snippets that changed their filenames,
but at last the mysterious diverging histories seem to have
encountered themselves back.

John, if you finally own a Masters (congratulations!) please take a
look at 519d9e493f62c on lilypond/translation. If all is OK in this
branch (I am trying to make doc right now), we could finally merge it
into master.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org


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

Re: empty-stencil and point-stencil

[Carl D. Sorensen]

On 6/16/09 1:51 PM, "Mark Polesky"  wrote:

> 
> 
> Trevor, could you add a bit to your recent LM 4.3.1 patch about
> empty-stencil and point-stencil? They are suitable substitutes for
> #'stencil = ##f.
> 
> \override  #'stencil = #empty-stencil
> \override  #'stencil = #point-stencil
> 
> See
> http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00332.html
> for a very recent discussion. I actually don't fully understand
> the subtleties of discerning when one is more appropriate than
> the other, but it sounds like you might!

I don't understand why empty-stencil has a non-zero extent; that means it
takes up space.

I believe that point-stencil should be used to replace ##f, because we want
to take up no space, and point-stencil has zero extent.

Thanks,

Carl



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

Re: improving cheatsheet appearance

[Graham Percival]

On Tue, Jun 16, 2009 at 11:25:36PM -0700, Mark Polesky wrote:
> 
> In cheatsheet.itely
> 
> I propose changing line 70 (in "time signature") from
> \override Staff.Clef #'transparent = ##t
> to
> \override Staff.Clef #'stencil = #empty-stencil

This is easy enough; I'll do that tomorrow morning.

> Also, in "key signature" (lines 95-102), 
> the auto-generated \paper block is
> 
> \paper {
>   #(define dump-extents #t)
> 
>   indent = 0\mm
>   ragged-right = ##t
>   force-assignment = #""
>   line-width = #(- line-width (* mm  3.00))
> }
> but looks better as 
> 
> \paper {
>   #(define dump-extents #t)
>   
>   indent = 0\mm
>   left-margin = 20\mm
>   ragged-right = ##f
>   force-assignment = #""
>   line-width = 15\mm
> }

That's a lot trickier, and I'm not convinced it would be worth it.
OTOH, the cheatsheet is a fairly small file, so there's no harm in
fiddling with those values.  And since we're not printing these
out verbatim, we coudl add a \paper{} in the code itself.

ok, I've convinced myself that it's at least worth trying these
new values and taking a look.  :)

Cheers,
- Graham


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