Preview ignoring some info in PDF table of content/sidebar

Indeed, my bug report could also have said that Preview, unlike Adobe, is ignoring the sign of ‘/Count’ parameters.

From pdfmark Reference, v9.0, June 2008:

Count integer Required if the bookmark has subordinate bookmarks, omitted otherwise. This key’s absolute value is the number of bookmarks immediately subordinate—that is, excluding subordinates of subordinates. If the value is positive, the bookmark is open, revealing its subordinates; if negative, the bookmark is closed, hiding its subordinates.

Note: This differs from the PDF Count key, which represents the total number of open descendants at all lower levels of the outline hierarchy.

Preview always shows bookmarks closed (unless manually opened), even if the /Count is positive. This is erroneous. Adobe’s behaviour is on-standard.

Preview is in some ways better (cleaner UI, more responsive), and some ways worse. But it should render PDFs according to the standard, at least as best it can. Doubtless some features would be difficult to implement. But the commented-upon mis-renderings seem (to me, on the outside, not knowing the code) to be easy to repair. So the request is not unreasonable.

Also see the related bug in the PDF plugin of Chrome version 45.0.2454.101.

A request about this, in case Apple see this when considering fixing the bug.

The request is to zoom to a FitR x y x y box. One direction will be the binding direction, and no more than the FitR range will be visible (or little more). In the other direction there will be room in the window to show more.

• If more can be shown in the vertical direction, have the top of the FitR box at the top of the window; unless that has the bottom of the PDF above the bottom of the window, in which case position by that; unless that has the top of the PDF below the top of the window, in which case centre vertically.

• If more can be shown in the horizontal direction, have the centre of the FitR box in the centre of the window; unless that leaves one edge of the window beyond the edge of the PDF, in which case align that side.

So vertically align top to top; horizontally align centre to centre.

Just upgraded to OS X El Capitan 10.11, and hence to Preview 8.1 (877).

No change. Still ignoring much of the information in the PDF.

Should I submit a new bug report? Is that being a pest, or is that a sensible way to ensure that Apple knows that it has not been fixed?

Wilco, thank you.

And should I start a new thread here?

(The below has been submitted as Apple Bug 22978817.)

Mac Preview (Preview 8.1 (877) under OS X El Capitan 10.11, and versions of Preview since at least Mavericks) ignores some information in PDFs. This is less minor than it seems. I use my Apple to create content. Open the PDF content in Preview: excellent content. Pat on back. Publish. No, it is not excellent. some parts of the PDF were wrong, but ignored by Preview so erroneously seemed correct. Hence I published non-excellent content. This is not what a Mac is for.

Because I’m creating PDFs from PostScript, the missing pieces will be described in those terms. The PDF terms are typically very similar.

• Outline items (i.e., something in the Table of Contents), can have child elements. If the parent has a positive number of child items (‘/Count’), the parent item should start by being open. If a negative number, the parent item should start by being closed. Mac Preview erroneously defaults to closed, even if positive.

mark /Action /GoTo /Dest … /Title … /Count -12 /F 0 /OUT pdfmark

• Outline items (i.e., something in the Table of Contents), can be formatted: /F 0 ⇒ plain; /F 1 ⇒ italic; /F 2 ⇒ bold; /F 3 ⇒ bold italic. This is ignored by Mac Preview.

mark /Action /GoTo /Dest … /Title … /Count -12 /F 2 /OUT pdfmark

• Outline items can have an /Action, of GoTo a ‘/DEST’ination. Mac Preview correctly goes to the page of the Destination, but ignores the within-page position. Destinations are created with code like (though there are several variations, see page 48 of pdfmark Reference, v9.0, June 2008).

mark /Dest /PageDetail /View [/FitR 100 100 250 200] /DEST pdfmark

and the Table of Contents item specified by code like

mark /Action /GoTo /Dest /PageDetail /Title (A very exciting detail on the page) /Count 0 /F 0 /OUT pdfmark

A bonus request about this. In zooming to a rectangle, there will typically be excess space in one of vertical and horizontal directions. If the excess space is vertical, align top of window to top of rectangle (unless this has the bottom of the PDF above the bottom of the window). And If the excess space is horizontal, centre it, again subject to not needlessly going outside the PDF page.

All three of the above bullets work correctly in Adobe Acrobat Reader DC, 2015 Release Version 2015.008.20082, and in many prior versions.

I have owned a Mac, typically several, since 1988. Please could this mean that I qualify for an acknowledgement that somebody in Apple agrees that this is less than ideal, even if not top priority? Thank you.

These has also been mentioned in https://discussions.apple.com/thread/7234631

(The above has been submitted as Apple Bug 22978817.)

The following has been added to bug 22978817.

Indeed, there is a piece of information that was heeded in pre-Capitan OS versions, but is now ignored in El Capitan. The following specifies that when the file is opened the sidebar should show the document outline:

mark /Page 1 /View [/Fit] /PageMode /UseOutlines /DOCVIEW pdfmark

but this is ignored and thumbs are shown. Please revert.