[smufl-discuss] Re: Some ideas

[T.J. Usiyan]

Interesting. With that in mind I still think that option 1 is viable.
We would want a rather large range but it provides the _ability_ to
handle everything you described without demanding that any font have
it.

It could actually make combining the glyphs easier. If a glyph for
"Major" is found then the application has one object to lay out
instead of 5.

Regardless, I think that we should consider a few of the pieces you
mentioned like the bar for "over" (maybe as 2. The slash and the
horizontal bar) and parenthesis as fixed code points.

TJ

On Fri, May 31, 2013 at 11:45 AM, Daniel Spreadbury
<[hidden email]> wrote:

> Thanks for this suggestion, TJ.
>
> My initial reaction to this proposal is that it will be hard to come up
> with a relatively small number of components that could be combined
> flexibly enough to produce a similarly flexible representation of chord
> symbols.
>
> Typically existing scoring applications have entire fonts with upwards of
> 200 glyphs (Opus Chords, for example, has 212; Jazz Chords has 227).
> Catering for all of the different ways the basic chord qualities can be
> rendered (M, m, ma, maj, etc. just for "major") and being able to create
> stacks of up to three digits, with accidentals, and parentheses, plus
> optional bass notes (ideally with the means to show the chord symbol like
> a fraction, with the main chord offset up and left, and the bass note
> offset down and right, with a fraction slash inbetween) seems like it
> might be outside the scope of SMuFL.
>
> The ideal scoring application should be able to use any reasonable text
> font for the root/bass notes and required digits, and should only need to
> resort to a SMuFL-compliant font for special symbols (accidentals, plus
> major 7, diminished, half-diminished symbols), which is why my initial
> proposal for SMuFL only includes these symbols.
>
> I'm somewhat uncomfortable even with encoding e.g. 'D.S.' and 'D.C.'
> (which are included because they're part of the Unicode Musical Symbols
> range) since this forces us to include some text characters in a specific
> typeface, whereas it really seems that in all scoring applications the end
> user ought to have control over the text font families used for as many
> kinds of text as possible.
>
> Daniel
>
> "SMuFL Discussion" <[hidden email]> wrote on 31/05/2013
> 16:26:40:
>
>> From: "T.J. Usiyan" <[hidden email]>
>> To: "SMuFL Discussion" <[hidden email]>
>> Date: 31/05/2013 16:26
>> Subject: [smufl-discuss] Re: Some ideas
>> Sent by: "SMuFL Discussion" <[hidden email]>
>>
>> I should add that option 1 places a burden of discovery on the
>> application developer. The application must figure out what chord
>> symbols are available using whatever metadata we provide and alter its
>> drawing behavior appropriately.
>>
>> TJ
>>
>> On Fri, May 31, 2013 at 11:24 AM, T.J. Usiyan <[hidden email]>
> wrote:
>> > I suggest that we set aside a range for Chord Symbol ligatures.
>> > Because I am not completely familiar with how ligatures work, I will
>> > propose three courses of action to complement the use of this range.
>> >
>> > 1. Along with this we establish a metadata key for what symbol the
>> > code point represents so that the font creator can represent what text
>> > the ligature should replace. This allows the most freedom in
>> > implementation but presents no uniformity of what text is used for
>> > chord symbols.
>> >
>> > 2. We agree upon a set of basic chord quality components (Major,
>> > Minor, Diminished, Augmented, Half Diminished, Suspended, Perfect
>> > etc…) and their code points. I think that numeric digits 0-9 would
>> > simply be their own components. It is then up to the font creator to
>> > decide if the ligature will be the full text ("Major"), an
>> > abbreviation ("Maj" or "Ma"), or a symbol ("∆"). We would then
> combine
>> > the ligature for Major with the number.
>> >
>> > 3. Much like option 2 except we also agree upon a fixed number of
>> > variations for each component. I propose the three listed: Full,
>> > Abbreviation, and Symbol. We might still use UFO or some such metadata
>> > to hint at what exact text the abbreviation represents or we might
>> > not.
>> >
>> > My order of preference would be 3, 1 then 2 but I admit that I am
>> > still very new to programmatic engraving. All of this said, my real
>> > point is that I think Ligatures can be the foundation of a solution
>> > for chord symbols and roman numerals. (We do not need to represent an
>> > infinite number of roman numerals. I am not sure that we even need
>> > more than 7) If the font creator does not implement ligatures then the
>> > engraving program can decide what to do. No ligatures for "Major"?
>> > Either lay it out like normal or try to get fancy but that is an
>> > implementation detail. Maybe the ligature is there but the Application
>> > wants to use its own methods to generate a special glyph. No problem.
>> > (Other than the possible confusion of "why _didn't_ it use the
>> > ligatures?")
>> >
>> > TJ
>> >
>> >
>> >
>> >
>> >
>> > TJ
>> >
>> > On Thu, May 30, 2013 at 7:20 PM, Daniel Spreadbury
>> > <[hidden email]> wrote:
>> >> Myke wrote:
>> >>
>> >>> The question here is will we be assuming that people want to be
>> >>> limited in their ability to do things based on what the scoring
>> >>> application (if any) is able to do or not? We may be able to render
>> >>> V6#42 properly in a chord symbol but what about in a lyric? (often
>> >>> the easiest way to show alignment under lyrics or other analytical
>> >>> elements). What about in text boxes and in word processing and web
>> >>> applications?  I think that there's a not too difficult solution
>> >>> involving providing a set of figures (numbers 1-9, flat, sharp,
>> >>> natural, parentheses) kerned to zero width at five different
>> >>> positions (mid-top, mid-bottom -- a la sub and superscript for two-
>> >>> digit symbols; and top, middle, bottom for three-digit symbols).  I
>> >>> have learned to simulate these very well in MS Word and in HTML, but
>> >>> ironically the only place where I need a custom font is in notation
>> >> software.
>> >>
>> >> This is exactly the kind of thing that seems like an inelegant hack,
> as I
>> >> wrote in an earlier reply.
>> >>
>> >> TJ suggested in another post that he thought using ligatures could be
> a
>> >> way to improve on this: TJ, would you mind elucidating on how in
> broad
>> >> terms you would approach this problem?
>> >>
>> >>> Any comments on further beaming hints (at least the two for hook
>> >>> left vs. hook right) to support integrating beamed notation in text-
>> >>> based rendering?  Very useful for simplifying display such as metric
>> >>> modulations:  <–E–E = E–E–E–>
>> >>
>> >> Yes, I can see that this would be useful. I've made a note to include
> a
>> >> range similar in scope to e.g. the Opus Metronome font or the
> Metronome
>> >> font from DVM Publications. I think it will only be truly useful in a
> font
>> >> designed to be mixed with text, but that's okay!
>> >>
>> >> Daniel
>> >>
>> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> >> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097
>> Hamburg, Germany
>> >> Phone: [phone] | Fax: [phone] | www.steinberg.net
>> >> Managing Director: Andreas Stelling, Kazunori Kobayashi
>> >> Registration Court: Hamburg HRB 86534
>> >>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> >>
>> >>
>> >> #############################################################
>> >> This message is sent to you because you are subscribed to
>> >>   the mailing list <[hidden email]>.
>> >> To unsubscribe, E-mail to: <[hidden email]>
>> >> To switch to the DIGEST mode, E-mail to <smufl-discuss-
>> [hidden email]>
>> >> To switch to the INDEX mode, E-mail to <smufl-discuss-
>> [hidden email]>
>> >> Send administrative queries to
> <[hidden email]>
>> >>
>>
>> #############################################################
>> This message is sent to you because you are subscribed to
>>   the mailing list <[hidden email]>.
>> To unsubscribe, E-mail to: <[hidden email]>
>> To switch to the DIGEST mode, E-mail to <smufl-discuss-
>> [hidden email]>
>> To switch to the INDEX mode, E-mail to <smufl-discuss-
>> [hidden email]>
>> Send administrative queries to
> <[hidden email]>
>>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
> Phone: [phone] | Fax: [phone] | www.steinberg.net
> Managing Director: Andreas Stelling, Kazunori Kobayashi
> Registration Court: Hamburg HRB 86534
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <[hidden email]>.
> To unsubscribe, E-mail to: <[hidden email]>
> To switch to the DIGEST mode, E-mail to <[hidden email]>
> To switch to the INDEX mode, E-mail to <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>