Werner LEMBERG | 1 Jun 2009 12:17
Picon

STEPMAKE_GETTEXT works incorrectly


[autoconf 2.63]
[g++ 4.3.2]

The STEPMAKE_GETTEXT function in aclocal.m4 is missing a test for the
autoconf version.  For the above tool versions I still get the message

  autoconf <= 2.59 with g++ >= 3.3 gettext test broken.
  Trying gcc, cross fingers.

which is completely bogus.

    Werner
Werner LEMBERG | 1 Jun 2009 12:22
Picon

type conversion warnings


Using g++ 4.3.2, I get many warnings like the one below while
compiling lilypond:

  libc-extension.cc: In function 'char* strnlwr(char*, int)':
  libc-extension.cc:26: warning: conversion to 'char' from 'int'
                        may alter its value
  libc-extension.cc: In function 'char* strnupr(char*, int)':
  libc-extension.cc:37: warning: conversion to 'char' from 'int'
                        may alter its value

Most of them, I presume, are harmless, but...  I think it would be a
good idea to fix them.

    Werner
Werner LEMBERG | 1 Jun 2009 15:01
Picon

wrong horizontal trill position in small staff lines


\version "2.13.1"

\header { texidoc = "
The horizontal position of the beginning of a trill spanner must be
positioned correctly relative to the note head it is attached to, even if
scaled to a smaller size.

Here is a counterexample, clearly showing an unwanted horizontal shift.
This is a regression; it has worked with version 2.11.13, for example.
" }

<<
  \new Staff \with {
    fontSize = #-6
    \override StaffSymbol #'staff-space = #(magstep -6)
  }
  \relative {
    c'1\startTrillSpan | c\stopTrillSpan |
  }

  \new Staff \relative {
    c'1\startTrillSpan | c\stopTrillSpan |
  }
>>

% EOF

(Continue reading)

Werner LEMBERG | 1 Jun 2009 15:49
Picon

bad German translation of convert-ly


There is a serious problem with the translations of convert-ly in
combination with `NOT_SMART'.  Consider, for example, this logging
output:

  Applying conversion: 2.11.15, 2.11.23, 2.11.35, 2.11.38, 2.11.46, 
                       2.11.48, 2.11.50, 2.11.51, 2.11.52, 2.11.53, 
                       2.11.55,
    Not smart enough to convert \put-adjacent argument order.
    Axis and direction now come before markups:
    \put-adjacent axis dir markup markup.
                       2.11.57, 2.11.60, 2.11.61, 2.11.62, 2.11.64,
                       2.12.0, 2.12.3, 2.13.0, 2.13.1

[This nice formatting has been added by me -- convert-ly produces
 awful output here, with overlong strings and missing newlines.]

The same under a German locale produces this:

  Anwenden der Umwandlung: 2.11.15, 2.11.23, 2.11.35, 2.11.38,
                           2.11.46, 2.11.48, 2.11.50, 2.11.51,
                           2.11.52, 2.11.53, 2.11.55,
    \put-adjacent Argumentreihenfolge.
    kann nicht umgewandelt werdenAchse und Richtung jetzt vor die Beschriftung setzen:
    \put-adjacent Achse Richtung Beschriftung Beschriftung.
                           2.11.57, 2.11.60, 2.11.61, 2.11.62,
                           2.11.64, 2.12.0, 2.12.3, 2.13.0, 2.13.1

There are two severe mistakes:

(Continue reading)

John Mandereau | 2 Jun 2009 15:49
Picon

Re: STEPMAKE_GETTEXT works incorrectly

Werner LEMBERG a écrit :
> [autoconf 2.63]
> [g++ 4.3.2]
>
> The STEPMAKE_GETTEXT function in aclocal.m4 is missing a test for the
> autoconf version.  For the above tool versions I still get the message
>
>   autoconf <= 2.59 with g++ >= 3.3 gettext test broken.
>   Trying gcc, cross fingers.
>
> which is completely bogus.
>   

What do you think of the attached patch?

Best,
John
_______________________________________________
bug-lilypond mailing list
bug-lilypond <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Werner LEMBERG | 2 Jun 2009 16:54
Picon

Re: STEPMAKE_GETTEXT works incorrectly

>> The STEPMAKE_GETTEXT function in aclocal.m4 is missing a test for the
>> autoconf version.  For the above tool versions I still get the message
>>
>>   autoconf <= 2.59 with g++ >= 3.3 gettext test broken.
>>   Trying gcc, cross fingers.
>>
>> which is completely bogus.
>
> What do you think of the attached patch?

Without testing it actually: It looks good.

    Werner
Till Rettig | 2 Jun 2009 20:50
Picon
Picon

Re: bad German translation of convert-ly

Werner LEMBERG schrieb:
>
> The same under a German locale produces this:
>
>   Anwenden der Umwandlung: 2.11.15, 2.11.23, 2.11.35, 2.11.38,
>                            2.11.46, 2.11.48, 2.11.50, 2.11.51,
>                            2.11.52, 2.11.53, 2.11.55,
>     \put-adjacent Argumentreihenfolge.
>     kann nicht umgewandelt werdenAchse und Richtung jetzt vor die Beschriftung setzen:
>     \put-adjacent Achse Richtung Beschriftung Beschriftung.
>                            2.11.57, 2.11.60, 2.11.61, 2.11.62,
>                            2.11.64, 2.12.0, 2.12.3, 2.13.0, 2.13.1
>
> There are two severe mistakes:
>
>   . There must not be a full stop after `Argumentreihenfolge' since
>     first and second part of the sentence have been exchanged in
>     German.  As a solution I propose that the final `.' is not part of
>     the translation at all but gets separated.
>
>   . `werdenAchse' should be `werden.' + `\n' + `Achse'.
>   
Is this a question of the formatting or of the .po file? You can always 
fetch the po file from the translation project and make the according 
changes, send a patch to me and I will send it to the translation 
project's robot.

Greetings
Till
> I suspect that virtually all `NOT_SMART' translations are affected by
(Continue reading)

Werner LEMBERG | 2 Jun 2009 21:25
Picon

Re: bad German translation of convert-ly

>> There are two severe mistakes: [...]
>
> Is this a question of the formatting or of the .po file?

Yes and no.  As I've written, the final `.', for example, shouldn't be
part of the translation; such a change must be applied to the
convert-ly scripts (or its include files).

> You can always fetch the po file from the translation project and
> make the according changes, send a patch to me and I will send it to
> the translation project's robot.

Not enough time, sorry.

    Werner
codesite-noreply | 3 Jun 2009 00:32
Picon
Favicon

Issue 774 in lilypond: wrong horizontal trill position in small staff lines

Status: Accepted
Owner: lemzwerg
Labels: Type-Defect

New issue 774 by lemzwerg: wrong horizontal trill position in small staff  
lines
http://code.google.com/p/lilypond/issues/detail?id=774

\version "2.13.1"

\header { texidoc = "
The horizontal position of the beginning of a trill spanner must be
positioned correctly relative to the note head it is attached to, even if
scaled to a smaller size.

Here is a counterexample, clearly showing an unwanted horizontal shift.
This is a regression; it has worked with version 2.11.13, for example.
" }

<<
   \new Staff \with {
     fontSize = #-6
     \override StaffSymbol #'staff-space = #(magstep -6)
   }
   \relative {
     c'1\startTrillSpan | c\stopTrillSpan |
   }

   \new Staff \relative {
     c'1\startTrillSpan | c\stopTrillSpan |
(Continue reading)

John Mandereau | 3 Jun 2009 00:53
Picon

Re: bad German translation of convert-ly

Werner LEMBERG a écrit :
> As I've written, the final `.', for example, shouldn't be
> part of the translation; such a change must be applied to the
> convert-ly scripts (or its include files).
>
>   

> Not enough time, sorry.
>   

I'm sad to whistle the same tone, as the draft of my master thesis 
should be finished in 10 days and the thesis defense is on June 29th.
I'll have some oodles of time to spend in July and August, but in the 
meantime it would be cool if Till or another translator could handle
this issue.

John

Gmane