Topics

關於 tab 的點字呈現方式

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

在此想麻煩 Sponge 跟 liblouis 團隊討論看看,tab 總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows 還是編輯器還是 liblous 的關係,總之與 linux 何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!

Sponge Jhan
 

Hi 高老師 & all,

我覺得 liblouis 應該不會特別改這個設定,除非我們自己強迫 overwrite 它在 zh-tw.ctb
就我所知,Tab 在不同設定下,又有不同寬度,一般狀況多為 4 or 8 spaces
這個寬度不一定的問題也是某些專案捨棄 Tab 而用四個 space 當縮排的原因,也因此 liblouis 不會決定改成幾個 space 的點字
以點字對照表跟 liblouis 的角色,都無法得知當下顯示的環境 Tab 有多寬
結論:大家都覺得不舒服就我們自己改,8 spaces 用太多方,因此我們就用 4 spaces, 是否 ok?

Thanks.

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/23 (週六),高生旺 <coscell@...> 寫道:

主旨: [nvda-tw] 關於 tab 的點字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月23日,六,下午9:12

在此想麻煩 Sponge 跟 liblouis
團隊討論看看,tab
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows
還是編輯器還是 liblous 的關係,總之與 linux
何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!

Sponge Jhan
 

Hi 高老師 & all,

另外,請問目前 NVDA 夾帶的點表當中是否有 en-us-compbrl.ctb?
這個表看起來,是新一代的美語電腦點字,一般操作起來應該跟以前的 en-us-comp8.ctb 差不多
它有注意到 Tab 的問題,可是解法是用第七點來顯示 Tab
也徵詢大家意見,如果改成 include en-us-compbrl.ctb 是不是有比 4 spaces 這樣的改法好?

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/23 (週六),高生旺 <coscell@...> 寫道:

主旨: [nvda-tw] 關於 tab 的點字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月23日,六,下午9:12

在此想麻煩 Sponge 跟 liblouis
團隊討論看看,tab
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows
還是編輯器還是 liblous 的關係,總之與 linux
何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

tab 的呈現不應該市固定的空白術,而是根據系統的定位點設定,通常距離八格,
換句話說,如果妳的資料有3格,後面就是5個空格,游標會停在地9格,市動態呈現的,
我在 linux and DOS 摸到的就是這樣。

On Sat, 23 Mar 2019, Sponge Jhan via Groups.Io wrote:

Hi 高老師 & all,

另外,請問目前 NVDA 夾帶的點表當中是否有 en-us-compbrl.ctb?
這個表看起來,是新一代的美語電腦點字,一般操作起來應該跟以前的 en-us-comp8.ctb 差不多
它有注意到 Tab 的問題,可是解法是用第七點來顯示 Tab
也徵詢大家意見,如果改成 include en-us-compbrl.ctb 是不是有比 4 spaces 這樣的改法好?

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/23 (週六),高生旺 <coscell@...> 寫道:

主旨: [nvda-tw] 關於 tab 的點字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月23日,六,下午9:12

在此想麻煩 Sponge 跟 liblouis
團隊討論看看,tab
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows
還是編輯器還是 liblous 的關係,總之與 linux
何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!






嘯傲俠羽
 

我寫程式便經常遇見這種困擾,執行過後才會發現錯誤,以前有個作法,游標移動到那邊的時候,才會顯示鎖定…,游標咦走以後就是空白,我覺得這樣的定義方式挺好,摸到空白,懷疑是否唯一tab
的時候,就把游標移到那邊,如果出現預定點為,(例如 二四七八點),我就會曉得那是 tab 了。謝謝!

在 2019/3/23,高生旺 <coscell@...> 撰寫:

tab 的呈現不應該市固定的空白術,而是根據系統的定位點設定,通常距離八格,
換句話說,如果妳的資料有3格,後面就是5個空格,游標會停在地9格,市動態呈現的,
我在 linux and DOS 摸到的就是這樣。

On Sat, 23 Mar 2019, Sponge Jhan via Groups.Io wrote:

Hi 高老師 & all,

另外,請問目前 NVDA 夾帶的點表當中是否有 en-us-compbrl.ctb?
這個表看起來,是新一代的美語電腦點字,一般操作起來應該跟以前的 en-us-comp8.ctb 差不多
它有注意到 Tab 的問題,可是解法是用第七點來顯示 Tab
也徵詢大家意見,如果改成 include en-us-compbrl.ctb 是不是有比 4 spaces 這樣的改法好?

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/23 (週六),高生旺 <coscell@...> 寫道:

主旨: [nvda-tw] 關於 tab 的點字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月23日,六,下午9:12

在此想麻煩 Sponge 跟 liblouis
團隊討論看看,tab
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows
還是編輯器還是 liblous 的關係,總之與 linux
何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!









Sponge Jhan
 

Dear all,

我將這個問題放在此,請 liblouis 的作者給予建議
https://github.com/liblouis/liblouis/issues/718
不過,我也無法排除他們會要我們轉向 NVDA 尋求協助,因為這種 runtime context 的問題,仍應該靠應用程式解決比較可行

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/24 (週日),嘯傲俠羽 <crazy@...> 寫道:

主旨: Re: [nvda-tw] 關於 tab 的���字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月24日,日,上午5:52

我寫程式便經常遇見這種困擾,執行過後才會發現錯誤,以前有個作法,游標移動到那邊的時候,才會顯示鎖定…,游標咦走以後就是空白,我覺得這樣的定義方式挺好,摸到空白,懷疑是否唯一tab
的時候,就把游標移到那邊,如果出現預定點為,(例如
二四七八點),我就會曉得那是 tab
了。謝謝!


2019/3/23,高生旺 <coscell@...>
撰寫:
> tab
的呈現不應該市固定的空白術,而是根據系統的定位點設定,通常距離八格,
>
換句話說,如果妳的資料有3格,後面就是5個空格,游標會停在地9格,市動態呈現的,
> 我在 linux and DOS
摸到的就是這樣。
>
> On Sat, 23 Mar 2019, Sponge Jhan via
Groups.Io wrote:
>
>> Hi 高老師 & all,
>>
>>
另外,請問目前 NVDA 夾帶的點表當中是否有
en-us-compbrl.ctb?
>>
這個表看起來,是新一代的美語電腦點字,一般操作起來應該跟以前的
en-us-comp8.ctb 差不多
>>
它有注意到 Tab
的問題,可是解法是用第七點來顯示 Tab
>> 也徵詢大家意見,如果改成
include en-us-compbrl.ctb 是不是有比 4 spaces
這樣的改法好?
>>
>>   sincerely yours
>>    Bo-cheng Jhan
>>
>>
--------------------------------------------
>> 19/3/23 (週六),高生旺 <coscell@...>
寫道:
>>
>>
主旨: [nvda-tw] 關於 tab 的點字呈現方式
>> 收件者: nvda-tw@groups.io
>> 日期:
2019年3月23日,六,下午9:12
>>
>> 在此想麻煩 Sponge 跟 liblouis
>> 團隊討論看看,tab
>>
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
>> 不知道這是 windows
>> 還是編輯器還是 liblous
的關係,總之與 linux
>>
何從前的 DOS 不同。
>>
如果能夠忠實呈現,對於城市寫作者應該市福音。
>> 麻煩你了,感謝!
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

感謝 Sponge 代為反應。如果有回應在麻煩告訴大家。

On Sat, 23 Mar 2019, Sponge Jhan via Groups.Io wrote:

Dear all,

我將這個問題放在此,請 liblouis 的作者給予建議
https://github.com/liblouis/liblouis/issues/718
不過,我也無法排除他們會要我們轉向 NVDA 尋求協助,因為這種 runtime context 的問題,仍應該靠應用程式解決比較可行

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/24 (週日),嘯傲俠羽 <crazy@...> 寫道:

主旨: Re: [nvda-tw] 關於 tab 的?????????字呈現方式
收件者: nvda-tw@groups.io
日期: 2019年3月24日,日,上午5:52

我寫程式便經常遇見這種困擾,執行過後才會發現錯誤,以前有個作法,游標移動到那邊的時候,才會顯示鎖定…,游標咦走以後就是空白,我覺得這樣的定義方式挺好,摸到空白,懷疑是否唯一tab
的時候,就把游標移到那邊,如果出現預定點為,(例如
二四七八點),我就會曉得那是 tab
了。謝謝!


2019/3/23,高生旺 <coscell@...>
撰寫:
tab
的呈現不應該市固定的空白術,而是根據系統的定位點設定,通常距離八格,
換句話說,如果妳的資料有3格,後面就是5個空格,游標會停在地9格,市動態呈現的,
我在 linux and DOS
摸到的就是這樣。

On Sat, 23 Mar 2019, Sponge Jhan via
Groups.Io wrote:

Hi 高老師 & all,

另外,請問目前 NVDA 夾帶的點表當中是否有
en-us-compbrl.ctb?
這個表看起來,是新一代的美語電腦點字,一般操作起來應該跟以前的
en-us-comp8.ctb 差不多
它有注意到 Tab
的問題,可是解法是用第七點來顯示 Tab
也徵詢大家意見,如果改成
include en-us-compbrl.ctb 是不是有比 4 spaces
這樣的改法好?

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/3/23 (週六),高生旺 <coscell@...>
寫道:

主旨: [nvda-tw] 關於 tab 的點字呈現方式
收件者: nvda-tw@groups.io
日期:
2019年3月23日,六,下午9:12

在此想麻煩 Sponge 跟 liblouis
團隊討論看看,tab
總是用一個空白呈現,如果沒有搭配語音實在不容易分辨。
不知道這是 windows
還是編輯器還是 liblous
的關係,總之與 linux
何從前的 DOS 不同。
如果能夠忠實呈現,對於城市寫作者應該市福音。
麻煩你了,感謝!












Sponge Jhan
 

Hi all,

Bue Vester-Andersen 與 Bert Frees 兩位開發者已經回覆意見
前者的大意跟我之前所說的一樣,怎樣顯示 Tab 這是應用程式端該管理的事情,這裡指的是 NVDA
後者提出更具體的解決方案,共三點,但是我看不懂,請問這邊有人可以替大家解釋或提供必要的資訊嗎?
以上,開發者的回答放在信末,thanks.

  sincerely yours
   Bo-cheng Jhan

From Bue Vester-Andersen:

Hmm, I would say that, on principal, all formatting should be the responsibility of the calling application (JAWS, NVDA etc.). They shouldn’t pass tabs on to Liblouis, but filter them and handle them separately.

The screen readers already make decisions on where to place the Braille string in the Braille display, e.g. a screen reader might decide to place the Braille string in the display so that the point of focus is in the center part of the display. Liblouis doesn’t know anything about these decisions.

In many user applications, the screen reader can query the application about indentation status or location in a table or other situations where tab is used, and which might require special formatting considerations in Braille. Again, Liblouis doesn’t know anything about this.

I think the Liblouis conversion of one tab to one space is a last resort fall-back method, which should only be used when the calling application doesn’t handle tabs in a proper way. The same goes for other formatting characters like formfeed.

Hope it makes sense.

From Bert Frees:

Rendering tabs with a specific tab-width is a layout thing rather than a translation thing and is therefore the responsibility of applications like NVDA in my opinion. Also because the tab-width is typically something you want to configure, and Liblouis is not very good at that.

In order to be able to handle tabs in the calling application, you should of course prevent Liblouis from translating them. There are three ways to accomplish this.

The DAISY Pipeline way: DAISY Pipeline has the option to preserve tabs and other spacing like newlines. It does this via the inputPos/outputPos functionality of Liblouis. Liblouis first translates all tabs and newlines to simple spaces, but DAISY Pipeline then converts these back to the original characters afterwards, which it finds via the inputPos/outputPos mapping info.

Because Liblouis has virtual dots you can map every kind of space to a different dot pattern. For instance, tab is sometimes mapped to "9", a newline is sometimes mapped to "a". The calling application can then handle these differently than normal spaces.

By only letting Liblouis translate the parts between the tabs. This has the downside that Liblouis possibly misses out on necessary context.

Larry Wang
 

1 用inputPos/outputPos 标记tab 再做特殊处理
2 用某个特殊点位表示tab
3 让NVDA处理tab 不把tab发送到liblouis

On 2019/3/25 11:29, Sponge Jhan via Groups.Io wrote:
Hi all,

Bue Vester-Andersen 與 Bert Frees 兩位開發者已經回覆意見
前者的大意跟我之前所說的一樣,怎樣顯示 Tab 這是應用程式端該管理的事情,這裡指的是 NVDA
後者提出更具體的解決方案,共三點,但是我看不懂,請問這邊有人可以替大家解釋或提供必要的資訊嗎?
以上,開發者的回答放在信末,thanks.

  sincerely yours
   Bo-cheng Jhan

From Bue Vester-Andersen:

Hmm, I would say that, on principal, all formatting should be the responsibility of the calling application (JAWS, NVDA etc.). They shouldn’t pass tabs on to Liblouis, but filter them and handle them separately.

The screen readers already make decisions on where to place the Braille string in the Braille display, e.g. a screen reader might decide to place the Braille string in the display so that the point of focus is in the center part of the display. Liblouis doesn’t know anything about these decisions.

In many user applications, the screen reader can query the application about indentation status or location in a table or other situations where tab is used, and which might require special formatting considerations in Braille. Again, Liblouis doesn’t know anything about this.

I think the Liblouis conversion of one tab to one space is a last resort fall-back method, which should only be used when the calling application doesn’t handle tabs in a proper way. The same goes for other formatting characters like formfeed.

Hope it makes sense.

From Bert Frees:

Rendering tabs with a specific tab-width is a layout thing rather than a translation thing and is therefore the responsibility of applications like NVDA in my opinion. Also because the tab-width is typically something you want to configure, and Liblouis is not very good at that.

In order to be able to handle tabs in the calling application, you should of course prevent Liblouis from translating them. There are three ways to accomplish this.

The DAISY Pipeline way: DAISY Pipeline has the option to preserve tabs and other spacing like newlines. It does this via the inputPos/outputPos functionality of Liblouis. Liblouis first translates all tabs and newlines to simple spaces, but DAISY Pipeline then converts these back to the original characters afterwards, which it finds via the inputPos/outputPos mapping info.

Because Liblouis has virtual dots you can map every kind of space to a different dot pattern. For instance, tab is sometimes mapped to "9", a newline is sometimes mapped to "a". The calling application can then handle these differently than normal spaces.

By only letting Liblouis translate the parts between the tabs. This has the downside that Liblouis possibly misses out on necessary context.