[BRLTTY] The unknown-character sign (26)

[Mario Lang]

Dave Mielke <dave at mielke.cc> writes:

> [quoted lines by Jason White on 2008/11/24 at 18:27 +1100]
>
>>I agree there is no perfect solution here, particularly for text tables that 
>>define all 256 possibilities, which I suspect most, perhaps all of them, do.
>
> Most do simply because it seemed to make sense to do so. There's really no 
> peractical need, for example, to define the range \x80-\x9F as those usually 
> are extended control characters which are rarely, if ever, needed.

Well, yes, and no.  I still think that the direct correlation
between 8bit-bytes and 8dot-cells is a strong argument
for a complete mapping.  I think the problem we are looking
at is a fundamental one which in 6-dot world is usually
solved by a proceeding "escape" dot, like the letsign in most
contracted braille variants.  The point here is really that
we are trying to represent something that has no unambigious representation.
I think in 6-dot uncontracted text-table world, the question mark
approach is OK, because in that world the user assumes every
char on the screen consumes one cell.  In contracted braille however,
the user knows what they read does not correspond to
whats on screen in terms of character width.  That, and the
fact that contracted braille overloads so many symbols allows/requires
us to break with the question mark idiom at least for some languages.
Two approaches are left IMO, either we break out of 6-dot world in
a contraction table and define something with dot7 or dot8 or both
so that it is obvious to the user that something special is going on,
or we define the unknown character as something like a valid question mark
in contracted braille.  In german that would be 6-25 I think.
In any case, what exactly needs to happen is probably very language
dependant and should be under the control of a contraction table author.
Dave, in your other post you ask if we should introduce a new
opcode "unknown".  I think that might be too limited because a contraction
table author might want to define begword \uFFFD in a different way
as midendword \uFFFD.  Its hypothetical, I have no real
use for it, but it sounds logical that the context sensitivity could
be useful.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/key at db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>