[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/16 at 19:40
+0100]
>Would it be unicode values of base codepoint+combining codepoints?
Yes, of course. The base character first would be nice.
>And highlight bit. Color by itself isn't trivial to infer highlight
>info from.
Yes, for brltty, a highlight bit would be sufficient.
>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.
>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.
>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.
>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. 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.
>>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.
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation.
EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html
http://FamilyRadio.com/ | http://Mielke.cc/bible/
_______________________________________________
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
