bug#44338: 27.1; EWW can't download and view pdf

[Nicholas Harrison]

After running the code you gave and using eww to open a pdf, this is what I get:

Debugger entered--entering a function:
* select-safe-coding-system("100" nil prefer-utf-8 nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
  write-region("100" nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
  #f(compiled-function () #<bytecode 0x1ff19f1>)()
  doc-view-sentinel(#<process pdf/ps->png> "finished\n")

Debugger entered--returning value: prefer-utf-8-dos
  select-safe-coding-system("100" nil prefer-utf-8 nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
  write-region("100" nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
  #f(compiled-function () #<bytecode 0x1ff19f1>)()
  doc-view-sentinel(#<process pdf/ps->png> "finished\n")

The buffer it ends up with says:

Cannot display this page!

Maybe because of a conversion failure!

On Thu, Nov 5, 2020 at 6:42 AM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Wed, 4 Nov 2020 16:43:13 -0700
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 44338@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.

Can you please produce the backtrace under those  modified conditions?