Hi Bert,
So, where do we go from here?
It looks like quite a few things need some working over. Perhaps fixing
capsnocont and changing the behavior when begcapsword/encapsword are not
defined would be a good place to start, since the other things depend on this.
Perhaps, I should start out by making some tests, so that we know what results
we want to get.
Bue
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] På vegne af Bert Frees
Sendt: 16. januar 2017 21:54
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Re: SV: Re: 8 dots contracted with caps was: are
the swap opcodes broken?
Answers inline:
2017-01-16 20:52 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx
<mailto:bue@xxxxxxxxxxxxxxxxxx> >:
Hi Bert,
Neither caps7 or capsletter add7 have been implemented. They were just my
thought about possible names for such an opcode.
Yes, of course. I never assumed that.
Yes, I would like to be able to use the
Uplow Aa 1-17
Syntax. That would also help with the hyphenation algorithm since it takes
small and capital letters into account if the relationship is known.
However, you still need to add dot 7 to chars that make a contraction, but
which are not letters, e.g. Ei 1467 and Ie 3467. If you were to do this
manually, your swap class might come in handy. But I still think that it should
be possible to do it automatically by adding or “or”ing dot 7 as capsletter
sign.
I understand that. I was just putting some ideas on the table on how things
could possibly be generalized.
The support for the uplow and the swapdd cases would be "in addition to" the
dot 7 support, not "instead of".
Do you have any idea if changing the behavior of not defining
begcapsword/endcapsord would be incompatible with any existing tables, e.g. the
UEB tables?
I don't think so, and if it is the case we can still create a new opcode that
implements the current behavior of "capsletter" (e.g. named "capssingleletter").
