[liblouis-liblouisxml] Re: letter indicator upate
- From: "Arend Arends" <mada73bg@xxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Tue, 10 Mar 2015 12:54:50 +0100
Hello Bert,
It is good that multipass rules like the context rule are available so some
problems can be solved.
But the case of placing a letter sign, Grade 1 symbol indicator or whatever
it is called between digits and characters a-j is such a common aspect of 6
dot braille that in my opinion the code should provide for this by itself. I
think it is more clear to assign a specific opcode or keyword for this case.
Further:
The context rule that you applied is only rarely used in other tables.
When I tried to use it in en-ueb-g1.ctb I had the unexplained effect that
the last digit before the replacement was presented in lowered format, for
instance 2 not as dots 12 but as dots 23.
Best Regards,
Arend Arends
-----Oorspronkelijk bericht-----
From: Bert Frees
Sent: Tuesday, March 10, 2015 12:27 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: letter indicator upate
Hi all,
I have a few general remarks, not directly related to Mike's code changes,
but
reading some recent messages made me think of them.
First, could we have some official UEB document on our format_braille_spec
page
(https://github.com/liblouis/liblouis/tree/formal_braille_spec)? For example
the
document that Mike is refering to in his documentation? For the people that
are
not familiar with UEB like myself it would be helpful to know the rules in
order
to make more sense out of the new opcodes.
Secondly I would like to say something in support of multipass rules. I
wanted
to respond to something that Susan said in another thread, and now seeing
all
these new opcodes reminded me of it. Susan you said:
I would like to offer general support for the longterm value of making the
extra effort to implement a translation rule in a way that reflects the
rule
itself. In my experience using a hack, that is, something that works but
is
indirect often leads to future problems in maintenance and extension.
I assumed you were refering to multipass rules when using the word hack. But
I
like them for a number of reasons and I don't believe opcodes that reflect
the
rules themselves are always better.
Multipass rules are a full part of the liblouis language, designed for
handling
special (non-universal) braille rules. So why not use them for such cases.
They
are very powerful and because they are so low-level they are also clear and
unambiguous. A disadvantage of being low-level is that you may not
understand
the rule in a glance. Therefore clear comments are required. But at least
you
don't have to fully comprehend the meaning of dozens of opcodes and their
interactions and mutual precedence, which may require more effort from a
table
maintainer. Whereas for understanding a multipass rule all it requires is
knowledge of the very simple multipass syntax.
Just to be clear, I'm not saying that UEB can or should be implemented with
multipass rules, I am just saying this as a general remark to get people not
to
fear them.
Regards,
Bert
Michael Gray writes:
I hope the following answers any questions:
How are nocontractsign and numericnocontchars used or defined in
en-ueb-g1.ctb? I could not find them there. If defined there, they would
not
need to be defined in en-ueb-g2.ctb.
They are defined only in en-ueb-g2.ctb as they do not seem necessary for
grade 1.
I would personally prefer to keep most of the old names of LibLouis
keywords
like letsign, capsign, begcaps, endcaps etc. even if they get a slightly
different meaning. Maybe you can do that in a following stage after the
changes have proven to be reliable.
I felt that had I simply updated letsign to do the behavior that
nocontractsign is doing, then it would seem to be confusing since
nocontractsign goes beyond working with just letters. It works with the
contraction opcode for any length of characters. Note that each letter
except
a, I, and o are defined as a contraction, so the letter opcodes are not
needed.
Is this intended primarily for UEB or also for other tables?
I have tried my best to keep the new functionality UEB independent so that
other tables can used them if needed. I have tried to set things up so
that
not defining these opcodes will cause LibLouis to revert back to its
original
behavior. For example I did not call the nocontractsign opcode
grade1sign.
Are these changes in keywords being reviewed and/or approved?
Will the documentation be adapted?
That is the reason I am posting to this mailing list
For a description of the software, to download it and links to
project pages go to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
Other related posts:
