Hi.
First, dot 356 is used with another case within Korean braille, but this dot is
not located first.
So if dot 356 is located first braile character, users can know that all next
characters should be read latin letters.
Second, based on computer perspective, it is a little confusing, because as you
said, dot 256 has period in UEB and Korean.
So actually braille readers understand this via context.
In other words, if in the middle of Korean, dot 256 is after start English mark
dot 356 and some letters, readers know that dot 256 is not period.
If you need more information regarding upgrade liblouis to apply these within
Korean braile table, please let me know.
Thank you for your consideration.
김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장
서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996
http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark
-----Original Message-----
From: "Bert Frees"<bertfrees@xxxxxxxxx>
To: <liblouis-liblouisxml@xxxxxxxxxxxxx>;
Cc:
Sent: 2019-02-03 (일) 04:36:43
Subject: [liblouis-liblouisxml] Re: SV: Re: SV: Re: A question about changing
braille table rule
Liblouis would still know the relation between upper and lower cases. That part
is not affected. The capsnocont opcode also works independently. It is true
that there are some differences between caps and emphasis handling at the
moment, but I think we should be able to solve that by doing some more
generalizations.
Op za 2 feb. 2019 om 12:47 schreef Bue Vester-Andersen
<bue@xxxxxxxxxxxxxxxxxx>:
Hi Bert,
Please, not to low level. (smile)
It should still be possible people to write tables, even if their primary skill
is Braille and not low level programming.
Yes, I agree. Caps handling is in deed a variant on that mechanism, but with a
couple of differences:
Liblouis still needs to know the relation between caps and small letters.
Otherwise, neither hyphenation nor contraction in general will work.
The different Braille codes have all possible variations on rules about caps,
when to mark what, when contractions are allowed and when not etc. So, if we
implemented caps management in this more general way, we would also need to
implement opcodes like capsnocont etc.
Hope it makes sense.
Bue
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> På vegne af Bert Frees
Sendt: 1. februar 2019 21:22
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Re: SV: Re: A question about changing braille
table rule
This is indeed a universal requirement and an old issue. There has recently
been a change in the Dutch braille code as well that would ideally require such
a change in Liblouis.
Your idea makes perfect sense. It is more or less what I had in mind. I think I
would like it to be a bit more low-level and powerful, and I would like it to
be so that we could even implement the capitalization rules with the same
mechanism.
Op vr 1 feb. 2019 om 17:46 schreef Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
Hi Christian and Kim,
I think it would be best if we could find a solution that does not depend on an
external routine to set the type form properly. That would limit the use of the
table to programs and environment that make use of the type form, which is not
the case with various screen readers, for instance.
At the moment, I think one needs to define the class of Latin letters a-z and
A-Z (Kim, what about other Latin letters with accent?). Then, one could use a
context rule to find out when members of the Latin letter class occur and when
they stop occurring and insert the appropriate marks. This would probably work
during forward translation, but might be difficult to handle during
backtranslation.
Actually, I think this case calls for a new mechanism in liblouis, which might
also be useful in other contexts. If a user defined emphasis class could be
associated with a character class, we would have an easy mechanism to mark
occurrences of characters, words or phrases of that class. I am sure the Korean
Braille code is not the only case where Latin letters need special treatment.
Almost all Braille codes have different markers to mark characters outside the
normal letters of the primary script or alphabet. This might also be a help
when writing phonetic passages, which should be marked as such. Also, it could
be useful with math or musical symbols, depending on the rules of the Braille
code in question.
Again, backtranslation is the difficult thing here. Braille authorities all
over the world are very good at defining how to write Braille, but less aware
when it comes to defining how to read it. So, getting the correct meaning out
of a given Braille string is often enough left to the users "common sense" and
knowledge about the context.
What do you think?
Bue
-----Oprindelig meddelelse-----
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> På vegne af Christian Egli
Sendt: 1. februar 2019 15:37
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Re: A question about changing braille table rule
Hi Kim
김형섭 writes:
But my real problem is that I really don’t know how to teach begin English
word or character, and end English character.
English is starting from a to z, and ending with a to z.
