I agree with your points.
The behavior of capsletter you describe is actually how I wanted it to be
after the big 3.0.0 change. But due to circumstances it has turned out to
be somewhat different. I still intend to change it at some point.
Currently, when you define the following table:
include latinLetterDef8Dots.uti
sign . 7
capsletter 7
and you pass in the string "Foobar", you get ".foobar" back, as expected.
However if you pass the string "FOOBAR", you get "foobar". I would like it
to return ".f.o.o.b.a.r". With the current behavior we should at least
return a compilation error if capsletter is defined and
begcapsword/endcapsword are not.
Not sure if using "capsletter add7" instead of "caps7" really adds value,
but it is an interesting idea. It made me think. Maybe we can even
generalize this idea by providing some more values. For example:
uplow Aa 17,1
uplow Bb 127,12
...
capsletter uppercase
I know it's a confusing name (a dedicated opcode, like with caps7, is
probably better), but it would mean: use the dot pattern for the uppercase
letter defined with the "uplow" opcode.
And you could even go further:
swapdd upper 1,12,14,... 17,127,147
capsletter %upper
2017-01-16 18:33 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
Hi Bert,
I have changed the subject to be somewhat more appropriate for the
discussion.
Perhaps, it doesn’t really matter if capsnocont is automatic, as long as
we define very carefully the behavior for each combination and what should
issue an error.
What I think just now is the following:
1. If caps7 and capsletter are both defined: error.
Perhaps caps7 should even be written as “capsletter specialValue”, e.g.
“capsletter add7”, since it really is just a special case of capsletter.
2. Capsletter/caps7 defined and begcapsword/endcapsword not
defined: All caps are marked individually with capsletter sign or dot 7.
This actually implies capsnocont, since you cannot contract and mark each
individual letter at the same time.
Perhaps one could imagine the need for marking single caps but not all
caps, but I don’t know of any tables that would need such a feature. I
think that would call for an “empty” begcapsword and endcapsword (if that
makes sense).
3. If both capsletter/caps7 and begcapsword/endcapsword are
defined, behavior is straight forward whether capsnocont is defined or not.
Perhaps, I should check out what exactly capsnocont does at present.
Bue
*Fra:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:
liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] *På vegne af *Bert Frees
*Sendt:* 16. januar 2017 13:48
*Til:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Emne:* [liblouis-liblouisxml] Re: SV: are the swap opcodes broken?
2017-01-16 13:45 GMT+01:00 Bert Frees <bertfrees@xxxxxxxxx>:
I'm still not really sure Liblouis should automatically do this though. I
prefer explicitly specifying "capsnocont" in the table.
Or maybe it does make sense... Need to think it through.
