[gs-bugs] [Bug 698769] - MuPDF - Internal fz_outline entries derive only point on the page, not a bounding box

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Bug ID: 698769
Summary: Internal fz_outline entries derive only point on the
page, not a bounding box
Product: MuPDF
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: mupdf
Assignee: mupdf-***@artifex.com
Reporter: ***@artifex.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

Internal outline entries specify a rectangular area within a page. Currently
MuPDF gives access only to the top left point of this area. The area is needed
for viewers to correctly position the page when an outline entry is selected.
In particular the MuSO project needs the area.

This is the cause of MuSO bug #698753.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Paul Gardiner <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@artifex.com

--- Comment #1 from Paul Gardiner <***@artifex.com> ---
Henry, adding you to the CC list in case you wish to set the priority and
allocate resources.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Joseph Heenan <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks| |698753

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Tor Andersson <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@artifex.com

--- Comment #2 from Tor Andersson <***@artifex.com> ---
To implement this you will need to extend pdf_parse_link_dest to tack on
other arguments to the (internal) URI link string we create.

PDF link destinations can do a LOT more than just setting a page area,
including things like changing the page zoom modes to FitV, FitH, FitBH,
FitBV, FitR, and XYZ zoom values, etc. I personally HATE it when documents
change the zoom level, so I have not implemented these idiotic features...

If you're willing you could put these values at the end of the link string and
crack the URI link string in MuSO.

The current formatting for an internal PDF link URI in mupdf is "#%d,%d,%d"
for where we have an X and Y coordinate (top left corner in PDF page coordinate
space). See pdf_resolve_link for where we crack this string and compute
the X,Y in fitz coordinate space.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

--- Comment #3 from Tor Andersson <***@artifex.com> ---
Also beware that this is PDF specific and needs care not to mess up other
document format's internal link types. EPUB uses string identifiers, etc.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

--- Comment #4 from Paul Gardiner <***@artifex.com> ---
Created attachment 14479
--> http://bugs.ghostscript.com/attachment.cgi?id=14479&action=edit
File with internal links that include area width and height

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Tor Andersson <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX

--- Comment #5 from Tor Andersson <***@artifex.com> ---
The attached document only has links of the XYZ variety, so there is no actual
zoom level or area to zoom into.

After some discussions on IRC we've decided not to pursue this feature (since I
think we can all agree that changing the UI zoom level on the whim of the
document author is bad form).

Closing as won't fix.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698769

Paul Gardiner <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks|698753 |