Re: SMuFL text font alignment (Bravura Text, etc.)

My thought is that for a super quick and dirty first pass, font authors should rescale each range so that the largest glyph in each range fills the space between base-line and caps height, and then manual scalling can take place from there.  For instance the Octaves (E510-E51F) range act like normal font characters, so few if any further adjustments would need to be made.  The dynamics range should probably be scaled (at least E520 - E53D) so that the “r” glyph fits as “x-height” (or a high x-height) and the “f” and “p” characters should not extend below the descender range.  Lyric elisions (E550-E55F) would need to be handled separately to not fill the whole space but rest on or just below the baseline.  For notes with stems, I’d break everything into half (+whole and breve) to 32nd, and then scale separately 64th to 1024th.  Combining figures (such as the combining tremolos) would be more complex — Ideally they would be able to combine with noteQuarterStemUp, but these are ideals that shouldn’t prevent a useful immediately practice.  Getting an implementation where the most basic symbols (common notes, accidentals, articulations) work fine would then let the community start defining ranges that need more individual tweaking.  As it is, I still use Yo Tomita's Bach font when I want to combine text and musical symbols instead of a SMuFL font as I’d like to.

Thanks!

Best,
Myke



> On Nov 5, 2017, at 04:55, Peter Stadler <stadler@weber-gesamtausgabe.de> wrote:
> 
> Hello Myke et al.,
> 
> just wanted to second this proposal: at present it’s quite cumbersome dealing with musical symbols in texts – you have to almost adjust (resize, offset) every glyph manually to fit the line / the context. Hence, creating visually appealing HTML versions automatically is almost impossible.
> 
> But I really have no idea how to fix this, since it depends on context so much – your example with the sharp next to a note is a good one. How do you keep proportions when adjusting everything to line height?
> 
> Cheers
> Peter
> 
>> Am 05.11.2017 um 00:55 schrieb Michael Scott Cuthbert <cuthbert@mit.edu>:
>> 
>> Hello all,
>> 
>> I think the initial idea behind the Text version of SMuFL fonts was my own, but so far they haven’t been implemented (at least in Bravura Text) in a way that helps my particular use case, so if possible I’d like to start a discussion around that.
>> 
>> The idea was that text versions of SMuFL fonts would include glyphs that look properly sized for use in the context of lines or paragraphs of text without needing special formatting to prevent disrupting the overall layout.  For instance, the unicode sharp ♯ is designed so that at 12 point it fits largely within a line width of 12-14 points.  Similarly for a unicode flat ♭ and other characters that have been included in the various unicode standards .  Some symbols such as most implementations of quarter note ♩ haven’t worked as well, but the general principle is to try to scale everything so it fits within a line.  This means though that the proportions between the symbols is often distorted, such as putting a sharp next to a note: ♯♩ the sharp is way too big for use in music notation next to the note, but it is very clear in text (and in general, one wouldn’t use these two symbols adjacent to each other).
>> 
>> I was wondering if the utility of Bravura Text and other SMuFL text-fonts would be improved if such a principle were adhered to — so clefs would be much smaller than normal and accidentals, ornaments, etc. would be much larger than normal.  Ideally, characters that might be used near each other would be scaled such that they would generally maintain their visual clarity, but fitting within a line would override this concern (e.g., a whole note would be only a little larger than the notehead of a half note with stem, and that would be the same size as a quarter, eighth, sixteenth, and possibly 32nd note, but a 512th note would need to be shrunk dramatically in order to fit).  Probably, symbols such as raise and lower staff positions would not be implemented in a text font (or would be compacted so much as to make little difference).  I realize that my initial proposal must have been quite unclear, but I can imagine many good uses for such a font standard, such as in the user interface for notation software (right now, Noteflight uses .svg files for its user interface, but it could be done with a text font like this one).
>> 
>> Thanks for listening.
>> 
>> Best,
>> Myke
>> 
>> ---                                                     ---
>> Michael Scott Cuthbert
>> 
>> Faculty Director, Digital Humanities, MIT             4-215
>> Associate Professor of Music, MIT
>>    +1.413.575.6024
>> cuthbert@mit.edu                    http://www.trecento.com

>> 
>> 
>> 
>> 
> 
> --
> Peter Stadler
> Carl-Maria-von-Weber-Gesamtausgabe
> Arbeitsstelle Detmold
> Hornsche Str. 39
> D-32756 Detmold
> Tel. +49 5231 975-676
> Fax: +49 5231 975-668
> stadler at weber-gesamtausgabe.de
> www.weber-gesamtausgabe.de
>

Received on Sunday, 5 November 2017 14:46:47 UTC