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:
1. Liblouis still needs to know the relation between caps and small
letters. Otherwise, neither hyphenation nor contraction in general will work.
2. 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
<mailto: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
<mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx>
<liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> > På vegne af Christian Egli
Sendt: 1. februar 2019 15:37
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
<mailto: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.
