[BRLTTY] Support for 'dead' or broken cells?

[Willie Walker]

Hi Yan:

I think that sounds about right.  The other thing that would be nice 
would be to adjust the cursor routing key events as well.  That is, make 
sure their offset is decremented appropriately if they occur after any 
broken cells.  The whole idea is that a BrlAPI client would not have to 
make any adjustments for the broken cells - BrlAPI and BrlTTY would just 
take care of everything.

Thanks!

Will

yan at mistigri.org wrote:
> Hi:
>   
>> Hi All:
>>
>> At CSUN, the LSR folks showed an interesting feature to provide support 
>> for filtering out broken or dead cells on the display.  This seems like 
>> a feature that should live in BrlTTY, since it could take advantage of 
>> such things when presenting information for virtual consoles.  I think 
>> the basic idea would be to just treat the cell as if it weren't even 
>> part of the display.
>>
>> Would being able to keep/use a record of broken/dead cells be possible 
>> to do in BrlTTY?
>>     
> Yes this could be an interresting feature:
> In the core we could make a difference bitween the 'real length ' of the 
> display and the 'actually used length'. 
> Moreover we would have to implement something like a table refering to 
> cells that are 'down' or 'not working'..
> For example wlets take a 20 length display content :
> [abcdefghijklmnopqrst]
>
> And lets suppose the 5th cell no longeer works, we would arrange the 
> message like this :
> [abcd efghijklmnopqrs]
>
> Here the 5th cell is dead so we put a space (0x00 dot-pattern), and 
> right-shift the end of our message content: so here, the actual 
> display-length would be 19 cells.
>
> Is that what you would like ?
>
> Yannick
>   
>> Will
>>
>> _______________________________________________
>> This message was sent via the BRLTTY mailing list.
>> To post a message, send an e-mail to: BRLTTY at mielke.cc
>> For general information, go to: http://mielke.cc/mailman/listinfo/brltty
>>     
>
>