GNU bug report logs -
#60308
30.0.50; Can't read some PDF files any more
Previous Next
Reported by: Jean Louis <bugs <at> gnu.support>
Date: Sun, 25 Dec 2022 11:37:02 UTC
Severity: normal
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60308 in the body.
You can then email your comments to 60308 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sun, 25 Dec 2022 11:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jean Louis <bugs <at> gnu.support>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 25 Dec 2022 11:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The attached PDF file I cannot read with emacs -Q including many other
files, not appearing for unknown reason. Before month or more it was all
working well.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.17.6, Xaw3d scroll bars) of 2022-12-22 built on
protected.rcdrun.com
Repository revision: e98ab3f458b25812eff1b3a7ce6429caece4c891
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Parabola GNU/Linux-libre
Configured using:
'configure --with-x-toolkit=lucid --with-mailutils'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=exwm-xim
locale-coding-system: utf-8-unix
Major mode: Dired by name
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils shell subr-x pcomplete comint
ansi-osc ansi-color ring doc-view filenotify jka-compr image-mode exif
dired-aux cl-loaddefs cl-lib dired dired-loaddefs rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 51499 5773)
(symbols 48 6414 2)
(strings 32 18519 1600)
(string-bytes 1 533945)
(vectors 16 13003)
(vector-slots 8 182726 11451)
(floats 8 57 22)
(intervals 56 451 0)
(buffers 984 14))
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
[erinn-clark-attack-appelbaum.pdf (application/pdf, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Thu, 05 Jan 2023 17:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 60308 <at> debbugs.gnu.org (full text, mbox):
I can't read this file with emacs -Q:
https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
I see that change happened before weeks.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Thu, 05 Jan 2023 17:13:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> I can't read this file with emacs -Q:
>
> https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
I can reproduce on Emacs 30 and Emacs 29, but not on Emacs 28
Recipe: emacs -Q /path/to/the/linked/downloaded/pdf
Observed: empty buffer
Expected: PDF page is displayed
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Thu, 05 Jan 2023 18:32:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> Cc: 60308 <at> debbugs.gnu.org
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Date: Thu, 05 Jan 2023 17:12:21 +0000
>
> Jean Louis <bugs <at> gnu.support> writes:
>
> > I can't read this file with emacs -Q:
> >
> > https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
>
> I can reproduce on Emacs 30 and Emacs 29, but not on Emacs 28
>
> Recipe: emacs -Q /path/to/the/linked/downloaded/pdf
>
> Observed: empty buffer
> Expected: PDF page is displayed
Can someone bisect this, please?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Thu, 05 Jan 2023 20:59:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>>> I can't read this file with emacs -Q:
>>>
>>> https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
>>
>> I can reproduce on Emacs 30 and Emacs 29, but not on Emacs 28
>>
>> Recipe: emacs -Q /path/to/the/linked/downloaded/pdf
>>
>> Observed: empty buffer
>> Expected: PDF page is displayed
>
> Can someone bisect this, please?
>
FTR, that file opens fine here, with Emacs 29 at ec172d748f, at
d2a9dae400, at a6bad4d60f, at c59b8dfefa... and with Emacs 28.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 06:35:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 60308 <at> debbugs.gnu.org (full text, mbox):
With latest Emacs, pulled from git before minutes, I can't see first
page of that file, but if I press page down, I can see subsequent
pages.
I have been observing similar with other PDF files.
Including I can't see some PNGs
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 06:41:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 05 Jan 2023 20:58:24 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Ihor Radchenko <yantar92 <at> posteo.net>, 60308 <at> debbugs.gnu.org,
> bugs <at> gnu.support
>
> >>> I can't read this file with emacs -Q:
> >>>
> >>> https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
> >>
> >> I can reproduce on Emacs 30 and Emacs 29, but not on Emacs 28
> >>
> >> Recipe: emacs -Q /path/to/the/linked/downloaded/pdf
> >>
> >> Observed: empty buffer
> >> Expected: PDF page is displayed
> >
> > Can someone bisect this, please?
> >
>
> FTR, that file opens fine here, with Emacs 29 at ec172d748f, at
> d2a9dae400, at a6bad4d60f, at c59b8dfefa... and with Emacs 28.
Thanks.
So maybe the problem is updates to libraries/executables we use for
viewing PDF? AFAIR, this is DocView, and it use Ghostscript and
libpng? Maybe both Jean and Ihor had their systems updated recently?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 10:00:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 60308 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 06 Jan 2023 08:40:13 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Thu, 05 Jan 2023 20:58:24 +0000
>> From: Gregory Heytings <gregory <at> heytings.org>
>> cc: Ihor Radchenko <yantar92 <at> posteo.net>, 60308 <at> debbugs.gnu.org,
>> bugs <at> gnu.support
>>
>> >>> I can't read this file with emacs -Q:
>> >>>
>> >>> https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf
>> >>
>> >> I can reproduce on Emacs 30 and Emacs 29, but not on Emacs 28
>> >>
>> >> Recipe: emacs -Q /path/to/the/linked/downloaded/pdf
>> >>
>> >> Observed: empty buffer
>> >> Expected: PDF page is displayed
>> >
>> > Can someone bisect this, please?
>> >
>>
>> FTR, that file opens fine here, with Emacs 29 at ec172d748f, at
>> d2a9dae400, at a6bad4d60f, at c59b8dfefa... and with Emacs 28.
>
> Thanks.
>
> So maybe the problem is updates to libraries/executables we use for
> viewing PDF? AFAIR, this is DocView, and it use Ghostscript and
> libpng? Maybe both Jean and Ihor had their systems updated recently?
I see the problem in Emacs 29 and master, but not in Emacs 28, on the
same system, i.e. with the same image libraries. When the bad display
appears, the following entry appears in *Messages*:
Error parsing SVG image: XML parse error: Error domain 1 code 68 on line
7393 column 18 of data: StartTag: invalid element name
This seems to comes from svg_load_image in image.c. I started Emacs 29
with -Q in gdb after setting a breakpoint at svg_load_image, opened the
PDF file, hit the breakpoint and stepped through till the bad display
appeared. The ouput of bt full is attached. (I also ran Emacs 28 under
gdb with the same breakpoint, and there visiting the PDF file does not
hit the breakpoint.)
Steve Berman
[backtrace (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 10:11:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>
> I see the problem in Emacs 29 and master, but not in Emacs 28, on the
> same system, i.e. with the same image libraries. When the bad display
> appears, the following entry appears in *Messages*:
>
> Error parsing SVG image: XML parse error: Error domain 1 code 68 on line
> 7393 column 18 of data: StartTag: invalid element name
>
> This seems to comes from svg_load_image in image.c. I started Emacs 29
> with -Q in gdb after setting a breakpoint at svg_load_image, opened the
> PDF file, hit the breakpoint and stepped through till the bad display
> appeared. The ouput of bt full is attached. (I also ran Emacs 28 under
> gdb with the same breakpoint, and there visiting the PDF file does not
> hit the breakpoint.)
>
Thanks. Can you please also share the "/tmp/docview1000/FR 205.pdf-7039e6f9886aceec549c36d51591d258/page-1.svg" file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 10:23:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>
> Thanks. Can you please also share the "/tmp/docview1000/FR
> 205.pdf-7039e6f9886aceec549c36d51591d258/page-1.svg" file?
>
And also the output of "mutool -v" (IOW, the version of mupdf that is
installed on your computer)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 10:34:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 60308 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 06 Jan 2023 10:10:03 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>
>> I see the problem in Emacs 29 and master, but not in Emacs 28, on the same
>> system, i.e. with the same image libraries. When the bad display appears,
>> the following entry appears in *Messages*:
>>
>> Error parsing SVG image: XML parse error: Error domain 1 code 68 on line
>> 7393 column 18 of data: StartTag: invalid element name
>>
>> This seems to comes from svg_load_image in image.c. I started Emacs 29 with
>> -Q in gdb after setting a breakpoint at svg_load_image, opened the PDF file,
>> hit the breakpoint and stepped through till the bad display appeared. The
>> ouput of bt full is attached. (I also ran Emacs 28 under gdb with the same
>> breakpoint, and there visiting the PDF file does not hit the breakpoint.)
>>
>
> Thanks. Can you please also share the "/tmp/docview1000/FR
> 205.pdf-7039e6f9886aceec549c36d51591d258/page-1.svg" file?
Attached (gzipped). In the mean time I found the problem: that file
contains occurrences of "<" and that causes the error; after replacing
them with "<" the PDF is displayed correctly.
On Fri, 06 Jan 2023 10:22:02 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>
> And also the output of "mutool -v" (IOW, the version of mupdf that is
> installed on your computer)?
mutool version 1.21.0
Steve Berman
[page-1.svg.gz (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 11:13:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>
> Attached (gzipped). In the mean time I found the problem: that file
> contains occurrences of "<" and that causes the error; after replacing
> them with "<" the PDF is displayed correctly.
>
> [...]
>
> mutool version 1.21.0
>
Thanks. So this looks like a mutool bug, which generates incorrect SGV
files, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 11:45:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 60308 <at> debbugs.gnu.org (full text, mbox):
On Fri, 06 Jan 2023 11:12:19 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>
>> Attached (gzipped). In the mean time I found the problem: that file
>> contains occurrences of "<" and that causes the error; after replacing them
>> with "<" the PDF is displayed correctly.
>>
>> [...]
>>
>> mutool version 1.21.0
>>
>
> Thanks. So this looks like a mutool bug, which generates incorrect SGV files,
> right?
Yep. I just converted the PDF to SVG with mutool 1.19.0 and the
resulting image displays correctly and there is no "<" in the file.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 12:05:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60308 <at> debbugs.gnu.org,
> yantar92 <at> posteo.net, bugs <at> gnu.support
> Date: Fri, 06 Jan 2023 12:44:16 +0100
>
> On Fri, 06 Jan 2023 11:12:19 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>
> >>
> >> Attached (gzipped). In the mean time I found the problem: that file
> >> contains occurrences of "<" and that causes the error; after replacing them
> >> with "<" the PDF is displayed correctly.
> >>
> >> [...]
> >>
> >> mutool version 1.21.0
> >>
> >
> > Thanks. So this looks like a mutool bug, which generates incorrect SGV files,
> > right?
>
> Yep. I just converted the PDF to SVG with mutool 1.19.0 and the
> resulting image displays correctly and there is no "<" in the file.
xmllint clearly says the file is invalid, due to those "<" characters.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 12:23:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>> Thanks. So this looks like a mutool bug, which generates incorrect SGV
>> files, right?
>
> Yep. I just converted the PDF to SVG with mutool 1.19.0 and the
> resulting image displays correctly and there is no "<" in the file.
>
Okay, so this bug should be reported to mupdf instead, and this one can be
closed.
FTR, I tried to open that SVG file with GIMP and ImageMagick, and both
failed.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 06 Jan 2023 12:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jean Louis <bugs <at> gnu.support>:
bug acknowledged by developer.
(Fri, 06 Jan 2023 12:56:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 60308-done <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Jan 2023 12:22:44 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 60308 <at> debbugs.gnu.org, yantar92 <at> posteo.net,
> bugs <at> gnu.support
>
>
> >> Thanks. So this looks like a mutool bug, which generates incorrect SGV
> >> files, right?
> >
> > Yep. I just converted the PDF to SVG with mutool 1.19.0 and the
> > resulting image displays correctly and there is no "<" in the file.
> >
>
> Okay, so this bug should be reported to mupdf instead
They already released version 1.21.1, maybe it fixes this problem?
> and this one can be closed.
Right, done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 13:03:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 60308 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2023-01-06 09:40]:
> Thanks.
>
> So maybe the problem is updates to libraries/executables we use for
> viewing PDF? AFAIR, this is DocView, and it use Ghostscript and
> libpng? Maybe both Jean and Ihor had their systems updated
> recently?
I use Parabola GNU/Linux-libre.
After viewing PDF, I could see background process of mutool which was
making CPU busy for no apparent reason. Maybe it is related, I can't
know.
I can also observe that viewing DVI files with xdvi is terribly slow,
I can't know why, maybe it is related, maybe not.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 13:03:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 60308 <at> debbugs.gnu.org (full text, mbox):
* Gregory Heytings <gregory <at> heytings.org> [2023-01-06 13:24]:
>
> >
> > Thanks. Can you please also share the "/tmp/docview1000/FR
> > 205.pdf-7039e6f9886aceec549c36d51591d258/page-1.svg" file?
> >
>
> And also the output of "mutool -v" (IOW, the version of mupdf that is
> installed on your computer)?
Mine is: mutool version 1.21.0
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Fri, 06 Jan 2023 20:39:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 60308 <at> debbugs.gnu.org (full text, mbox):
On Fri, 06 Jan 2023 14:55:56 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 06 Jan 2023 12:22:44 +0000
>> From: Gregory Heytings <gregory <at> heytings.org>
>> cc: Eli Zaretskii <eliz <at> gnu.org>, 60308 <at> debbugs.gnu.org, yantar92 <at> posteo.net,
>> bugs <at> gnu.support
>>
>>
>> >> Thanks. So this looks like a mutool bug, which generates incorrect SGV
>> >> files, right?
>> >
>> > Yep. I just converted the PDF to SVG with mutool 1.19.0 and the
>> > resulting image displays correctly and there is no "<" in the file.
>> >
>>
>> Okay, so this bug should be reported to mupdf instead
>
> They already released version 1.21.1, maybe it fixes this problem?
FTR, I just updated my mupdf to 1.21.1 and unfortunately the problem
remains as before. I'll try to file a bug report with mupdf.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 15:49:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 60308 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stephen Berman <stephen.berman <at> gmx.net> writes:
[...]
> FTR, I just updated my mupdf to 1.21.1 and unfortunately the problem
> remains as before. I'll try to file a bug report with mupdf.
Hi,
Here a first patch that prevent producing SVG when mutool has a
version > 1.20. Feel free to comment and fix.
Best regards,
[0001-Prevent-DocView-to-produce-SVG-with-mutool-for-versi.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 18:27:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>
> Here a first patch that prevent producing SVG when mutool has a version > 1.20. Feel free to comment and fix.
>
I just tried, and most PDF files are processed without problems with
mutool 1.21. So I'm not sure we should install such a workaround in
Emacs, for a bug that happens in some cases for some specific versions
(1.20 and 1.21) of a specific external program.
Those who have these versions of that program can (temporarily) add
(setq doc-view-mupdf-use-svg nil)
to their init file, or toggle that value to open problematic files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 18:36:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Jan 2023 18:25:58 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Stephen Berman <stephen.berman <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>,
> 60308 <at> debbugs.gnu.org, yantar92 <at> posteo.net, bugs <at> gnu.support
>
>
> >
> > Here a first patch that prevent producing SVG when mutool has a version > 1.20. Feel free to comment and fix.
> >
>
> I just tried, and most PDF files are processed without problems with
> mutool 1.21.
That's not what Stephen says, he tried 1.21.1.
> So I'm not sure we should install such a workaround in Emacs, for a
> bug that happens in some cases for some specific versions (1.20 and
> 1.21) of a specific external program.
>
> Those who have these versions of that program can (temporarily) add
>
> (setq doc-view-mupdf-use-svg nil)
>
> to their init file, or toggle that value to open problematic files.
We can, of course, have an entry in etc/PROBLEMS, if that's the best
we can do. But I wonder why you see something different from what
others see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 18:38:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
>>
>> Here a first patch that prevent producing SVG when mutool has a
>> version > 1.20. Feel free to comment and fix.
>>
>
> I just tried, and most PDF files are processed without problems with
> mutool 1.21.
It happens when a document contains a '<' character so it can be rare
for someone.
> So I'm not sure we should install such a workaround in Emacs, for a
> bug that happens in some cases for some specific versions (1.20 and
> 1.21) of a specific external program.
You are right that it should be a temporary bug in mupdf. But I was
more worry of random page not rendering as it was before with DocView.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 18:46:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>> I just tried, and most PDF files are processed without problems with
>> mutool 1.21.
>
> That's not what Stephen says, he tried 1.21.1.
>
Sorry, I meant 1.21.1.
>
> We can, of course, have an entry in etc/PROBLEMS, if that's the best we
> can do. But I wonder why you see something different from what others
> see.
>
I see the same problem with the Jean's file, but I tried a random sample
of about 20 PDF files and only a couple failed to be rendered correctly.
Perhaps we could add a command to toggle the rendering mode?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 19:00:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>> I just tried, and most PDF files are processed without problems with
>> mutool 1.21.
>
> It happens when a document contains a '<' character so it can be rare
> for someone.
>
More precisely: it happens for pages with a '<' character. Other pages of
the document are rendered correctly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 20:08:03 GMT)
Full text and
rfc822 format available.
Message #82 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Jan 2023 18:59:27 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
> yantar92 <at> posteo.net, 60308 <at> debbugs.gnu.org, bugs <at> gnu.support
>
>
> >> I just tried, and most PDF files are processed without problems with
> >> mutool 1.21.
> >
> > It happens when a document contains a '<' character so it can be rare
> > for someone.
> >
>
> More precisely: it happens for pages with a '<' character. Other pages of
> the document are rendered correctly.
If it's rare, maybe a PROBLEMS entry is good enough.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 20:54:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
[...]
>> It happens when a document contains a '<' character so it can be
>> rare for someone.
>>
>
> More precisely: it happens for pages with a '<' character. Other
> pages of the document are rendered correctly.
Yes you're right.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 21:00:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> More precisely: it happens for pages with a '<' character. Other pages of
>> the document are rendered correctly.
>
> If it's rare, maybe a PROBLEMS entry is good enough.
I guess I'm not lucky because most of the document I read have some
pages with a '<' character 😅
Anyway, I'm fine with an etc/PROBLEMS entry. For the moment, I'll set
doc-view-mupdf-use-svg to nil and try to see with Stephen how to have it
handled upstream.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 07 Jan 2023 22:20:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 60308 <at> debbugs.gnu.org (full text, mbox):
A bug report, with a corrective patch, has been submitted to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028156
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sun, 08 Jan 2023 12:58:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> A bug report, with a corrective patch, has been submitted to Debian:
Thanks. I'm not using Debian so I hope it will make it upstream. Could
I try to submit it to mupdf?
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Tue, 10 Jan 2023 11:00:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>> A bug report, with a corrective patch, has been submitted to Debian:
>
> Thanks. I'm not using Debian so I hope it will make it upstream.
> Could I try to submit it to mupdf?
>
Sure. Perhaps add a link to the Debian bug report, and mention in the
Debian bug thread that you reported it upstream.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Wed, 11 Jan 2023 10:36:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 60308 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
[...]
> Sure. Perhaps add a link to the Debian bug report, and mention in the
> Debian bug thread that you reported it upstream.
Hi Gregory,
It seems that your patch was merged upstream:
https://bugs.ghostscript.com/show_bug.cgi?id=706320
So I think that we could left `doc-view-mupdf-use-svg' as it is and just
have an entry in etc/PROBLEMS.
Thanks,
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Wed, 11 Jan 2023 16:27:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 60308 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> It seems that your patch was merged upstream:
> https://bugs.ghostscript.com/show_bug.cgi?id=706320
>
Great, that was fast! 😃
>
> So I think that we could left `doc-view-mupdf-use-svg' as it is and just
> have an entry in etc/PROBLEMS.
>
Agreed, just mentioning that some specific versions of mupdf have a bug
should be enough. It would be even better if DocView could automatically
fall back to generating a PNG file, but that seems rather complex to do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Wed, 11 Jan 2023 17:04:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 60308 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 11 Jan 2023 16:26:26 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 60308 <at> debbugs.gnu.org, bugs <at> gnu.support, yantar92 <at> posteo.net,
> Eli Zaretskii <eliz <at> gnu.org>, stephen.berman <at> gmx.net
>
> > So I think that we could left `doc-view-mupdf-use-svg' as it is and just
> > have an entry in etc/PROBLEMS.
>
> Agreed, just mentioning that some specific versions of mupdf have a bug
> should be enough.
How do we do that? I don't see in that bug report anything that says
which version will have that fixed. What did I miss?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Wed, 11 Jan 2023 19:34:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 60308 <at> debbugs.gnu.org (full text, mbox):
>> Agreed, just mentioning that some specific versions of mupdf have a bug
>> should be enough.
>
> How do we do that? I don't see in that bug report anything that says
> which version will have that fixed. What did I miss?
>
Versions 1.19 and 1.20 are not affected by that bug, currently only
version 1.21 is (1.21.0 was released two months ago, 1.21.1 one month
ago).
According to https://mupdf.com/releases/history.html they release a new
version every six months or so, and a minor version when necessary. So I
would guess that this will be fixed either in version 1.21.2, or in
version 1.22 in a few months.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60308; Package
emacs.
(Sat, 14 Jan 2023 08:54:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 60308-done <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 11 Jan 2023 19:33:54 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 60308 <at> debbugs.gnu.org, stephen.berman <at> gmx.net, yantar92 <at> posteo.net,
> bugs <at> gnu.support, manuel <at> ledu-giraud.fr
>
>
> >> Agreed, just mentioning that some specific versions of mupdf have a bug
> >> should be enough.
> >
> > How do we do that? I don't see in that bug report anything that says
> > which version will have that fixed. What did I miss?
> >
>
> Versions 1.19 and 1.20 are not affected by that bug, currently only
> version 1.21 is (1.21.0 was released two months ago, 1.21.1 one month
> ago).
>
> According to https://mupdf.com/releases/history.html they release a new
> version every six months or so, and a minor version when necessary. So I
> would guess that this will be fixed either in version 1.21.2, or in
> version 1.22 in a few months.
OK, I've now added a PROBLEMS entry about this. We can update it with
a non-buggy version when we know it.
And with that, I'm closing the bug.
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Feb 2023 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.