[liblouis-liblouisxml] Re: Display opcode versus normal character opcodes
- From: "Vic Beckley" <vic.beckley3@xxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Wed, 27 Jun 2012 15:25:17 -0400
Thanks Mesar. That was very helpful.
Best regards from Ohio, U.S.A.,
Vic
E-mail: vic.beckley3@xxxxxxxxx
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Mesar Hameed
Sent: Wednesday, June 27, 2012 9:47 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Display opcode versus normal character
opcodes
Hi Vic,
On Wed 27/06/12,08:47, Vic Beckley wrote:
> I am looking at the latest version of the Czech table. What is the purpose
> of including the *.uti files if those characters are already defined in
the
> text_nabcc.dis file which is included?
> These included definitions will just
> be superseded by the ones in the text_nabcc.dis file, right?
Not quite,
There are two levels of translation going on here.
1. the uplow, sign etc, defines the mapping between various characters and
the dots that are expected.
Any rewrite rules, contractions etc will operate on these.
2. when everything is done, and we wish to send to a printer, another layer
of transformation is done.
This mapping is a direct character by character replacement, and is simply
to interface correctly with hardware.
Lets say you wish to print the letter m,
The internal table of the printer may know that if it receives m it should
print 134
but lets say instead it produces something else, so now we need to inform
liblouis that if we wish to print dots 134, we need to send letter n.
This is where the display opcodes come in.
display n 134
display m 1345
would tell liblouis to do all its stuff, and when everything is said and
done, wherever you wish dots 134 to be printed, send a 'n' character,
and when you want to print dots 1345 send 'm'.
This is for an imaginary printer that has its internal table screwed up,
most printers stick to ascii braille, which defines 64 braille chars,
its the remaining characters that are a bit of a hit and miss, so thats why
we have the display opcodes.
But yes, I strictly see display opcodes as different from liblouis
internals, so should really not be in the same braille table, just in
dis files, because me and you may be using exactly the same contraction
table, but my hardware prints dots differently from yours.
I hope I havent confused the matter further.
Thanks,
Mesar
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
