From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nicholas Harrison Newsgroups: gmane.emacs.bugs Subject: bug#44338: 27.1; EWW can't download and view pdf Date: Thu, 5 Nov 2020 08:18:19 -0700 Message-ID: References: <878sbmo6i0.fsf@tcd.ie> <83tuu5b1oh.fsf@gnu.org> <837dqzc42r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bc8e9305b35d9bab" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14938"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44338@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 05 16:19:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kah2e-0003kj-Fx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Nov 2020 16:19:12 +0100 Original-Received: from localhost ([::1]:38282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kah2d-0007sM-Do for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Nov 2020 10:19:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kah2U-0007rh-B3 for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 10:19:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kah2U-0005Hu-1g for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 10:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kah2T-00066T-U8 for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 10:19:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nicholas Harrison Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Nov 2020 15:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44338-submit@debbugs.gnu.org id=B44338.160458951823428 (code B ref 44338); Thu, 05 Nov 2020 15:19:01 +0000 Original-Received: (at 44338) by debbugs.gnu.org; 5 Nov 2020 15:18:38 +0000 Original-Received: from localhost ([127.0.0.1]:53844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kah25-00065o-J5 for submit@debbugs.gnu.org; Thu, 05 Nov 2020 10:18:38 -0500 Original-Received: from mail-yb1-f174.google.com ([209.85.219.174]:35246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kah23-00065Y-Ae for 44338@debbugs.gnu.org; Thu, 05 Nov 2020 10:18:36 -0500 Original-Received: by mail-yb1-f174.google.com with SMTP id m188so1657093ybf.2 for <44338@debbugs.gnu.org>; Thu, 05 Nov 2020 07:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1tWd+WNR5mcHVhATQSxW3CIue2Lv9SFbet+O+rltbxQ=; b=P0a7w2FTeCXPN6d4VPuDTrbAj4J/9tI8jPXF+ZHixcP07EDFg3Sm3Oaex5yFR0YmQp OplOsWYorOXJbNX7Qx95Y4FkJMPXIwaDun6RW4N9PCQkAgSJNX/ZtJqTFcgw3Ut3gpK8 4S6Y75ZxjHFudD/STvDrSDevLy8NpZdK2Lk4qSKec9djiUDuKv7H3n0lCZtyjmT+Nn8W /fNmSm69r7rgTNrEv8X8hpCn3r0mEjcvfjP/oATEUw9sJckr3vOKP12pseM4L910QjCl oocll/5NM4s6WQEgvHnlx9k5THEsvqm14XzjR31H70+RSEiVIF4aYeE07xscy/DSnmNf S6Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1tWd+WNR5mcHVhATQSxW3CIue2Lv9SFbet+O+rltbxQ=; b=nTgrwcoBvSFLk57ivX4pSaSrJsnPdeMd0ZGgzAqOlbfdcu+MIH1KzgYgcVGpijHtXZ 3UQPM9es9jQF7EBv7neoJp4beYrm4dBqZktDeyP276PT0iqhB5YFZJoGLh5mTZsZGB7n /vo6inxy+jXBDL7xb5wGi5gEm1htET4LI9cNaNx84BAHwJM2PpvR0POoKF4qr9YIxc/N /DkIdk5t6pxHpQ0EN0EBzyM3/lBipGRbadW1JyP2gwlzvkCa0qatKltgXX19Ecn553bp K3QPMnTrVEIPWSPXVJliwUTprCX3croeUzgwiMSHdAyqYW38ZD+yVV9K/KsCgRR6ghjm Epcw== X-Gm-Message-State: AOAM533nWpxmdXz6wqWRDpKJw8CzwE0mzvfjLk3OSro/Ya7NUN7m9tWf E6Vpq1cXvm9SaL8WuD3NbCcE37E0Ttc3zYyaYr4= X-Google-Smtp-Source: ABdhPJw3PTN5IxVsEYX7WlFocbXQOe0gdBhVGzgt0gSdu6LO6iy2N0/hO3BlwMfCVcubPKna6kD4wUmiQltNKjFApMc= X-Received: by 2002:a25:81d0:: with SMTP id n16mr3996026ybm.140.1604589509708; Thu, 05 Nov 2020 07:18:29 -0800 (PST) In-Reply-To: <837dqzc42r.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192729 Archived-At: --000000000000bc8e9305b35d9bab Content-Type: text/plain; charset="UTF-8" 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 () #)() doc-view-sentinel(#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 () #)() doc-view-sentinel(#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 wrote: > > From: Nicholas Harrison > > Date: Wed, 4 Nov 2020 16:43:13 -0700 > > Cc: "Basil L. Contovounesios" , 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? > --000000000000bc8e9305b35d9bab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After running the code you gave and using eww to open a pd= f, this is what I get:

Debugger entered--entering a func= tion:
* select-safe-coding-system("100" nil prefer-utf-8 nil &= quot;c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee= 28e656f1a01f0cb4a9/resolution.el")
=C2=A0 write-region("100&qu= ot; nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e= 1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
=C2=A0 #f(= compiled-function () #<bytecode 0x1ff19f1>)()
=C2=A0 doc-view-sent= inel(#<process pdf/ps->png> "finished\n")
=
Debugger entered--returning value: prefer-utf-8-dos
=C2= =A0 select-safe-coding-system("100" nil prefer-utf-8 nil "c:= /Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26ee28e656f= 1a01f0cb4a9/resolution.el")
=C2=A0 write-region("100" nil= "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!-2072e1249b26= ee28e656f1a01f0cb4a9/resolution.el" nil silently)
=C2=A0 #f(compile= d-function () #<bytecode 0x1ff19f1>)()
=C2=A0 doc-view-sentinel(#&= lt;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<= /a>> wrote:
&= gt; 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!") >=C2=A0 =C2=A0write-region(nil nil "c:/Users/nicho/AppData/Local/Te= mp/docview1001/!eww pdf!")
>=C2=A0 =C2=A0doc-view-mode()
>=C2=A0 =C2=A0funcall-interactively(doc-view-mode)
>=C2=A0 =C2=A0call-interactively(doc-view-mode record nil)
>=C2=A0 =C2=A0command-execute(doc-view-mode record)
>=C2=A0 =C2=A0execute-extended-command(nil "doc-view-mode" &qu= ot;doc-view-mo")
>=C2=A0 =C2=A0funcall-interactively(execute-extended-command nil "d= oc-view-mode" "doc-view-mo")
>=C2=A0 =C2=A0call-interactively(execute-extended-command nil nil)
>=C2=A0 =C2=A0command-execute(execute-extended-command)

Thanks.=C2=A0 This tells part of the story, but not all of it.=C2=A0 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:

=C2=A0(add-to-list 'mailcap-user-mime-data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 '((type . "applic= ation/pdf")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (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-codi= ng-system
is the platform default, in your case iso-latin-1-dos.=C2=A0 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.=C2=A0 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<= br> temporary file, and yet in your screenshot I still see it tried to use
iso-latin-1-dos, which I cannot explain.=C2=A0 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=C2=A0 modified conditions?=
--000000000000bc8e9305b35d9bab--