[liblouis-liblouisxml] Re: SV: Re: SV: 8 dots contracted with caps was: are the swap opcodes broken?

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

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: