Re: Font_metric code cleanup breaks fetaText positioning
On 2010-03-22, Han-Wen Nienhuys wrote: > On Mon, Mar 22, 2010 at 11:02 PM, Patrick McCarty > wrote: > > > > Previous to your changes, IIRC, text_stencil() was never called. > > Are you sure? > > SCM > Text_interface::interpret_string (SCM layout_smob, > SCM props, > SCM markup) > > -which powers all markup text- is basically a call to > Font_metric::text_stencil(). True. I see why this is so confusing. I'll try my best to explain. * Before the API changes, Text_interface::interpret_string() called Font_metric::word_stencil(), which then called Font_metric::text_stencil(). The confusing thing is that Pango_font::text_stencil() was overloaded, in order to filter text with a tight or non-tight bbox. Only *one* of these functions was called: Stencil Pango_font::text_stencil (string str, bool music_string, bool tight) const The other one, with two parameters, was never called: Stencil Pango_font::text_stencil (string str, bool music_string) const The only possible way to enter "non-tight bbox" mode was to call this second function. Since it was never called, the "tight bbox" was always used for both fetaText markup and normal text markup. * Does this all make sense? In what situations would a "non-tight" bbox be useful, since we don't appear to be using it right now? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On Mon, Mar 22, 2010 at 11:02 PM, Patrick McCarty wrote: > On Mon, Mar 22, 2010 at 6:41 PM, Han-Wen Nienhuys wrote: >> On Mon, Mar 22, 2010 at 10:39 PM, Han-Wen Nienhuys wrote: Okay, pushed. Let me know if you find any problems. >>> >>> doesnt this equally mess up the vertical alignment, this time of normal >>> text? >> >> More to the point, I'd expect the fix to be adding another property >> (font-tight-rendering, or similar), which controls the tight vs. >> nontight mode; time sigs and similar would use the tight mode. > > Previous to your changes, IIRC, text_stencil() was never called. Are you sure? SCM Text_interface::interpret_string (SCM layout_smob, SCM props, SCM markup) -which powers all markup text- is basically a call to Font_metric::text_stencil(). -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository with fixed history ready
On 3/22/10 7:49 PM, "Graham Percival" wrote: > On Mon, Mar 22, 2010 at 09:18:40AM +0100, Jan Nieuwenhuizen wrote: >> There's one small problem with replacing the old repository, >> *all* committishes change, and everyone will have to make >> a fresh clone, and any work based on the old repository >> must be copied over to the new clone using git format-patch >> and git am. > > Could somebody translate for the git-impaired? > > - if I have no non-pushed commits, do I need to do anything? No. > > - does anything need to happen to branches like dev/waf ? (again, > assuming that we have pushed everything) No. > > - if we tell new contributors to remove their lilypond-git dirs > before the changeover, then tell them to run lily-git after the > changeover, will it work? Yes. If a user has *non-pushed* branches, then the proper way to deal with it, IIUC, is to clone a new repository. Then create a branch from the equivalent commit in the new repository. Create a patch in the old repository, and apply the patch to the new repository. But for people who don't have *non-pushed* branches around, it should be no problem. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On Mon, Mar 22, 2010 at 6:41 PM, Han-Wen Nienhuys wrote: > On Mon, Mar 22, 2010 at 10:39 PM, Han-Wen Nienhuys wrote: >>> >>> Okay, pushed. Let me know if you find any problems. >> >> doesnt this equally mess up the vertical alignment, this time of normal text? > > More to the point, I'd expect the fix to be adding another property > (font-tight-rendering, or similar), which controls the tight vs. > nontight mode; time sigs and similar would use the tight mode. Previous to your changes, IIRC, text_stencil() was never called. text_stencil() might have had callers when the "char" and "text" stencil expressions were still used, but I think those were obsoleted a while ago. In other words, I don't think a "tight" versus "non-tight" bbox is still relevant. Though I could be wrong. I'll do a regtest check later, but the vertical alignment of normal text looks okay upon casual inspection. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository with fixed history ready
On Mon, Mar 22, 2010 at 09:18:40AM +0100, Jan Nieuwenhuizen wrote: > There's one small problem with replacing the old repository, > *all* committishes change, and everyone will have to make > a fresh clone, and any work based on the old repository > must be copied over to the new clone using git format-patch > and git am. Could somebody translate for the git-impaired? - if I have no non-pushed commits, do I need to do anything? - does anything need to happen to branches like dev/waf ? (again, assuming that we have pushed everything) - if we tell new contributors to remove their lilypond-git dirs before the changeover, then tell them to run lily-git after the changeover, will it work? if the answer to any of those questions is yes... I mean no... I mean, if the answers aren't no, no, yes... then I'd like to move more slowly on this. If the answers *are* no, no, yes, then let's declare Thurs 25 March as the changeover date and get it over with. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On Mon, Mar 22, 2010 at 10:39 PM, Han-Wen Nienhuys wrote: >>> > Your first patch from the set you've pushed breaks the positioning of >>> > fetaText glyphs, since they now all have logical extents in the Y axis >>> > (rather than ink extents). >>> >>> I have a patch in-progress, so I'll push a fix shortly. >> >> Okay, pushed. Let me know if you find any problems. > > doesnt this equally mess up the vertical alignment, this time of normal text? More to the point, I'd expect the fix to be adding another property (font-tight-rendering, or similar), which controls the tight vs. nontight mode; time sigs and similar would use the tight mode. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On Mon, Mar 22, 2010 at 6:54 PM, Patrick McCarty wrote: >> > Your first patch from the set you've pushed breaks the positioning of >> > fetaText glyphs, since they now all have logical extents in the Y axis >> > (rather than ink extents). >> >> I have a patch in-progress, so I'll push a fix shortly. > > Okay, pushed. Let me know if you find any problems. doesnt this equally mess up the vertical alignment, this time of normal text? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On Mon, Mar 22, 2010 at 6:02 PM, Neil Puttock wrote: > Your first patch from the set you've pushed breaks the positioning of > fetaText glyphs, since they now all have logical extents in the Y axis > (rather than ink extents). > > I've attached picture with the debug code for checking extents > switched on (the circle is supposed to be a string number :) Ouch - can someone pass me the brown-paper bag? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository with fixed history ready
On 2010-03-22, Jan Nieuwenhuizen wrote: > > I've taken another look at fixing lily's history this weekend, > it should be ready now to replace our old broken repository, > have a look at the result > > git clone http://lilypond.org/people/janneke/vc/hysterical-lily.git Wow, this is very awesome! That must have been a tremendous effort. :) Just a side note: cloning over HTTP by default is really inefficient right now, so the download size of the above repo is ~900MB. After running `git gc --aggressive', the repo shrinks to the normal size (~120MB). > Our current GIT archive suffers from major problems in the > CVS->GIT conversion, and also at the time of CVS conversion > (looong ago), so if you go further back than release 1.5.49, > you get eventually into some sort of crappy cycles like > > 3114c9b lilypond-0.0.1 > 673ae03 lilypond-0.0.9 > 3d9b7e6 lilypond-0.0.1 > 27058a7 lilypond-0.0.1 > f5a68ac lilypond-0.0.1 > 0292bf9 lilypond-0.0.1 > 1c3b8de flower-1.0.18 > 8e98b32 flower-1.0.2 > f53fdff lilypond-0.0.1 Yeah, I've noticed that. The new repo looks much better. > The new archive fixes this and has a smooth history line > all down to > > $ git log --abbrev-commit --pretty=oneline | tail > a7cbcf7 release: 0.0.3 > 8f9609a release: 0.0.2 > f9ae673 release: 0.0.1 > fc51c93 Initial. > > it contains all stable branches and tags and also fixes/ > unifies some weird email addresses from the CVS and pre-CVS > era. It is up-to date as of yesterday evening (6510c4a). This is mostly true. There are still some random commits that have CVS-style usernames. For example, in the new repo, $ git show bc86bf displays commit bc86bf019ae3d2f03c12e8b52527bd5eb48283f3 Author: jneem Date: Thu Aug 10 05:53:53 2006 + convert-ly the user manual But, overall, there are relatively few of these cases. Most of them have been fixed. > There's one small problem with replacing the old repository, > *all* committishes change, and everyone will have to make > a fresh clone, and any work based on the old repository > must be copied over to the new clone using git format-patch > and git am. I'm generally okay with this. Of course, it would be optimal to fix only the "pre-Git" part of LilyPond's history, but I imagine that would take a lot of work. Thanks a lot, Jan. This will be incredibly helpful for the Ohloh project page, too. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical defects and collisions
On 2010-03-22, Graham Percival wrote: > > Since last month, we have a net gain of 3 Critical issues. This isn't > the right direction for releasing 2.14. > > Defects: > IDStatus Priority Owner Summary > 915 Accepted Critical pnorcks Multi-measure rests dependent ... Unfortunately, I don't think I can tackle this one, so I've removed my name from the Owner field. My latest comment on this issue reflects my current understanding of the problem. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
Am Montag, 22. März 2010 19:50:47 schrieben Sie:
> On 22/03/10 14:56, Reinhold Kainhofer wrote:
> > Am Dienstag, 16. März 2010 18:04:37 schrieb Reinhold Kainhofer:
> > Initially I used \contextModifications {...}, but as Neil points out, all
> > parser keywords are supposed to be lowercase, so now we have the
> > ugly-looking \contextmodifications {...}...
> >
> > What do you think of this name, it is okay or too long/unclear?
>
> Both. How above xxx = \savecontext {...} (which is what your doing)?
No, that's not what I'm doint.
That's exactly what xxx=\context{..} does now. And by storing the whole
context, it will later on reset the whole context to the settings when the
assignment was done (in particular the \RemoveEmptyStaff context saves the
status of the \Staff context during lilypond's initialization and later on
simply applies all these settings, reverting later manual changes to \Staff...
My patch only stores a list of context modifications, without a particular
context attached. Think of it as storing just the contents of a \with block.
E.g.
xxx = \with {
\remove Clef_engraver
\consists Ambitus_engraver
}
> I've seen later replies and I don't like "\with" in this usage (I nearly
> wrote "context").
>
> By and large \ commands tend to be verbs or nouns, and I don't know how
> to "with" anything, and I've never ever set eyes on a "with".
> \with {blah...}
> {}
> is OK because the \with clause contains property values parameterizing
> the main context block.
That reasoning was also my motivation to not reuse \with, but add a new
keyword (although \with also works in this situation and is treated in the
parser just like the \contextmodifications keyword).
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variableand inserted into \context or \with
Am Montag, 22. März 2010 16:51:50 schrieben Sie: > Reinhold Kainhofer wrote Monday, March 22, 2010 3:45 PM > > > The patch allows this as well (It treats \with and > > \contextmodifications > > exactly the same)... However, \with just doesn't tell you that > > this is only > > about Context modifications. > > > > So, do you all think that we should only go with \with? > > I would prefer that. Are multiple \withs permitted? Yes, multiple nested \with are allowed, and \with is now also allowed as the value of a variable and inside a \context definition. That's basically all that my patch does (internally, it also adds a C++ object for \with instead of simply treating it as a scheme list of modifications). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On 22 March 2010 21:54, Patrick McCarty wrote: > Okay, pushed. Let me know if you find any problems. Cheers, Patrick. Looks fine so far. Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
On 2010-03-22, Patrick McCarty wrote: > > On 2010-03-22, Neil Puttock wrote: > > > > Your first patch from the set you've pushed breaks the positioning of > > fetaText glyphs, since they now all have logical extents in the Y axis > > (rather than ink extents). > > I have a patch in-progress, so I'll push a fix shortly. Okay, pushed. Let me know if you find any problems. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Font_metric code cleanup breaks fetaText positioning
Hi Neil, On 2010-03-22, Neil Puttock wrote: > Hi Han-Wen, > > Your first patch from the set you've pushed breaks the positioning of > fetaText glyphs, since they now all have logical extents in the Y axis > (rather than ink extents). I have a patch in-progress, so I'll push a fix shortly. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical defects and collisions
On 22 March 2010 20:33, Boris Shingarov wrote: >> 1027 Accepted Critical nobody Lyrics ignore minimum-Y-extent > > > This one, I have a suspicion that it may be related to the "Lyrics break > estimation of vertical spacing" bug I am working on. This is a documentation issue, since minimum-Y-extent is no longer used with VerticalAxisGroup grobs. There's a convert rule warning for this. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Font_metric code cleanup breaks fetaText positioning
Hi Han-Wen, Your first patch from the set you've pushed breaks the positioning of fetaText glyphs, since they now all have logical extents in the Y axis (rather than ink extents). I've attached picture with the debug code for checking extents switched on (the circle is supposed to be a string number :) Cheers, Neil <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical defects and collisions
1027 Accepted Critical nobody Lyrics ignore minimum-Y-extent This one, I have a suspicion that it may be related to the "Lyrics break estimation of vertical spacing" bug I am working on. If no one else is looking at 1027, it *might* make sense to treat them together while I am in that area of code. But for either/both to happen, I'd need a little help from Joe, to push me in the right direction re: understanding the design of the axis group interface. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
Ian Hulin writes:
> On 22/03/10 14:56, Reinhold Kainhofer wrote:
>> Am Dienstag, 16. März 2010 18:04:37 schrieb Reinhold Kainhofer:
>>> Am Freitag, 12. März 2010 14:41:20 schrieb Reinhold Kainhofer:
Our problems with \RemoveEmptyStaffContext resetting previous context
modifications highlights one problem we have: So far, it was not possible
to store a bunch of context modifications into a variable and apply them
later on.
>>>
>>> An updated patch is now available at
>>> http://codereview.appspot.com/475041
>>
>> Before I finally push this (I assume the silence means approval ;-) ), I just
>> want to bring up the issue how to name the new command to store context
>> modifications.
>>
>> Initially I used \contextModifications {...}, but as Neil points out, all
>> parser keywords are supposed to be lowercase, so now we have the ugly-looking
>> \contextmodifications {...}...
>>
>> What do you think of this name, it is okay or too long/unclear?
>>
> Both. How above xxx = \savecontext {...} (which is what your doing)?
No, it isn't. That's the whole point.
> By and large \ commands tend to be verbs or nouns, and I don't know
> how to "with" anything, and I've never ever set eyes on a "with".
It is setting a variable to material to be used in a \with clause, just
like
varname = \chordmode { ... }
os setting a variable to material to be used in \chordmode clauses or
equivalent.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
On 22/03/10 14:56, Reinhold Kainhofer wrote:
Am Dienstag, 16. März 2010 18:04:37 schrieb Reinhold Kainhofer:
Am Freitag, 12. März 2010 14:41:20 schrieb Reinhold Kainhofer:
Our problems with \RemoveEmptyStaffContext resetting previous context
modifications highlights one problem we have: So far, it was not possible
to store a bunch of context modifications into a variable and apply them
later on.
An updated patch is now available at
http://codereview.appspot.com/475041
Before I finally push this (I assume the silence means approval ;-) ), I just
want to bring up the issue how to name the new command to store context
modifications.
Initially I used \contextModifications {...}, but as Neil points out, all
parser keywords are supposed to be lowercase, so now we have the ugly-looking
\contextmodifications {...}...
What do you think of this name, it is okay or too long/unclear?
Both. How above xxx = \savecontext {...} (which is what your doing)?
I've seen later replies and I don't like "\with" in this usage (I nearly
wrote "context").
By and large \ commands tend to be verbs or nouns, and I don't know how
to "with" anything, and I've never ever set eyes on a "with".
\with {blah...}
{}
is OK because the \with clause contains property values parameterizing
the main context block.
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Critical defects and collisions
Hi all, Since last month, we have a net gain of 3 Critical issues. This isn't the right direction for releasing 2.14. Defects: ID Status PriorityOwner Summary 786 AcceptedCriticalnobody Extenders in lyrics stop prematurely if a single underscore is found 818 Started Criticaln.puttock Bus error when adding Instrument_name_engraver to StaffGroup and outputting MIDI. 915 AcceptedCriticalpnorcks Multi-measure rests dependent on prefatory matter in other staves 917 AcceptedCriticalnobody Regression: Full-bar rests take more space at the beginning of a line 943 Started Criticaln.puttock input/regression/slur-broken-trend.ly broken 1027AcceptedCriticalnobody Lyrics ignore minimum-Y-extent 1031AcceptedCriticalnobody constantly-changing input/regression/rest-collision-beam-note.ly 1042AcceptedCriticalnobody Broken regtest: spanner-break-overshoot.ly Collisions: ID Status PriorityOwner Summary 881 AcceptedCriticalnobody Arpeggios may collide with laissezVibrer ties 974 AcceptedCriticalnobody music overflows page There's also some doc and build items, but I'm working on those with the new doc editors. all critical items: http://code.google.com/p/lilypond/issues/list?can=2&q=priority=Critical&colspec=ID Type Status Priority Milestone Owner Summary Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
> So, do you all think that we should only go with \with? \with is fine for me. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
Reinhold Kainhofer writes:
> Am Montag, 22. März 2010 16:15:31 schrieb David Kastrup:
>> Can't you just use
>>
>> whatever = \with { \remove "Some_engraver" }
>>
>> for those objects?
>>
>> It would seem that this syntax is not yet taken.
>
> The patch allows this as well (It treats \with and \contextmodifications
> exactly the same)... However, \with just doesn't tell you that this is only
> about Context modifications.
I was not aware that \with was used for anything apart context
modifications.
> So, do you all think that we should only go with \with?
Seems good enough for me.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 22. März 2010 16:15:31 schrieb David Kastrup:
> Can't you just use
>
> whatever = \with { \remove "Some_engraver" }
>
> for those objects?
>
> It would seem that this syntax is not yet taken.
The patch allows this as well (It treats \with and \contextmodifications
exactly the same)... However, \with just doesn't tell you that this is only
about Context modifications.
So, do you all think that we should only go with \with?
Cheers,
Reinhold Kainhofer
- --
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFLp5CQTqjEwhXvPN0RAiPQAJ9zX6MOA/mE1IazyrW9J972u+7ZdgCg2j9C
/fHPxpK3j7Ul2HQ/rmEyAJg=
=mytr
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
Reinhold Kainhofer writes:
> Am Dienstag, 16. März 2010 18:04:37 schrieb Reinhold Kainhofer:
>> Am Freitag, 12. März 2010 14:41:20 schrieb Reinhold Kainhofer:
>> > Our problems with \RemoveEmptyStaffContext resetting previous context
>> > modifications highlights one problem we have: So far, it was not possible
>> > to store a bunch of context modifications into a variable and apply them
>> > later on.
>>
>> An updated patch is now available at
>> http://codereview.appspot.com/475041
>
> Before I finally push this (I assume the silence means approval ;-) ), I just
> want to bring up the issue how to name the new command to store context
> modifications.
>
> Initially I used \contextModifications {...}, but as Neil points out, all
> parser keywords are supposed to be lowercase, so now we have the ugly-looking
> \contextmodifications {...}...
>
> What do you think of this name, it is okay or too long/unclear?
Can't you just use
whatever = \with { \remove "Some_engraver" }
for those objects?
It would seem that this syntax is not yet taken.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Allow context modifications to be stored in a variable and inserted into \context or \with
Am Dienstag, 16. März 2010 18:04:37 schrieb Reinhold Kainhofer:
> Am Freitag, 12. März 2010 14:41:20 schrieb Reinhold Kainhofer:
> > Our problems with \RemoveEmptyStaffContext resetting previous context
> > modifications highlights one problem we have: So far, it was not possible
> > to store a bunch of context modifications into a variable and apply them
> > later on.
>
> An updated patch is now available at
> http://codereview.appspot.com/475041
Before I finally push this (I assume the silence means approval ;-) ), I just
want to bring up the issue how to name the new command to store context
modifications.
Initially I used \contextModifications {...}, but as Neil points out, all
parser keywords are supposed to be lowercase, so now we have the ugly-looking
\contextmodifications {...}...
What do you think of this name, it is okay or too long/unclear?
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup: sort header order, use explicit std:: prefix rather than using std; (issue681041)
On Mon, Mar 22, 2010 at 3:24 AM, Werner LEMBERG wrote: >> there are some backward incompatible changes (removal of SCM >> functions), but I believe it should be safe, because the functions >> were not useful, little used anyway. > > In case someone has been using them, are there workarounds to > reestablish the functionality? Good question; I am not sure if there are any sensible uses anyway. (ly:get-glyph uses get_ascii_char which is not really appropriate for either pango fonts or the music fonts). -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PDF Named Destinations at each bar number
Hi Everyone,
I am trying add a feature to Lilypond but I have looked through the code a
fair amount and really have no idea what is going on. I'm hoping someone may
be able to give me some pointers (no pun intended).
I am hoping to modify Lilypond so that a 'named destiation' pdfmark may be
included in the postscript ouptut for each bar number. The aim is to be able
to jump to any place in the music according to bar number. ie. going to the
named destination 'bar.12' would move the music to the twelth bar.
>From my very limited understanding of Lilypond and postscript I think I
would need to write out a pdfmark line to the postscript on the correct
page, and in that line I would need to include the bar number and it's x and
y coordinates.
Could someone maybe suggest which areas of the code I would need to
understand to achieve this, and how I might go about it?
I have been unable to find a good description of how lilypond works
internally (at least in terms of laying out the music in postscript).
Any help would be appreciated, thanks.
Amiel
--
Below is a few notes about what I have seen and have been trying so far.
I have been reading about pdfmarks and have added a new postscript function
to create the required pdfmark in music-drawing-routines.ps (based on the
mark_URI entry).
---
/mark_DEST_xy
{ /name exch def
/left exch def
/top exch def
[ /Dest name
/View [ /XYZ x y NULL ]
/DEST pdfmark
} bind def
I see that a mark_URI line is created in ouput-ps.scm like:
(ly:format "~4f ~4f ~4f ~4f (textedit://~a:~a:~a:~a) mark_URI\n"
(+ (car offset) (car x-ext))
(+ (cdr offset) (car y-ext))
(+ (car offset) (cdr x-ext))
(+ (cdr offset) (cdr y-ext))
;; Backslashes are not valid
;; file URI path separators.
(ly:string-percent-encode
(ly:string-substitute "\\" "/" file))
(cadr location)
(caddr location)
(cadddr location))
-
So from that I figure I will probably need to have some code in
output-ps.scm
to create the pdfmark in the ps file such as:
(ly:format "~4f ~4f bar.~l mark_DEST_xy\n"
()
()
())
where the are replaced by scheme which returns the relevent values.
I have no idea how to get these required values, or where to put this code
snippet.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository with fixed history ready
Op maandag 22-03-2010 om 10:34 uur [tijdzone +0100], schreef Francisco Vila: > 2010/3/22 Jan Nieuwenhuizen : > Great! Thanks. Let's move. Thanks! Don't we need some kind of coordination for this? Hmm, looking at IRC it seems that everyone is still asleep, this may indeed be a good time ;-) > Hopefully stats will improve from > > http://paconet.org/lilypond-statistics/files.html > > to something real. Yes, that too. Also, I've added gcc-ancient to GUB which makes it possible (with some hackery) to build real old versions. > My advice to translators is to keep the old repository until output of > make-check is saved onto a file, and make two versions of it, coloured > and no-color. Some diffs are not visible in coloured version. Right. It so happens that I did update/rewrite the latest translation committishes in HEAD, and verified that check-translation produces the same diff for spanish. Of course, translators are probably working on things... Ah, which reminds me, the french translation had some problems, notably it uses soms committishes that do not exist: skipping: 3fd3ac03336676739982f4554be5c751f1d02ee9 skipping: 4c1851bab1e5e5d4aa4465eb20de2b2694aaf37a skipping: 9d789d3cb5f3b0f227d28d16b81f79dd1dfd2927 iwbn if they could be fixed (see: git grep -E '3fd3ac|4c1851|9d789') Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git repository with fixed history ready
2010/3/22 Jan Nieuwenhuizen : > Hi, > > I've taken another look at fixing lily's history this weekend, > it should be ready now to replace our old broken repository, Great! Thanks. Let's move. > Our current GIT archive suffers from major problems in the > CVS->GIT conversion, and also at the time of CVS conversion > (looong ago), Hopefully stats will improve from http://paconet.org/lilypond-statistics/files.html to something real. This deserves a new code_swarn video with the full history. > There's one small problem with replacing the old repository, > *all* committishes change, and everyone will have to make > a fresh clone, and any work based on the old repository > must be copied over to the new clone using git format-patch > and git am. My advice to translators is to keep the old repository until output of make-check is saved onto a file, and make two versions of it, coloured and no-color. Some diffs are not visible in coloured version. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
git repository with fixed history ready
Hi, I've taken another look at fixing lily's history this weekend, it should be ready now to replace our old broken repository, have a look at the result git clone http://lilypond.org/people/janneke/vc/hysterical-lily.git Our current GIT archive suffers from major problems in the CVS->GIT conversion, and also at the time of CVS conversion (looong ago), so if you go further back than release 1.5.49, you get eventually into some sort of crappy cycles like 3114c9b lilypond-0.0.1 673ae03 lilypond-0.0.9 3d9b7e6 lilypond-0.0.1 27058a7 lilypond-0.0.1 f5a68ac lilypond-0.0.1 0292bf9 lilypond-0.0.1 1c3b8de flower-1.0.18 8e98b32 flower-1.0.2 f53fdff lilypond-0.0.1 The new archive fixes this and has a smooth history line all down to $ git log --abbrev-commit --pretty=oneline | tail a7cbcf7 release: 0.0.3 8f9609a release: 0.0.2 f9ae673 release: 0.0.1 fc51c93 Initial. it contains all stable branches and tags and also fixes/ unifies some weird email addresses from the CVS and pre-CVS era. It is up-to date as of yesterday evening (6510c4a). There's one small problem with replacing the old repository, *all* committishes change, and everyone will have to make a fresh clone, and any work based on the old repository must be copied over to the new clone using git format-patch and git am. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
