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
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
