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

[Nicholas Harrison <nicholasharrison222@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]

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?
>

[-- Attachment #2: Type: text/html, Size: 4814 bytes --]