gmane.comp.gnu.lilypond.bugs

\omit Dots acts like \hide Dots

Pavel Roskin — 2013-06-19T14:16:19

Hello!

\omit Dots should not reserve space for the omitted dots.  That's what  
\hide does.  The problems exists in Lilypond 2.16 as well.  The \omit  
keyword just makes it more obvious that the current behavior is wrong.

\version "2.17.20"
\score {
   <<
     \new Staff
     <<
       \new Voice { <b' g'>4. }
       \new Voice {
         \omit NoteHead \omit Stem \omit Dots
         \override NoteColumn #'ignore-collision = ##t
         b'4.
       }
     >>
   >>
}

Re: convert-ly produces invalid output forKeySignature.c0-position

Pavel Roskin — 2013-06-19T14:03:47

Quoting David Kastrup <dak< at >gnu.org>:


I just hope you won't take away the ability to adjust the key  
signature without placing the accidentals manually.  It turns out the  
LSR snippet 792 would show the initial key signature incorrectly.   
http://lsr.dsi.unimi.it/LSR/Item?id=792

Re: convert-ly produces invalid output for KeySignature.c0-position

David Kastrup — 2013-06-19T09:29:04


Given the analysis in a longer mail, I revert my opinion that we need to
do something here.  c0-position for the relevant grobs _can't_ be set by
overrides or tweaks.  Renaming it to middleCPosition would likely cause
more confusion.  What _is_ wrong is that the Internals Reference calls
it a user property: as far as I can see, it is for internal use only.
The question is where this distinction is established.

Re: convert-ly produces invalid output for KeySignature.c0-position

David Kastrup — 2013-06-19T09:13:10


Well, we have
void
Key_engraver::create_key (bool is_default)
{
  if (!item_)
    {
      item_ = make_item ("KeySignature",
                         key_event_ ? key_event_->self_scm () : SCM_EOL);

      /* Use middleCClefPosition rather than middleCPosition, because cue
       * notes with a different clef will modify middleCPosition. The
       * Key signature, however, should still be printed at the original
       * position. */
      item_->set_property ("c0-position",
                           get_property ("middleCClefPosition"));

So the KeySignature grob is created (which triggers all overrides and
tweaks on c0-position), and then right away c0-position is overwritten.

There is also

          if (scm_is_pair (restore))
            {
              cancellation_ = make_item ("KeyCancellation",
                                         key_event_
                                         ? key_event_->self_scm () : SCM_EOL);

              cancellation_->set_property ("alteration-alist", restore);

Re: convert-ly produces invalid output forKeySignature.c0-position

Pavel Roskin — 2013-06-19T07:45:47

Quoting David Kastrup <dak< at >gnu.org>:


I'm fine with renaming.  We have Staff.middleCPosition.  Perhaps the  
same name could be used in KeySignature.

On the other hand, we don't care where the _middle_ C is positioned.   
We only need to know where _some_ C is positioned to decide how to  
print the key signature.  Then "middle" could be dropped.

By the way, setting KeySignature.c0-position with \override doesn't  
work.  I had to resort to setting it in Scheme:

\once \override Staff.KeySignature #'stencil =
   #(lambda (grob)
     (ly:grob-set-property! grob 'c0-position 6)
     (ly:key-signature-interface::print grob))

Full example here:
https://gitorious.org/lilypond-music/lilypond-music/blobs/master/Samuel_Barber/The_Daisies.ly

Perhaps c0-position can only be set together with other properties to  
have an effect.  Or maybe it's not meant to be set.  But I need to  
change it when I want the key signature to correspond to the staff  
clef that is not in effect on the first note (the staff clef is b

Re: convert-ly produces invalid output for KeySignature.c0-position

David Kastrup — 2013-06-19T07:11:05


Small wonder.  I thought our default use of symbols matched our naming
rules, but that one's an exception.

We can make an exception for convert-ly here, but that's not a
satisfactorily final solution.

I propose renaming it.  Suggestions?

Re: Patch:Doc-enhancement identifiers

Marek Klein — 2013-06-19T06:03:04

Hello Urs,

2013/6/18 Urs Liska <lilyliska< at >googlemail.com>

convert-ly produces invalid output for KeySignature.c0-position

Pavel Roskin — 2013-06-19T04:15:34

Hello!

I'm using the current lilypond from git.  This is what I have before  
the conversion:

\version "2.16.0"
{
   \override KeySignature #'c0-position = #6
}

convert-ly turns it into:

\version "2.17.20"
{
   \override KeySignature.c0-position = #6
}

The original file can be processed by lilypond, but the converted file cannot.

$ lilypond converted.ly
GNU LilyPond 2.17.21
Processing `converted.ly'
Parsing...
converted.ly:3:26: error: syntax error, unexpected NOTENAME_PITCH,  
expecting SCM_IDENTIFIER or SCM_TOKEN or STRING
   \override KeySignature.
                          c0-position = #6
converted.ly:3:27: error: not a duration: 0
   \override KeySignature.c
                           0-position = #6
converted.ly:3:38: error: syntax error, unexpected '='
   \override KeySignature.c0-position
                                      = #6
converted.ly:3:40: warning: Ignoring non-music expression
   \override KeySignature.c0-position =
                                        #6
converted.ly:2:1: error:

Re: Patch:Doc-enhancement identifiers

James — 2013-06-18T19:23:50

What's the google tracker number?

I don't recall testing this patch.

Did it just get thrown onto the list or did they follow the process for 
submitting patches?

Re: Patch:Doc-enhancement identifiers

Urs Liska — 2013-06-18T18:47:57

Am 15.06.2013 10:10, schrieb Urs Liska:
Nobody bothering accepting or at lest commenting a free patch contribution?

Re: If incipit has soprano clef,its staves are notaligned with main score

David Kastrup — 2013-06-18T08:08:17


That kind of construct would behave even more obscure than just zeroing
out the extents would.

Re: If incipit has soprano clef, its staves are notaligned withmain score

ArnoldTheresius — 2013-06-18T07:27:40

David Kastrup wrote



Just an idea: a markup command which evaluates the Y-extent of its argument,
and returns it symetrically expanded ( -max(abs(extent_Y_min),
abs(extent_Y_max)) . +max(abs(extent_Y_min), abs(extent_Y_max))).

I know, it's to opposite thing of reducing the extent to zero - expand it
with white space to be symmetric.

ArnoldTheresius



--
View this message in context: http://lilypond.1069038.n5.nabble.com/If-incipit-has-soprano-clef-its-staves-are-not-aligned-with-main-score-tp146996p147157.html
Sent from the Bugs mailing list archive at Nabble.com.

Re: system start bracketsgroups are cropped to the left in NR

David Kastrup — 2013-06-17T07:49:53



I don't think it is, but the underlying problem is the same.

Re: system start bracketsgroups are cropped to the left in NR

Eluze — 2013-06-16T22:01:26

David Kastrup wrote



sorry for the noise - I didn't know that -dpreview is involved when creating
those examples

Eluze



--
View this message in context: http://lilypond.1069038.n5.nabble.com/system-start-bracketsgroups-are-cropped-to-the-left-in-NR-tp147133p147143.html
Sent from the Bugs mailing list archive at Nabble.com.

Re: system start bracketsgroups are cropped to the left in NR

David Kastrup — 2013-06-16T17:14:39


<URL:http://code.google.com/p/lilypond/issues/detail?id=3386>

Issue 3386: Output crops staff braces when produced with -dpreview

Re: system start bracketsgroups are cropped to the left in NR

Phil Holmes — 2013-06-16T17:10:00

"Eluze" <eluzew< at >gmail.com> wrote in message 
news:1371400573215-147133.post< at >n5.nabble.com...

This is http://code.google.com/p/lilypond/issues/detail?id=3386

system start bracketsgroups are cropped to the left in NR

Eluze — 2013-06-16T16:36:13

hi

starting with 2.17.14 (pdf & html) examples in
http://www.lilypond.org/doc/v2.17/Documentation/notation/displaying-staves#nested-staff-groups
are cropped at left

compiling myself the output is ok

Eluze



--
View this message in context: http://lilypond.1069038.n5.nabble.com/system-start-bracketsgroups-are-cropped-to-the-left-in-NR-tp147133.html
Sent from the Bugs mailing list archive at Nabble.com.

Patch:Doc-enhancement identifiers

Urs Liska — 2013-06-15T08:10:06

Hi,

as discussed here: 
http://lists.gnu.org/archive/html/lilypond-user/2013-06/msg00342.html
The definition of identifier names in 
http://www.lilypond.org/doc/v2.17/Documentation/notation/file-structure.html 
is slightly misleading.
I think applying the attached patch would make it clearer.

Best
Urs
_______________________________________________
bug-lilypond mailing list
bug-lilypond< at >gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: If incipit has soprano clef,its staves are notaligned with main score

David Kastrup — 2013-06-14T05:59:38


Visually, you'd rather want to center not on the "true" center, but on
something like half the x-height above the baseline: one would not want
different baselines for "Daisy" and "Joe".  There is a complication that
with all-caps word, the x-height is not the same: one centers "Violin"
at a different height than "VIOLIN".


Hey, I just wrote an entire paragraph unnecessarily.


I am not overly enthused about downing extents for the purpose of
getting baselines heeded.  It's not really intuitive.

Re: If incipit has soprano clef,its staves arenotaligned with main score

Keith OHara — 2013-06-14T02:00:23

The primary use of InstrumentName is to print the instrument name, and
we would rather have the text centered than have its baseline centered.
(Maybe another reason to shift the baseline to the center of the 
ex-height?)

So I think the behavior is what we want overall, but maybe we should put
one of the Y-extent overrides in the examples that put an incipit in 
the Instrument Name.   I suggest this be a documentation request; any
project member please open an item if you agree, complain if not. I'll
open a doc suggestion in a few days if my opinion remains the same.

Re: If incipit has soprano clef,its staves are notaligned with main score

Keith OHara — 2013-06-14T01:54:22



Thomas' seems pretty easy?  You can also override one dimension only of
the instrument name.

incipit = \markup \score {{\clef soprano s4 \bar "" } \layout{} }
\new Staff \with { 
  \override InstrumentName #'Y-extent = #'(-4 . 4)
  instrumentName=\incipit
} { g'1 }

The bug report remains, though, that someone expected a (generalized)
InstrumentName to be aligned on its baseline, whereas it is centered.