Re: `+repage' option for convert?

[Alexander Kobel]

Werner LEMBERG wrote:

[Sorry if this has already been dealt with; I'm abroad, with no access
to the internet.]

This change

+   convert -depth 8 \
-alpha Off \
-background white \
-layers flatten \
-trim \
+repage \
$< $@

isn't understood by `convert' version 6.4.3 -- the `+repage' option
fails.  Is this a typo?


That's strange. +repage should be supported from IM 6.1.0 on, AFAIK. 
What gets converted here?


It's definitely not a typo. But if I get it right, it's just a shortcut 
for -page +0+0. (At least for BMP/GIF/PNG output; tested here using IM 
6.4.5, Ubuntu Jaunty build, on PNGs.)


Note that +repage is not (yet?) supported in the GraphicsMagick fork 
(which is the default replacement package at least in Ubuntu), while 
-page is. So to the best of my knowledge, using -page +0+0 is both an 
equivalent and more portable option, anyway.



Cheers,
Alexander


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

Re: Breve with double lines on each side

[Alexander Kobel]

Reinhold Kainhofer wrote:
A while ago we had that discussion about a user wanting two vertical lines on 
each side of the breve instead of one. I have now prepared a patch for our 
font, which adds such a "noteheads.sM1double" glyph:


Woah, great! Praise you! :-)

Regarding the single- vs. double-line breve: I have not yet found a reference 
to the single-line breve. Only the double-lined breve can be found practically 
everywhere:


I know the double-line shape very well, but I've seen the single-line 
version, too, in some transscriptions of Gregorian-inspired choral 
works, e.g. Samuel Barber's "Agnus Dei", edition by G. Schirmer, 1967, 
and several others.


But the single-line version is especially often encountered in 
"Psalmtönen", i.e. the semi-modern transscriptions of short Gregorian 
melodys, e.g. in the "Gotteslob", the German Catholic church choral 
books. In this context, it is used to denote the main note (tenor) of 
the melody, which is to be repeated arbitrarily often depending on the 
number of syllables in the verse.
(See e.g. 
http://lilypond.org/doc/v2.12/input/lsr/lilypond-snippets/Rhythms#chant-or-psalms-notation.ly)


And, while you're at it: there is also a solid node head (quarter note 
head?) with single vertical lines, which basically means the same, but 
is only used for notes at the end of a line, not to be repeated too 
often, to adapt the melody to the stresses of the lyrics (finalis or 
flexa or something like that, IIRC).
I'd greatly appreciate a method to enter these without fancy scheme 
tweaks! ;-)


One thing I notice is that the vertical lines are usually a bit larger than 
the notehead. This would also change the default breve glyph, so I haven't 
included that in the patch. What do you think about this issue?


In the mentioned "Gotteslob", the single-line version (both the brevis 
and the one with the solid note head) are larger than the note head - as 
a rough guess, they extend about 1/4 to 1/3 staff space above and below.
And, by the way, the lines are horizontally tight on the note head, not 
like the brevis in e.g. 
http://imslp.org/wiki/Mass_for_Five_Voices_(Byrd,_William)

If you want me to, I can make some scans tomorrow.

The same holds for some instances of the double-line variant I've 
checked in my songbooks; although I think the shape in the scores of 
Byrd's mass (with horizontal space between note head and lines) looks 
more elegant, the tight version seems to be more common.



Cheers,
Alexander


___
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

[Alexander Kobel]

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

Re: Vertical spacing of lyrics

[Alexander Kobel]

Christian Hitz wrote:

Hi,

the new vertical spacing is evaluating the skyline of the lyrics lines for
spacing. This leads to situations with a very uneven look, as the example
below shows. IMHO the tallest glyph in the used font should be used to 
derive the height of the lyrics line.


This very much depends on what you engrave. If you're making larger 
scores with many staves per system, vertical space is pretty much more 
important than everything else, and it's common practice to fit the 
lyrics as tight to the staves and as close together as possible.


If you want to have a more equal spacing, try modifying the LyricText 
#'minimum-Y-extent or (not sure if this works out) the new 
Lyrics.VerticalAxisGroup #'inter-loose-line-spacing [1]. E.g., in your 
example, adding

  \layout {
\context {
  \Lyrics
  \override LyricText #'minimum-Y-extent = #'(-1.5 . 1.5)
}
  }
to the score seems to solve the problem for me.

There are simple "workarounds" to simulate the 
one-box-to-rule-all-glyphs-approach, but if you decide to drop the 
skyline algorithm, it's nearly impossible to automatically achieve the 
tighter setting.



Cheers,
Alexander

[1] http://lists.gnu.org/archive/html/lilypond-user/2009-10/msg00215.html


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

Re: repeated music

[Alexander Kobel]

[from -user]

Francesco Petrogalli wrote:

I have no idea where to find documentation about this programming in
"lilypond-scheme". There is a big list of scheme function in the
documentation, but I can't see any "tutorial" about using it.


Should this section "A.16 Scheme functions" also be moved to the "Extend 
LilyPond" manual, now that the "Interfaces for programmers" section is 
there? At least, there should be a link to the function list in the TOC 
of the Extend manual, and a corresponding link to the Extend manual on 
top of A.16.



Cheers,
Alexander


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

Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam

[Alexander Kobel]

lilyp...@googlecode.com wrote:
Comment #7 on issue 638 by percival.music.ca: auto-beam-settings do not 
take into account *all* durations covered by the beam


I think this is the autobeaming issue that Carl's working on.



Hi, Carl,

from what I understand from Graham's remark it is you who's working on 
beaming?
If so, perhaps you can help me with the following and/or include it in 
your thoughts and implementation.


I have a few pieces where I want use beams to denote melismata . On the 
other hand, for some longer melismata - often also including quarter or 
half notes - which I specify with slurs, I want the usual automatic 
beaming take place inside.


Now, it's awkward to always write ([ ]), when essentially ( ) already 
implies what I want. So, a straightforward idea was to leave auto 
beaming activated, and try a function like this:


INPUT: music m

slurred = false
for each chord c in m {
  if (c contains a "(" [slur-begin]) {
slurred = true
add forbid-beam-to-the-left to c
add allow-beam-to-the-right to c
  } else if (c contains a ")") {
slurred = false
add allow-beam-to-the-left to c
add forbid-beam-to-the-right to c
  } else {
if (slurred) {
  add allow-beam-to-the-left to c
  add allow-beam-to-the-right to c
} else {
  add forbid-beam-to-the-left to c
  add forbid-beam-to-the-right to c
}
  }
}

Alas, the problem is: the allow-beam-* and forbid-beam-* are 
nonexistent, AFAICS. \noBeam outside of the slurs destroys the auto 
beaming from the last possible beam start position to this point, which 
may influence notes in the surrounding melismata; and something like 
just adding [ to ( and ] to ) gives stub beams also in cases like { c8([ 
c4 c8]) }, where I actually want flags.



So, my question is: how much effort would it take to have such a 
allow-beam-* or forbid-beam-* functionality?
I also could imagine a \splitBeam command, which forbids a "bridge beam" 
between the preceding and the following note:


  { c8 c c c c \splitBeam c c c }
==  |  ===
|  |  |  |  |\ |  |  |
|  |  |  |  |  |  |  |

Then, the code for my function would look like

slurred = false
for each chord c in m {
  if (c contains a "(" [slur-begin]) {
slurred = true
insert \splitBeam before c
  } else if (c contains a ")") {
slurred = false
  } else {
if (! slurred) {
  insert \splitBeam before c
}
  }
}

Hell, even simpler. But - as I said - I have no idea of the work 
involved in this. It'd be great if you think about it, though.



Thanks,
Alexander


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

[GLISS] Syntax of \parallelMusic

[Alexander Kobel]

Hi, all,


something to discuss for the GLISS... I don't know where the right place 
is for such a suggestion (or if it's there at all), so I send it to 
-devel - so that it ends up in the archives at least.



I propose using a different separator for \parallelMusic than "|", and 
allow to include bar checks in there.


\parallelMusic as is is very fine and handy, but sometimes you want to 
enter a whole phrase of two or three measures in a single go, and 
include the bar checks in there for readability and checking later on.
It somewhat disturbs the workflow if you always have to look up where 
the voiceN ended up in the last measure, especially if you have larger 
intervals in the voices, or reentering the durations if one voice stays 
in 16, the next in 8 and the third in 2.


What about, e.g., ":"? It's fast to type, and AFAICS, it only is used 
for chord mode and figured bass. And I don't see a use for those two in 
\parallelMusic, since - well, you usually only have one chord at a time, 
right?
Another idea: "||", to serve both as bar check and as delimiter. And 
there's definitely no use conflict against two bar checks at the same 
point in time, right?



Cheers,
Alexander


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

Re: [GLISS] Syntax of \parallelMusic

[Alexander Kobel]

[With forward to -user, since this may be interesting now for everybody.]

Nicolas Sceaux wrote:

Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit :


I propose using a different separator for \parallelMusic than "|", and allow to 
include bar checks in there.

\parallelMusic as is is very fine and handy, but sometimes you want to enter a 
whole phrase of two or three measures in a single go, and include the bar 
checks in there for readability and checking later on.
It somewhat disturbs the workflow if you always have to look up where the 
voiceN ended up in the last measure, especially if you have larger intervals in 
the voices, or reentering the durations if one voice stays in 16, the next in 8 
and the third in 2.

What about, e.g., ":"? It's fast to type, and AFAICS, it only is used for chord 
mode and figured bass. And I don't see a use for those two in \parallelMusic, since - 
well, you usually only have one chord at a time, right?
Another idea: "||", to serve both as bar check and as delimiter. And there's 
definitely no use conflict against two bar checks at the same point in time, right?


Currently, \parallelMusic highjacks the usual meaning of the pipe symbol: [...]
This was done so that \parallelMusic has no impact on the parser.


Thanks, Nicolas,

this was exactly the hint I needed... It never occured to me that 
parallelMusic might be a simple music function; I figured it's low-level 
and pretty involved in parser.

"I can see clearly now, the rain is gone..."

Which allows for a quite simple modification, to make the delimiter be 
"||", combining a bar check and a voice cycle: Just count how often the 
existing voice change has been called, and only do some work if it's two 
times in a row.

The modification is attached, and seems to work flawlessly.

Of course, this still leaves the question whether the delimiter should 
be changed, and whether it's good to overload the bar check.
But it seems to me that the convert-ly rule should be so simple that 
even I might figure out how to write it, and I'm perfectly satiesfied 
with not having to remember the position of yet another symbol on the US 
keyboard layout... ;-)



Cheers,
Alexander
parallelMusic =
#(define-music-function (parser location voice-ids music) (list? ly:music?)
  (_i "Define parallel music sequences, separated by '||' (double bar check 
signs),
and assign them to the identifiers provided in @var{voice-ids}.

@var{voice-ids}: a list of music identifiers (symbols containing only letters)

@var{music}: a music sequence, containing double BarChecks as limiting 
expressions.

Example:

@verbatim
  \\parallelMusic #'(A B C) {
c c | d d | e e ||
d d | e e | f f ||
e e | f f | g g ||
  }
<==>
  A = { c c | d d | e e | }
  B = { d d | e e | f f | }
  C = { e e | f f | g g | }
@end verbatim
")
  (let* ((voices (apply circular-list (make-list (length voice-ids) (list
 (current-voices voices)
 (current-sequence (list))
 (change-voice-call-count 0))
   ;;
   ;; utilities
   (define (push-music m)
"Push the music expression into the current sequence"
(set! current-sequence (cons m current-sequence)))
   (define (change-voice)
"Stores the previously built sequence into the current voice and
   change to the following voice."
;; only do the actual work if change-voice is called the second time in a 
row
(if (odd? change-voice-call-count)
 (begin
  (list-set! current-voices 0 (cons (make-music 'SequentialMusic
 'elements (reverse! current-sequence))
   (car current-voices)))
  (set! current-sequence (list))
  (set! current-voices (cdr current-voices
;; increase the call counter
(set! change-voice-call-count (- 1 change-voice-call-count)))
   (define (bar-check? m)
"Checks whether m is a bar check."
(eq? (ly:music-property m 'name) 'BarCheck))
   (define (music-origin music)
"Recursively search an origin location stored in music."
(cond ((null? music) #f)
 ((not (null? (ly:music-property music 'origin)))
  (ly:music-property music 'origin))
 (else (or (music-origin (ly:music-property music 'element))
(let ((origins (remove not (map music-origin
  (ly:music-property music 
'elements)
 (and (not (null? origins)) (car origins)))
   ;;
   ;; first, split the music and fill in voices
   (map-in-order (lambda (m)
  (push-music m)
  (if (bar-check? m)
   (change-voice)
   (set! change-voice-call-count 0))) ;; reset the call counter
(ly:music-property music 'elements))
   (if (not (null? current-sequence)) (begin

Re: [GLISS] Syntax of \parallelMusic

[Alexander Kobel]

Valentin Villenave wrote:

On Sun, Nov 29, 2009 at 4:51 PM, Nicolas Sceaux
 wrote:

Modify parallelMusic, so that when a VoiceSeparator (instead of BarCheck)
music element is found, the function switches to the next voice.  The
parallelMusic function seems well documented, this part should not be
difficult.


(To whomever starts working on parallelMusic: please, please, please
implement #451 already!)
http://code.google.com/p/lilypond/issues/detail?id=451


Hi, Valentin,

to be honest - I have no clue what this bug report is about. Even 
assuming syntactically correct input. (By the way, after looking at 
parallelMusic, I'm not surprised at all that the newly posted snippet 
jun.ly works - however, if you wanted to use this, you'd have to write a 
new \relative {} construct for each and every bar.)


NR 1.5.2, section "Writing music in parallel", explicitly explains 
examples (exciting alliterations...) to handle relative input:
	"Relative mode may be used. Note that the \relative command is not used 
inside \parallelMusic itself.
	The notes are relative to the preceding note in the voice, not to the 
previous note in the input – in other words, relative notes for voiceA 
ignore the notes in voiceB."
The latter is not a bug, it's a feature - when I want to use relative 
mode, I want to not count octaves between notes, and it's much more 
reasonable for a ongoing voice to stay in the same range than the 
intervals between voices.


What's the problem about adding the "relativity" _after_ the 
\parallelMusic command? You barely start a \parallelMusic instance for 
three or seven notes, and if you have fifty lines of music, who cares 
about another

  relA = \relative c \A
  relB = \relative c \B
after a \parallelMusic #'(A B) { }? It's there, it's documented, and it 
does exactly what I understand to be desired from the mail linked in the 
bug description.


I think it's no problem defining a \parallelRelativeMusic command which 
does nothing but call \parallelMusic and wrap each argument inside a 
\relative c { ... } afterwards.

But do we really want this to exist?


Okay. After all the rant, I just saw that the discussion dates back to 
March 2006. Maybe this is just fixed by documentation work?



Cheers,
Alexander


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

Re: Issue #768 - chord repetition shortcut: patch for review

[Alexander Kobel]

Hi, Nicolas,

I recognized two potential sources of trouble with your new q command. 
(Excellent! Wonderful! Tremendous! idea, by the way.)

I might have a solution for one of them, but I don't trust myself at all.


Firstly, the one I have no clue about. Is it reasonable to hope for an 
addition s.t. q ignores preceding rests or skips? If I want to repeat 
those, I can just write r or s, but it'd be great if they don't 
overwrite the previous-chord register. E.g. for the following

  { 8 q r q  q q r q }
instead of
  { 8 q r   q q r  }
? AFAICS, the previous-chord is set during parsing/lexing (?), so this 
once more needs coding in the C++ part, and this is well beyond my scope 
right now.



Secondly, q behaves somewhat unintuitive in relative mode when repeating 
chords where the octave changes for the "main" note (is there a better 
name for this one?).

When I enter
  \relative c {   q }
I expect the outcome to be (in absolute mode)
  {},
but instead it's
  {}.
I kind of seem to have a fix for this - which is a very naive "I'm 
feeling lucky"-modification of your default-repeat-chord repetition 
function. I attach it, and it seems to work well, but to be honest - I 
have not the slightest clue why, and I don't trust it at all. I'd 
probably feel better if I had (ly:make-pitch 0 ...) in line 13 (which 
was my initial guess), but it might well be false trust also then.


And, of course, what's missing (if at all possible without C++ hacking) 
is to find out whether the function is called inside a relative or an 
absolute context, thus choosing the appropriate repetition function. I'm 
not even sure if that's reasonable, since I don't know when the function 
actually gets evaluated, and, alas, one can define music in absolute 
context and put a \relative before it later on. See \parallelMusic, 
which suffers from the same problem, as I understand.



Okay, looking forward to read your reply,

Cheers,
Alexander
#(define-public (relative-repeat-chord previous-chord duration articulations)
  "Copy the previous chord, filter out events which are not notes, set the
chord duration, add articulations."
  (let ((new-chord (ly:music-deep-copy previous-chord)))
   (set! (ly:music-property new-chord 'elements)
(append! articulations
 (let ((notes (filter (lambda (event)
   (eqv? (ly:music-property event 'name) 'NoteEvent))
   (ly:music-property new-chord 'elements
  (if (not (null? notes))
   (let ((pitch (ly:music-property (car notes) 'pitch)))
(set! (ly:music-property (car notes) 'pitch)
 (ly:make-pitch -1 (ly:pitch-notename pitch) (ly:pitch-alteration pitch)
  notes)))
   (for-each (lambda (event)
  (if (ly:duration? (ly:music-property event 'duration))
   (set! (ly:music-property event 'duration) duration)))
(ly:music-property new-chord 'elements))
   new-chord))

#(ly:parser-set-repetition-symbol parser 'q)
#(ly:parser-set-repetition-function parser relative-repeat-chord)

\relative c {  q q q |  q q q }
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: severe chord repetition problem

[Alexander Kobel]

Nicolas Sceaux wrote:

Le 6 déc. 2009 à 06:28, Werner LEMBERG a écrit :

Concerning chord repetition, the issues that have been raised are:

- Which elements should be copied?
Restrict the memorization to note chords (like ), and exclude
simple notes and rests?
I was recently in a situation where I would have liked to do e.g.
  re''2\rest q4 q8
whereas Alexander suggested not to memorize rests, so that on can write e.g.
  8 q r q  q q r q


I think this relates to my preference of relative mode and Dutch note 
names. In contrary to the absolute mode and Do-re-mi-names, there is 
nearly no need to repeat single notes with q, since you can just type 
the note name another time without too much overhead (well, assuming you 
don't write too many eseses or fancy micro-accidentals).


I have to admit I had to look up \rest; I did not remember this command, 
and never used it so far. In such a case it really makes sense to have a 
shortcut for the copying, but IMHO the memoization of "simple rests" is 
unnecessary. May it be a reasonable decision to remember rests only if 
they have an attached pitch?


As another idea, I thought about implementing a custom copy policy for 
myself, which also copies some articulations, eventually those types 
defined by the user in a dedicated list. This could be done in Scheme: 
replace the repetition function and plug it in at runtime.
It'd be great if a similar approach could also be done concerning 
copying of simple notes vs. chords: The more you write in relative mode 
and with "simple" keys, the less you probably want q to memoize.


I'm not sure, though, if such a policy-based version is possible via 
Scheme (read: at runtime), since it seems to affect the parser.



Cheers,
Alexander


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

Re: severe chord repetition problem

[Alexander Kobel]

David Kastrup wrote:

Nicolas Sceaux  writes:

Concerning chord repetition, the issues that have been raised are:

- \relative mode
A patch is available for review at 
If nobody objects I'll commit it within a few days.


Maybe there should be a common strategy with \parallelMusic in
connection with \relative?  Possibly there is some overlap in the
problems.


Thought about this, too. The main difference is that it is currently not 
possible to attach ' and , to q, whereas this has to be considered for 
\parallelMusic input - although it'd make sense to have this feature 
also for q in the long term. The current patch, to my understanding, 
does not allow such an attachment, since it hardwires the octave of the 
repeated chord.



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

Re: severe chord repetition problem

[Alexander Kobel]

Nicolas Sceaux wrote:

I was also thinking about that:
Should the chord repetition function be enabled by default, or should
the interested user write e.g. \include "chord-repetititon-init.ly" ?

The call to a memorization function for every chords does not look like
a good idea wrt performances.


I don't know how much overhead that means. My intuition says it's not 
that bad, since it does not at all affect the positioning and layout, 
which AFAIK takes the lion's share of LilyPond's runtime. But it's 
really just intuition...


I suppose when this shortcut is polished, it will become part of the 
basic syntax in no time, so it should be as easily accessible as 
possible. That's a different thing than, e.g., the #'keep-inside-line 
property of NonMusicalPaperColumn, since it affects whether a file will 
compile at all, not just how it looks like.
If we allow the user to override the semantics of q, we could as well 
forbid it's use before "booting" it up, though - it's very similar to 
the choice of input note names. A sensible default could also be the 
"don't copy anything and throw an error on use"-policy.


In any case, I'd rather not suggest an \include "..." syntax, 
considering the recent discussion about \include "language.ly" and the 
problem w.r.t. jail/safe mode.



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

Re: severe chord repetition problem

[Alexander Kobel]

David Kastrup wrote:

Actually, if q stands for "last _chord_" rather than "last note event",
then removing octave indicators is not sufficient since intervening
notes might have shifted the meaning.


Correct, that's the remaining drawback from the 
notes-chord-memorization; otherwise, this one perfectly fits /my/ usual 
needs.




But let it be clear: if LilyPond changes, it is no problem for me to
adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have
Frescobaldi support it.


If the meaning is defined well enough.


I tend to use very simple tools - Emacs that is, in this case, without 
much sophisticated input shortcuts (like lyqi) - so I could not image 
where the problem might be to allow exchanging the memorization 
function, as long as the input is parseable. As most not-too-experienced 
programmers I tend to be overly self-confident, and say "I'm gonna 
understand this if it's written there". Even when I'm going to read 
files, especially since I agree with Nicolas in:

On the other hand... which ratio of users might ever change the behavior
of chord repetition memorization?  I don't really think that readability
might suffer, as long as the default is the most convenient.
For instance, users can also completely change the note names [...]

And such a change should catch my eye.

But when it comes to editor support, things change. (In particular: a 
feature I'm desperately missing with my primitive input methods is 
actually already featured by other editors, so there might not be the 
need for it that I assume.)
Wilbert changed my opinions here - now, it looks like Nicolas' first 
idea of copying everything (well, perhaps everything but rests) may be 
what's actually needed more often. And it looks both easier maintainable 
and more robust than the notes-chord-memorization (see above.)



You (especially David i.e., but also Nicolas and Wilbert) certainly 
proved a clearer mind on such issues than me, and I agree with your 
concerns.
Still, since I'm happy to see that notes-chord-memorization gives me a 
feature I've been subconsciously craving for, and I'd be sad if it's 
removed again:
Is it okay to have an exchangable policy as long as it is very 
"low-level", i.e. there are no commands inviting to write them every two 
lines, but only something like the current syntax to replace the 
repetition-memorization-function? Is it reasonable to have only one of 
those methods officially supported and recommended, the other 
deprecated, yet available? (Assuming it's not as prominently advertized 
as \parallelMusic, of course.)



Cheers,
Alexander


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

Re: bug rating

[Alexander Kobel]

Werner LEMBERG wrote:

Wouldn't it be
helpful if I could check the priority flag of the bugs to find
something I should work on more urgently than other things?  For
example, the Savannah bugzilla allows users to `rate' bugs.  The
higher the score, the more people would like to have this bug fixed.


That's actually possible, although not very prominently advertized. 
(Well, in fact it could be worse.  Once you open a specific bug, you can 
request these "notifications" with several links.)
It is a "vote [aka star, aka subscribe] for this bug" feature (first 
column in the bug list, if you're logged in), and you can show and sort 
by the "Stars" count column with "..." on the upper right.


http://code.google.com/p/lilypond/issues/list?can=2&q=&sort=-stars&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars

It's not too exciting, though, for now:  Out of 336 bugs, only 18 have a 
voting count of > 3, with maximum 7, and about 50 have 3.  And I suppose 
one vote is automatically assigned to the one who opened the bug.



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

Re: Behaviour of chord repetition in \relative mode

[Alexander Kobel]

Werner LEMBERG wrote:

Hmm.  I won't mind if `q' is able to repeat a single note too, for the
sake of consistency.  Nicolas, would this be difficult to implement?


I don't think so - that's what Nicolas had in mind (and implemented) 
first.  I suppose I'm the one who made him thinking about the other 
variant, since I took "chord" not as the Event structure, but actually 
as a chord consisting of different notes, which seems useful in piano 
music.  In the meantime, I changed my mind a bit, considering the 
(valid) concerns from David and Wilbert:  the repetition of all events 
(but, perhaps, skips and rests) seems to be easier to define 
consistently, and the lack thereof might not justify irritations about 
the semantics of the input.  (E.g. in the case of this relative mode 
problem.)


Well, since the code basically seems to be there in both variants, and 
both of them are useful:  (and I expect David to come after me, but 
that's what I want since he proves a far better understanding of 
meaningful semantical conventions...)
Is it reasonable to use _both_ approaches, with shortcuts, say, q 
(everything repeated, including pitched rests, e.g.) and Q (only 
"chords" with several notes repeated), but not to offer the exchange of 
the memorization functions for those?



Cheers,
Alexander


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

Re: LyricExtender suicide fix

[Alexander Kobel]

On 2017-06-14 12:07 PM, Kieren MacMillan wrote:

Hello all,

The attached file includes a hack/fix I sponsored a couple of years ago.

Any thoughts/discussion towards putting this in the codebase would be 
appreciated. Happy to shepherd it myself, if it's just a matter of adding this 
code somewhere [not in C++] and submitting a patch.


Hi Kieren,

without looking at your snippet any closer (don't have Lily available 
right here, right now): please see


https://sourceforge.net/p/testlilyissues/issues/4509/
https://codereview.appspot.com/313240043

This aims to be a full-stop solution to extender handling that most 
probably offers a superset of your proposal, thanks to Knut's hard work. 
Unfortunately, while the code is working, there are implications w.r.t. 
long-term maintainability of the feature and impact to clean backend 
design. David K. has (very valid) concerns there, and has it on his 
todo-list - but as you know, the time he can and should devote is fairly 
limited these days.


For a very easy-to-use, no-compile-time-patches-needed workaround that 
still offers plenty of automation and functionality, see the 
autoextenders.ily from

  http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00536.html
(I hope I pointed you to the last version).


HTH,
Alex

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

Re: Please test gub

[Alexander Kobel]

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python -> python3 
is the default on Arch). I placed a symlink to python -> python2 in a 
high-priority $PATH as a workaround, but it might be a good idea to 
replace the shebang line by ".../env python2" for scripts which are not 
Python3-compatible.



Apart from that minor buzz, `make lilypond` does a good chunk of work, 
but fails building tools::guile; log attached.


FWIW, the gcc7 and gcc7-libs packages from the upstream repo (7.4.1) are 
installed (as well as the up-to-date gcc and gcc-libs 8.2.1), as well as 
all build and runtime dependencies for Lilypond on this architecture. At 
least, I successfully built 2.19.something from Git clones on this machine.
As far as I can remember, such a "standalone arch-specific" build of 
Lilypond doesn't compile guile, but relies on the guile1.8 package from 
the repos (the package maintainers don't seem to require any special 
precautions for building it, as can be seen in the packaging script at 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/guile1.8).
Notable difference here: GUB tries to work with Guile 1.8.7, upstream is 
at 1.8.8.



The only other part of the log that caught my eye:

building package: linux-x86::cross/gcc-core
 *** [...]
 *** Stage: pkg_install (cross/gcc-core, linux-x86)

building package: linux-x86::glibc-core
 *** [...]
 *** Stage: pkg_install (glibc-core, linux-x86)

building package: linux-x86::cross/gcc
 *** [...]
 *** Stage: pkg_install (cross/gcc, linux-x86)
  cross/gcc-core conflicts with cross/gcc-doc
removing cross/gcc-core


Not sure whether that's intended; is gcc-core just required to build gcc 
and supposed to be replaced after that?



Cheers,
Alex


On 28.01.19 13:53, Knut Petersen wrote:

Hi everybody!

I created a branch in my gub repository  that contains 
https://github.com/gperciva plus pull requests 53-60. Therefore it is 
pretty easy to test if that version of gub succeeds to build current 
lilypond master on your machine.


All you need to do is to execute the following commands:

    git clone https://github.com/knupero/gub.git -b DevelHead
    cd gub
    mkdir regtests
    cd regtests
    wget 
http://lilypond.org/downloads/binaries/test-output/lilypond-2.19.82-1.test-output.tar.bz2 


    touch ignore
    cd ..
    time make lilypond

Even on a fast computer 'make lilypond' will take some hours to complete.

If downloading of a source archive fails because of some network problem 
restart 'make lilypond'.


You'll need some free disk space ... about 20 GB is a minimum.

Please report success / fails with os / version / cpu info.

Knut

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


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test new lilypond installers

[Alexander Kobel]

Hi,

On 29.01.19 10:19, Knut Petersen wrote:
Urs Liska provides installers for branch master of lilypond, generated 
by an updated version of our build system GUB:

[...]
    lilypond-2.21.0-1.linux-64.sh
    lilypond-2.21.0-1.linux-x86.sh


Work like a charm on Arch Linux.


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

strace according to Knut's instructions is attached.

On 31.01.19 12:54, Werner LEMBERG wrote:



Apart from that minor buzz, `make lilypond` does a good chunk of work,
but fails building tools::guile; log attached.


I see. libtools segfauls.



../libtool: line 950: 23645 Segmentation fault  (core dumped)
ar cru .libs/libguile.a [...]


This is probably the same bug I've encountered on my openSUSE box.
Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so'
and replace it with the gcc variant `liblto_plugin.so'.  On my system
I had to do

   cd /usr/lib/bfd-plugins
   ln -s /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so .


Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.



FWIW:

# pacman -Qo /usr/lib/bfd-plugins/{LLVMgold.so,liblto_plugin.so}
/usr/lib/bfd-plugins/LLVMgold.so is owned by llvm-libs 7.0.1-2
/usr/lib/bfd-plugins/liblto_plugin.so is owned by gcc 8.2.1+20181127-1

So probably deinstalling llvm-libs (and clang, and some other packages 
that depend on it) might help... :-/


BTW, since gcc7 was mentioned couple of times in this thread:
/usr/lib/bfd-plugins/liblto_plugin.so points to 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/liblto_plugin.so, but I also have 
the gcc7-libs variant under 
/usr/lib/gcc/x86_64-pc-linux-gnu/7.4.1/liblto_plugin.so; but the build 
succeeded with gcc8's liblto_plugin.so, so I did not test that.



I don't quite get why (IIUC, which I might not) gub apparently builds 
gcc, but then seems to use the system-wide gcc down the road?



Cheers,
Alex


TP.21085.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 31.01.19 15:21, David Kastrup wrote:

Knut Petersen  writes:


On 31.01.19 08:43, Alexander Kobel wrote:

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python ->
python3 is the default on Arch).


I don't think that matches Python's own recommendation.  Has this
changed?


Kind of, yes, but then again, no, not really, it turns out. Lucky 
buzzwords for Google gave me PEP 394:

  https://www.python.org/dev/peps/pep-0394/

Relevant is the abstract, which in fact mentions that Arch, 
specifically, switched "early", broke the former practice (and, 
apparently, implicit and unwritten recommendation) and thus raised the 
discussion that led to PEP 394. It also says that "for the time being, 
all distributions should ensure that python, if installed, refers to the 
same target as python2, unless [...]".


*Also* relevant *now*, however, are the following point(s) from the 
recommendation:


"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."


and

"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."



I second the recommendation: as a happy year-long Archer, python 
shebangs are, by far, the number 1 of annoyances I encounter regularly. 
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.
On the other hand, I still occasionally use systems with Python2 <2.7 
(strictly less than). Hence, I'd refrain from specifying a minor version 
if it can be avoided. AFAIK, 2.8 is promised to never appear, so it 
shouldn't matter for 2.x. And I don't have 3.y for y < 7 available on my 
system; yet, 3.3 scripts run perfectly albeit the author might not have 
thought about that version when writing the script.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Addendum:

On 31.01.19 15:39, Alexander Kobel wrote:
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.


That is to say: I've yet to encounter a system where python points to 
python2.x, but at the same time there's no python2 -> python2.x 
symlink/hardlink/anylink/copy/wrapper. So I doubt that adding the "2" 
will cause any grief.




smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 31.01.19 13:25, Alexander Kobel wrote:

Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.


The build went on cleanly until poppler 0.49, which apparently is clever 
enough to figure out that it can't deal with my openjpeg installation ...


checking for LIBOPENJPEG... no
checking for opj_cio_open in -lopenjpeg... yes
checking openjpeg.h usability... no
checking openjpeg.h presence... no
checking for openjpeg.h... no

... but nevertheless insists on using it ...

Building poppler with support for:
  [...]
  use libopenjpeg: yes
  with openjpeg1
  [...]

... and, to no surprise, fails:

/home/akobel/gub/gub/target/tools/src/poppler-0.49.0/poppler/JPEG2000Stream.cc:20:10: 
fatal error: openjpeg.h: No such

 file or directory
 #include 
  ^~~~
compilation terminated.


FWIW, both openjpeg 1 and 2 are installed system-wide:

extra/openjpeg2 2.3.0-3 [installed]
An open source JPEG 2000 codec, version 2.3.0
extra/openjpeg 1.5.2-2 [installed]
An open source JPEG 2000 codec

and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend 
from source, with a simple cmake + make.



Perhaps it's wise to disable openjpeg entirely for poppler within GUB? 
Note that, despite the name, openjpeg is only a concern for JPEG2000; 
plain old JPEG is supported by libjpeg. (BTW, can we actually add images 
in Lily?)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 31.01.19 16:15, Karlin High wrote:

On 1/31/2019 9:04 AM, Alexander Kobel wrote:

BTW, can we actually add images in Lily?


Encapsulated PostScript images are fair game with \epsfile

<http://lilypond.org/doc/v2.19/Documentation/notation/graphic.en.html>

I know I used that once, but I forget which program I used to make the 
EPS file containing the image. Perhaps it was GIMP.


Ah, of course. There's jpeg2ps (from CTAN) which IIRC wraps JPEG without 
recompression to ps or eps files; for anything else, I'd probably go for 
pdfjam or img2pdf, followed by pdftops -eps, or just ImageMagick's (or 
GraphicsMagick's) convert.
GIMP can do it, too, but I doubt you can specify the compression 
algorithm (in particular, choose between lossless and lossy, the latter 
possibly without recompression).


But in fact I'm fairly happy to leave PostScript behind the scenes, only 
touch PDF, and not to worry too much when buying printers... ;-)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to install 
and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


% ls -1 /usr/include/openjpeg-*/*
/usr/include/openjpeg-1.5/openjpeg.h
/usr/include/openjpeg-2.3/openjpeg.h
/usr/include/openjpeg-2.3/opj_config.h
/usr/include/openjpeg-2.3/opj_stdint.h

% pkg-config --cflags --libs libopenjpeg 


-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjpeg1
-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjp2
-I/usr/include/openjpeg-2.3 -lopenjp2


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:09, Alexander Kobel wrote:

Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to 
install and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


Moreover, checking with poppler 0.49 as used in GUB, and loosely 
following the package build script for 0.49 from



https://git.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/poppler&id=1626dc8989ffc95eab611e4bd47d54f9b0fcfde0

(nothing too fancy in Arch packaging, yay!), the build succeeds after

  ./configure <--enable-unrelated-stuff> --enable-libopenjpeg=openjpeg1
  make

Note the absence of any paths, flags, etc. - everything is detected 
automagically:


Building poppler with support for:
  font configuration:  fontconfig
  splash output:   yes
  cairo output:yes
  qt4 wrapper: yes
  qt5 wrapper: yes
  glib wrapper:yes
introspection: yes
  cpp wrapper: yes
  use gtk-doc: no
  use libjpeg: yes
  use libpng:  yes
  use libtiff: yes
  use zlib compress:   yes
  use zlib uncompress: no
  use nss: yes
  use libcurl: no
  use libopenjpeg: yes
  with openjpeg1
  use cms: yes
  with lcms2
  command line utils:  yes


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:28, Knut Petersen wrote:
I wonder if we really need libopenjpeg ...  Yes, we need jpeg ... but  
we also link against our own libjpeg, and we talk about tools::poppler.


Note: libopenjpeg is (misnomed and) only required for JPEG 2000. 
Traditional JPEG is taken care of by libjpeg, which doesn't cause problems.



You could try to build with:

commit 751ac35d67764c9be22a887ad513b819d8ed101d (HEAD -> newStateOfArt)
[...]


Almost.

diff --git a/gub/specs/poppler.py b/gub/specs/poppler.py
index d8381f68..c8ec7063 100644
--- a/gub/specs/poppler.py
+++ b/gub/specs/poppler.py
@@ -11,8 +11,9 @@ class Poppler (target.AutoBuild):
 'libxml2-devel',
 ]
 configure_flags = (target.AutoBuild.configure_flags
-+ ' --disable-poppler-qt'
++ ' --disable-libopenjpeg'
 + ' --disable-poppler-qt4'
++ ' --disable-poppler-qt5'
 + ' --enable-xpdf-headers'
 + ' --disable-gtk-test')
 # FIXME: poppler, librsvg, cairo, gtk dependencies?
@@ -43,7 +44,8 @@ class Poppler__tools (tools.AutoBuild, Poppler):
 'libxml2',
 ]
 configure_flags = (tools.AutoBuild.configure_flags
-   + ' --disable-poppler-qt'
+   + ' --disable-libopenjpeg'
+ ' --disable-poppler-qt4'
+   + ' --disable-poppler-qt5'
+ ' --enable-xpdf-headers'
+ ' --disable-gtk-test')

did the job.

Note the 'lib' in ' --disable-libopenjpeg', and that I added it to 
Poppler__tools as well (just in case).
Also, '--disable-poppler-qt' is reportedly unknown, and should end with 
a '5' instead.

Finally, some solace from configure:

"Warning: Using libopenjpeg is recommended. The internal JPX decoder is 
unmaintained."


Which probably means that there's no loss in functionality, as the 
decoder at least used to work.



GUB-bing further down the road now...


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt -lm 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'

collect2: error: ld returned 1 exit status


Cheers,
Alex


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 02.02.19 10:27, Knut Petersen wrote:

On 01.02.19 15:06, Alexander Kobel wrote:

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt 
-lm /home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status 


The argumens given are ok. As usual

mkdir -p STRACE
strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile

will help to identify the problem.


hm, that gives appx. 2 GB of traces, and I'm not sure which process' 
trace I should look at. Nothing segfaults, so I don't get a PID hint as 
for the previous problem.


Appx. 380 MB worth of traces contain the buzzwords out_of_memory; those 
compress to 4.6 MB, so I could send them off-list?



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 05.02.19 08:40, Knut Petersen wrote:

On 04.02.19 15:29, Alexander Kobel wrote:

Remote debugging... Perfectly correct, here you are.


Thanks.

The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.


Could you please execute

ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2`

and mail me the result?


Sure, that'd be

lrwxrwxrwx 1 akobel akobel 11 31. Jan 17:32 
/home/akobel/gub/gub/target/linux-64/root/lib64/ld-linux-x86-64.so.2 -> 
ld-2.3.6.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib64/ld-linux-x86-64.so.2 
-> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib64/ld-linux-x86-64.so.2 -> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib/ld-linux-x86-64.so.2 -> ld-2.28.so


and /usr/lib/ld-2.28.so is part of the glibc package.

In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 05.02.19 09:20, Knut Petersen wrote:

Hi Alexander!


In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Ok, that's an important difference to other linux systems:

Could it be that

bin/gub --fresh darwin-ppc::guile darwin-x86::guile
freebsd-64::guile freebsd-x86::guile linux-ppc::guile mingw::guile
tools::guile

succeeds


It does.


and that

bin/gub --fresh linux-x86::guile
bin/gub --fresh linux-64::guile

both fail?


They do.


I think (hope) that

bin/gub --fresh darwin-ppc::lilypond darwin-x86::lilypond
freebsd-64::lilypond freebsd-x86::lilypond linux-ppc::lilypond
mingw::lilypond

should also succeed in that case ...


Perfectly correct, your expectations are met.


HTH,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi Knut,

On 06.02.19 13:17, Knut Petersen wrote:

Hi Alexander!

Perfectly correct, your expectations are met. 


I hope that story of success continues ;-)


it does. :-)


Would you be so kind to test the attached patch?


Sure.

  bin/gub --fresh linux-x86::lilypond linux-64::lilypond

succeeded with your patch.

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
  (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

and

- the need to make sure that `python` calls a python2 interpreter.


For the latter, the course of action is clear (but sorry, I didn't find 
the time to investigate yet), and AFAIU, the problem is entirely 
Arch-specific at the current point in time.
So the former issue apparently is more pressing, as it also emerged on 
Werner's OpenSUSE setup.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 06.02.19 23:31, Knut Petersen wrote:

On 06.02.19 15:09, Werner LEMBERG wrote:

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
   (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

This is definitely *not* a gub issue.  It's strange that only the
compilation of guile is affected by the problem, but I consider this a
pure coincidence.  IOW, this should be added to the gub documentation,
as a special preparation step for some LLVM/binutils combinations.


I agree.


I have no idea regarding that issue and trust your assessment.


- the need to make sure that `python` calls a python2 interpreter.

No idea how this could be solved elegantly.  I guess it can't, so we
have again something to document...

Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?


Not sure, but according to PEP 394, they "should". The PEP dates back to 
2011, so I'd assume that all systems have a corresponding alias by now, 
and only the default `python` is different.


(IIUC, Gentoo follows Arch's example, see the bottom of 
https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?)


Of course, Arch obviously disregards the PEP's first recommendation 
(python should point to python2), so it's perfectly fair to consider 
this entirely Arch's / Gentoo's fault. However, one of the good reasons 
Archers state to follow the explicit python2 / python3 spelling (and 
having python3 as default) is that python2 will see it's end of 
maintenance at the end of this year, and they plan to stop distributing 
python2 as a first-class citizen in the core repositories more or less 
immediately (it will still be easily available via community repos 
though). So following all of the PEP, you'd end up with a system that 
has python3, but neither python nor python2. Perhaps that's harsh, but 
it's a reasonable decision given that official support ends.


In the rationale, the PEP says

"As some of the former distributions did not provide a python2 command 
by default, there was previously no way for Python 2 code (or any code 
that invokes the Python 2 interpreter directly rather than via 
sys.executable) to reliably run on all Unix-like systems without 
modification, as the python command would invoke the wrong interpreter 
version on some systems, and the python2 command would fail completely 
on others."


so this might not be *entirely* smooth.
https://mail.python.org/pipermail/python-dev/2011-March/108491.html 
mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP 
these days.



I think we also would need to change some lilypond files ...


FWIW, this is what is done in the Arch packaging process:

  for file in $(find . -name '*.py' -print); do
sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file
sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file
  done

  sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags 
guile-1.8`"|' configure
  sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs 
guile-1.8`"|' configure


plus a patch regarding fontsizes; not sure what this is about:

https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypond


It might be worth testing whether applying this patch upstream breaks 
anything for someone else; but of course, that's from an Arch user's 
perspective...



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 08.02.19 04:51, Carl Sorensen wrote:

On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" 
 wrote:

 
 >> - the need to make sure that `python` calls a python2 interpreter.

 > No idea how this could be solved elegantly.  I guess it can't, so we
 > have again something to document...
 >
 Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?
 
OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only python.


At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.



Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 08.02.19 14:12, Knut Petersen wrote:

Hi everybody!
 Use /usr/bin/env python2? Does every python 2.x installation 
really contain a python2 executable?
 OSX 10.12 Sierra has python 2.7 but does not have a python2 
executable.  Only python.


At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.



Again, something to document ;-)

Gub itself does not provide a python2.

I think with the attached test-patch on top of the patch I already sent 
to you 'make lilypond' (not only bin/gub xxx::lilypond) should succeed 
after you put the newly created wrapper directory in front of PATH.


I see; this wrapper directory is more convenient than asking the user to 
provide a dir with only the symlinks python{,-config} -> 
/some/where/python2{,-config} on his own and add it to the PATH.


But isn't it against the purpose that now the shebangs of bin/gub/* read

#! /usr/bin/env python2

? I think you meant: add the wrapper directory PATH such that we *don't* 
have to replace python by python2 in those shebangs.


-TARGET_PYTHON=/usr/bin/python
+TARGET_PYTHON=/usr/bin/env python

in gub/specs/lilypond{,-doc}.py (rather than python2) is necessary and 
(almost) correct in the patch, though.



Cherry-picking only those changes, everything seems to start fine.


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Re: Centered Poet rolling of the paper 2.12.2 and 2.13.1

[Alexander Kobel]

Alexander Kobel wrote:

Wilbert Berendsen wrote:

Hi,

this code:

\header {
  poet = \markup \center-column {
\line { poet with Long Name }
\small (1800-1900)
  }
  composer = \markup \center-column {
\line { composer with Long Name }
\small (1800-1900)
  }
}

{ c' }

results in falling the poet off the paper. It looks like the column is 
centered on the margin.


Confirmed.  Looks like a strange artifact of the \fill-line markup 
(containing both poet and composer) w.r.t. a negative first X-extent 
entry of a \center-column, IIUC.


The attached patch for fill-line (scm/define-markup-commands.scm) should 
do the expected thing.
fill-line currently only considers the extents of the stencils, not 
their position relative to the X-origin; with the patch, they are 
shifted according to the first stencil argument.


Sorry in advance for non-proper indentation, a probably non-proper patch 
format, and not having in on Rietveld or something like this, but to be 
honest, I don't want to take the time to bother with git's functionality 
and a coding account setup right now.



Cheers,
Alexander
--- scm/define-markup-commands.scm.new	2010-01-11 16:47:46.0 +0100
+++ scm/define-markup-commands.scm	2010-01-11 16:43:31.0 +0100
@@ -850,11 +850,8 @@
 
 (if (null? (remove ly:stencil-empty? orig-stencils))
 	empty-stencil
-  (ly:stencil-translate-axis
-  	 (stack-stencils-padding-list X
-  RIGHT fill-space-normal line-stencils)
- (- (car (ly:stencil-extent (car stencils) X)))
- X
+	(stack-stencils-padding-list X
+ RIGHT fill-space-normal line-stencils
 
 (define-markup-command (line layout props args)
   (markup-list?)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Where does paper-height come from?

[Alexander Kobel]

b...@shingarov.com wrote:

Hi all,

I am playing with the vertical spacing algorithms, and am very
surprised by the behavior of "page-height".

Let's say for example that I set my paper to A6.  This, by ISO216, is
148mm high.
when calc-printable-height applies (ly:output-def-lookup layout
'paper-height), it ends up in Output_def::lookup_variable() and
ultimately in ly_module_lookup().  This does not return 148, but
84.22!!! [...]


Hi.

Are you aware of the units?  I'm not at all, and neither did have a look 
in the code, but 84.22 is suspiciously near to 148 / (7/4), where the 
parenthesized term is 7 mm per 4 staff units, which is (not considering 
rounding errors) the default global staff size.
More accurate: I think LilyPond uses a pt size of 1/72.27 in, so a staff 
(with four staff units) has height 20*25.4/72.27 mm = 7.0292 mm, and 148 
/ (7.0292 / 4) = 84.22 to a precision of three digits.


So I'm quite sure that the output of output-def-lookup is in global 
staff size units, not in mm, and a conversion happening somewhere hidden 
in the code, and not specifically for page-height.



HTH,
Alexander


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

Re: (bug?) irregular lyrics distance in 2.13.10

[Alexander Kobel]

Joe Neeman wrote:

Am Mittwoch, 13. Januar 2010 17:02:18 schrieb David Kastrup:
That's basically the approach taken by Joe for spacing staves: Place the 
center lines minimum-spacing apart, except if the skylines would (almost?) 
overlap (including a padding). In the latter case add space until no overlap 
occurs. Of course, when stretching is enabled, things are a little more 
involved.


I just don't know how Joe aligns lyrics, in particular, whether only the 
extents are used or whether the baseline is used like the center line for 
staves.


The minimum-distances are measured from the "origin" of the line. That
is, if the extent of a staff is (-5 . 5) then we measure from the
center. Thus, we just need to make sure that the "origin" of a Lyrics
line is its baseline (I can't check this right now). Then it should be
sufficient just to set minimum-distance to the desired line-skip.


This would be sufficient for the inter-lyrics spacing, but we should 
take care that it does not influence the staff-to-lyrics spacing for the 
bad.  Or is this one determined by the actual extent of the glyphs?



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

Re: (bug?) irregular lyrics distance in 2.13.10

[Alexander Kobel]

Reinhold Kainhofer wrote:

Here's a file with all different spacings from 2.0 to 4.0...

Looking at some scores with two lyrics lines (mostly oratorios with two 
different language), I would tend to choose 2.8 or 3.0.


+1.


There are some other issues I notice with the layout:

1) For my taste the piece names are too close to the previous score (and too 
far away from the one they are attached to).


+1.

2) The distance between the last lyrics line to the next staff is not constant 
throughout the page!


It's not a bug, it's a feature.  At least I think so - it's because of 
the default 'staff-affinity to the top staff.  See the attached file 
with 'staff-affinity = #CENTER.  You won't change the 'minimum-distance 
for each system in a real-world example, so IMHO it'd be a very minor 
problem, anyway.


Still, the lyrics have a larger subjective whitespace distance to the 
staff below than the one above, probably due to the spacing based on the 
baseline.
\version "2.13.11"
\pointAndClickOff

\paper { ragged-last-bottom = ##f }

lyr = \lyricmode { 
  These are just some ran -- dom __ _ _ ly -- rics, these are just some ran -- _ _ dom ly -- rics!
}

cs = \new ChoirStaff <<
\new Staff { \new Voice ="1" \relative c'' { \repeat unfold 5 { c4 c c c } } }
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto "1" \lyr
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto "1" \lyr
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto "1" \lyr
\new Staff { \new Voice ="2" \relative c' {\clef "bass" \repeat unfold 5 { c2 c } } }
\new Lyrics \lyricsto "2" \lyr
\new Lyrics \lyricsto "2" \lyr
>> 

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.0
}
  }
  \header { piece = "Lyrics minimum-distance = 2.0" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.25
}
  }
  \header { piece = "Lyrics minimum-distance = 2.25" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.5
}
  }
  \header { piece = "Lyrics minimum-distance = 2.5" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.8
}
  }
  \header { piece = "Lyrics minimum-distance = 2.8" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.0
}
  }
  \header { piece = "Lyrics minimum-distance = 3.0" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.2
}
  }
  \header { piece = "Lyrics minimum-distance = 3.2" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.5
}
  }
  \header { piece = "Lyrics minimum-distance = 3.5" }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.7
}
  }
  \header { piece = "Lyrics minimum-distance = 3.7" }
}



\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #4.0
}
  }
  \header { piece = "Lyrics minimum-distance = 4.0" }
}



lyrics_spacing.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

I don't know. The staff lines should end a little bit earlier, see

http://lilypond.googlecode.com/issues/attachment?aid=-394070284723943851&name=segno-end.png&inline=1 

I don't think it is a good idea to let the segno sign reach into the 
margin, so

the staff lines have to end before reaching the right margin.


Hi, Marc,

thanks for dealing with this.


I found another example (the one in the bugtracker comes from me, too), 
from Bosworth & Co. as well, but this time without bar lines spanned 
across the staves.  (Anyone seen a source where this glyph is used by 
another publisher?)
Here, the double bar lines are not drawn through the whole staff, but 
the staff lines actually extend across the segno.


I'd prefer drawn-through bar lines (which seems easier to implement, 
anyway), but I'd expect the segno sign to reach into the margin.  (The 
same as with, say, a fermata centered over the final bar line.)
If (as shown here) the system is actually ragged-right (or stopped after 
the segno), it doesn't harm too much, anyway, since the Dal segno text 
comes after it with some padding.  However in case the segno ends a 
flush-right system, it occurs to me that a visually shorter staff 
(especially with SpanBar lines) is worse than the segno extending into 
the margin.


Just my two pennies...


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

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Trevor Daniels schrieb:

It is easy
for a user to move the sign to the end of the staff lines with

   \once \override Score.BarLine #'extra-offset = #'(1 . 0)
   \once \override Score.SpanBar #'extra-offset = #'(1 . 0)

if this was really wanted, although this would admittedly push
it into the right margin.


Indeed.  It's not quite exactly '(1 . 0), but just slightly less, but 
this is nearly not noticeable.



Would it make sense to provide another varsegno symbol which looks exactly as
the one I have drawn, but has no positive witdh (to the right of the center)?


This sounds more elegant than the tweak above, but I'm not sure if this 
alone is worth the effort of an additional symbol.



Another idea: Is it possible to have a double bar line at the end of a 
line, and the segno bar line at the beginning of the next?  What about 
".S" doing this, as opposed to "S", or have an additional "||S" and "S||"?



Cheers,
Alexander


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

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Alexander Kobel schrieb:

Marc Hohl wrote:

Trevor Daniels schrieb:

It is easy
for a user to move the sign to the end of the staff lines with

   \once \override Score.BarLine #'extra-offset = #'(1 . 0)
   \once \override Score.SpanBar #'extra-offset = #'(1 . 0)
[...]
Would it make sense to provide another varsegno symbol which looks 
exactly as
the one I have drawn, but has no positive witdh (to the right of the 
center)?


This sounds more elegant than the tweak above, but I'm not sure if 
this alone is worth the effort of an additional symbol.
Me, too. It still feels somewhat clumsy to do it in this way, but on the 
other hand - if it looks alright,

one more sign in the font should not be a big problem.


I just noticed that the 'extra-offset won't influence the spacing of the 
notes before the bar line.  The better property to tweak should be the 
right-edge extra space, but this does not work if the line ends 
prematurely.  (See the attached example.)
Still, like Trevor I'm not sure why modifying the X-extent does not work 
- this should be the favourite option, theoretically equivalent to 
another glyph without positive width, right?


Another idea: Is it possible to have a double bar line at the end of a 
line, and the segno bar line at the beginning of the next?  What about 
".S" doing this, as opposed to "S", or have an additional "||S" and 
"S||"?


I must admit that I don't have lots of references for this symbol and 
its use. If this is a sensible
default, there is no problem in defining ".S" just doing what you 
proposed. Can you do some investigations?
As you posted the examples in the tracker, I think you are the most 
important source of informations here ;-)


I don't really know if I saw the "||-before-break, S-after-break" 
combination, but I think it makes sense to offer it since coda parts are 
often seperated by double bar lines when the "default" segno sign is 
above them.
I'll see what I can find in real examples.  I don't think I have 
anything more at my place, though, so I'll have to look through the 
repertoire of my choir.  (Again, I can't remember to have it seen in any 
non-Bosworth & Co. scores...)  I'll give you feedback ASAP.



Cheers,
Alexander


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

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Alexander Kobel schrieb:
I don't really know if I saw the "||-before-break, S-after-break" 
combination, but I think it makes sense to offer it since coda parts 
are often seperated by double bar lines when the "default" segno sign 
is above them.
I'll see what I can find in real examples.  I don't think I have 
anything more at my place, though, so I'll have to look through the 
repertoire of my choir.  (Again, I can't remember to have it seen in 
any non-Bosworth & Co. scores...)  I'll give you feedback ASAP.
Did you find anything? If not, tell me what you want to have as 
standard, and I will adapt my code.
I doesn't seem that there is an overwhelming interest in the varsegno - 
which doesn't bother me,
because *I* like the sign and will use it regularly as soon as it is 
released.  So we both, being called the

"varsegno group" should be able to decide what we want ;-)


Hi Marc, hi all,

and sorry for the delay.  As you certainly noticed, the weather was an 
experience the last days, and thus my choir did not have any rehearsals, 
so I had to wait for a look into our note repertoire.


I did not found too much.  Most parts have the plain "S" bar somewhere 
in between, but I found one combination of a segno and a "|:" bar line 
afterwards (once more Bosworth & Co.).  This one also has the double bar 
line drawn through the segno symbol, and there's about the width of a 
double bar line between "S" and "|:".  (It's a cheap old copy, not very 
legible, but I can provide you a scan if you want.)  Yes, this really 
makes sense if there are several stanzas (with volta repeats), and the 
first part of the last stanza switches to a coda.
I'm not sure how the double bar line would look in combination with a 
SpanBar, though - I'd guess it looks best if the SpanBar only affects 
the "|:", but not the "S" part.


So, what do I think is useful?  In the optimum, we should have the 
following combinations:


In-line:
- "S"
- ":|S" (repeated intro, e.g.)
- "S|:" (the case mentioned above)
- ":|S|:" (certainly unusual, but possible)

On a line break:
- "|S" ("|" end of line, "S" begin of line)
- "S|" ("S" only end of line)
- "||S" ("||" end of line, "S" begin of line)
- "S||" (vice-versa)
- basically the same options for repeats, i.e. ":|S", "S:|", "S|:", 
"|:S", ":|S|:", and perhaps even ":|S.|:", where the ":|S" is at the end 
of line, and only "|:" at begin of line.


"S" should be mapped to either "|S" or "||S" on line breaks - I'd prefer 
"||S", since this exactly fits my use of the traditional segno glyph so 
far, but that's just personal taste.
In general, I have a strong opinion against the "S" at the end of the 
first line in break situations, because the reader is forced to do an 
additional saccade, but I've seen several scores where the traditional 
segno sign is placed at the end of the line.  Anyway, it has to be 
offered, because things like \stopStaff followed by a "Dal segno al 
fine" have to be possible.


As for the X-extent, as I mentioned before, I'd prefer the segno 
slightly sticking out of the staff lines into the margin and having the 
"||" aligned with the right edge, but that's just personal taste - I 
could not find a print where "S" is used at the end of a line without a 
"D.S. al fine" text following, and for this both variants (staff lines 
drawn through the whole symbol, or just to the double bar line) can be 
found.
One more remark: I did not test your current implementation in 
combination with clef, key or time changes.  Is this an issue?  It'd be 
nice to have a key change printed between "S" and a "D.S. al fine" text 
to remind the reader of the different key in the repeated part.



Whoah.  I'm afraid that might be more than you hoped for?

Cheers,
Alexander


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

Re: bounties

[Alexander Kobel]

On 2010-05-19 17:00, Kieren MacMillan wrote:

Hi Graham,

There are also other sponsorship offers (by me, which I can confirm are still "open") 
which don't seem to be in the Google code "bounty" pile: [...]



Plus, I seem to recall at least two other people willing to chip in for the 
bounties on break-alignment with MetronomeMarks, and a real 
piano-with-centred-dynamics fix.
[Can't find the links right now.]


Yup, here I am for the piano-centered dynamics - same link, 50 EUR.  Not 
sure if there's anybody else, though.

And of course my offer still holds.

Oh, and of course I know that this amount "is extremely low given the 
work involved", as Graham stated, but ... well - it's better than 
nothing.  Even more so when Joe provides a perfect example, saying that 
"he's happy to accept bribes, but they won't drastically affect his TODO 
list priorities, just because his main constraint on Lilypond work is 
time rather than money."
AFAIK (and hope), none of you guys codes in Lily for his living, but at 
least there may be a free dinner sometimes to soothe the Significant 
Other...



Cheers,
Alexander

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

Re: bounties

[Alexander Kobel]

On 2010-05-19 19:08, Graham Percival wrote:

I mean, if something
would take you 20 hours, and somebody offers $10 and a piece of
bubble gum, it's not very encouraging.  If ten people offered the
same thing, it would add up, of course.


True.  And that's how we all like to see it, right?  Alas, the joy of 
idealism...



But I've heard from some
developers that taking a bounty isn't worth the trouble of setting
up a paypal account.


Depends on your usual day business, I guess, and whether you're paid 
what you're worth.  If not so, the 300 $ you mentioned is quite a bunch 
of money, too...



AFAIK (and hope), none of you guys codes in Lily for his living, but at
least there may be a free dinner sometimes to soothe the Significant
Other...

[...]
An alternative to donating it to the FSF (or whatever charity you
like) would be for the developer to offer a bounty on something
that affects *them* -- either something they want to use for their
own lilypond compositions, or something they want for their own
*development* work (like the source code indentation program or
new build system).


Of course that's entirely up to the developer of some patch.  I'd be 
fine with either option.



Cheers,
Alexander

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

Re: Bezier curves [was: Dependencies in Lilypond]

[Alexander Kobel]

On 2010-06-08 17:59, Carl Sorensen wrote:

P.S. If you have more stuff you want to do with Beziers, give me a shout.
I've taken Dr. Sederberg's class, so I'm somewhat aware of clever tricks
with splines.  That's where my bezier stuff came from earlier.


Whoever wants to do something serious with Bezier curves or splines 
(curves, surfaces, whatever), be sure to check out Gerald Farin's 
"Curves and Surfaces for CAGD (Computer Aided Geometry Design): A 
practical guide", Morgan Kaufmann Publishers.  It's to Bezier what Ross 
is to music engraving, I guess (though I didn't manage to get the latter 
in my hands yet).  A really amazing book, which should be available in 
every university library with an ounce of self-respect.



Cheers,
Alexander

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

PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

[Alexander Kobel]

See .

My fix tries to reintroduce the behaviour of 2.13.11 for the issue 
mentioned, before my patch to 
, but 
to keep the 2.13.12+ behaviour for more than two elements inside a 
fill-line.
Besides, I tried to tackle the issue I mentioned here: 
, which 
is that nested fill-lines used to shift their contents by some amount to 
the right.


I still think that fill-line is badly specified for single arguments, 
but I can't think of any better rationale for it as well.


For some reason, I don't seem to be able to build the regtests; so all 
this should be taken with care, I did not really check if it breaks 
anything.
And once again, please clean up the indentation.  The "real" sources 
just look like a complete mess in my Emacs configuration.  I did not try 
to understand this, but rather to guess my tabs and spaces to fit...



Cheers,
Alexander

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

Re: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

[Alexander Kobel]

On 2010-06-14 20:24, Neil Puttock wrote:

On 14 June 2010 15:34, Alexander Kobel  wrote:


Besides, I tried to tackle the issue I mentioned here:
<http://www.mail-archive.com/lilypond-u...@gnu.org/msg51242.html>, which is
that nested fill-lines used to shift their contents by some amount to the
right.


Heh, I was just about to post a fix for that myself
(http://code.google.com/p/lilypond/issues/detail?id=382), using a
slightly different approach: checking whether the text-width equals or
exceeds line-width.


I thought about that, too, when I first tried to do this several months 
ago.  Not sure why it didn't work out; probably it was just a < vs. <= 
issue.
On the other hand, I don't quite get why word-space = 1 is necessary. 
If there's no space left, the user has trouble anyway, and I don't see 
why an arbitrary minimum space should help.  And this should be the 
reason for the shift, IIUC.  Seems like an ugly hack to me, but probably 
there's some reason?


Another question: What does "mol" stand for in the markup definitions, 
e.g. in general-align in define-markup-commands.scm?



For some reason, I don't seem to be able to build the regtests; so all this
should be taken with care, I did not really check if it breaks anything.


It compiles fine without any breakages.


That's how far I could go.  I just can't get the regression tests, so I 
can't compare if it breaks desired output in other examples than mine.



And once again, please clean up the indentation.  The "real" sources just
look like a complete mess in my Emacs configuration.  I did not try to
understand this, but rather to guess my tabs and spaces to fit...


Doesn't C-M-\ indent a region for you automatically?


It does, but it also reindents the existing code in a completely 
different manner than what's currently there.



One thing your patch doesn't cover is Reinhold's problem with compound
time signature formatting (see
http://code.google.com/p/lilypond/issues/detail?id=732);


Okay; didn't check this.  Probably one can see it in some regression 
test, then...



I wonder
whether we should just add his suggestion for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably "normalize" all stacked stencils (read: 
right-column, too) in the same manner.  Which would make sense to me, 
since it's a consistent behaviour, but I suspect this to be incompatible 
with the current design.  And one might require to write \right-align 
\right-column to get the (current?) extent ((- width) . 0), which looks 
clumsy from the typical user's POV.



Cheers,
Alexander

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

fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

[Alexander Kobel]

[ Reordering the topics according to general interest. ]

On 2010-06-14 23:14, Neil Puttock wrote:

On 14 June 2010 21:47, Alexander Kobel  wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. If
there's no space left, the user has trouble anyway, and I don't see why an
arbitrary minimum space should help.  And this should be the reason for the
shift, IIUC.  Seems like an ugly hack to me, but probably there's some
reason?


I don't know why that's there; the default is set in
ly/paper-defaults-init.ly to 0.6.


Uh-oh, so that's another occurence of defaults set in different places 
to different values (in define-markup-commands.scm, and thus the NR, 
it's 1)...  I can hear David's screams... ;-)


Anybody knows if we can remove the minimum space?  IMHO, this will make 
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention 
a separate default for word-space, and the description of \fill-line 
says nothing about it's meaning.  Looks to me like it was copied from 
\line, and been forgotten afterwards.



I wonder whether we should just add his suggestion
[Reinhold: <http://code.google.com/p/lilypond/issues/detail?id=732>]
for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably "normalize" all stacked stencils (read:
right-column, too) in the same manner.  Which would make sense to me, since
it's a consistent behaviour, but I suspect this to be incompatible with the
current design.  And one might require to write \right-align \right-column
to get the (current?) extent ((- width) . 0), which looks clumsy from the
typical user's POV.


Hmm, I hadn't considered that, though I wonder if anybody uses \right-column.


Definitely, at least in the composer field (though it should not matter 
there, since this one gets nested in a fill-line anyway), but probably 
also for instrument names or a whole bunch of little tweaks and markups. 
 Googling on the LSR gives about 40 hits for center-column and 
right-column, and of course there's thousands of hits on the whole web. 
 It seems very hard to tell in advance how many of those will be 
affected by a change in the extent.




Some of the indentation in \fill-line is incorrect (e.g., for the
definition of fill-space), so you're probably improving it. :)


Ah, this might well be why it does not make too much sense to me right now.
So, usually the Emacs default is okay for Scheme code, too?  The CG only 
says that GNU style is used for C++, but nothing about Scheme.



Another question: What does "mol" stand for in the markup definitions [...]

It's short for "molecule" [...]


Ok, thanks.


Sorry, I meant the regression tests run fine (with `make check'); no
test snippets appear broken.


Perfect.  Thanks, too.


Cheers,
Alexander

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

Re: fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

[Alexander Kobel]

On 2010-06-15 00:28, Alexander Kobel wrote:

On 14 June 2010 21:47, Alexander Kobel wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. [...]


Anybody knows if we can remove the minimum space? IMHO, this will make
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention
a separate default for word-space, and the description of \fill-line
says nothing about it's meaning. Looks to me like it was copied from
\line, and been forgotten afterwards.


I updated the issue on Rietveld with a version of fill-line where 
word-space is completely ignored: <http://codereview.appspot.com/1689041>.


I think I know now how to properly compile and check the regression 
tests, and I can't spot anything that's broken by this change.  Comments?



Cheers,
Alexander

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

[Doc Patch] Re: (2.13.x) bottom-system-spacing

[Alexander Kobel]

Hi, dear developers & doc reviewers,

concerning the documentation of bottom-system-spacing discussed on -bug, 
I'd like to propose some additions/corrections to the docs.  All those 
deal with NR 4.1.2, "Page formatting".

<http://codereview.appspot.com/1710046>


Cheers,
Alexander


On 2010-06-18 17:02, Graham Percival wrote:

On Fri, Jun 18, 2010 at 3:42 PM, Alexander Kobel  wrote:

On 2010-06-18 16:02, Joe Neeman wrote:

For the same reason that between-system-spacing uses the center of the
staff and not the edge. The height of the footer can vary from page to
page and if we use it then the vertical spacing will not be consistent.


Okay, I see now.  Maybe this should be mentioned in the docs, then.


I don't have a clue what you're talking about, but it sounds like
something that falls under the "small doc additions" after looking at
"documentation suggestions":
http://lilypond.org/website/help-us.html


True.  Again, a hint in the docs, where foot-separation used to be, might be
useful.


Same here.


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

Re: "patch" for underline function

[Alexander Kobel]

On 2010-05-25 14:33, Kieren MacMillan wrote:

Hi all,

I want to have independent control of the thickness and offset of the
underline markup function -- unfortunately, they are currently linked
(i.e., the offset is a multiple of the thickness). [...]


[This mail is essentially copied from 
 to have it on 
-devel...]


@ Graham: W.r.t. 
, what's 
a non-developer supposed to do with his review?  Post on -devel? 
Comment in the issue description?  Both?  Neither?



Hi, Kieren,


LGTM, but I'm not allowed to push, too.  I'm just trying to follow 
Graham's beg for reviewers...


A minor correction:
(* -1 offset) can be simplified to (- offset) in the (let*) clause for y.

   (let* ((thick (* (ly:output-def-lookup layout 'line-thickness)  [...]
  (y (* -1 offset))   [...]


I like your default value for offset, since in normalsize text, the 
underline does not cross the descenders of the font.  But I wonder 
whether both offset (linearly) and thickness (<= linearly) should be 
scaled with font-size, for a consistent look e.g. in the 
((sub-)sub-)title fields?



Cheers,
Alexander

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

Re: "patch" for underline function

[Alexander Kobel]

On 2010-07-14 10:42, Graham Percival wrote:

On Wed, Jul 14, 2010 at 10:34:01AM +0200, Alexander Kobel wrote:

@ Graham: W.r.t.
<http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html>,
what's a non-developer supposed to do with his review?  Post on -devel?
Comment in the issue description?  Both?  Neither?


A post to -devel is fine.  If you have a lot of comments, it might
be nice to post on the codereview google website... but "merely"
sending an email to -devel is still incredibly helpful.


Once I recognized that it's not very hard to get the build setup running 
(on a Linux box, I mean), I immediately appreciated the benefits of 
Rietveld.  If the patch is there, it's of course the best option to 
comment there.
Kieren still lacks a git setup, though, and this very patch has only 
been mentioned on the -devel list and the bug tracker, so I guess it's a 
special case.  I can prepare a proper git patch and post it on Rietveld, 
but I'd rather do so once I have some comments about the font-size 
relation of this functionality.


Regarding your new entry in the tracker about how to comment:  Rietveld 
looks like the best option for reviews, but I dislike to force everybody 
to use it.  I'm not sure how many developers really can't prepare git 
diffs or submit to Rietveld, but I vaguely remember and respect David's 
concerns to open yet another account, especially with a possible data 
leech, and it requires an up-and-running git.
Since it requires write access to finally push the patch anyway, I 
propose discussions on -devel, and a link to the thread in the bug 
tracker for reference.  Once the patch LGTEveryone, preparing the git 
diff-style patch should not take long.  And it can be done by anybody, 
like me, with no need for real (LilyPond) programming experience.



Cheers,
Alexander

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

Re: "patch" for underline function

[Alexander Kobel]

On 2010-07-14 12:15, Graham Percival wrote:

On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote:

Regarding your new entry in the tracker about how to comment:  Rietveld
looks like the best option for reviews, but I dislike to force everybody
to use it.  I'm not sure how many developers really can't prepare git
diffs or submit to Rietveld,


Everybody developer can do this.  Lilybuntu makes it easy to have
git and compile stuff.


You're aware that Kieren reads this, too? :-)  Or does this run in the 
virtual box under MacOS now?



but I vaguely remember and respect David's
concerns to open yet another account, especially with a possible data
leech, and it requires an up-and-running git.


I'm not happy about requiring a gmail account, but since that's
necessary for the issue tracker as well, I think we just need to
bite the bullet and accept it.  :(


Uh, correct.  I completely forgot this. I never use my gmail account 
anyway, and the login's stored...


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

Re: "patch" for underline function

[Alexander Kobel]

On 2010-07-14 12:34, Graham Percival wrote:

On Wed, Jul 14, 2010 at 12:21:56PM +0200, Alexander Kobel wrote:

Or does this run in the virtual box under MacOS now?


Lilybuntu is a virtual machine.  It can be run in vmware or
virtualbox on top of linux, windows, or macos.  We've had two new
documentation writers using lilybuntu exclusively for the past 6
months, on a mixture of windows and osx machines.


Oh, that's good news.  I missed that; I didn't want to be sarcastic, but 
rather really didn't know about it.



Any other questions?


Nope, thanks. :-)


Cheers,
Alexander

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

Re: [PATCH] fix to issue 1116

[Alexander Kobel]

On 2010-07-30 21:51, Neil Puttock wrote:

On 30 July 2010 15:11, Mike Solomon  wrote:

This solution works for the minimal example given with the issue, and it
works in general if one accepts the assumption that there is no reason that
anything fed through stack-lines (in scm/stencil.scm) should have an X
extent whose left boundary is anything other than 0.  However, I
don'tunderstand lilypond well enough to know:

a) if this is a good assumption
b) if this assumption breaks something else.


You'll probably be interested in Alexander Kobel's patch for this
(http://codereview.appspot.com/1689041/show).


Hi, Mike and Neil,


I just had a quick glance at your mails, and as Neil recognized, I'm 
still waiting for a response on my latest patch to fix this issue.
I'm quite satisfied with the solution w.r.t. centering headers, but 
there's still room left for further investigation of fill-line, as I 
described in the comments to the patch Neil quoted.


Unfortunately, I most probably won't have any spare minute until Aug 09 
to care about this piece of code (there's a kind of festival taking 
place in my hometown which I help to manage), but feel free to discuss 
my code and possible extensions.  I'll have a look at it next week.



Cheers,
Alexander

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

Re: Odd messaage from 2.13.32

[Alexander Kobel]

On 2010-09-01 04:28, Mike Solomon wrote:

Hey all,
 Just got 2.13.32 running and got the following message:

warning: couldn't fit music on page: overflow is -0.00

I think it's good to get a warning message when there's spillover, but it
seems odd that an overflow of 0 would solicit a warning message.  Thoughts?


I think this might be due to an actual value just below zero, but not 
far enough to fit in the seven shown digits.  This warning comes from 
lily/page-layout-problem.cc, line 307-309:

  if (!spacer.fits ())
warning (_f ("couldn't fit music on page: overflow is %f",
 spacer.configuration_length(spacer.force()) - 
page_height_));


I suspect the warning procedure (macro?) just calls printf, which by 
default only shows the leading digits:

  printf ("Small number: %f\n", -0.01);
  printf ("Higher output precision: %.16f\n", -0.01);
gives
  Small number: -0.00
  Higher output precision: -0.0100
on my system.


HTH,
Alexander

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

Re: -dinclude-settings=INCLUDEFILE.ly

[Alexander Kobel]

On 2010-09-04 00:35, Trevor Daniels wrote:

Am Freitag, 3. September 2010, um 22:49:50 schrieb -Eluze:

my command was: lilypond -V -dinclude-settings
"c:\data\ly\includes\myTestInit.ly" test.ly

what is wrong?


No idea. Your file works fine here.


This works fine here in the Vista command window:

C:\Users\Trevor>lilypond -dinclude-settings=includes/testInit.ly test4.ly

It also works if I use a backslash, but it generates the warning:

programming error: file name not normalized: includes\testInit.ly
continuing, cross fingers


Looks like relative paths are okay, while absolute paths cause trouble. 
 Just an idea, I don't own a Windows system to test.



Cheers,
Alexander

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

Re: lily/freetype-error.cc: const struct #include ;

[Alexander Kobel]

On 2010-09-07 01:28, Alexander Kobel wrote:

[...] Here's my shot to explain it:  [...]


Hm, when I just tried to look up a bit of the syntax, I stumbled across 
this:

  <http://en.wikipedia.org/wiki/C_preprocessor#X-Macros>
That's basically it.


Cheers,
Alexander

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

Re: lily/freetype-error.cc: const struct #include ;

[Alexander Kobel]

 On 06/09/10 22:30, Wols Lists wrote:

> Because C doesn't give a monkeys about white space, but the
> pre-processor does. The #include has to be the first thing on the line
> otherwise the pre-processor will screw up, but once the pre-processor
> has done its job, the compiler will happily ignore all the surplus new
> lines.


And, IIRC, the preprocessor even deletes the newline after the include, 
which is why the compiler issues a warning if included files do not end 
with a newline character.  An #include in the next line would be 
ignored, or something like this.



const struct Freetype_error_message // this bit is the structure definition
{
  FT_Error err_code;
  const char*  err_msg;
// this bit now declares the array and fills it
} ft_errors[] = ( (1, "message1"), (2, "message2"), (0, 0) ) ;


That bit between the "=" and ";" initialises the array (and I've almost 
certainly got my syntax complete crap :-).


The ()s should be {}s, but otherwise it's okay, I think.


Here's my shot to explain it:
Assume you have a list of items like these in a header file, which 
should not be copied, but rather only included to stay aware of updates:


/* data.h */
/*TitleArtist Year  Best Song */
DISC ("Back in Black", "AC/DC",   1980, "Hells Bells")
DISC ("IV","Led Zeppelin",1971, "Stairway to Heaven")
DISC ("Thriller",  "Michael Jackson", 1982, "Billie Jean")
/* EOF */

Now you want to fill an array of structs, but you only care about the 
best songs of each artist.  Then you can just do:


/* some .c file */
/* ... */
#define DISC (t, a, y, s) { a, s }
struct BestSongOfArtist {
  const char * artist,
  const char * song
} artist_song_map[] = {
#include 
};
#undef DISC
/* ... */

and here you are.

In the case of fterrors.h, stuff is slightly more complicated since 
there are default mappings for some macros.  Say, most people won't need 
the best song, but only the remaining fields, then the file looks like this:


/* default_format_data.h */
#ifndef DATA_START_TOKEN
{
#else
DATA_START_TOKEN
#endif

#ifndef DISC
#define DISC_DEFAULT_USED
#define DISC (t, a, y, s) { t, a, y }
#endif
#include 
#ifdef DISC_DEFAULT_USED
#undef DISC
#endif

#ifndef DATA_END_TOKEN
}
#else
DATA_END_TOKEN
#endif
/* EOF */

and you could just write

/* some .c file */
/* ... */
struct DiscStruct {
  const char * title,
  const char * artist,
  const char * year
} database[] =
#include 
;
/* ... */

It's not a nice coding style, but it keeps all those definitions at only 
one place (good thing), and once you figured out what's going on, it's okay.
And as is noted somewhere in the docs for the Boost preprocessor 
metaprogramming library, "the preprocessor exists to be used, so don't 
shy away".  It's bad to clutter the global space with #defines, but it's 
equally bad to introduce a lot of non-macro (struct, function, 
variable...) names there.  (Sadly, namespaces are not an option for C.) 
 It's not all that rare for larger libraries to have a little stuff 
coded like this.


As Wol, I didn't compile this, so my syntax might be crap, too; but the 
essence should be there.  (And no, I didn't know the release years just 
out of my head... ;-))



HTH,
Alexander

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

Re: equivalent to \once within scheme?

[Alexander Kobel]

On 2010-09-15 10:09, Marc Hohl wrote:

Hello all,

IIUC, \override grob #'foo = #bar
is more or less the same as
(ly:grob-set-property! grob foo bar)

Is there a scheme equivalent for
\once \override Grob #'foo = #bar ?


Hi, Marc,

if _I_ understand correctly, the (ly:grob-set-property! grob ...) is 
_exactly_ the \once \override ..., since it applies to the specific 
instance of a grob you give as an parameter.  It just depends where you 
call it - which is usually inside some callback set by \override Grob 
#'after-line-breaking or such.  Thus, the (ly:grob-set-property grob 
...) is called for every grob of type Grob.
But if you, say, construct grobs in scheme, and run the function only 
for one of the resulting grobs, or apply it only the second instance of 
a broken spanner (which is divided into two grobs (or even more for a 
three-system-long VoltaBracket, e.g.?) it behaves exactly like a \once 
\override.



HTH,
Alexander

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

Re: equivalent to \once within scheme?

[Alexander Kobel]

On 2010-09-15 10:24, David Kastrup wrote:

Alexander Kobel  writes:

if _I_ understand correctly, the (ly:grob-set-property! grob ...) is
_exactly_ the \once \override ..., since it applies to the specific
instance of a grob you give as an parameter.


That would rather be a \tweak, wouldn't it?  \once \override affects
every grob at a given timestep.


D'oh.  Of course.


Cheers,
Alexander

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

\transpose and \relative

[Alexander Kobel]

Dear bug squad, dear developers,

is there a particular semantical or syntactical reason (other than 
implementation left to do) why \transpose does not respect \relative mode?
If not: I know of the agreement not to file known issues mentioned in 
the docs as enhancement requests in the bug tracker, but I guess this 
might be a candidate for GLISS.  Is there a topic list where I can leave 
a note?



Cheers,
Alexander

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

Re: attachment points for vertical spacing dimensions

[Alexander Kobel]

On 2010-10-05 21:53, Carl Sorensen wrote:

On 10/5/10 12:09 PM, "Mark Polesky"  wrote:

Of the three, bottom-system-spacing is slightly more
complicated, since it currently controls the spacing below
systems *and* markups, when either is the last on a page.
So the natural attachment point for systems would remain the
same, but would be shifted to the lowest Y-coordinate for
markups (ideally).


Again, I like the name last-item-spacing, which would apply to whatever is
the final layout item and the bottom margin.

Again, with proper understanding of padding, I think everything works
properly.

As I now understand things, I think that I would be unlikely to use
minimum-distance for anything.  I think I'd just use space and padding.


I regularly use 'minimum-distance and a large negative 'padding in 
bottom-system-spacing to align the last staves to the same Y-offset, 
regardless of single note descenders or similar.
Also, this is a case where I actually wish the "reference point" of the 
markup were on the opposite side, i.e. the bottom of the markup (or top 
of the bottom margin), s.t. any copyright or tagline really stays inside 
the footer and does not destroy the alignment of the staves on the page. 
 That'd amount to introducing a new last-staff-to-bottom-margin-spacing 
and leaving bottom-system-spacing as is, or - functionally equivalent, 
but somehow irritatingly - shifting the attachment point of 
bottom-system-spacing to the bottom of the markup and adding 
last-staff-to-top-of-markup-spacing.



Personally, I think we should add a new variable to control
the spacing between a markup and the bottom margin.  We
could call it bottom-markup-spacing for now


@ Mark: is the latter what you meant with your idea from above?


Cheers,
Alexander

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

Re: attachment points for vertical spacing dimensions

[Alexander Kobel]

On 2010-10-07 04:11, Joe Neeman wrote:

On Wed, Oct 6, 2010 at 1:26 AM, Mark Polesky mailto:markpole...@yahoo.com>> wrote:
Joe Neeman wrote:
>  I would argue that the baseline is more natural then the
>  bottom.  Moreover, using the baseline as a reference point
>  will result in more even spacing of multiple consecutive
>  lines of markup.

Okay, that's a good point, so I agree -- baseline is better
than bottom.  But do you agree with Carl and Trevor that we
should always use the same reference point for markups?  I
was specifically proposing to use the bottom of the upper
markup and the top of the lower markup for
between-title-spacing, but Carl argued eloquently against
it.  Carl's argument is probably much more solid than mine,
but just for the record, what do you think?

I don't care so much about one versus two reference points (although the
current code only works with one), but I do think that the reference
points should not depend on any ascenders or descenders.


Hm, I'm not sure.  The baseline in some sense is the natural place to 
attach references to - that's how it's done in most applications I can 
think of.  On the other, hand, these typically deal with single lines on 
their own...
For a markup placed /above/ a staff (or another markup, by the same 
argument), the baseline of the lowest line of the markup is a sensible 
reference (even better than the bottom corner, since, as you pointed 
out, this does not depend on an ascender).  However, this is a poor 
choice for markups (like footer) /below/ a staff - if you add a line 
here, you'd have to redo spacing.  Using the baseline of the top-most 
line would be better, but looks far harder to code.
Furthermore, both baselines don't allow a good handling of the case of 
non-character markups (a score - What's the baseline there? The middle 
line of some staff? -, a figure, whatever) which has larger height than 
a letter of the default font.  And font sizing doesn't change the 
baseline, but the ascender and descender height.


Honestly, I don't think it's worth the hassle.  IMHO, we should try to 
give reasonable definitions, but not to deal with each and every 
possible use case; the user needs to tweak, and he probably won't find 
the optimal values for all these spacing variables by anything but 
trial-and-error.  Let's not complicate this by overcluttering with a 
huge bunch of options.
As for fonts, it's not too hard to guess the extent of a line, 
especially since baseline-skip is given in staff units.  The topmost 
point as anchor works fine in many cases, and padding additionally is 
there to avoid trouble.


The only point the current layout does not work well for me is tweaking 
the pages s.t. the topmost and bottommost (center lines of) staves align 
over all pages, but even there I can perfectly live with a manual 
positioning of the footer and, optionally, a \with-dimension #'(0 . 0) 
#'(0 . 0) there.  And if the very last line of a score is slightly above 
the others, I don't feel it disturbs the overall impression.  Things are 
easier for the top, since the first page has the book header, and the 
page number has the same extent on all the others.



I've noticed that in many traditionally-engraved scores, [...]
For example, say score1 has title/subtitle/etc. in the usual
place (top center), and piece/opus also in the usual place
(flush left and flush right just above the top system), and
the top system has no protruding skyline.  Now score2 has
all the same titling but the top system has a really high
note just before the rightmost barline.

To prevent a collision between the last note and the opus,
LilyPond will shift the first system down.  Fine.  But what
I've noticed in the classic scores is that in this
situation, the top system is not shifted down, but rather
the opus is shifted *up*.  This is an important difference!

It means that the placement of the top system is determined
by the bookTitleMarkup, and the scoreTitleMarkup is
determined by the top system.  And it usually looks better
this way (and more consistent from score to score). [...]

I won't say it's more trouble than it's worth, but I don't think it's
trivial. In lilypond-spacing-backend terms, I think you want to treat
the opus markup as a "loose line."


Now, that'd be an feature...  Even assuming that we'd have to take opus 
out of the header tags - can one manually add "loose lines" besides Lyrics?



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-06 17:46, Mark Polesky wrote:

I also think the name 'space is misleading; I propose
'default-distance.  Opinions?


I can't see why 'space should be misleading, but that might just be that 
I'm accustomed to it by now.  It's shorter, but anything other is okay 
as well.
(Of course, this requires an understanding of the connections 'padding 
vs. 'space and 'stretchability vs. 'minimum-distance.)


But should it be 'default-distance or 'optimal-distance?  "Default" to 
me (non-native speaker) implies that it's the value proposed by the 
system, which can be overridden by the user.  I think "optimal" fits 
better in the sense that it's the user-given value which the layout 
algorithms aims to achieve, but does not always succeed to reach.  In 
this sense, 'stretchability is a deeper feature most users hopefully 
don't have to care about too much; what you want to tweak is 'space.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-07 15:53, Carl Sorensen wrote:

I like base-; it's shorter to type, and it still carries the right
connotation.


+1.


Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-09 17:46, Mark Polesky wrote:

CURRENT NAME   PROPOSED NAME
   -
top-system top-system
top-title  top-markup
between-title  markup-markup
after-titlemarkup-system
between-system system-system
before-title   system-markup
bottom-system  system-bottom
between-scores-system  score-system


Huh.  Sorry that I missed the weekend discussion; in general I support 
these names.
I'm not quite sure if they will be clearer to the "everyday user" who 
mainly thinks in terms of titles and scores, headers and footers, 
though, and probably won't have a bunch of settings for all of these, 
but rather uses the default for everything but what used to be 
'after-title-spacing. [1]
But since the new names are consistent and I definitely lack to come up 
with something more clever, I'm satisfied.  (At least until GLISS, that is.)


[1] I tried to figure out what's the buzz with scoreTitleMarkups and 
bookTitleMarkups.  From a user's POV, both of them are 
top-level-markups, right?  Is there anything different because one 
belongs to the score and the other to the book (aka "real" top-level)?
I think after-title and between-title are the perfect identifiers for 
the spacing between those, but the whole naming system gets messed up if 
you include custom markups.  /Perhaps/ I'd like aliases, but I don't 
want to think about this until GLISS.  And, essentially, aliases are 
ugly anyway, so encapsulating headers in a separate category (score - 
markup - headerMarkup?) may be better, or...  Not something to discuss now.


By the way, right now it isn't possible to change spacing /in between/ 
of a book environment, is it?  It's reasonable to think that the very 
main header (and the very first music line) will need a different 
spacing than all other markup-system-pairs, even if a scoreTitleMarkup 
is absent.
So it'd be cool to allow changing the spacing variables inside the book 
block, or have some LaTeX-\vfill-like command with the four spacing 
variables as arguments:  \vspace #'((spacing . 5) (stretchability . 
20)), ... you get the point.  But again, this looks like a major (read: 
postponed) change is necessary.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-12 14:27, James wrote:

On 12/10/2010 12:54, David Kastrup wrote:

James writes:

Why do we have
'top-system' but 'system-bottom' and not instead, 'bottom-system'?


Because there is no system after the bottom?


?

I'll stop if I am really showing my ignorance (I am not a code
developer), but from a user-point of view it would be much more
'logical' if the naming was split *consistently* into

What you are changing (system, markup, title etc) and where you are changing.


That's what I meant when I wrote after-title-spacing and 
before-title-spacing (as is) are good names IMHO.
/But:/ The more consistent naming scheme is the new one; on this I agree 
with Mark, Carl, David, and some of the others.


All these variables describe vertical spacing, which means there is 
always a Foo above the space and a Baz below the space.  Thus, 
foo-baz-space sounds fine, doesn't it?  (This logic implies 
system-bottom-spacing, of course.)
Of course, the user usually thinks of your three-divisioned scheme 
titling/headers, music, markups, but Lily's state of the art is that 
titling and top-level markups are the same.  If we were to introduce 
this distinction as a separate, well, 
"object-taking-vertical-top-level-space" category, we'd have even more 
meaningful and understandable names; but this looks like it's /far/ out 
of the scope of this patch and discussion.


And as to "where you are changing": The settings just do not allow 
controlling the spacing independent of the subsequent element.  That'd 
look like - similar to the (horizontal) space-alists for some grobs - 
the following, if I understand you correctly:

  after-staff-spacing = #'((Staff . ((space . 5) (stretchability 7)))
   (Lyrics . ((minimum-distance . 7)))
   (Markup . ((padding . 3)))
   (Titling . ((space . 8) (stretchability 20) 
(minimum-distance . 8) (padding . 5
... and so on.  This looks theoretically possible, but to me it does not 
look better than the current approach.  Rather worse: what if you want 
to change just a single entry? Rewrite the whole thing?


I see your point, but do you think it's worth it before GLISS?


Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-13 00:20, Wols Lists wrote:

  On 12/10/10 14:02, Kieren MacMillan wrote:

Hi James,
 [...]
If Lilypond users are confused because they don't have an understanding of that 
basic and universal terminology, they should read (1) some engraving books, and 
(2) the Lilypond introductory documentation.

3) Take a basic music theory course.

For a musician to get that wrong is as seriously incompetent [...]


On 2010-10-12 15:24, Trevor Daniels wrote:

I'm afraid you're showing your ignorance as a musician.
System and score are not synonomous. [...]


Come on, guys, calm down.  First, not everybody's a native speaker, and 
even if they are or know the terms, score-system-spacing is confusing at 
the first glance.  After all, the user might think: My scores consist of 
systems - why should I specify a distance between the system and the 
score it is in?  Ah, okay, it probably means the spacing between 
different systems in a score.
Well, bang, you're dead - wrong conclusion drawn.  I'd understand this 
way of reasoning if somebody only sees the name of the variable without 
further explanation, and thus I see James' point.  But really, the logic 
"upper object - lower object" is simple enough to explain in one 
sentence, and if the user reads it, he should be fine.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-13 00:27, Wols Lists wrote:

Add "stave" to this. Actually, I would have defined a stave as a line of
music, and a system as a group of linked staves played simultaneously.
But that all depends on how you understand the word "line" :-)


"Stave" or "staff"?!  Are these identical?  I thought "stave" is just a 
wrong singular form of "staves", which itself is the correct plural of 
"staff"?

Merriam-Webster says nothing about these words in a musical context... :-(

Cheers,
Alexander

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

LyricText #'font-series = #'bold-narrow ?!

[Alexander Kobel]

Hi, folks,


why does LyricText #'font-series default to #'bold-narrow?

First, it's counterintuitive to me to have a bold narrow font as the 
most important thing to read in a piece; it's just too black-ish. 
Condensed seems fine for lyrics, but bold?
Second, it's defined for nearly no font, in particular Century 
Schoolbook L (the default of LilyPond) does not have it, IIUC, so 
regular is used instead.  At least, this holds for the free typeface; 
according to Wikipedia, there are Century designs featuring a narrow 
variant, but AFAICS all are commercial, and don't necessarily come as 
Century /Schoolbooks/.
Third, even /if/ it were defined, it doesn't seem to work: I tried 
"Nimbus Sans L", the only font I could find right now which actually 
offers a bold condensed variant (with the same basename, i.e. [1]), and 
it falls back to regular even there.  Which came to no surprise after I saw


# git grep bold-narrow
Documentation/misc/ChangeLog-2.1: * scm/font.scm (paper20-font-vector): 
add bold-narrow series (only
Documentation/misc/ChangeLog-2.1: * scm/define-grobs.scm 
(all-grob-descriptions): use bold-narrow
scm/define-grob-properties.scm:   include @code{medium}, @code{bold}, 
@code{bold-narrow}, etc.")

scm/define-grobs.scm: (font-series . bold-narrow)

Is this symbol actually defined somewhere, and what am I missing?


[1] This observation makes me wonder: is it possible to define different 
font basenames for several series of, say, the serif default font?  Some 
of my favourite fonts come in two flavours for normal spacing and 
condensed spacing, and my workaround - if I need both - is to define the 
condensed one as the monospace font to have easy access on it.  Which 
works, but is a complete abuse of the monospace entry.  The Real Thing 
would be to say "GarmdITC Bk BT" is my default serif font, with default 
proportions, "GarmdITC BkCn BT" is the corresponding condensed font. 
Some typefaces even need the same for bold, ultra-bold or something like 
this (e.g. Arial vs. Arial Black).  And when 'font-series is switched, 
of course the appropriate basename should be chosen.



Cheers,
Alexander

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

Re: LyricText #'font-series = #'bold-narrow ?!

[Alexander Kobel]

On 2010-10-20 15:34, Werner LEMBERG wrote:

why does LyricText #'font-series default to #'bold-narrow?


This looks like an oversight.  The change is from 2004 where TeX has
been still used as the output device.


Ok.  So #'medium should be correct now?
It's hardly worth it (it's just one change in scm/define-grobs.scm), but 
here's a patch: .  Would you 
check this?



Cheers,
Alexander

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

Re: LyricText #'font-series = #'bold-narrow ?!

[Alexander Kobel]

On 2010-10-28 02:30, Ralph Palmer wrote:


On Wed, Oct 20, 2010 at 9:27 AM, Valentin Villenave
mailto:valen...@villenave.net>> wrote:

Hi Alexander,

CC-ing to the bug list just in case.

On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel mailto:n...@a-kobel.de>> wrote:
>  why does LyricText #'font-series default to #'bold-narrow?
[...]
Greetings -

I'm directing this primarily to bug-list folks. This was submitted over
a week ago, and I see no action. Did I miss something? [...]


Hi, Ralph,

thanks for your attention, but it's fixed (by commit 
d0c8a258b168c41a3d40f714c55f8fccadfe7d8c).  Werner and I forgot to send 
a note to the bug- list, sorry.



I don't
understand fonts or typefaces or their parameters well, so I don't
understand whether there is a bug or not.


Since we don't offer a bold-narrow style in Century Schoolbook (and most 
other fonts don't as well), the fallback was the regular font anyway. 
So it's been an "unexpected expected (desired) behaviour".



[1] This observation makes me wonder: is it possible to define different
font basenames for several series of, say, the serif default font?  Some of
my favourite fonts come in two flavours for normal spacing and condensed
spacing, and my workaround - if I need both - is to define the condensed one
as the monospace font to have easy access on it.  Which works, but is a
complete abuse of the monospace entry.  The Real Thing would be to say
"GarmdITC Bk BT" is my default serif font, with default proportions,
"GarmdITC BkCn BT" is the corresponding condensed font. Some typefaces even
need the same for bold, ultra-bold or something like this (e.g. Arial vs.
Arial Black).  And when 'font-series is switched, of course the appropriate
basename should be chosen.


This might count as enhancement request.  Postponed, if you ask me.


Cheers,
Alexander

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

Re: Renaming the 'space alist-key

[Alexander Kobel]

On 2010-11-06 18:32, Mark Polesky wrote:

7 proposals for renaming the 'space alist-key have been
discussed, but a decision has not yet been made.  And I just
added an 8th proposal (initial-distance).  [...]

2) optimal-distance
* sounds like the resulting trade-off between the
  desired distance and situational spacing constraints
3) desired-distance  [...]
5) base-distance
* sounds like the distance between "bases"  [...]


This might complicate it, but 2, 3 or 5, with decreasing preference.

Sorry for not being active anymore in the recent discussions, by the way.


Cheers,
Alexander

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

Re: Renaming the 'space alist-key

[Alexander Kobel]

On 2010-11-07 16:30, Mark Polesky wrote:

[...]
 SPACE  MINIMUM-DISTANCE
--  --
1)   basic-distanceminimum-distance
2) initial-distanceminimum-distance
3)   basic-separation  minimum-separation
4) initial-separation  minimum-separation

Alexander, I hope you don't feel disenfranchised, [...]


I didn't even know that word until now, so I can't possibly be. ;-)  I'm 
by no means offended, and I very much appreciate the thoughts and work 
you invested in this topic; far more than I'm able to do.



It's nothing personal, and I hope you understand!


Of course - you're welcome.


Trying to sum up:


Alexander: 1
Carl:  1
David:  1
Joe:
Mark:  1
Patrick:   2
Trevor: 4
Valentin:  2


Doesn't look like my opinion is underrepresented, by the way... ;-)


Cheers,
Alexander

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

Re: renaming "vertical spacing inside systems" props

[Alexander Kobel]

On 2010-11-09 00:54, Trevor Daniels wrote:

Mark Polesky wrote Monday, November 08, 2010 7:14 PM

Keith E OHara wrote:

We will use this in context that makes that first
qualifier almost redundant :
\override Context.StaffGrouper #'withingroup-staff-staff-spacing


This is an excellent point, and in response I'd like to
propose one more option -- just remove the "withingroup"
prefix altogether:

\override StaffGrouper #'staff-staff-spacing
\override StaffGrouper #'staffgroup-staff-spacing

Thoughts?


LGTM

(As I've said before, I admire your persistence :)


+1.


Cheers,
Alexander

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

Re: Clarifying the 'padding alist-key

[Alexander Kobel]

On 2010-12-09 16:15, Mark Polesky wrote:

Mark Polesky wrote:

1)
padding - the minimum required amount of vertical
whitespace between two items, measured in staff-spaces.
When available, skylines are used in the spacing
calculation.

2)
padding - the minimum required amount of vertical
whitespace between the skylines of two items, measured in
staff-spaces.



Carl Sorensen wrote:

I prefer 2.


Trevor Daniels wrote:

2, but is "skylines" explained anywhere in the docs?  If
it is, it is not indexed.


2 for me, too.


Interesting.  I just assumed you'd both prefer #1, because
IIUC most items don't have skylines for padding.


Most?  Anyway, after all, the main task of LilyPond still is typesetting 
/music/, not the headers.  And for the spacing of staves, the skyline is 
both available and essential to understand, and should be prominently 
advertized.



For example, do things like title/toplevel markups, lyrics, etc.
have skylines?


Markups: No, but - no skyline is a skyline, too, just a flat one...  I 
consider this as a missing feature; I don't see the point why headers 
and toplevel markups should not have skylines.  It's an annoyance when a 
single high note and a tempo mark at the beginning of a piece push the 
distance to the header, although only the composer and arranger (right 
side markup) are given.  So, documenting the skylines sounds like the 
correct thing to me, but stating that top-level markup's ones are, well, 
somewhat unusual for now.
("When available" from #1 sounds simple and descriptive, though, but I'd 
like to have skyline the default.)


Lyrics do have skylines, as well as chord names and IIUC basically 
everything you can enter in a score block.  That is, everything /but/ 
top-level markups?
(Though sometimes the estimations aren't that good as well; see the 
discussions recurring every now and then about refining skylines for 
hairpins, slurs or volta brackets, where the skylines are used for the 
intra-system spacing and extent estimation.)



Trevor: when I `git grep' for "skyline" in the Documentation
directory, I get nothing, so to answer your question: no,
skylines are not explained anywhere in the docs.


Well, the same point I mentioned in 
, right?
I'm still not sure if it eases or complicates things to not use the term 
for the user, but in the end it's not too hard to understand to spare it 
out.  And that it's lacking in the whole Documentation dir means that 
it's in absolutely no docs, right?  That's bad - I can't see a point 
where this fits in the IR, but for some spacing tweaks it's important to 
have the real deal explained.



Cheers,
Alexander

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

Re: Most popular French users request : bar numbering of alternatives

[Alexander Kobel]

On 2011-11-28 09:44, Colin Hall wrote:


On Mon, Nov 28, 2011 at 01:04:06AM +0100, Xavier Scheuer wrote:

Dear LilyPond developers,

Dear Bug Squad members, could you add this enhancement request to
the tracker?  Thanks!

This is by far the most popular enhancement request from the French
users mailing list: Bar numbering of repeat volta _alternatives_.

Currently LilyPond counts the measures of each "alternative" as
normal, unrepeated, measures hence incrementing the currentBarNumber
in both alternative "1." and "2.".  Several references supports what is
actually asked by many users: bar numbering of alternatives should not
be counted twice.


Thanks, Xavier. Added to the tracker as issue 2059:

http://code.google.com/p/lilypond/issues/detail?id=2059


Looks like a duplicate of
  http://code.google.com/p/lilypond/issues/detail?id=785
with some additional links...


Best,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 11:09, James wrote:
> Marc,
> 
> On 05/01/2011 09:50, Marc Hohl wrote:
>> My contribution to fonts was the rotation of the G clef and the varsegno
>> sign
>> (which nobody seems to use, anyway ;-)
> 
> Au contraire mon amis!
> 
> I use the varsegno glyph at the slightest opportunity!

Dito.

> It helps the 'beginners' (I find) that I play with as it seems to be
> much more easy to spot for them that are not used to jumping about in a
> score, than the regular segno.

Additionally, sometimes I think it's far more easily to integrate in the
overall design than the usual symbol.  Yours takes no precious vertical
space, and I don't have to bother with shifting around till it's at the
best place.

> I am sure that I am breaking some engraving 'rule' but it's a nice glyph.

I've seen it in Bosworth & Co. scores only, but they seem to use it
exclusively instead of the common shape.
But I also made up the habit of telling the ones I hand my scores out to
that I use a unusual symbol for d'al segno, to avoid irritations.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 11:13, Graham Percival wrote:
> On Wed, Jan 05, 2011 at 10:09:27AM +, James wrote:
>> Marc,
>> What I think we need actually - slightly off topic - is a nice
>> LilyPond-glyph similar in essence to when you see the word 'Latex'
>> in a body of text. I suppose some would call it a 'logotype' or
>> colophon.
>>
>> tagline = \markup { "Engraved by \musicglyph #"scripts.lilylogo" }
> 
> I've mused about trying to create a logo using the markup
> commands.  If you think about all the graphical ones, plus music
> glyphs, there's a lot of options.  The "d" could be a rotated bass
> clef, the ls could be compressed treble clefs, the p could be a
> half note, etc.

I tend not to like those assembled logos very much.  Most of the time,
they end up too clumsy IMHO; more like something quickly hacked
together, just for the sake of quoting musical symbols.
However, I'd certainly use a predefined command for the inclusion of
something like Valentin's logos from lilynet.net. [*]  (Sadly, I don't
remember the correct address where I downloaded it from.  I mean the SVG
sources of  and
.)
 One might argue that the quaver looks childish, but IMHO it does in a
very joyful and charming manner.  And I really like the lilys, but I'm
not sure whether a full-colored logo is a good default choice.

[*] I actually already used these once, but in a separate title page
generated with inkscape, not via LilyPond itself.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 12:11, James wrote:
> No this isn't what I was referring to. [...]
> I was thinking more of a 'lilypond' in some
> cursive-cum-signature-cum-all-joined-up script,
> but something 'created' as a glyph than just put together.
> 
> If you think of J S Bach's signature then that could be used as nice
> glyph on a tagline.

Ah, okay, I get it.  Sorry for the misunderstanding.  Of course I meant
logo + "LilyPond" text, not the logo alone, but still that's a different
thing.
Yeah, that'd be nice indeed...

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 12:58, Federico Bruni wrote:
> Il giorno mer, 05/01/2011 alle 11.36 +0100, Alexander Kobel ha scritto:
>> I tend not to like those assembled logos very much.  Most of the time,
>> they end up too clumsy IMHO; more like something quickly hacked
>> together, just for the sake of quoting musical symbols.
> 
> You mean something like this? (my 5 minute try, really horrible)
> 
> \version "2.13.45"
> 
> \markup {
>   \lower #.5 { \number 1 }
>   \musicglyph #"scripts.ustaccatissimo"
>   \lower #.5 { \number 1 }
>   \musicglyph #"scripts.ustaccatissimo"
>   \lower #.5 { \dynamic p }
>   \musicglyph #"noteheads.s0" \hspace #1
>   \musicglyph #"scripts.prall"
>   \semiflat
> }

13371p4wn3d, huh? ;-)

Yup, that's what I meant.  I know a couple of amateur musicians who
copied some musical symbols to replace single characters of their names
for their letterheads.  I can't think of a single one which doesn't look
ugly.  Sizes don't match, kerning (if that term is allowed for this)
does not match, it looks crowded...  Just like using about the whole
fonts folder for an A5 greeting card.

I'm aware that a good designer can do amazing stuff in this direction,
but this will need subtle quotations and resemblence to the symbols, not
just concatenating and rotating a few of them.  If someone's up to it -
well, then show us what you can do!

>> However, I'd certainly use a predefined command for the inclusion of
>> something like Valentin's logos from lilynet.net. 
> 
> That's a nice idea. Maybe we could provide a black&white logo also...

Still, I like James initial idea of a scripted logo.  But in the
meantime, this looks like a good alternative to me.
Isn't there an engraver application which has some inkpot-and-feather
logo? Something along this line.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 15:17, Reinhold Kainhofer wrote:
> Am Mittwoch, 5. Januar 2011, um 13:33:26 schrieb Graham Percival:
>> On Wed, Jan 5, 2011 at 11:58 AM, Federico Bruni  wrote:
>>> Il giorno mer, 05/01/2011 alle 11.36 +0100, Alexander Kobel ha scritto:
>>>> I tend not to like those assembled logos very much.  Most of the time,
>>>> they end up too clumsy IMHO; more like something quickly hacked
>>>> together, just for the sake of quoting musical symbols.
>>>
>>> You mean something like this? (my 5 minute try, really horrible)
>>
>> That looks quite "busy" to my taste.  My latest 5-minute hack is
>> something like this:
> 
> Attached is a small modification (created in inkscape rather than lilypond 
> itself). What I really don't like about it is the different slant of the L, 
> the l and the p)...

Huh, that's a good one, kudos!

I personally think the p is just a bit too large; IMHO it should fit to
the same x-height as the neighbor letters.
In smaller size, I also think that the blackness of L and p is extremely
dominant in contrast to the other letters, but this is just from scaling
of the PNG.  Maybe a "real" markup implementation in Lily would perform
better due to the scaled fonts.
And I'm not too sure about the "Music typesetting for everyone".  It's
nicely integrated, and looks very good in a large image.  But if the
logo goes into the tagline, IMHO it should also look acceptable in a
size where the staff lines are at about the same distance as for the
default music staves.  The "subscript tagline" has certainly less than
1.5 mm height then, and if it's removed, the lower serif of the L gets a
bit too dominant for my taste, too.  So I suppose we'd need this in two
versions, for smaller and larger logos.


Cheers,
Alexander

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

Re: Bug in ties over barlines

[Alexander Kobel]

On 2011-01-31 11:04, Jan Warchoł wrote:
> [...] If the last note in the
> following example doesn't get a natural, it's *impossible* to tell
> that it's not another ces:
> 
> ces'1~ | ces'
> ces'1( | c')
> 
> It may be argued that the slur looks different than the tie, but it's
> not enough.
> I'm sure that engraving books will agree with me - may someone check this?

Now that I have a brand new copy of Gardner Read's "Music Notation" in
my bookshelf since just yesterday, I do.  I didn't yet read the whole
book, though...

In the chapter for accidentals (p. 131), it says:
"It is not necessary to repeat the accidental before a tied note. The
tie itself serves to prolong the effect of the accidental. The one
exception to this general rule occurs when the note or notes affected by
an accidental and tied over the barline come at the end of a system or
at the bottom of the page."
Which is what we all know.

Regarding slurs, I found exactly nothing.  But I'm absolutely sure, if
Read had written anything about it, it would be: "If in doubt whether
the reader will know what to do: make it clear."  Or, rather: "Write the
natural, dummy."  He constantly advocates the use of notation that eases
the understanding of the music, and disapproves any elements that are
hardly possible to distinguish or perform.
And this may be an example just too obvious that he felt the need to
comment it.

Not that I know a single instance where this occurs, though.  In a piano
piece that requires a moderately trained player, perhaps I'd leave it
out; but only in the case of chords which are very clear to interpret.
Yet, in any other case, I consider it good style to write the natural
even when there's no slur.  In particular for a single voice, say a
two-note melisma in choral music.
By the way: if you have  { r2.. cis8( | c2!) r2 }  all over the place,
and then there suddenly comes a  { r2 cis2~ | cis2 r2 }, you'd expect an
additional sharp there too, don't you?

Just my two pence...


Cheers,
Alexander

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

Re: Bug in ties over barlines

[Alexander Kobel]

On 2011-01-31 21:06, James Lowe wrote:
> -Original Message-
> From: Alexander Kobel 
>> By the way: if you have  { r2.. cis8( | c2!) r2 }  all over the place,
>> and then there suddenly comes a  { r2 cis2~ | cis2 r2 }, you'd expect an
>> additional sharp there too, don't you?
> 
> Hmm...why not use (in your example) { r2.. cis8( | c2?) r2 } which to me
> makes more sense. [...]
> No one (as I can see) has spoken about the ? Vs ! And I think that's the
> difference for me. It depends on what is already sharp/flat in the key
> signature as a musician. ! Means it isn't and ? Means it is but 'be aware'
> right?

Ah, good point. I didn't actually think about the ? vs. ! difference;
probably it's just a matter of personal taste of the engraver.  In this
situation, I guess both can be reasoned: the cautionary since the key
signature says it should be c by default anyway, and the mandatory
accidental (without parentheses) because tie and slur could not be
distinguished otherwise, so it's indeed at least semi-mandatory.
But IMHO the important point here is the fact that the notation can be
ambigous without the accidental, and is definitely clear with it.  No
matter if ? or !.


Cheers,
Alexander

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

Re: upgrade to c++11

[Alexander Kobel]

On 07/14/2013 10:41 PM, Frédéric Bron wrote:

I had taken a look previously at CGALhttp://www.cgal.org/>  since
the kind of stuff we are doing with skylines would benefit from
ready-made code like
http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Envelope_2/Chapter_main.html>
and frankly, doing things like computational geometry tasks is
a) a resource drain
b) a source for problems


It seems that cgal makes more than boost::geometry that cannot compute
convex hull of curves.


Disclaimer: (By choice of PhD topic and working group,) I'm a CGAL 
developer, though rarely active and if so, then not in one of the 
publicly visible areas.


CGAL is a very neat library if you need robust and exact geometry 
processing. It's complex to set up though (the current workflow requires 
CMake and, for a "typical" setup, quite a number of dependencies), so I 
don't know how nicely it plays with GUB. OTOH, the hard requirements 
boil down to Boost and GMP+MPFR(+MPFI). There's currently progress on 
even removing GMP as a dependency, but for us GMP licensing is a 
non-issue, and using it makes your CGAL life a lot easier.
For use cases like skylines of segments which mostly deal with linear 
geometry and are very unlikely to hit degenerate cases, CGAL is a very 
heavy hammer. But using it saves you from even thinking about what 
situations can occur, and this code is highly optimized.


If you know a good piece of code to test a migration to CGAL, give me a 
ping, and I'll try to help.



Best,
Alexander

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

Re: Suggestion: Keep original breaks

[Alexander Kobel]

On 11/27/2013 04:32 PM, Urs Liska wrote:

Am 27.11.2013 16:25, schrieb Carl Sorensen:

On 11/27/13 8:04 AM, "David Kastrup"  wrote:


Urs Liska  writes:
[...]

originalBreak =
#(define-music-function (parser location)()
   ( #{ \tag #'keep-original-breaks \break #} ))
[...]

If the general case were added, and a special include were included, then
it seems like we'd have both David's wish for keeping things general and
Urs's wish for having an easily-used tool for the specific use case.


For me this sounds good.
Requiring to write \include "original-breaks.ly" is significantly better
than requiring to define the commands.
But it would still need a separate switch, presumably through the
command line.


I do not want to open a Pandora's box here... Just some thoughts:
Would it be easy to add commandline switches for
 - including files with LilyPond input at the very beginning of the 
"compilation unit"
 - inserting Lilypond input given as a commandline argument at the 
beginning of the document?
And would it be feasible to have the equivalent of the LaTeX commands 
\providecommand and \renewcommand and/or \if\defined?


I imagine commandlines like the following:
  lilypond --include-first=stylesheet1.ly piece.ly [equivalent to]
  lilypond --input='\include "stylesheet1.ly"' piece.ly
  lilypond --input='#(set-default-paper-size "a5")' \
   --input='#(set-global-staff-size 15.87)' piece.ly
and, eventually,
  lilypond --input='originalBreak = {}' piece.ly
where piece.ly contains an
  \include "original-breaks.ly"
which uses \providecommand instead of the Urs' above command to define 
\originalBreak. Or you could re-point a tag name to the actual tag which 
will be used in the score.


Even without the \providecommand and \if\defined functionality, this 
looks like a useful feature for commandline control of Lily's output. 
And of course I hope that "pretending" some lines in front of the actual 
input file should not be too complicated or intrusive to implement?



Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 02:30 PM, Werner LEMBERG wrote:



Which browser?


Firefox 26, Chromium and Konqueror 4.8.5 - also after reload.


Very strange.


Fine here with Chromium (Debian wheezy, v31.something) and Iceweasel 23, 
but the cropped image I made (see below) exhibits the "blue 
only"-behaviour. Workaround also below.



BTW, how can I make Lilypond crop the SVG, similar to EPS output?


I only know the setting of the paper dimensions beforehand.


Looks like this should be put on the wishlist...


 (fully?) working version below 
inkscape --verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg

does the job, albeit not from LilyPond.

Also, IIRC not all browsers can deal with SVG fonts very well - maybe 
you should convert to paths? That'd be


inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg


at the expense of an increase of file size by ~30%.


 (fully?) working version here 
This seems to be fine, but no clue why:

inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FileSave --verb=FileClose file.svg

./svgclip.py -o cropped.svg file.svg

where svgclip.py is here: https://github.com/skagedal/svgclip
If text is not rendered to paths first, this moves the tuplet numbers 
around, but with the Inkscape command first, it works.



BTW, I recognized that the SVG contains (local) links to the .ly file; 
did you remember to disable pointAndClick?




Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 02:17 PM, Joram Berger wrote:

On the other hand, the uncropped SVG image

   
http://upload.wikimedia.org/wikipedia/de/archive/4/4d/20140113112433%21Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg

gets displayed fine, while the cropped SVG image

   
http://upload.wikimedia.org/wikipedia/de/4/4d/Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg

(cropping done with Inkscape) exhibits color mistakes in Firefox's SVG
handling.  Sigh.  I thought that displaying SVG images is mature
meanwhile.


Yes, it shows more blue objects than the original, no red.
The article image links to the uncropped image and shows the
corresponding ~A4 aspect ratio. The content however is the cropped one.
The article has not changed, the image has.


Note that (at least for me) objects are blue exactly if they have a 
textedit:///home/wl/stockhausen.ly hyperlink. Could you try to crop the 
same file, compiled with \pointAndClickOff?
Inkscape seems to rewrite the entire document when changing the page 
margins. I suspect that it removes colors for the a tags, Firefox makes 
links blue per default, and the color for the noteheads has no priority 
over that. (Which might be a bug. Or not.)



Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 04:16 PM, Werner LEMBERG wrote:

This seems to be fine, but no clue why:

inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath
--verb=FileSave --verb=FileClose file.svg
./svgclip.py -o cropped.svg file.svg

where svgclip.py is here: https://github.com/skagedal/svgclip


I've followed that and uploaded a new version.


BTW, I recognized that the SVG contains (local) links to the .ly file;
did you remember to disable pointAndClick?


This time I did. :-)


Excellent. This also solves the blue-notes issue in Firefox for me, even 
after clipping in Inkscape. So, to summarize for reference:


1.) For cropping,
  inkscape --verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose 
file.svg
works, but has some caveats (probably for non-standard-conforming 
viewers only, including Wikipedia's SVG-to-PNG-converter).


2.a) Firefox in some version(s) draws elements with links in blue if the 
a tag does not specify another color.
2.b) Since Inkscape's FitCanvas rewrites the entire SVG and drops those 
(seemingly superfluous) color attributes, you have to use a different 
route with links: https://github.com/skagedal/svgclip
2.c) svgclip does not handle position of real text properly, hence you 
have to convert to paths first.
  inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FileSave --verb=FileClose file.svg

  ./svgclip.py -o cropped.svg file.svg
That's the only universal variant we have for SVGs with links.

3.) Even without links, "real" text causes funny positions with 
Wikipedia's PNG thumb renderer [1]. Hence,
  inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg
should be okay for SVGs with \pointAndClickOff, eliminating the need for 
an additional tool.



Correct?


HTH,
Alexander


[1] Compare

https://upload.wikimedia.org/wikipedia/de/thumb/archive/4/4d/20140113150856%21Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg/500px-Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg.png
with text and

https://upload.wikimedia.org/wikipedia/de/thumb/4/4d/Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg/500px-Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg.png
with paths.

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

Re: Question about customizing emmentaler font

[Alexander Kobel]

On 04/23/2014 07:00 AM, Werner LEMBERG wrote:



[...]  They all show this artifact of rounded interior corners.  I
promise I'm not just making this up.  They come from the punch
manufacturing process AND the engraving process AND printing
process.  I think it would be quite nice to incorporate these
somehow, but maybe that's just me, in which case I would do it for
myself.

What I love about them is the eye doesn't really notice them when
they are there, but I would argue that the eye DEFINITELY notices
when they are NOT there, like with any of the major notation fonts
today. If you need more examples, I'd be happy to supply
them. Cheers!


Especially this example

   
http://lilypond.1069038.n5.nabble.com/attachment/161770/2/barenreiter-examples.png

shows very well that what you want to achieve is not related to the
font itself: It's definitely one level `later', so to say: The round
edges, which can be clearly seen, are not only affecting the clef
outline but *every intersection* of lines, including bar lines!


I agree when I look at the picture, but I wonder what's the cause - can 
you enlighten me?
IIUC you argue that the reason for the rounds is that the metal punches 
for noteheads etc cannot be cut out with 100% sharp inner corners. 
Makes sense.  Now, the barlines are drawn on an engraving plate first, 
and apart from slight rounds at the ends, they will be perfectly 
straight and sharp.  An intersection with a bar line or stem (or any 
other object) will collect a tiny bit of metal next to the intersection 
point, but this should be related to the direction of the stroke of the 
bar line or stem, right?  So, all I can think of as causes for the 
general rounding are dust on the engraving plate, artifacts from 
polishing the plate before printing, or random feathering of ink.  But 
all those must affect both inner and outer angles?



Your confused
Alexander

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

Re: Changing how a font style is requested

[Alexander Kobel]

Hi all,

since I could not find anything suitable to solve the issue described 
below, I decided to write a little patch.  Please have a look at


https://codereview.appspot.com/108700043

and tell me what you think about it.

[ BTW: This might or might not be entirely orthogonal to the music font 
selection methods which are debated about currently, in the sense that 
the feta font loader is hard-coded and built-in into 
make-pango-font-tree and the proposed make-expert-font-tree.  Sorry, I 
did not follow those discussions in detail; but if you think that's a 
good time to integrate music font selection as well, please go ahead. ]


I could not see a way to achieve what I need in user-level Scheme, since 
add-font is not exposed publicly (and probably for a good reason).  I'm 
happy to take comments on functionality and coding style; I will write a 
bit of documentation in addition to the regtest once (if?) you deem the 
interface acceptable.


I hope goals and syntax are somewhat self-explaining; otherwise, feel 
free to ask for further explanations.  I barely added syntactic sugar 
(except the default font scale 1.0), but I'm willing to reconsider the 
input syntax to make-expert-font-tree if you have any better ideas. 
However, a front-end to it should be much more easy to write, and this 
is doable in user-level code.



Thanks in advance,
Alexander


On 07/11/2014 11:59 AM, Alexander Kobel wrote:

Dear all,

I like to use the Romande ADF font family [1] in one of my scores. I do
the usual rule-of-three with

   \paper { ... (make-pango-font-tree
 "Romande ADF No2 Std" "Romande ADF Std" "monospace"
 (/ myStaffSize 20)) ... }

(If you wonder, No2 is condensed, and the non-condensed version, used in
the headers, is mapped to sans for easy access.)

However, here's the catch: Romande does offer a bold variant, but it
announces it as "DemiBold" instead of "Bold", according to fc-list. I
know that I can switch to the different font each time I need bold, but
that's an utter nuisance.
Is there any way to tell Lily how to choose a bold variant? Bonus points
if it only applies to a specific, say, the serif font. Or, , if it is possible to define a mapping similar to

   myserif = { regular: # default
"Romande ADF No2 Std:style=Regular",
   bold:# choose way of selecting bold
"Romande ADF No2 Std:style=DemiBold",
   italic:  # pretend I don't like Romande's italics
# and need to scale some other font to match
"Gentium:style=Italic:scaling=0.93",
   bold-italic: # use small caps family instead
"Romande ADF Style Std:style=Regular" }
   ...
   \paper { #(define fonts (myserif mysans mymono (/ myStaffSize 20)) }

Obviously, that's not Lily's syntax, but you get the point...


Thanks in advance,
Alexander


[1] http://arkandis.tuxfamily.org/adffonts.html

___
lilypond-user mailing list
lilypond-u...@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



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

Rietveld with Google two-factor authentification

[Alexander Kobel]

Hi all,

does one of you use Google's two-factor authentification thingie?  I 
used it without any trouble on "usual apps", but now I'm kind of stuck 
with git cl to commit patches to Rietveld.
AFAICS, the only way to login is via an application-specific password, 
which is an ugly beast not meant for manual input more than once.  My 
usual password is not accepted (which is good), since git-cl does not 
ask for the second-factor token (which is bad).  And obviously git-cl is 
not able to cache the credentials - I get


Could not find stored credentials
  $HOME/.lilypond-project-hosting-login

each time.
What am I missing here?


Best,
Alexander

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

Re: Rietveld with Google two-factor authentification

[Alexander Kobel]

On 07/16/2014 03:58 PM, Graham Percival wrote:

On Wed, Jul 16, 2014 at 03:11:31PM +0200, Alexander Kobel wrote:

My usual password is not accepted (which is good), since
git-cl does not ask for the second-factor token (which is bad).  And
obviously git-cl is not able to cache the credentials - I get

Could not find stored credentials
   $HOME/.lilypond-project-hosting-login
each time.


That is correct, git-cl does no caching, no fancy authentication,
etc.  It attempts to read the above file, and it takes the first
line in that file as the username and the second line in that file
as the password.  That's all it does.


Ah, okay.  That means if I put this application-specific password there, 
I'm done?  Cool.  Now I just need to write some new patch to test...



Patches to git-cl most welcome.  :)


I see... ;-)


I've heard of this "two-factor authentication", but I've never
used it (even in my personal life),


I do like the concept a lot, but it's certainly not for everyday tasks - 
if you push 30 patches a day, you don't want to read a token each time. 
 That's what those app-specific passwords are there for; they can be 
revoked independently of each other, and they only apply for specific 
tasks.  E.g., with the Rietveld-only password it is impossible to access 
my calendar.  So while it's still a risk to store it in some potentially 
publicly available place, I don't expose my entire Google profile with 
it.  YMMV.



and git-cl was my first foray into authentication on foreign servers.
I was kind-of expecting that somebody familiar with
python+google+authentication to take 30 minutes (rough estimate for
somebody familiar with the above) to fix it after a few months, but
obviously there's been no takers yet.


I just stumbled across the issue; I'll never did anything 
authentication-related, too, but I'll have a look.



Thanks,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/20/2014 11:47 AM, Janek Warchoł wrote:

2014-07-19 16:48 GMT+02:00 tisimst :

- Question 1: *Should the new syntax be something like this?* (where the
music and piano-brace fonts are put at the first)

\paper {
   #(define fonts
 (make-pango-font-tree
 *"lilyjazz"*  ; music font
 *"gonville"*  ; piano brace font
 "FreeSerif"
 "FreeSans"
 "Inconsolata"
 (/ staff-height pt 20)))
}


I agree with David's comment here.
Btw, just to make sure: have you seen
https://code.google.com/p/lilypond/issues/detail?id=4014 ?


Hi all,

and Janek: thanks for the ping...  I'm currently travelling, I won't 
have too much internet access for the next week or so, and then again 
just for a few days til vacation starts.  In other words, don't expect 
much time from me until mid-August.
@all: feel free to modify the make-expert-font-tree as you think it fits 
if you want to!
I think if the make-expert-font-tree makes it into master at some point 
in some variant, it would be worth to check whether we should have this 
as the backend for make-pango-font-tree.



Best,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/22/2014 02:58 PM, Urs Liska wrote:

On 22. Juli 2014 07:51:00 MESZ, James  wrote:

On 21/07/14 09:46, Alexander Kobel wrote:

On 07/20/2014 11:47 AM, Janek Warchoł wrote:

Btw, just to make sure: have you seen
https://code.google.com/p/lilypond/issues/detail?id=4014 ?


Janek: thanks for the ping...  I'm currently travelling, I won't
have too much internet access for the next week or so, and then again
just for a few days til vacation starts.  In other words, don't
expect much time from me until mid-August.


So does that mean this patch 'needs work' now?

It's currently on countdown (I'm the owner/patch-shepherd as Alexander
doesn't have commit access).


IISC it does _not_ mean to postpone it, quite the contrary.


Yes and no.  It does not necessarily mean to postpone the feature, but 
my intention for the announcement of the patch in its current shape was 
threefold:


a) (ACHIEVED.)
I needed the feature, right now.  Well, turned out I didn't, but I 
thought I do.


b) (ACHIEVED.)
I wanted to have a draft ready before some interface for the music font 
changing is settled, because we might want to do both in one shot.


c) (TODO)
I hoped for a small comment or two about the (informal) interface 
proposal (by example).  I do intend to write a piece of documentation 
about it, because I feel that already make-pango-font-tree is not as 
accessible for people which are not familiar with the Linux-/LaTeX-style 
{roman,sans,monospace}-default-definition idea.  I might be mistaken, 
though.  On the other hand, I actually don't know if it is correct when 
I say: "the Pango description string for the font, which is passed as-is 
to the Pango interface".  Is this Pango?  Is it fontconfig?  Is it 
correct that `fc-match ` will tell me what 
`(make-expert-font-tree '((... )) ...)' will do, or almost, but 
not quite?  I'm kinda lost there myself.



The last one is the big TODO, and the reason why I'm also fine with 
postponing it.  And I don't want to have it in master unless it's 
reasonably unlikely that the interface (let's say the format of 
font-spec-list) will change within a few days.



BTW: I think it's strange that Century Schoolbook is taken as the 
default, while sans is left to the environment.  Is that because there 
was no need for a sans or mono font with built-in features before chords 
and the tagline were introduced?  Or because there was no agreement on a 
"good" (quality/liberty/freedom) font?



Best,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/24/2014 01:08 AM, Alexander Kobel wrote:

https://code.google.com/p/lilypond/issues/detail?id=4014 ?


On the other hand, I actually don't know if it is correct when
I say: "the Pango description string for the font, which is passed as-is
to the Pango interface".  Is this Pango?  Is it fontconfig?  Is it
correct that `fc-match ` will tell me what
`(make-expert-font-tree '((... )) ...)' will do, or almost, but
not quite?  I'm kinda lost there myself.


Oh, and I forgot one:
Is it an expected and supported behaviour that I'm "allowed" to 
advertise that you can introduce new lily-family symbols ('markup and 
'condensed in the example, but I could think of, e.g., 'lyrics, 'header, 
'chords or 'mark to be useful)?  Or is it rather an unexpected feature 
(aka. bug) that might vanish at some point?  I assume that it's safe to 
use, but I'm not sure.
And if yes, should we also implement a mapping between "logical" and 
"physical" lily-families (similar to structural markup vs. direct markup 
in Latex or HTML)?  Like, per default,

  'lyrics -> 'roman
  'header -> 'roman
  'chords -> 'sans
  'url-> 'typewriter
and the user may add a 'condensed family and re-map 'lyrics to 
'condensed.  Or is this overkill, and we should stick to the one-layer 
strategy we already have?



Best,
Alexander

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

Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)

[Alexander Kobel]

On 07/25/2014 05:55 AM, markpole...@gmail.com wrote:

https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly


Mark, thanks for the comments.  James, give this at least one more 
cycle, please.  I'll incorporate the changes as soon as I can find the 
time, and want to double-check the entire patchset again - hopefully 
I'll have more time available next week.



Best,
Alexander

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

Re: Text and music font handling

[Alexander Kobel]

On 07/26/2014 09:30 AM, Urs Liska wrote:

Hi Abraham and Alexander,

I'm slightly losing track of the font selection discussions that happen
in parallel currently.
Are you actually in touch with each other? I'd be really sorry if either
of your development wouldn't make it into LilyPond because of a lack of
communication.


Hi Urs, hi Abraham,

don't worry, it'll end up in LilyPond at some point.  But I have to 
admit that I did not have a look at Abraham's work other than skimming 
over the newest PDFs.  I was travelling, and also will be on vacation 
from Sunday for a week.  As soon as I'm back again, I will push myself 
to polish up and see how we can integrate our work.


By the way, Abraham: IIRC, you asked about how to prepare a patch for 
review.  I'm not an expert in that, but it looks like I did so 
successfully; so if you can wait for another 10 days or so, feel free to 
contact me and I'll do what is necessary.  Or take the offer by other 
friendly helpers.



Regarding the music font selection:
My uneasy feeling about breakinge existing code is surely invalid
because convert-ly will handle that easily.


That's good to hear.  I'm not familiar enough with convert-ly, but I 
agree that if we come up with a somewhat sane approach for choosing the 
fonts, it should not be too hard to concoct a rule which will do the job.



What I'm still not completely happy with is the fact that one has to
always specify all five fonts, even when one only wants to change the
roman font or the music font.


+1.  It's on my TODO list.  I consider this as syntactic sugar over the 
current make-pango-font-tree and make-expert-font-tree, but I totally 
agree that this should be integrated.  Won't be difficult, I just need 
to figure out how to modify the currently active font tree in place.



It would be awesome if you could think of an infrastructure that
separates the internal work and the user interface so that one could
either have a function using, say, named arguments with default values
or have different functions depending on what you want to change.


Ditto.


Best,
Alexander

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