[liblouis-liblouisxml] Re: SV: 8 dots contracted with caps

  • From: Bert Frees <bertfrees@xxxxxxxxx>
  • To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
  • Date: Thu, 26 Jan 2017 13:22:32 +0100

Hi Bue,

That sounds right.




2017-01-20 22:12 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:

Hi Bert,



Here is a test suite for the things we have talked about: capsnocont,
changed behavior when no begcapsword/endcapsword, and capsletter as added
dot 7, all tests going both forward and backward. I hope the tests make
sense.



For simplicity, I have currently not included all types of contraction
rules in the tests, only word and partword rules. We can extend the tests
to include more contraction opcodes at any time.



The capsnocont_capsword_8 tests hardly make any sense, since the
combination of capsnocont, defining begcapsword/endcapsword, and using 8
dots just make the whole thing take up much more space. “,,foo ,,bar” is
simply much longer than “FOO BAR”, which would be the result without the
begcapsword/endcapsword. I am not sure whether we should signal an error
for this particular combination. Perhaps someone might need to use it some
day???



To me, it seems like we should do the following:

1.       Make capsnocont work again as expected.

2.       Change the behavior when begcapsword/endcapsword are not defined.

3.       Implement the special value for capsletter to add dot 7.

What do you say?



Bue





*Fra:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:
liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] *På vegne af *Bert Frees
*Sendt:* 20. januar 2017 11:44
*Til:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Emne:* [liblouis-liblouisxml] Re: SV: Re: SV: Re: SV: 8 dots contracted
with caps was: are the swap opcodes broken?



OK thanks. Well, in this particular example it's pretty clear what the
correct back-translation is, right? And this case isn't that hard for a
computer program to solve. Do you also have examples where it is less
clear, or even completely ambiguous?

I imagine a lot of braille codes have cases even without capitals that
pose challenges on automatic back-translation. I have to admit I have no
idea what Liblouis does at the moment, and haven't thought about
back-translation in general much at all, so this could be a pointless or
naive question, but I'll ask anyway: wouldn't it be a good strategy to
validate different back-translation scenarios by forward-translating them
again?





2017-01-19 23:37 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:

Hi Bert,



Technical or computer unfriendly? Probably a bit of both, but not
impossible, I think.



I will try to give an example where back-translation might go wrong:



Take the string “TXT”. Never mind that it is also a computer term and
should probably therefore not be contracted in the first place.

If capsnocont is in effect, it will be translated as either ,,txt or
,t,x,t depending on the status of capsword (plain TXT in 8 dots). So far,
so good. No contraction anyway.



Back-translating ,,txt you get TXT because the begcapsword tells liblouis
to not use contraction rules when back-translating.

However, back-translating ,t,x,t or TXT, you get TMmT, unless Liblouis
knows that it should use the capsnocont rule whenever it sees two
consecutive caps, or unless the x had a letsign in addition to the
capslettersign.



The rules for letsigns in this context might be different from language to
language, hence the computer unfriendliness. The Danish rules are unclear
on this, but I think most people would use a letsign in a case like this
one.



So, it is mainly a question of securing the correct back-translation, even
if there is no begcapsword sign to indicate clearly that contraction rules
should not be used here.



Hope it makes more sense now.



Bue









*Fra:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:
liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] *På vegne af *Bert Frees
*Sendt:* 19. januar 2017 09:55
*Til:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Emne:* [liblouis-liblouisxml] Re: SV: Re: SV: 8 dots contracted with
caps was: are the swap opcodes broken?



2017-01-18 21:17 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:

Hi Bert,



Regarding your first "btw" I don't quite understand what the problem is.
Maybe you are overthinking it?



The problem is that the back-translator could apply contraction rules
because it does not know that it is in a no-contractions state. A German
example would be the letters that are also used as partword contractions,
i.e. q, x, and y. In Danish, we have similar letters: q, w, x, and z. If
capsnocont is defined and the back-translator sees a begcapsword, it knows
that contraction rules should not be applied. But if no begcapsword is
used, it should react on seeing two or more capital letters.  Asimilar
problem occurs with the nocont opcode where a certain text string triggers
the no-contractions state, e.g. http://, .txt, or .zip. Hope it makes
sense.




Sorry, didn't realize you were talking about backward translation at
first. But I'm still not sure whether this is about a technical difficulty
(that can be solved), about a non-computer-friendly braille code, or about
a fundamental problem in the braille code? Some real examples would be
nice. (Sorry I must sound stupid but some things are just not so easy to
grasp without proper braille knowledge). Thanks.



Regarding your second btw, yes perhaps you are right. But in which
category fall words that are not fully uppercase, but also not only the
first letter?



Hmm, good question. I don’t know about the rules for this in other
languages, but I would say that mixed caps should be treated like all caps.
Otherwise, you could have some very confusing combinations of contracted
and uncontracted braille within the same word. The alternative is to have
three separate opcodes: singlecapsnocont, mixedcapsnocont, and
allcapsnocont. I think that would be overkill, but of course I might be
proven wrong. J





Yes I agree extra opcodes would probably be overkill. Just wanted to know
how mixed caps should be treated. Documentation should make this clear.




2017-01-17 20:56 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:

Btw: Testing backwards made me aware of a little snag: If capsnocont has
been defined, contraction rules should of course not be used when in
capsword mode. This should be easy enough when begcapsword/endcapsword are
also defined. However, if begcapsword/endcapsword are not defined, we have
to assume a capsword situation and activate capsnocont if capital letters
or contractions appear after each other.



Btw: according to the manual, capsnocont only affects all caps words, not
words with only the first letter capitalized. This is fine for the current
purpose, but I think there are languages where you cannot contract words
with first cap either. Until recently, this was the case in Danish 6 dots
grade 2, but the rules have been changed, so that it now behaves more like
English in this respect. Perhaps “allcapsnocont” would be a better name in
respect to what it does. If we then need an opcode to stop contraction of
single caps, we could use the name capsnocont. What do you say?









Other related posts: