Re: [Issue #3947] fixing \huge et al.

Hi James, >> 'Accepted'. Is that better? Or at least sufficient? > No. I only filter on 'Started' Okay. >> null > Needs to be 'New'. Okay. > You can always go in and change these fields yourself manually. Okay. Thanks for the help! Kieren. Kieren MacMillan,

Re: [Issue #3947] fixing \huge et al.

On Sun, 25 Jun 2017 21:12:49 -0400 Kieren MacMillan wrote: > Hi James, > > > I am sure you know the process > > Actually, I *don't*. This will be my first patch. > > > make sure that there is a tracker issue > > > > > AND that the t

Re: [Issue #3947] fixing \huge et al.

Hi James, > I am sure you know the process Actually, I *don't*. This will be my first patch. > make sure that there is a tracker issue > AND that the tracker issue is marked as 'started' 'Accepted'. Is that better? Or at least sufficient

Re: [Issue #3947] fixing \huge et al.

Kieren, On Sun, 25 Jun 2017 11:35:37 -0400 Kieren MacMillan wrote: > Hi Marc, > > Thanks for the quick response. > > > I think that no response means "yes, submit a patch" in this case. > > If you checked your changes and did not find any negative effects, > > then submitting a patch is the be

Re: [Issue #3947] fixing \huge et al.

Hi Marc, Thanks for the quick response. > I think that no response means "yes, submit a patch" in this case. > If you checked your changes and did not find any negative effects, > then submitting a patch is the best way to go IMHO. Okay. > The guidance/mentoring is great in principle, but it is

Re: [Issue #3947] fixing \huge et al.

Hi Kieren, Am 25.06.2017 um 17:11 schrieb Kieren MacMillan: Hi, Another ten days has passed… I guess I don't understand how the Lilypond development process works. I keep hearing we need people to jump in and learn how to develop/improve Lilypond. I took the initiative, found an issue I tho

Re: [Issue #3947] fixing \huge et al.

Hi, Another ten days has passed… I guess I don't understand how the Lilypond development process works. I keep hearing we need people to jump in and learn how to develop/improve Lilypond. I took the initiative, found an issue I thought I could tackle, and offered a solution that appears to wor

Re: [Issue #3947] fixing \huge et al.

Hello, Just checking on this, since a week has passed since I asked… Should I start moving towards a submittable patch? Thanks, Kieren. > Hi David, > >> Maybe check the effects that super- and subscripts cause on a block of text? > > > Good thought. Doesn't seem to have a negative effect. >

Re: [Issue #3947] fixing \huge et al.

2017-06-07 21:53 GMT+02:00 Carl Sorensen : > > Is there any place else in the codebase where we include lilypond examples > in the doc strings? It seems like we ought to try for consistency; either > use lilypond examples in all of the doc strings (maybe at least for markup > functions) or in non

Re: [Issue #3947] fixing \huge et al.

Hi David, > Maybe check the effects that super- and subscripts cause on a block of text? Good thought. Doesn't seem to have a negative effect. Other thoughts? Or should I start moving towards a submittable patch? Thanks, Kieren. Kieren MacMillan, composer ‣ web

Re: [Issue #3947] fixing \huge et al.

Kieren MacMillan writes: > Hi Carl, > >> You have not yet tested your baseline-skip parameter with a different >> default-staff-size. I think that you will probably need to include the >> default baseline-skip when determining the new baseline-skip. Font sizes >> avoid this problem by using a s

Re: [Issue #3947] fixing \huge et al.

Hi Carl, > You have not yet tested your baseline-skip parameter with a different > default-staff-size. I think that you will probably need to include the > default baseline-skip when determining the new baseline-skip. Font sizes > avoid this problem by using a scale parameter. I don't know that

Re: [Issue #3947] fixing \huge et al.

On 6/7/17 2:01 PM, "Kieren MacMillan" wrote: >> Is there any place else in the codebase where we include lilypond >>examples >> in the doc strings? It seems like we ought to try for consistency; >>either >> use lilypond examples in all of the doc strings (maybe at least for >>markup >> function

Re: [Issue #3947] fixing \huge et al.

Hi Carl, Thanks for the helpful response. > The spacing appears pretty good to me. Excellent. > Seems like an abstracted function with two parameters (magstep and > baselineskip) would be about right. Of course, if you can determine > baselineskip from magstep, you would only need one paramete

Re: [Issue #3947] fixing \huge et al.

On 6/7/17 12:17 PM, "lilypond-devel on behalf of Kieren MacMillan" wrote: >Hello all, > >Thanks to some help (on the user-list) from David K, I've started to >attack issue #3947. >(I figured this would be a nice, relatively painless way to get my feet >wet in the dev/git/patch process.) > >The sn

[Issue #3947] fixing \huge et al.

Hello all, Thanks to some help (on the user-list) from David K, I've started to attack issue #3947. (I figured this would be a nice, relatively painless way to get my feet wet in the dev/git/patch process.) The snippet included below is what I have so far. It appears to work as hoped. Two ques