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:
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>:
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 beginEnglish word or character, and end English character.
English is starting from a to z, and ending with a to z.
You probably just want to define one emphasis class "english" for example.
Then for that class you define how to annonce the beginning and the end of
a word, phrase, etc.
Then when you are actually invoking liblouis for a translation you will
have to tell liblouis where the english word or phrase begin. This is done
using the typeform array when invoking the translate function.
I don't know how you invoke liblouis and whether the typeform is exposed
in your scenario
Hope that helps
Christian
