New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NVDA not line breaking text in PDFs #7275
Comments
Can you please provide steps to reproduce this problem?
…On Mon, Jun 12, 2017 at 9:01 AM, Dickson Tan ***@***.***> wrote:
When browsing PDFs in jaws vs NVDA in adobe reader, NVDA doesn't break
across lines (e.g, especially across source code), while jaws breaks it
appropriately.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7275>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFGivZFu2lIa7-qk153SMBcmvp6Ygp2Nks5sDVK4gaJpZM4N3Pdi>
.
--
Derek Riemer: Improving the world one byte at a time!
- University of Colorado Boulder Department of computer science, 4th
year undergraduate student.
- Accessibility enthusiast.
- Proud user of the NVDA screen reader.
- Open source enthusiast.
- Skier.
Personal website <http://derekriemer.com>
|
@Neurrone In particular it would be handy if you could provide a PDF which demonstrates this issue. Thanks for bringing this to our attention! |
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. |
@feerrenrut the pdfs i've been dealing with have copyright on them, so i wasn't sure how i could legally distribute a sample. Wanted to put it up here first to see if anyone knew what was happening before I cut a page out of the pdf or something. |
That's ok, thanks @Neurrone. If you happen to come across one that you can safely distribute, please do attach it. This will make life easier for the person who works on this, since they can get started straight away without first having to find a test case. |
@derekriemer @feerrenrut I've found a free PDF I can link to to demonstrate. This is a sample from the book Haskell Programming from First Principles. On page 3 (press ctrl+shift+n and type 3 to directly go to it), this is the output in NVDA for the source code near the middle of the page.
But the output in jaws is
The latter is obviously much easier to read, especially when code gets more complex. This also happens in many other places, e.g section titles. |
Sidenote, how are the priority labels chosen? Feel that this should be medium severity at least, given how common PDFs are, and fixing would be a big usability win. |
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.
|
@jcsteh noted. There's probably no chance that tools being used in the wild will get fixed though (PdfLaTeX is one of the worst offenders). |
I think here we have the nub of many of the problems we see, particularly in
PDFs.
IE when talking to those making these files you are in fact talking to
people who know nothing about accessibility or tagging or any of that cool
stuff we rely on. This is why, in my view, whatever we do with trying to fix
things at the screenreader level, we should instead be trying to get the
authoring packages modified so people cannot ignore the accessibility parts
of the job. Quite who you lobby for this I have no idea.
Brian
bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal email to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
|
@Brian1Gaff it would be nice if the tools being used to generate PDFs got updated so they are standards compliant, but I'm not holding my breath It might happen for e.g, word but I don't think for PdfLaTeX. Even if they got fixed, we still have to deal with existing PDFs, so we'd still have to support them. |
I have a simple example attached here. It would be great if this could be fixed. |
RD-800_PA.pdf |
cc: @LeonarddeR |
Could somebody check if this issue is still valid with Adobe Reader DC 19.012.20040 and NVDA 2019.2.1? |
According to my test, Foxit Reader does not have this problem, but this problem is still important, and it would be great if it can be solved. |
There have been multiple duplicate Issues so I believe people are very concerned about this issue. |
When browsing PDFs in jaws vs NVDA in adobe reader, NVDA doesn't break across lines (e.g, especially across source code), while jaws breaks it appropriately.
The text was updated successfully, but these errors were encountered: