[BRLTTY] BRLTTY in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 16.03.2012 20:02, Dave Mielke wrote:
>> We don't currently cache some attributes like serial number.
> Brltty reads the serial number in common code with a USB string descriptor read
> operation.
>
Yes which has no cache.
>> Could you perhaps enable -Wformat-security on your codebase? Since
>> you have a lot of constructions like
>> printf (gettext ("Hello"));
>> This creates a problem if translation contains %. I'm not sure if
>> xgettext recognizes such a usage as c-format correctly. If it doesn't
>> translator wouldn't even know that adding % is wrong and he has to
>> use %% instead.
> Sure. It's an option I'll have to look up since I haven't heard of it before.
> I'm all for as much compiler checking as possible, though.
I've disabled following warnings used in GRUB for brltty part:
  -Wstrict-prototypes -Wmissing-field-initializers -Wunused-parameter 
-Wshadow -Wsign-compare
>> What's with bidi? Does our code has to supply unicode lines in
>> logical or visual order (preferred as the code currently handles
>> reordering together with some other tasks)
>> Is Hebrew/Arabic/Thaana/... braille read from left to right or right
>> to left?
> That's a question I can't answer. All I can say at this point is that we
> haven't had any complaints. A user once contacted us to help fix up our Hebrew
> braille characters, and she didn't say anything about ordering problems. Our
> code places the braille in the same order as the characters are found on the
> screen, which is probably why it probably works. Put another way, what we
> ultimately do is rely on the operating system to render the screen correctly,
> and then we just use that result.
I've just checked with linux terminal, gnome-terminal and mlterm and 
only mlterm got Hebrew (on screen) right, all others have written it 
from left-to-right. Perhaps I just miss a software component. So this 
doesn't give much info as to how it should be done.
According to wikipedia http://en.wikipedia.org/wiki/Hebrew_Braille 
braille in Hebrew is read from left-to-right. This creates a weird 
situation with screen-reading solution that you have to get it wrong on 
screen to get it right on braille.
Similar situation with Arabic: http://libbraille.org/arabic_alphabet.php
For GRUB it won't be any problem as I can easily make GRUB to do bidi on 
visual terminal and don't reorder it on braille.
>> How does braille handles a mixture of Latin and National characters?
> There are conflicts, of course. There's only so much that can be done with
> eight dots. Each language has a brltty text table which defines the way users
> of that language like their braille to be represented.
Does it create any problem with gettext in presence of untranslated 
strings, identifiers and latin filenames?
>   Complex languages, e.g.
> Chinese, use brltty's contraction table facility instead, which allows, among
> other things, a single text character to be represented by multiple braille
> characters.
>
> Since I'm guessing you're curious, what they do in Chinese is roughly like
> this: They use a single braille character to represent a sound. The single text
> character for a Chinese word is then translated into the sequence of braille
> characters which put together all the sounds of the word in the correct order.
That makes me indeed curious. In China they use same characters for the 
same concepts but they're pronounced differently in different parts of 
China. But I see only zh-tw (Mandarin, Traditional characters). Also I 
don't see any zh-cn, so I suppose that braille user has to set his 
computer to use traditional characters even though everyone around him 
uses simplified characters. Do these problems really exist? Is it 
because it takes a lot of work to make Chinese contraction tables?
>>> There are various options. My personal preference is to have the lowest row of
>>> dots be briefly raised every second or so. Other users may configure it
>>> differently. One option, of course, is to turn off such notification.
>> This would make impossible to know which entry is selected. That's
>> something that probably has to be fixed in GRUB.
> Is it possible to place the cursor on the selected item? That'd make it really
> easy.
>
We already do so unintentionally. We can upgrade this to intentional 
behaviour.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko