Bug 703834

Summary: Regression: Widget no longer accepted as annotation link
Product: MuPDF Reporter: Krzysztof Kowalczyk <kkowalczyk>
Component: mupdfAssignee: MuPDF bugs <mupdf-bugs>
Status: RESOLVED WONTFIX    
Severity: normal    
Priority: P4    
Version: master   
Hardware: PC   
OS: Windows 10   
Customer: Word Size: ---

Description Krzysztof Kowalczyk 2021-05-06 03:35:04 UTC
Originally reported as https://github.com/sumatrapdfreader/sumatrapdf/issues/1914

Repro pdf: https://github.com/sumatrapdfreader/sumatrapdf/files/6216075/UNE-EN_1991.pdf

In older versions of mupdf, pdf_load_link() would accept object of any type. At some point a check was added to reject objects that are not Subtype/Link. 

In some pdfs (like on page 49 in repro pdf), links are Subtype/Widget.

A fix would be to relax check in pdf_load_link() to accept objects with Subtype Link and Widget.

Something like:

diff --git a/mupdf/source/pdf/pdf-link.c b/mupdf/source/pdf/pdf-link.c
index 5ccefcf1a..8de33b464 100644
--- a/mupdf/source/pdf/pdf-link.c
+++ b/mupdf/source/pdf/pdf-link.c
@@ -405,7 +405,7 @@ pdf_load_link(fz_context *ctx, pdf_document *doc, pdf_obj *dict, int pagenum, fz
        fz_link *link = NULL;

        obj = pdf_dict_get(ctx, dict, PDF_NAME(Subtype));
-       if (!pdf_name_eq(ctx, obj, PDF_NAME(Link)))
+       if (!(pdf_name_eq(ctx, obj, PDF_NAME(Link)) || pdf_name_eq(ctx, obj, PDF_NAME(Widget))))
                return NULL;

        obj = pdf_dict_get(ctx, dict, PDF_NAME(Rect));
Comment 1 Tor Andersson 2021-08-11 14:59:59 UTC
Those are buttons, not links :)

Older versions of MuPDF didn't handle buttons, so we converted simple buttons with follow-a-link actions into links. We can't do that anymore without risking breaking interactive documents using javascript actions in forms and widgets.