On 3/20/22 11:50 PM, Werner LEMBERG wrote:
>>> * A glyph should be created for SMuFL's clefChangeCombining
>>>character.
>>
>> Really? Why?
>
> I was following precedent. Bravura includes it, even though it's a
> zero-width empty character.
OK.
>> If this is correct, no glyph is needed a
>>> * A glyph should be created for SMuFL's clefChangeCombining
>>> character.
>>
>> Really? Why?
>
> I was following precedent. Bravura includes it, even though it's a
> zero-width empty character.
OK.
>> If this is correct, no glyph is needed at all.
This was a bit sloppy. I meant 'no ne
High priority issues (I'd like to get these done before I begin
integrating my GSoC work):
* A glyph should be created for SMuFL's clefChangeCombining
character.
Really? Why?
I was following precedent. Bravura includes it, even though it's a
zero-width empty character.
As far as I unde
Hi Benkő,
On 3/19/22 02:00, Benkő Pál wrote:
Hi Owen,
Owen Lamb ezt írta (időpont: 2022. márc. 19., Szo, 7:38):
Hi Benkő,
On 3/17/22 10:05, Benkő Pál wrote:
re the longest rests:
1. a perfect longa rest and a maxima rest are not the same;
2. a perfect longa rest should take three spaces (li
Hi Owen,
Owen Lamb ezt írta (időpont: 2022. márc. 19., Szo, 7:38):
>
> Hi Benkő,
>
> On 3/17/22 10:05, Benkő Pál wrote:
>
> re the longest rests:
> 1. a perfect longa rest and a maxima rest are not the same;
> 2. a perfect longa rest should take three spaces (like current
> emmentaler rests.M3men
Hi Benkő,
On 3/17/22 10:05, Benkő Pál wrote:
re the longest rests:
1. a perfect longa rest and a maxima rest are not the same;
2. a perfect longa rest should take three spaces (like current
emmentaler rests.M3mensural), not four (as, I fear, the bravura
mensuralRestLongaPerfecta implies)
3. a ma
> I've finished mapping the last five glyph categories: Mensural,
> Neomensural, Petrucci, Solesmes, and Kievan. Of those, only the
> Mensural and Neomensural glyphs provided much trouble, but as
> always, extra pairs of eyes are encouraged to spot typos and other
> mistakes or give suggestions t
Hi Owen,
first: thanks for this work.
Owen Lamb ezt írta (időpont: 2022. márc. 17., Cs, 16:42):
>
> Hi all,
>
> I've finished mapping the last five glyph categories: Mensural,
> Neomensural, Petrucci, Solesmes, and Kievan. Of those, only the Mensural
> and Neomensural glyphs provided much troubl
Hi all,
I've finished mapping the last five glyph categories: Mensural,
Neomensural, Petrucci, Solesmes, and Kievan. Of those, only the Mensural
and Neomensural glyphs provided much trouble, but as always, extra pairs
of eyes are encouraged to spot typos and other mistakes or give
suggestions
Hi Jürgen,
Thank you so much! Apologies for the delayed reply.
*noteheads.uM2, noteheads.dM2*
IIRC, I have seen these noteheads various times in print (which does
not necessarily mean that they are an agreed standard), though I can
not immediately find an example to show. If I remember correc
Hi Owen,
first of all, thank you very much for all of your great work and
patience with those structures grown sometimes wildly over many years!
Here are my comments regarding the mapping specifically for ancient
notation glyphs.
noteheads.uM2, noteheads.dM2
IIRC, I have se
Hi all!
With the semester over, I found the time to get the next three glyph
categories mapped: Vaticana, Medicaea, and Hufnagel. Second pairs of
eyes are very welcome to catch mistakes and give suggestions, especially
regarding the contentious red entries:
https://wolfgangsta.github.io/emmen
>> Regarding "Ped" vs. "Ped.": What exactly do you mean with the
>> sentence I wonder if there's any way to map a SMuFL base name to a
>> sequence of Emmentaler glyphs.
>
> Emmentaler has a "Ped" glyph and a "." glyph, but no "Ped." glyph.
>
> SMuFL has a "." glyph and a "Ped." glyph; "Ped" is
Regarding "Ped" vs. "Ped.": What exactly do you mean with the sentence
I wonder if there's any way to map a SMuFL base name to a sequence
of Emmentaler glyphs.
Emmentaler has a "Ped" glyph and a "." glyph, but no "Ped." glyph.
SMuFL has a "." glyph and a "Ped." glyph; "Ped" is merely a
> Just got the next batch of glyphs in:
> https://wolfgangsta.github.io/emmentaler-bravura/. That completes
> the mapping of Feta to SMuFL (bar the still-contentious mappings).
Exellent, thanks a lot!
Regarding "Ped" vs. "Ped.": What exactly do you mean with the sentence
I wonder if there's
Hi all,
Just got the next batch of glyphs in:
https://wolfgangsta.github.io/emmentaler-bravura/. That completes the
mapping of Feta to SMuFL (bar the still-contentious mappings).
Parmesan's ancient notation glyphs are all that's left now!
There's just one questionable glyph matchup: accordio
Hi all,
Just wanted to give a quick half-update. I sent a message to the W3C
mailing list about the rotated arpeggio glyphs, so that should move
along soon.
I also discovered I'd missed a treasure trove of pre-encoded ornaments
in SMuFL! Things are matching up quite nicely now. There's just
>> * About the rotated wiggle glyphs in Bravura: Do you have any idea
>> why this is so? If not, can you please ask the SMuFL people? It
>> looks definitely wrong to me! They should either correct the
>> font or provide glyph name aliases for horizontal typesetting
>> (assuming that glyp
Hi Werner,
* about `trill_element` vs. `trillelement`: This was changed by Han-Wen in
commit c49e0fd544f (dated 2004) without any log messages. It looks
like an oversight that `trillelement` wasn't removed then.
Good to know! I'll put a further investigation/usage poll on the list of
side
> After a rather long hiatus, here's the next batch of glyphs (Script
> glyphs): https://wolfgangsta.github.io/emmentaler-bravura/. [...]
Again many thanks for your investigations.
* about signum congruentiae: I agree with you that the exact shape is
not significant since the variety of this
Hi all!
After a rather long hiatus, here's the next batch of glyphs (Script
glyphs): https://wolfgangsta.github.io/emmentaler-bravura/. There are a
couple oddities regarding arpeggios, trills, and the "signum
congruentiae" that warrant attention. If you have time, please check
them out and gi
That's right--good catch! I just pushed a fix. (SMuFL prefers -Black to
-Quarter, but otherwise you're spot on.)
Thanks for your help,
Owen
On 7/24/2021 6:31 AM, Mark Knoop wrote:
At 23:43 on 23 Jul 2021, Owen Lamb wrote:
Hi all! A few updates from the SMuFL front.
You have mapped both note
At 23:43 on 23 Jul 2021, Owen Lamb wrote:
Hi all! A few updates from the SMuFL front.
You have mapped both noteheads.s1triangle and noteheads.s2triangle to
noteheadTriangleHalf. Perhaps s2triangle should be noteheadTriangleQuarter?
--
Mark Knoop
Hello Owen,
thanks for updating the page. Everything looks very nice, and this
time I don't have comments :-)
Werner
Hi all! A few updates from the SMuFL front.
First off, Werner suggested the database gain a more permanent nature.
To that end, I've brought back rejected glyph matchups (in gray now) and
have begun adding links to mailing list discussions in the notes. I
shortened some of my notes where they
On 7/10/2021 9:38 PM, Werner LEMBERG wrote:
* Regarding `noteheads.uM2`, I don't see a problem with removing the
hard-coded stems.
That's good to hear. If we do, though, we'll have to reconcile
breve/longa sidebars with Lily's customizable stems. I'm thinking
we keep our breve glyphs for S
I suspected that. :-) It would be good if one could use the Bravura font
without external files, which perhaps should be integrated into the LilyPond
distribution.
> On 11 Jul 2021, at 01:33, Owen Lamb wrote:
>
> Thanks for the suggestion, Hans!
>
> Unfortunately, I have next to zero experie
>> * Regarding `noteheads.uM2`, I don't see a problem with removing the
>>hard-coded stems.
>
> That's good to hear. If we do, though, we'll have to reconcile
> breve/longa sidebars with Lily's customizable stems. I'm thinking
> we keep our breve glyphs for SMuFL compatibility, but in LP it
Hi Karlin,
I looked over the list, focusing on the shape notes. Nothing stood out
to me as being wrong, although I have no skill for the font design
concerns here.
To be honest, neither do I. I'm just making sure the glyphs match up and
are categorized correctly, which is more an archival pers
Thanks for the suggestion, Hans!
Unfortunately, I have next to zero experience actually designing new
glyphs, so I'm not (yet?) the guy to ask about that. Right now, my
number-one priority is making our existing font SMuFL-compliant and
giving LilyPond SMuFL support, after which (I stress: I c
Hi Werner,
* Regarding `noteheads.uM2`, I don't see a problem with removing the
hard-coded stems.
That's good to hear. If we do, though, we'll have to reconcile
breve/longa sidebars with Lily's customizable stems. I'm thinking we
keep our breve glyphs for SMuFL compatibility, but in LP its
On 7/9/2021 9:09 PM, Owen Lamb wrote:
I've dropped in the next few Emmentaler categories (Default Noteheads,
Special Noteheads, and Shape-note Noteheads), so feel free to give it a
look at https://wolfgangsta.github.io/emmentaler-bravura/. Please let me
know what you think, especially regarding
> On 10 Jul 2021, at 04:09, Owen Lamb wrote:
>
> A bit of news on the SMuFL front. I've dropped in the next few Emmentaler
> categories (Default Noteheads, Special Noteheads, and Shape-note Noteheads),
> so feel free to give it a look at
> https://wolfgangsta.github.io/emmentaler-bravura/. P
> A bit of news on the SMuFL front. I've dropped in the next few
> Emmentaler categories (Default Noteheads, Special Noteheads, and
> Shape-note Noteheads), so feel free to give it a look at
> https://wolfgangsta.github.io/emmentaler-bravura/. Please let me
> know what you think, especially regar
Hi all!
A bit of news on the SMuFL front. I've dropped in the next few
Emmentaler categories (Default Noteheads, Special Noteheads, and
Shape-note Noteheads), so feel free to give it a look at
https://wolfgangsta.github.io/emmentaler-bravura/. Please let me know
what you think, especially reg
>> Indeed. Care to open an SMuFL issue at their site?
>
> Do you mean we propose that SMuFL *itself* should explicitly
> recommend that programs default to timeSigX when the other number
> sets aren't present?
I think I was slightly confused, trying to apply Unicode principles on
SMuFL. Howeve
Hi Werner,
Indeed. Care to open an SMuFL issue at their site?
Do you mean we propose that SMuFL *itself* should explicitly recommend
that programs default to timeSigX when the other number sets aren't
present? I doubt we'd find success there; I only meant it'd be less
awful for Emmentaler to
>> * Number sets: Since LilyPond uses the same glyphs for time
>> signatures, figured bass, and fingerings, we probably have to map
>> the Emmentaler glyphs to all SMuFL sets, irrespective of the
>> size. In general, I think that size issues are only to be
>> considered if the size matters
Hi Werner,
* Number sets: Since LilyPond uses the same glyphs for time
signatures, figured bass, and fingerings, we probably have to map
the Emmentaler glyphs to all SMuFL sets, irrespective of the size.
In general, I think that size issues are only to be considered if
the size matter
Le 13/06/2021 à 04:23, Owen Lamb a écrit :
Hi all,
It's been a while, and I apologize. Evidently I'm not as good at
managing my own schedule as I thought I'd be.
That said, I'd like to pick up where I left off, choosing once and for
all what LilyPond glyphnames (i.e. clefs.G) go with what SM
Hello Owen!
> Instead of an Excel sheet, I've prepared a somewhat janky GitHub
> Pages site here: https://wolfgangsta.github.io/emmentaler-bravura/.
> It includes my current opinions on what glyphs should match up
> where, and indicates possibly contentious decisions.
Aah, *much* better, thanks
Hi all,
It's been a while, and I apologize. Evidently I'm not as good at
managing my own schedule as I thought I'd be.
That said, I'd like to pick up where I left off, choosing once and for
all what LilyPond glyphnames (i.e. clefs.G) go with what SMuFL
glyphnames (i.e. gClef), so that, in th
42 matches
Mail list logo
