GNU bug report logs - #44338
27.1; EWW can't download and view pdf

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicholas Harrison <nicholasharrison222 <at> gmail.com>
Cc: contovob <at> tcd.ie, 44338 <at> debbugs.gnu.org
Subject: bug#44338: 27.1; EWW can't download and view pdf
Date: Thu, 05 Nov 2020 15:42:30 +0200

> From: Nicholas Harrison <nicholasharrison222 <at> gmail.com>
> Date: Wed, 4 Nov 2020 16:43:13 -0700
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 44338 <at> debbugs.gnu.org
> 
> Not sure if this is much help, but here is the backtrace given when I do the following steps:
> 
> 1. emacs -Q
> 2. M-: (debug-on-entry 'select-safe-coding-system) RET
> 3. M-x eww RET https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf RET
> (no backtrace here)
> 4. M-x doc-view-mode RET
> 
> Debugger entered--entering a function:
> * select-safe-coding-system(1 381654 iso-latin-1-dos nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
>   write-region(nil nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
>   doc-view-mode()
>   funcall-interactively(doc-view-mode)
>   call-interactively(doc-view-mode record nil)
>   command-execute(doc-view-mode record)
>   execute-extended-command(nil "doc-view-mode" "doc-view-mo")
>   funcall-interactively(execute-extended-command nil "doc-view-mode" "doc-view-mo")
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)

Thanks.  This tells part of the story, but not all of it.  What I
wanted to see was the backtrace when doc-view-mode is invoked by EWW.
AFAIU, that requires you to augment mailcap-user-mime-data as this:

 (add-to-list 'mailcap-user-mime-data
              '((type . "application/pdf")
                (viewer . doc-view-mode)))

before performing the reproduction steps.

To give you more background: when you invoke doc-view-mode manually in
a buffer produced by "M-x eww", the buffer's buffer-file-coding-system
is the platform default, in your case iso-latin-1-dos.  That is what
doc-view-mode uses to write the PDF bytestream to a temporary file,
and that fails because iso-latin-1-dos cannot encode the raw bytes in
the binary content.  But eww-display-pdf binds coding-system-for-write
to 'raw-text, and then doc-view-mode ought to use that to write to the
temporary file, and yet in your screenshot I still see it tried to use
iso-latin-1-dos, which I cannot explain.  So I'd like to see the
backtrace when you invoke doc-view-mode via EWW, after augmenting
mailcap-user-mime-data, to try to understand why it uses the wrong
encoding.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.