Problem with capital letter mark #505
Comments
|
Comment 1 by jteh on 2009-12-09 11:21 |
|
Comment 2 by jteh on 2010-02-02 01:30 |
|
Comment 3 by werwoelfchen on 2010-02-08 12:06 |
|
Comment 4 by jteh on 2010-07-14 04:18 |
|
Comment 5 by jteh on 2010-07-26 03:35 |
|
Comment 6 by jteh on 2010-09-23 02:03 |
|
Comment 8 by bdorer on 2014-01-14 13:35 |
|
CC @egli Maybe NVDA could gain an option to suppress capitals. SuperNova has this too IIRC. The clean solution requires an option in liblouis. A hacky solution could be to transform all text to lowercase before translation. The problem is that German grade 0 does show a capital sign for two or more consecutive capitals. So clearly it's not so straight-forward. |
|
This feature is wanted from many German Braille Readers. Some of them
are using Grade 2 to proove reading so if you'll find a solution it
would be great.
Some persons created their own braille tables with capital letter mark
enabled but they have to restore the table after nvda updates.
Am 08.06.2017 um 20:26 schrieb Davy Kager:
…
CC @egli <https://github.com/egli>
This seems to be done on purpose. Is this the preference of German
readers?
Maybe NVDA could gain an option to suppress capitals. SuperNova has
this too IIRC. The clean solution requires an option in liblouis. A
hacky solution could be to transform all text to lowercase before
translation. The problem is that German grade 0 does show a capital
sign for two or more consecutive capitals. So clearly it's not so
straight-forward.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#505 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKun5YkQKEwPwx76gxKMtBXMIP5GkNz3ks5sCDzkgaJpZM4N0czj>.
|
|
Separate Tables with and without caps letters will blow up braille
tables list but if there isn't any better way we'll accept it.
Am 27.06.2017 um 20:07 schrieb Davy Kager:
…
See liblouis/liblouis#363
<liblouis/liblouis#363>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#505 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKun5dBcirIhtYd8q6JEDbg_CXUhxiOgks5sIUTfgaJpZM4N0czj>.
|
|
Then again, German is the only table I've seen without capitals. |
|
I think our resident braille expert created the tables w/o caps letters because we produce most braille without. |
Even if most braille is produced without capital signs, if a braille spec contains them, they should be included in the braille table by default. Probably better to discuss this in liblouis/liblouis#363. |
|
The impact of this issue is limited to the intersection of (a) Braille users, (b) German users. Doing some research on the German language, let me share some of what I found. Austria and Germany, both of which have German as their official language, cumulatively account for a third of German speakers worldwide. According to NVDA User Statistics, Germany and Austria together account for 1.3% of NVDA users. Thus, it can be extrapolated that roughly 3.9% of NVDA users are German speakers. According to WebAim Screen Reader Survey #8, 3.9% of respondents reported that they relied primarily on Braille output and they neglected to ask about using Braille in combination with visual or audio output. Even if we assume that 20% of screen reader users use Braille to some degree, we still have our German Braille users constituting well under 1% of the total user base. Therefore, given the small proportion of the impacted audience, this ticket should be assigned a low priority. |
|
@bhavyashah even though the statistics show this number, this was the current user respondents at that time. This changes over time and not to forget that most users using braille displays come from western countries such as germany, france and so on. Most braille contributions come from such countries. So this should not be neglected. |
|
@BueVest now that the bidirectional talbes for german are integrated in NVDA, do you see this issue as solved? |
|
Hey all, Since nvda has the "detailed braille translation tables" integrated, the capital letter marks are displayed correctly. ... BUT: In some Cases, NVDA crashes when the detailed braille translation table is used. Steps to reproduce:
There are some exceptions from this "stranger thing": in dayly use, this means that nearly all file names can bring nvda to crash when they are displayed in an explorer list. |
|
@Adriani90 you have followed this issue. Do you think that it is fixed? Also @BueVest and other users, can we consider this issue fixed? @dave090679, the initial description of this issue is indicating that braille is not reported as expected by users. What you describe instead is a crash of NVDA. Please open a new issue for this with all related details so that it can be looked at specifically. Thanks. |
Hi @dave090679 can you reproduce this crash just using liblouis? And then file an issue at the liblouis issue tracker? That would be appreciated. |
|
The issue as it stands in the description seems fixed. Please open a new issue about the crash with Liblouis and if related, also with NVDA so we can track where it comes from. I am closing this issue as works for me. |
Fixes #3304. Fixes #9863. Supersedes PR #9864, #10172. Addresses #505 (comment) Summary of the issue: In NVDA, there is no easy and reliable way for an add-on to provide a new braille table. For an experienced users wishing to do so there are two options: Alter manually an existing table in louis/tables. The new table still has its original name in the settings GUI. This change is lost upon NVDA updates. Set the absolute path to the table file in the configuration in lieu of the usual file name. The settings GUI shows an empty entry for this one. Forces to manually alter nvda.ini. Forces to copy in the same directory the whole dependency chain of the new table plus braille-patterns.cti. This is because liblouis default table resolver only looks for tables in a single directory, See Make it easier for add-ons to supply custom braille tables #5489 (comment) Description of how this pull request fixes the issue: Add a new brailleTables optional directory in both the user scratchpad directory and the add-on directory structure. Support reading tables metadata from an optional brailleTables section of the add-on manifest or from a manifest.ini file with the same format found in the root of the scratchpad directory, allowing a user to provide a display name and set output/input/contracted capabilities with no code. Implement a custom liblouis table resolver that resolves tables based on what is registered in the brailleTables module: When liblouis calls the resolver without a base file specified, the table is looked up from the brailleTables module and either resolved from the add-ons brailleTables directory or the built-in tables directory When liblouis calls the resolver with a base file specified (e.g. when processing includes in tables), the table is looked up from the folder of the base table and/or the built-in tables directory Enforce the existing fallback mechanism to ensure there still is braille output if the configured table cannot be found e.g. because an add-on or the scratchpad directory was disabled. This now applies both to the main configuration and individual profiles and also covers braille input. Note that if an add-on author wants a table to be listed in the GUI, he/she should always define the table in the manifest. Contrary to earlier incarnations of this pr, replacing a table in an add-on (i.e. when it has the same filename as a built-in table) without defining it in the manifest is no longer possible. Therefore it is also not possible to replace unlisted tables that are included by listed tables. For example, if you want to replace spaces.uti as included in nl-comp8.utb, you weel need to both define and bundle a replacement of nl-comp8.utb and spaces.uti in your add-on.
Fixes nvaccess#3304. Fixes nvaccess#9863. Supersedes PR nvaccess#9864, nvaccess#10172. Addresses nvaccess#505 (comment) Summary of the issue: In NVDA, there is no easy and reliable way for an add-on to provide a new braille table. For an experienced users wishing to do so there are two options: Alter manually an existing table in louis/tables. The new table still has its original name in the settings GUI. This change is lost upon NVDA updates. Set the absolute path to the table file in the configuration in lieu of the usual file name. The settings GUI shows an empty entry for this one. Forces to manually alter nvda.ini. Forces to copy in the same directory the whole dependency chain of the new table plus braille-patterns.cti. This is because liblouis default table resolver only looks for tables in a single directory, See Make it easier for add-ons to supply custom braille tables nvaccess#5489 (comment) Description of how this pull request fixes the issue: Add a new brailleTables optional directory in both the user scratchpad directory and the add-on directory structure. Support reading tables metadata from an optional brailleTables section of the add-on manifest or from a manifest.ini file with the same format found in the root of the scratchpad directory, allowing a user to provide a display name and set output/input/contracted capabilities with no code. Implement a custom liblouis table resolver that resolves tables based on what is registered in the brailleTables module: When liblouis calls the resolver without a base file specified, the table is looked up from the brailleTables module and either resolved from the add-ons brailleTables directory or the built-in tables directory When liblouis calls the resolver with a base file specified (e.g. when processing includes in tables), the table is looked up from the folder of the base table and/or the built-in tables directory Enforce the existing fallback mechanism to ensure there still is braille output if the configured table cannot be found e.g. because an add-on or the scratchpad directory was disabled. This now applies both to the main configuration and individual profiles and also covers braille input. Note that if an add-on author wants a table to be listed in the GUI, he/she should always define the table in the manifest. Contrary to earlier incarnations of this pr, replacing a table in an add-on (i.e. when it has the same filename as a built-in table) without defining it in the manifest is no longer possible. Therefore it is also not possible to replace unlisted tables that are included by listed tables. For example, if you want to replace spaces.uti as included in nl-comp8.utb, you weel need to both define and bundle a replacement of nl-comp8.utb and spaces.uti in your add-on.
Reported by werwoelfchen on 2009-12-09 10:06
Since Snapshot R3422 the braille display doesn't show any longer the capital letter marks. It would be good if one could dis- or enable these marks by using the braille settings menu.
Text in German:
Betreff: Problem mit Großbuchstabenzeichen
Beschreibung:
Seit dem Snapshop R3422 zeigt die Braillezeile keine Großbuchstabenzeichen mehr an. Es wäre gut, wenn man dies ein- oder ausschalten könnte, indem man das Menü "Brailleeinstellungen" benutzt.
The text was updated successfully, but these errors were encountered: