GNOME Bugzilla – Bug 704616
Accessible link endIndex is off by one
Last modified: 2013-07-25 13:06:49 UTC
Created attachment 249709 [details] event listener Steps to reproduce: 1. Open a PDF with links on the first page. 2. Enable caret navigation (see bug 702079) 3. Run the attached listener in a terminal. 4. Click within the text on the first page. Expected results: The full text of each link on the first page would be printed out correctly. Actual results: The final character of each link is chopped off.
Created attachment 249710 [details] PDF test case
Created attachment 249711 [details] HTML version of the same test case
Created attachment 249712 [details] ODT version of the same test case
Sorry for the attachment spam, but looking at the docs [1], one *might* make the argument that it's not an Evince bug, but a bug in my listener. After all the docs say that atk_hyperlink_get_end_index () returns "the index with the hypertext document at which this link ends." Which one might think means "the index of the last character in the link." But I'm pretty sure it means the "index/offset" where the link stops for two reasons: 1. The AT use case is to get the text of the link via getText(start, end) 2. Other implementors do it that way On the latter front, here's the output when performing the steps in the opening report with the different document formats: LibreOffice Writer: Accessible has 4 links: [(0, 29), (42, 54), (90, 123), (152, 153)] Link text: <Link at the start of the line> Link text: <another link> Link text: <one that wraps onto the next line> Link text: <a> ----------------- Epiphany: Accessible has 4 links: [(0, 29), (42, 54), (90, 123), (152, 153)] Link text: <Link at the start of the line> Link text: <another link> Link text: <one that wraps onto the next line> Link text: <a> ----------------- Evince: Accessible has 5 links: [(0, 28), (152, 152), (105, 122), (90, 104), (42, 53)] Link text: <Link at the start of the lin> Link text: <> Link text: <onto the next lin> Link text: <one that wraps> Link text: <another lin> Lastly, I myself am not too worried about the wrapping link being split; it's the missing text (which after "wraps" is a whitespace char). [1] https://developer.gnome.org/atk/unstable/AtkHyperlink.html
Created attachment 249714 [details] [review] proposed patch Return the index/offset after the last character in the link.
Review of attachment 249714 [details] [review]: Reworked commit message and pushed to git master. Thanks!