Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for Korean grade 1 braille #2737

Closed
nvaccessAuto opened this issue Oct 21, 2012 · 24 comments
Closed

support for Korean grade 1 braille #2737

nvaccessAuto opened this issue Oct 21, 2012 · 24 comments

Comments

@nvaccessAuto
Copy link

Reported by MHameed on 2012-10-21 14:39
Currently Korean users has no usable braille other than for Latin characters.

  • convert brltty Korean table(s)
  • test with nvda
  • make sure numbers, punctuation is displayed correctly.
  • possibly add harness file
  • include in liblouis
  • update braille.py to include Korean braille.
@nvaccessAuto
Copy link
Author

Comment 2 by nvdakor on 2012-10-21 19:21
This will require that we test this using Braille Sense products (mostly), as Korean users use this device for braille output. Some users have begun testing Braille Sense compatibility with NVDA 2012.3 Beta. Also, I suggest starting with grade 1 braille, then move onto grade 2.

@nvaccessAuto
Copy link
Author

Comment 4 by nvdakor on 2012-11-11 05:09
Hi,
Thanks for the added keyword. This is something that we need to work with John and LibLouis team, as braille translation (even for BRLTTY devices) is handled by LibLouis. Now that I have my braille display device back, let's get started with testing... Thanks.

@nvaccessAuto
Copy link
Author

Comment 5 by nvdakor on 2012-11-13 06:32
Hi,
Preliminary testing was a half success - Korean words as shown, while punctuation and English chars are not. This may mean further testing is in order.

@nvaccessAuto
Copy link
Author

Comment 6 by MHameed on 2012-11-13 12:05
Good, this is what was expected.

Any idea what the Korean braille standard says should be used? table/grade.
i.e. should US grade 1 2, or english UK grade 1 or 2 be used to represent english text?

btw, I assume you are using the ko.ctb that I put in your translation folder.

@nvaccessAuto
Copy link
Author

Comment 7 by nvdakor on 2012-11-13 16:35
Hi,
From what I've seen on Korean text and on iPhone, English text is written using U.S. Grade 1 braille. For symbols, it uses mixture of some English symbols and Korean ones. For numbers, it's the same ones as English braille. Thanks.

@nvaccessAuto
Copy link
Author

Comment 8 by nvdakor on 2012-11-13 16:36
Hi,
For testing, yes, I'm using ko.ctb found in the translations folder you sent me earlier.

@nvaccessAuto
Copy link
Author

Comment 9 by nvdakor on 2012-11-14 12:19
Progress update 2: In SVN, added punctuation dot patterns as comments starting at line 24 in ko.ctb. Thanks.

@nvaccessAuto
Copy link
Author

Comment 10 by nvdakor on 2012-11-16 13:58
In SVN, added the final version of Korean uncontracted braille code file, ready for testing by the public. Once users sya it is working, then I guess we can continue with contac=racted braille code.

@nvaccessAuto
Copy link
Author

Comment 11 by nvdakor on 2012-11-16 13:59
Oops - typos - I meant that we could start working on contracted (G2) braille code file once people say G1 is working well. Thanks.

@nvaccessAuto
Copy link
Author

Comment 12 by MHameed on 2012-11-16 18:34
Please test the following cases:

korean followed directly by punctuation.
korean followed by numbers
numbers followed by korean
punctuation followed by korean
korean followed by english
english followed by korean.

followed by in this context means there is no space between the various characters/symbols.

I know that some of these things might not be valid texts, but we need to be sure that if a user writes something on the display they can read it back even if what they have written doesnt make sence.

Thanks.

@nvaccessAuto
Copy link
Author

Comment 13 by nvdakor on 2012-11-16 20:23
Hi,
Tests were successful. In Korean, since there is no computer braille involved, we can uncheck expand current word checkbox under braille settings dialog.
Thanks.

@nvaccessAuto
Copy link
Author

Comment 14 by nvdakor on 2012-12-17 14:59
Hi,
Korean tables are done (both uncontracted and contracted). The uncontracted one is slated to be included in LibLouis 2.5.2, with contracted braille table to follow. In the meantime, I'll await harness instructions before closing this ticket (for sure). Thanks for your help.

@nvaccessAuto
Copy link
Author

Comment 15 by jteh on 2013-01-30 04:42
Joseph, what's the correct description for ko.ctb? Should we say "Korean grade 1" or "Korean uncontracted"? This is a bit confusing because I gather there are no contractions for Korean text, only for English text.

@nvaccessAuto
Copy link
Author

Comment 16 by nvdakor on 2013-01-30 06:29
Hi,
Korean has contractions. The ko.ctb table is the "base" table which contains all Korean chars and basic rules. Grade 1 and 2 rules are in ko-g1.ctb and ko-g2.ctb, respectively.
In the end, the structure is:

  • ko.ctb: The base table. For now, since liblouis 2.5.2 includes this table, we can safely say it is Korean grade 1 (uncontracted). In the next version of liblouis, since Korean grades are in g1 and g2 tables, we should not list ko.ctb as part of the braille tables list in NvDA - ideally, ko-g1 and ko-g2 would be in there.
  • ko-g1.ctb: Korean grade 1 (uncontracted)
  • ko-g2.ctb: Korean grade 2 (contracted).
    The ko-gN.ctb are included as part of next liblouis version after 2.5.2.
    As for English, in Korea, U.S. grade 1 is used for English text. Computer braille follows U.S. computer braille table.
    Hope this makes sense.

@nvaccessAuto
Copy link
Author

Comment 17 by jteh (in reply to comment 16) on 2013-01-30 06:46
Replying to nvdakor:

Korean has contractions. The ko.ctb table is the "base" table which contains all Korean chars and basic rules. Grade 1 and 2 rules are in ko-g1.ctb and ko-g2.ctb, respectively.

So there is no computer Braille code for Korean characters?

  • ko.ctb: The base table. For now, since liblouis 2.5.2 includes this table, we can safely say it is Korean grade 1 (uncontracted). In the next version of liblouis, since Korean grades are in g1 and g2 tables, we should not list ko.ctb as part of the braille tables list in NvDA - ideally, ko-g1 and ko-g2 would be in there.

If ko.ctb is grade 1 already, there's little point in ko-g1.ctb, since it will only include ko.ctb. Unless there's a good reason to have ko-g1.ctb, I wouldn't recommend it, as it will break existing configurations when users update.

As for English, in Korea, U.S. grade 1 is used for English text. Computer braille follows U.S. computer braille table.

Is there any reason you don't simply include en-us-g1.ctb, rather than redefining it all? Are there differences from the official English tables?

@nvaccessAuto
Copy link
Author

Comment 18 by jteh on 2013-01-30 06:58
Korean grade 1 available to users as of 6c6796b.

@nvaccessAuto
Copy link
Author

Comment 19 by nvdakor on 2013-01-30 07:23
Hi,
In Korean braille, many punctuations are represented using different dot combinations e.g. In English, exclamation is 2-3-5; in Korean, it is 4-5-6.
As for the table, it came from BRLTTY with modifications via Mesar and I.
The reason for splitting the uncontracted table between ko.ctb and ko-g1.ctb was the fact that some conscenants were confused as numbers (there are seven such cases; since LibLouis does not handle components of Korean chars, we had to define all possible Korean chars in ko.ctb). Also, when I include these conscenant cases in ko.ctb and when I included ko.ctb in ko-g2.ctb, certain conscenants which follows numbers were not represented correctly (usually, Koreans put space when a Korean character comes after numbers; so when I included ko-ctb in ko-g2.ctb and when I tested these seven conscenant cases, space was not inserted between chars and numbers).
As an example, the Korean conscenant "N" is written as dots 14. However, as you may know, dots 14 is number 3. For instance, "year 2003" (2003 nyun) is usually written in Korean as dots 3456-12-245-245-14-14-156-25.
The effects of various table scenarios were:

  • 2003 nyun (in korean) is originally written as 3456-12-245-245-14-14-156-25.
  • Correct output: 3456-12-245-245-14-0-14-156-25.
  • Test 1: ko-g1 removed - all entries from ko-g1 and moved them to ko.ctb. ko-g2.ctb includes ko.ctb: After selecting Korean grade 2, I read the braille text. Where there should be a space between number and char, there is no space.
  • Test 2: above scenario, but switched to Korean grade 1: there is indeed a space between numbers and Korean char.
  • Test 3: Restored ko-g1 and moved the original entries from ko-g1 back to the file. ko-g1 includes ko.ctb and I switched to Korean grade 1: there is a space between number and char.
  • Test 4: Test 3, but switched to grade 2: now there is a space between number and char, as ko-g2 contains contracted versions of the number+char rule.
    I'll follow-up with this in the next comment. Thanks.

@nvaccessAuto
Copy link
Author

Comment 20 by nvdakor on 2013-01-30 07:47
As a follow-up:
Thanks for including the grade 1 table in the main branch.
As for Korean contractions: these are short-hand notations for Korean chars. These fall into the following rules:

  1. For some conscenants, whenever the vowel "ah" (dots 126) is present, remove the dots for the vowel (for example, the word "hah" is written as 245-126 in grade 1; in grade 2, dots 245 is written). There are nine such conscenants. However, whenever conscenant+ah char is followed by "ng" conscenant (not the ending conscenant, but as the start conscenant of the next character), do not remove dots 126.
  2. Certain conscenants and vowel "ah" (as part of Korean char) take different dots in grade 2. There are two cases: "gah" and "sah" (gah is written as 4-126 in grade 1, 1246 in grade 2; sah is written as 6-126 in grade 1, 123 in grade 2).
  3. Vowels followed by certain ending conscenants take different dot combinations in grade 2 altogether (for example, the char "jin" is written as 46-135-25 in grade 1, 46-12345 in grade 2). There are 13 cases.
  4. There are seven three to four letter words which have two-cell contractions in grade 2, whereas these are written "as is" in grade 1.
    In summary, the majority of contraction rules can be summarized as thus: a Korean char has different dot combinations in grade 1 and grade 2, hence duplication was needed.
    As for table design decision, I designed that way around possible extensions in the future. Here's how I imagine it (at least in my thinking as I expand the Korean table much later):
  5. Does the change or new entry apply everywhere regardless of grade, such as punctuation? If so, then only ko.ctb will be modified.
  6. Does a given entry apply to a particular grade? If so, then tables for respective grades will be modified.
    Thanks.

@nvaccessAuto
Copy link
Author

Comment 21 by jteh (in reply to comment 16) on 2013-01-30 07:52
I'm not so much arguing against the use of a base table and then having g1 and g2 tables which include it. My confusion comes from this statement:

  • ko.ctb: The base table. For now, since liblouis 2.5.2 includes this table, we can safely say it is Korean grade 1 (uncontracted).

From what you've said later, ko-g1.ctb and ko.ctb won't be identical, so it isn't in fact safe to call ko.ctb grade 1. The problem is that now, when users upgrade to a later version of NVDA which changes to ko-g1.ctb, their configuration will be broken. If you want to avoid this, the only solution for now is to remove Korean grade 1 from the list until ko-g1.ctb makes it into liblouis.

@nvaccessAuto
Copy link
Author

Comment 22 by jteh on 2013-01-30 07:54
Btw, if ko.ctb is a base table, it should probably be called ko.cti, as that suggests it shouldn't be used by end users and is only for inclusion by other tables.

@nvaccessAuto
Copy link
Author

Comment 23 by nvdakor on 2013-01-30 08:20
Hi,
Oh, I see - apologies for miscommunication.
Your last two comments provided a better way to explain that statement (ko.ctb is a base table, so I should better rename it to ko.cti).
As for cti suggestion, I've seen a number of tables implement sort of a similar structure to Korean, so I think I'll follow your recommendation (I'll write to libLouis list about this then).
So, in the end, I think we should wait until 2013.2 or next LibLouis version. Or, another idea might be to rename ko.ctb to ko-g1.ctb for now (if this is even possible, but I doubt it'll work).
Thanks.

@nvaccessAuto
Copy link
Author

Comment 24 by jteh on 2013-01-31 07:25
To clarify, the current ko.ctb is missing these seven consonants?

For 2013.1, you have two options:

  1. I can leave ko.ctb as Korean grade 1. This will allow users to use it right now. However, things will break when they update to a version when this changes to ko-g1.ctb. They won't break horribly. Users will just need to know that they should select the table again.
  2. We can remove Korean grade 1 and wait for a release of liblouis which includes ko-g1.ctb. This is cleaner, but means users have to wait until at least NVDA 2013.2.

@nvaccessAuto
Copy link
Author

Comment 25 by nvdakor on 2013-01-31 07:38
Hi,
Yes - these seven conscenants are missing in ko.ctb.
as for Korean, yes, let's leave it at that - ko.ctb = Korean grade 1. I told Korean braille users that NVDA now includes Korean grade 1. Thanks.

@nvaccessAuto
Copy link
Author

Comment 26 by jteh on 2013-01-31 11:30
Narrowing the scope of this ticket to just grade 1. You can open another ticket for Korean contracted or just handle this entirely in the liblouis project.
Changes:
Changed title from "support for Korean braille" to "support for Korean grade 1 braille"
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant