Topics

問題-NVDA 瀏覽 pdf 文件 在瀏覽模式/焦點模式 內容排版有差異

蔡宗豪 Victor Cai
 

朋友們好:
請問大家,瀏覽某些 pdf 文件,是否也曾遭遇以下狀況:
在「測試」附件中,如果切換到焦點模式,複製內容會有條列的排版。
反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。

問題重現:

  1. 開啟附件。(這是一個 4 頁的文件)
  2. 按 NVDA+空白鍵 切換到焦點模式。
  3. 按 control+a 全選這一頁。
  4. 按 control+c 複製內容,然後貼到記事本。
    (此時,我們得到的排版類似:
  • 壹、 緣起
  • 貳、 參選條件
    一、 參選資格: 二、 評選分類:
  • 參、 評選標準

反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。

系統環境:

  • Windows 版本: Windows 7 (6.1.7601 service pack 1)
  • NVDA 版本: 2018.4.1
  • NVDA 安裝版或可熙版: 安裝版
  • Adobe Acrobat Reader DC: Chinese Traditional 19.010.20098

電郵附件:

  • 測試.pdf

惠婷
 

報告,我的電腦是win十,
有Microsoft Edge
直接點開pdf檔,在流覽模式下即可依序閱讀,且複製也不改變格式
但如果切成焦點模式,則無法閱讀、複製。

在 2019/3/5,蔡宗豪 Victor Cai <surfer0627@...> 撰寫:

朋友們好:
請問大家,瀏覽某些 pdf 文件,是否也曾遭遇以下狀況:
在「測試」附件中,如果切換到焦點模式,複製內容會有條列的排版。
反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。
問題重現:

1. 開啟附件。(這是一個 4 頁的文件)
2. 按 NVDA+空白鍵 切換到焦點模式。
3. 按 control+a 全選這一頁。
4. 按 control+c 複製內容,然後貼到記事本。
(此時,我們得到的排版類似:


- 壹、 緣起
- 貳、 參選條件
* 一、 參選資格: * 二、 評選分類:
- 參、 評選標準

反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。
系統環境:

- Windows 版本: Windows 7 (6.1.7601 service pack 1)
- NVDA 版本: 2018.4.1
- NVDA 安裝版或可熙版: 安裝版
- Adobe Acrobat Reader DC: Chinese Traditional 19.010.20098

電郵附件:

- 測試.pdf

------------------------------



特種兵
 


  可能跟閱讀的軟體有關
  我使用google chrome在瀏覽模式下閱讀都正常
  使用Qread閱讀也正常(在Qread只有一種模式)

thank you for much
Logo Kuo from Taiwan
蔡宗豪 Victor Cai 於 2019/3/5 下午 04:42 寫道:

朋友們好:
請問大家,瀏覽某些 pdf 文件,是否也曾遭遇以下狀況:
在「測試」附件中,如果切換到焦點模式,複製內容會有條列的排版。
反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。

問題重現:

  1. 開啟附件。(這是一個 4 頁的文件)
  2. 按 NVDA+空白鍵 切換到焦點模式。
  3. 按 control+a 全選這一頁。
  4. 按 control+c 複製內容,然後貼到記事本。
    (此時,我們得到的排版類似:
  • 壹、 緣起
  • 貳、 參選條件
    一、 參選資格: 二、 評選分類:
  • 參、 評選標準

反觀在瀏覽模式,無論是直接閱讀,或複製內容,文件排版都無法條列分明。

系統環境:

  • Windows 版本: Windows 7 (6.1.7601 service pack 1)
  • NVDA 版本: 2018.4.1
  • NVDA 安裝版或可熙版: 安裝版
  • Adobe Acrobat Reader DC: Chinese Traditional 19.010.20098

電郵附件:

  • 測試.pdf


蔡宗豪 Victor Cai
 

朋友們好:
接續這個討論,有關再瀏覽模式閱讀 pdf檔案,該段行的地方沒有段行。
查閱幾個議題,閱讀開發者於2017年的幾則回覆後,有以下收穫,(如有理解錯誤,還請幫忙補充):

在瀏覽模式的段行,原始設計是透過字元數來控制的。這個做法的好處,是避免在閱讀過程產生更多行,或每一行的長度太長。但是,遇到沒有正確標籤的 pdf,可能就會導致 NVDA 使用原本瀏覽模式的斷行規則。造成前文所提到,原本應該段行的地方,全部連在一起了。理想的情況,是 pdf 文件,有適當的表格、清單標籤。不過,我們還是有不少機會,收到一些沒有加入標籤的 pdf。
未來,一個可能的解決方法,是讓 NVDA 在特定情況,忽略目前已自原數來段型的規則。這個做法,會導致瀏覽模式的運作行為不一致,但同時能解決目前閱讀沒有標籤化 pdf 文件的流暢性問題。

以下摘錄開發者,於議題 7275 的兩則回應。

jcsteh commented on 13 Jun 2017
PDF has semantic tags for paragraphs, lists, tables and the like. However, it does not differentiate author inserted line breaks (as in source code or poetry, sometimes known as hard line breaks) from line breaks used to wrap text which cannot fit on a single line (sometimes known as soft line breaks).
Because NVDA splits text into lines itself (according to the "Maximum number of characters on one line" Browse Mode setting), we strip line break characters, as otherwise, you end up with a lot of long lines followed by short lines (as I recall happened in JAWS when I used it years ago). Having spoken to someone involved in PDF accessibility specification writing, my understanding is that the correct way to author such content is to tag each line as a separate list item or paragraph. Unfortunately, it seems no one actually does this in the wild.

I think the only way we could reasonably solve this is to ignore NVDA's own settings for splitting lines and instead use only the line breaks in the PDF. That would also require us to not treat line breaks as paragraphs for PDF. This would be somewhat inconsistent with browse mode everywhere else, but I think consistency is probably outweighed by usability here.

jcsteh commented on 17 Jun 2017
Working around this requires a pretty significant refactor of the way lines work in virtual buffers. Also, while I accept this happens in the wild, this is technically incorrect authring according to PDF accessibility standards.
 
內容出處:
https://github.com/nvaccess/nvda/issues/7275