Re: issues 2266 and 1721
Le 13/04/2012 19:54, Phil Holmes disait :
- Original Message - From: "Jean-Charles Malahieude"
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present a
translated link towards "snippets", like @rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is "snippets/hauteurs.fr.html" which
doesn't exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is "snippets/pitches.fr.html" where I
want to go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present a
translated link towards "glossary" both in LM and NR, and I never get
any kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
"music-glossary/pitch-names.fr.html" where I want to arrive and it's a
perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and
why, though they look identical do they work differently according to
the target manual?
I thought I'd have a look at this, and have just been doing so. I think
the difference between learning and notation is that there is no
instance of @rlsrnamed or @rlsr in learning, whereas it's used
extensively in notation. So there's no difference in the file types,
except it's used in one and not in the other
The fact is that I've added a @rlsrnamed somewhere in the LM in order to
test.
Secondly, both @rglosnamed and @rlsrnamed should have the same effect:
neither glossary nor snippets are translated, an I wonder why I get no
problem at all with @rglosnamed as opposed to @rlsrnamed.
@macro rglosnamed{TEXT,DISPLAY}
@vindex \TEXT\
@ref{\TEXT\,,\DISPLAY\,music-glossary,Glossaire}
@end macro
@macro rlsrnamed{TEXT,DISPLAY}
@ref{\TEXT\,,\DISPLAY\,snippets,Morceaux choisis}
@end macro
and even adding a @vindex \TEXT\ to rlsrnamed doesn"t change anything.
Cheers,
Jean-Charles
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues 2266 and 1721
- Original Message -
From: "Jean-Charles Malahieude"
To: "Lily Bugs" ; "lilypond-devel"
Sent: Saturday, March 31, 2012 6:47 PM
Subject: Re: issues 2266 and 1721
Hi all,
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present a
translated link towards "snippets", like @rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is "snippets/hauteurs.fr.html" which doesn't
exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is "snippets/pitches.fr.html" where I want to
go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present a
translated link towards "glossary" both in LM and NR, and I never get any
kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
"music-glossary/pitch-names.fr.html" where I want to arrive and it's a
perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and why,
though they look identical do they work differently according to the
target manual?
Cheers,
Jean-Charles
I thought I'd have a look at this, and have just been doing so. I think the
difference between learning and notation is that there is no instance of
@rlsrnamed or @rlsr in learning, whereas it's used extensively in notation.
So there's no difference in the file types, except it's used in one and not
in the other
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond bug 2368
- Original Message - From: Karol Majewski To: Janek Warchoł Cc: LilyPond Developmet Team ; Lilypond Bugs Sent: Wednesday, April 11, 2012 7:33 PM Subject: Re: lilypond bug 2368 OK, thanks for explanation! Actually, I've menaged to solve my problem by entering hidden notes with unHidden slur in separate voice. Now the tie refers to the right notes and appeals to my sense of aesthetic - despite colliding with an accidental (take a look at the attachment). Janek, I'm not a student of Politechnika Warszawska - neither former nor present. I'm a former student of Akademia Muzyczna w Gdańsku :) Best Wishes Karol Majewski Check my suggestion at http://code.google.com/p/lilypond/issues/detail?id=2368 - it works better and is designed for this. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond bug 2368
OK, thanks for explanation! Actually, I've menaged to solve my problem by entering hidden notes with unHidden slur in separate voice. Now the tie refers to the right notes and appeals to my sense of aesthetic - despite colliding with an accidental (take a look at the attachment). Janek, I'm not a student of Politechnika Warszawska - neither former nor present. I'm a former student of Akademia Muzyczna w Gdańsku :) Best Wishes Karol Majewski 2012/4/11 Janek Warchoł > On Wed, Apr 11, 2012 at 2:36 AM, Colin Hall wrote: > > > > On Sat, Apr 07, 2012 at 05:32:28PM +0200, Karol Majewski wrote: > >> > >> Is it possible to mark 2368 bug as critical? I think this kind of > >> regression is a serious problem. Just take a look at my last > >> comment: > >> > >> http://code.google.com/p/lilypond/issues/detail?id=2368#c6 > > > > I agree with you that the notation output is not correct, especially > > in the sample you provide in comment 6. > > > > I'm going to do my best to explain why this issue should not be marked > > critical. I hope that others will correct my statements as necessary. > > > > You might not be aware that there are several open issues for Lilypond > > that relate to the typesetting of ties and slurs. For example see > > issue 298, referenced from issue 2368. > > > > http://code.google.com/p/lilypond/issues/detail?id=298 > > > > There are others. > > > > As I understand it the development team have identified that a better > > implementation of ties is possible but requires aesthetic design work > > to establish how this feature should work before technical > > implementation work can begin. The technical work may be substantial. > > Yes, i do think that it will make more sense to rewrite tie code > bearing in mind all bad tie cases instead of fixing the issues one by > one. Besides, i suppose that marking this as critical will have only > one result: next stable release will be postponed for 3 months or so. > It won't make the bug fixed immediately, nor even soon. > > > Janek has a study of Lilypond's typesetting of ties and slurs which is > > work in progress and which may provide the aesthetic design we > > need. He mentioned it in response to your original bug report: > > > > http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg01203.html > > Yes. The bad news is that i won't have time to finish it until > summer. However, if there's anyone willing to finish it, i can share > my results and provide some guidance. The task requires aesthetic > sense and analytical skills, and i estimate 40 hours of work is needed > to finish the tie analysis - no idea how long implementation will > take. > > Bottom line: find someone to finish tie report and implement it's > conclusions (or pay David to implement them - i will add EURO 50 from > myself if this is done before May 15). > > i hope that didn't sound too discouraging :) > Janek > > PS Karol, are you a (former) student of Warsaw University of > Technology, Faculty of Electronics (Elka)? > <>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
