Hi Owen,
Le 6 août 2020 à 03:19, Owen Lamb a écrit :
Wow!
Thanks everyone... even if a lot of this went over my head. I've never
rebased before, so I can't say what would be the better option.
There are many tutorials on the Web about this, for instance
Wow!
Thanks everyone... even if a lot of this went over my head. I've never
rebased before, so I can't say what would be the better option.
At any rate, my understanding is that I'll organize my commits near the end
of the project to make sure everything is reviewable, correct? If that's
the
On Fri, Jul 31, 2020 at 9:59 PM Werner LEMBERG wrote:
> A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
> you change from the (IMHO preferable) `-` to `_` in the file name? I
> consider `_` an abomination that is only necessary because `-` is not
> a valid character in
Thanks for the tip! I just filed issue #4417 on their repo.
(I originally was going for the mailing list because I thought there might
be something wrong with our font files, not FontForge itself, and it'd be
premature to file a bug report. But I guess if FontForge can't fail
gracefully and tell
(Forgot to reply-all, so sending this to the mailing list as well.)
Hi Daniel,
I see what you mean. Judging from the example you offered, however, I
believe the issue is not one of scaling, but of origin misplacement. When
zoomed in, my current reproduction of Bravura appears to be too far to
Am Samstag, den 01.08.2020, 23:31 +0200 schrieb Jean Abou Samra:
> While I generally prefer merging over rebasing, since we enforce an
> all-fast-forward policy for merging to master, I think we should rebase
> here. My reasoning is that you put in more information when resolving
> conflicts
Well, there's a good reason that gitlab has a big, fat 'rebase'
button...
>>
>> Not sure about the meaning of your message: this button shows up
>> because we enabled it as a project-wide setting. To my knowledge,
>> the default and most common strategy is merging.
Exactly! It's our
Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra :
>Hi everyone,
>
>Le 01/08/2020 à 18:19, Urs Liska a écrit :
>> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
> Another issue: Maybe it makes sense if you try to rebase your
> branch from time to time.
Really
Hi everyone,
Le 01/08/2020 à 18:19, Urs Liska a écrit :
Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
Another issue: Maybe it makes sense if you try to rebase your
branch from time to time.
Really rebase?
Yes, I favour rebasing over merging since the former causes a
`prettier'
Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>> Another issue: Maybe it makes sense if you try to rebase your
>>> branch from time to time.
>>
>> Really rebase?
>
>Yes, I favour rebasing over merging since the former causes a
>`prettier' git commit tree.
>
>> This would be a case
>> Another issue: Maybe it makes sense if you try to rebase your
>> branch from time to time.
>
> Really rebase?
Yes, I favour rebasing over merging since the former causes a
`prettier' git commit tree.
> This would be a case where "general wisdom" argues against modifying
> pushed commits.
Am 1. August 2020 06:59:16 MESZ schrieb Werner LEMBERG :
>
>> In the meantime, I've gotten Bravura glyphs to appear on the page!
>
>Congrats!
>
>A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
>you change from the (IMHO preferable) `-` to `_` in the file name? I
>consider
> In the meantime, I've gotten Bravura glyphs to appear on the page!
Congrats!
A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
you change from the (IMHO preferable) `-` to `_` in the file name? I
consider `_` an abomination that is only necessary because `-` is not
a
Also, the best way to get at the FF devs is by opening an issue on
GitHub, where there are no issues with attachments.
On 8/1/20 12:34 AM, Daniel Benjamin Miller wrote:
Great work, Owen, and I'll be happy to use your implementation of
smufl in LilyPond, instead of having to deal with my own
Great work, Owen, and I'll be happy to use your implementation of smufl
in LilyPond, instead of having to deal with my own manual Bravura
conversions.
But the flags as they stand are not displaying at the same scale as they
do in Bravura when output by Dorico. See this file for a sample:
Hi all,
Thanks for your encouragement from last week! I took Monday off and made
sure not to overwork myself this week.
I tried posting to the public-music-notation-contrib mailing list with my
SMuFL proposals, but it turns out you have to be a member of the group to
do so. SMuFL's specs offered
16 matches
Mail list logo
