Highlighting PDFs not working properly

[marcoiac]

I am running the latest public beta of High Sierra, 10.13.3 Beta (17D25b). I am seeing this behavior in two machines (MacBook and MacBook Pro 13" first generation) both running Scrivener 3.0.1 (966). When I highlight multiple lines of a PDF only one line gets highlighted. When re-highlight the non highlighted lines, again only one line gets highlighted and the previously highlighted line is no longer highlighted!

Tried a couple of PDFs, obviously both imported in a Scrivener project, just to make sure it's not a file-specific issue.

Checked console and the only thing I found that might be related to this issue and in both machines is what is shown in the screenshots. There are multiple messages per second. What I am saying is, it may not be a Scrivener problem, since I would assume someone else should have noticed this.

I think this is all the meaningful information I can provide. Happy to answer questions if there is something that you need to know and I am not reporting.

Screenshot 2017-12-28 09.44.29.png (43.27 KiB) Viewed 4738 times

[KB]

Testing on 10.13.2 I'm not seeing any issues. Strange.

[hangulmalmotayo]

Hi,

I'm having this same issue. I'm not tech savvy so I don't really know how to fix it if the problem is not with Scrivener.

Thanks!

[sero]

I can confirm this problem in Scrivener 3.0.2 on macOS 10.13.3. It only happens for some PDF files, though. My theory is that the problem appears in PDFs with very narrow line spacing, where each line vertically "overlaps" slightly. One PDF were this happens for me is http://www.kerndatensatz-forschung.de/v ... DSF_v1.pdf.

The problem does not appear in Preview.app, but you can see the "overlapping" there, because the area between two lines is highlighted in a darker shade if you use the highlighter in Preview.app. I am sorry that I fail to describe this better in words, but English is not my native language.

Since the Cmd-Shift-H keyboard shortcut in Scrivener works as a toggle, that applies or removes the highlighting depending on whether or not the selected text is already highlighted, I would guess that the slight vertical overlap it confusing the logic that applies or removes the highlighting. So if I select two consecutive lines and press Cmd-Shift-H, the highlighting is applied to line one, and after that to line two. But because line one and two slightly overlap, at the same time line two is highlighted, the highlighting is removed from line one.

Let’s hope this can be fixed in Scrivener and is not a bug in the underlying PDF framework from Apple.

[AmberV]

On macOS 10.12, there does seem to be something the matter with annotations. To rule out any odd PDF-related inconsistencies:

1. Pasted some junk text into a new blank project’s starter file.
2. Hit ⌘P and used the PDF button to save a copy back to Scrivener (print settings: A4/25mm margin).
3. Selected the first three words from beginning of the first paragraph and hit ⇧⌘H.
   
   Result: the very bottom line of the PDF is highlighted from the edge of the paper on the left side. The width of the highlight area corresponds to the width of the three words being highlighted.
4. Selected two words from the second line.
   
   Result: again the highlight is applied to the very bottom of the page on the left side. Because the highlight range is slightly transparent, the effect is to darken the yellow stripe by the width of the two selected words.

All highlights will be applied in such a manner, even if the selection is further over to the right on the page. It should also be noted that overstrike exhibits the same behaviour. The following screenshot shows the result of three differently sized highlights, along with an overstrike added to the same word as the third highlight:

Let’s hope this can be fixed in Scrivener and is not a bug in the underlying PDF framework from Apple.

I’m curious about it as well, but given the input/output issue here, I highly doubt this is something Scrivener can do anything about, or has any influence over. It just assigns the keyboard shortcuts to the underlying commands.

[KB]

There are actually two completely separate issues here: the first was well-deduced by sero, and is a general issue; the second, reported by Ioa is a macOS bug specific to 10.12. I've fixed both for 3.0.3, but in case you are interested in the details:

1. Not all of the selection gets highlighted

Sero's gess was spot-on here. When Scrivener toggles highlights (or strike-throughs) on or off in a PDF view, it has to apply or remove the rectangle for each line separately. When adding highlights, it also removes any existing highlights from the selection (otherwise you could end up putting a pink highlight over a green highlight.) The only way it can detect existing highlights, though, is by going through all highlights on the page and checking to see if any of their bounding rectangles intersect with the current selection rectangle. If so, it removes the highlight before adding a new one.

However, my code currently works like this:

1. Go through, the selections, line by line.
2. For each line, check to see if it intersects with any existing highlights on the page.
3. If so, remove the old highlight.
4. Add the new highlight.

This assumes that selection rectangles never intersect *across* lines, though, whereas in sero's example PDF, they do, thanks to the narrow line spacing. So in that case, the code adds highlighting to a line, and then when it checks the line below, the selection for that line intersects with the highlighting of the line above, so the highlight above gets removed.

I have fixed this by iterating through selected lines and removing all intersecting existing highlights before going through and adding them. This way there is no interference between the two operations.

2. Highlights and strike-throughs appear at the bottom of the page on macOS 10.12

This was harder to fix, because it's an Apple bug, and took a little experimentation and logging lots of parameters. Essentially, Apple completely changed the way PDF annotations (including highlights and strike-throughs) are assigned as of 10.12 (or it might have been 10.11), deprecating old classes and replacing them with new ways of doing things. Unfortunately, they completely messed up and didn't provide the necessary replacements methods to to be able to be able to create things like highlights and strike-throughs again until 10.13. In the interim, we were advised to stick with the out-of-date methods. Somewhere in their rewrites, though, they messed up those old methods too.

Annotations (highlights etc) are added to a PDF page based on the selection rectangle. It should be straightforward: you ask the PDF view for its selection per line. Then you go through the selection and ask the PDF page for the rectangle of each piece of the selection. Then you create an annotation of a particular type (highlight, strike-through) with the selection rectangle as its bounding rectangle and add it to the page. What was weird that was, in this case, the bounding rectangle was correct - I logged everything and found the rectangles the same between 10.12 and 10.13 - and yet the highlights were appearing in the wrong place anyway. After a bit more digging I found that annotations have another obscure and not-very-well documented property called "quadrilateralPoints". It turned out that in good annotations, these contained a mixture of zeros and the width and height of the selection rectangle, whereas the bad annotations had some odd negative numbers in here. So I worked out the necessary values and assigned them myself, and things now seem to be working. It therefore seems that on macOS PDFKit has a bug whereby the selection bounds isn't correctly setting all of the internal properties of the annotation, causing it to appear in the wrong place.

So, yes, the short version is that these should - I hope! - both be fixed for 3.0.3.

Thanks to sero for the sample file, by the way!

All the best,
Keith