Natural character Unicode 266e not spoken by NVDA

[LeonarddeR]

Reported on behalf of James Bowden, working for the music department at RNIB.

Description

The music natural sign, Unicode 266e is not spoken by NVDA. To test this, simply have a document which contains the character. Notice that NVDA skips the character. This is important for musicians.

Proposed solution

The symbols.dic file in \locale\en\symbols.dic is missing definitions for many Unicode characters, including music flat, natural and sharp. Please can the following three lines be added to this file in appropriate place:

♭ flat some
♮ natural some
♯ sharp some

James would like to advocate that all arrows, fractions and mathematical signs in U+21xx and u+22xx are also added, but that's a bigger job. This is covered in #3805.

[LeonarddeR]

@dkager: might be good to have your thoughts.

In English, announcing c♯ as "C sharp" makes sense. However, in Dutch and other languages, c♯ is usually referred to as "cis".

[DrSooom]

I manually added those three characters years ago for my German systems ("symbols-de.dic") as

♭ Flat some # ♭ ♮ Auflösung some # ♮ ♯ Sharp some # ♯

"Flat" is spoken as "Flett" and "Sharp" as "Scharp". In most cases a German dictionary entry isn't needed for the last one because "Sharp" is already spoken as "Scharp".

[Update 2019-01-11-0350+0100] Sorry, the above information isn't fully correct. As I'm using eSpeak on my NUC, I define "♭ Flett some # ♭" there, because of a speaking issue when replacing "Flat" with "Flett" through the NVDA dictionary – as far as I remember me correctly. On my Stand-PC I'm using another synthesizer with its own dictionary where "Flat" already was replaced with "Flett". So using "Flat" in the "symbols-de.dic" on my Stand-PC was already enough. [/Update]

Well, and in the "de-de-comp8.ctb" I also added the following as well:

sign \x266d 12 sign \x266e 2356 sign \x266f 3456

[Update 2019-01-12-2353+0100] ♭ is equal to b, ♮ to = and ♯ to #. [/Update]

In German ♯ alone is spoken as "Kreuz-Vorzeichen" or just "Kreuz" and ♭ alone as "b-Vorzeichen" or just "b". But in combination of a note "C♯" is called "Cis" and "D♭" "Des" – normally, but not on my systems because I'm not working with the German notation, I'm using the ABC notation and within a text also the MIDI notation.

[Update 2019-01-12-2353+0100] The Kreuz-/b-Vorzeichen stands near the key and the Kreuz-/b-Versetzungszeichen near the note. So it's better to call them just "Kreuz" and "b" (or "Be") in German. And "Auflösung" is also shorter than "Auflösungszeichen". The shorter, the better. btw: The correct pronunciation of "Ais" in German is "A-Is", not "Eis" (like "Ice" in English). [/Update]

See this table here to get a list of all 88 notes in the MIDI/American, in the ABC and in the German notation.

[LeonarddeR]

A of course. The dutch variant ought to be as follows:

♭ mol some ♮ herstelling some ♯ kruis some

[bdorer]

May you could open a ticket on liblouis for the braille patterns? Than you could add a pull request to implement your changes. If you need help doing this feel free to ask.

Am 11.01.2019 um 02:17 schrieb Daniel Mayr:

I manually added those three characters years ago for my German systems ("symbols-de.dic") as

♭ Flat some # ♭
♮ Auflösung some # ♮
♯ Sharp some # ♯

"Flat" is spoken as "Flett" and "Sharp" as "Scharp". In most cases a German dictionary entry isn't needed for the last one because "Sharp" is already spoken as "Scharp".

Well, and in the "de-de-comp8.ctb" I also added the following as well:

sign \x266d 12
sign \x266e 2356
sign \x266f 3456

In German ♯ alone is spoken as "Kreuz-Vorzeichen" or just "Kreuz" and ♭ alone as "b-Vorzeichen" or just "b". But in combination of a note "C♯" is called "Cis" and "D♭" "Des" – normally, but not on my systems because I'm not working with the German notation, I'm using the ABC notation and within a text also the MIDI notation.

See this table here https://danielmayr.at/abc/noten.html to get a list of all 88 notes in the MIDI/American, in the ABC and in the German notation.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9138#issuecomment-453330701, or mute the thread https://github.com/notifications/unsubscribe-auth/AKun5WXsPFAorLwbH-jCzFeArULqaaWVks5vB-YegaJpZM4Z5nDk.

[Adriani90]

@leonardder I thought mol is minor, dur is major. For example you could have a c sharp minor, in german this would be cis or c# mol. I can imagone in Netherlands this should be prety similar. Or not?

[Adriani90]

How would you write for example c sharp minor and c sharp major? I couldn't find unicode signs for minor or major.

[DrSooom]

@Adriani90: You are wrong because you are mixing keys and notes in an incorrect way. See: https://danielmayr.at/abc/242.html

[Adriani90]

@DrSooom it's not wrong, I am talking about guitar cord annotation for example. Since we are talking here about the unicode sign for sharp, flat and normal, we are talking about midi annotation. What you linked to is the ABC annotation which is quite different and for which you don't need any of these unicode signs.

When an user would like to read a cord table for a song in midi annotation, he or she would find such cords like for example C sharp minor which would be written like C♯m I was just trying to make sure that the translation in Netherlands is not wrong. The m here means actually mol, and in german we use the sufix "is" for the sharp sign. However no idea how it is in Netherlands, but it should not be that different I guess.

[DrSooom]

@Adriani90: I'm not familiar with guitar tablature notation. Therefore C♯m for a note looked odd to me. Furthermore with the Reference to the ABC notation I just wanted to show you the different meanings of ♯, ♭ and ♮ near a note and ♯ and ♭ near a key. That these three Unicode characters themselves aren't needed in the ABC notation was clear to me. But that wasn't my point here.

But I still have no idea, why you are talking about this here because the Major and Minor key existence cannot influence the way how ♯ and ♭ is spoken by NVDA – as long as only these three Unicode characters are defined alone. Or do you wanna define C♯ together in the symbols.dic files, so NVDA would speak "C Sharp" in English and "Cis" in German during word navigation (not letter navigation)? Unsure if this is possible here too, but it could work (see CLDR implementation).

For MIDI/American and German notation (note names), see also: https://danielmayr.at/abc/noten.html

[DrSooom]

After thinking about this a little bit longer, I sadly had to figure out that we cannot add F♯m, F♭m etc. If we would do this, we would also have to add Fm, which also stands for Fermium and not only for F minor. And there are many other examples.

PS: Sorry, that I totally forgot the usage of chord symbols, as I never really used and also never needed them so far. My failure.

[Adriani90]

@DrSooom things like m, M Fm etc should still remain at users ability to interpret them. Only unicode signs like sharp sign etc, should be considered. If there would be a unicode sign for minor, major etc, then we could consider to add them too. But as I said, there are no signs for that, so a musician should be able to interpret the letters when he or she reads them. In case of M (Major) or m (Minor) it is for blind users a bit trickier because you indeed have to explore the cord letter by letter to find out if it is small or capital letter. Otherwise users could use the feature "say cap for capital letters" which can be enabled in the keyboard settings of NVDA. But this might not work in every case.

[DrSooom]

@Adriani90: You exactly pointed out the reason why I had to pause my private music lessons in April 2017 due to my broken braille display caused by the Austrian monopolist.

The one and only solution I see so far, is to create an add-on, which temporarily adds and deletes all chord symbols to the temporary dictionary. Then the TTS can speak all chord symbols correctly – and sadly also unwanted text in lyrics and in GUIs (e.g. "Am" in German). Additionally the end user would no longer require a braille display to read them in a suitable way. Performing letter navigation during learning and playing a score is horrible and definitively not practical. But creating such a tiny add-on is another topic.