GNU bug report logs - #65299
29.1; ZIP archived WEBP images can not be displayed correctly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65299 in the body.
You can then email your comments to 65299 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: awrhygty <at> outlook.com
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; ZIP archived WEBP images can not be displayed correctly
Date: Tue, 15 Aug 2023 13:02:43 +0900

Opening a entry for a WEBP image in a ZIP archive,
the subfile buffer is multibyte and the image is not displayed or
displayed collapsed.


In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3324)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  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 emacsbug help-mode gnutls network-stream nsm mailalias smtpmail
textsec uni-scripts url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source eieio eieio-core cl-macs json map byte-opt gv bytecomp
byte-compile url-vars idna-mapping ucs-normalize uni-confusable
textsec-check sort cl-seq misearch multi-isearch mail-extr message
sendmail mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader cl-loaddefs cl-lib
term/bobcat japan-util rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
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
w32notify w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 212299 10574)
 (symbols 48 7316 0)
 (strings 32 35739 2019)
 (string-bytes 1 725531)
 (vectors 16 38994)
 (vector-slots 8 785300 24810)
 (floats 8 95 119)
 (intervals 56 407 0)
 (buffers 984 11))

Message #8 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: awrhygty <at> outlook.com
Cc: 65299 <at> debbugs.gnu.org
Subject: Re: bug#65299: 29.1;
 ZIP archived WEBP images can not be displayed correctly
Date: Tue, 15 Aug 2023 14:05:42 +0300

> From: awrhygty <at> outlook.com
> Date: Tue, 15 Aug 2023 13:02:43 +0900
> 
> 
> Opening a entry for a WEBP image in a ZIP archive,
> the subfile buffer is multibyte and the image is not displayed or
> displayed collapsed.

You need to say

  C-x RET c no-conversion RET RET

to open such files from a zip archive.

Determining the right coding system when opening files from ZIP
archives is a tricky issue, and frequently needs forcing a certain
encoding manually.  I don't know how to do better in general, what
with all the possible sources of the files and their encodings.  A Zip
archive can include files from Unix systems or from Windows, and we
unzip by running the 'unzip' program.  So the usual defaults for
guessing the encoding don't really work.

Message #11 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: awrhygty <at> outlook.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65299 <at> debbugs.gnu.org
Subject: Re: bug#65299: 29.1; ZIP archived WEBP images can not be displayed
 correctly
Date: Tue, 15 Aug 2023 22:05:36 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: awrhygty <at> outlook.com
>> Date: Tue, 15 Aug 2023 13:02:43 +0900
>> 
>> 
>> Opening a entry for a WEBP image in a ZIP archive,
>> the subfile buffer is multibyte and the image is not displayed or
>> displayed collapsed.
>
> You need to say
>
>   C-x RET c no-conversion RET RET
>
> to open such files from a zip archive.
>
> Determining the right coding system when opening files from ZIP
> archives is a tricky issue, and frequently needs forcing a certain
> encoding manually.  I don't know how to do better in general, what
> with all the possible sources of the files and their encodings.  A Zip
> archive can include files from Unix systems or from Windows, and we
> unzip by running the 'unzip' program.  So the usual defaults for
> guessing the encoding don't really work.

At least modifying 'auto-coding-alist takes effect.

Message #14 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: awrhygty <at> outlook.com
Cc: 65299 <at> debbugs.gnu.org
Subject: Re: bug#65299: 29.1; ZIP archived WEBP images can not be displayed
 correctly
Date: Tue, 15 Aug 2023 17:13:15 +0300

> From: awrhygty <at> outlook.com
> Cc: 65299 <at> debbugs.gnu.org
> Date: Tue, 15 Aug 2023 22:05:36 +0900
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > You need to say
> >
> >   C-x RET c no-conversion RET RET
> >
> > to open such files from a zip archive.
> >
> > Determining the right coding system when opening files from ZIP
> > archives is a tricky issue, and frequently needs forcing a certain
> > encoding manually.  I don't know how to do better in general, what
> > with all the possible sources of the files and their encodings.  A Zip
> > archive can include files from Unix systems or from Windows, and we
> > unzip by running the 'unzip' program.  So the usual defaults for
> > guessing the encoding don't really work.
> 
> At least modifying 'auto-coding-alist takes effect.

OK, but that cannot be done by default, since the right encoding is
not known in advance.

Message #17 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65299 <at> debbugs.gnu.org, awrhygty <at> outlook.com
Subject: Re: bug#65299: 29.1;
 ZIP archived WEBP images can not be displayed correctly
Date: Fri, 1 Sep 2023 22:24:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: awrhygty <at> outlook.com
> > Cc: 65299 <at> debbugs.gnu.org
> > Date: Tue, 15 Aug 2023 22:05:36 +0900
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > You need to say
> > >
> > >   C-x RET c no-conversion RET RET
> > >
> > > to open such files from a zip archive.
> > >
> > > Determining the right coding system when opening files from ZIP
> > > archives is a tricky issue, and frequently needs forcing a certain
> > > encoding manually.  I don't know how to do better in general, what
> > > with all the possible sources of the files and their encodings.  A Zip
> > > archive can include files from Unix systems or from Windows, and we
> > > unzip by running the 'unzip' program.  So the usual defaults for
> > > guessing the encoding don't really work.
> >
> > At least modifying 'auto-coding-alist takes effect.
>
> OK, but that cannot be done by default, since the right encoding is
> not known in advance.

So is this a wontfix, then?

Message #20 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 65299 <at> debbugs.gnu.org, awrhygty <at> outlook.com
Subject: Re: bug#65299: 29.1;
 ZIP archived WEBP images can not be displayed correctly
Date: Sat, 02 Sep 2023 09:20:27 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 1 Sep 2023 22:24:40 +0200
> Cc: awrhygty <at> outlook.com, 65299 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > > From: awrhygty <at> outlook.com
> > > Cc: 65299 <at> debbugs.gnu.org
> > > Date: Tue, 15 Aug 2023 22:05:36 +0900
> > >
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > >
> > > > You need to say
> > > >
> > > >   C-x RET c no-conversion RET RET
> > > >
> > > > to open such files from a zip archive.
> > > >
> > > > Determining the right coding system when opening files from ZIP
> > > > archives is a tricky issue, and frequently needs forcing a certain
> > > > encoding manually.  I don't know how to do better in general, what
> > > > with all the possible sources of the files and their encodings.  A Zip
> > > > archive can include files from Unix systems or from Windows, and we
> > > > unzip by running the 'unzip' program.  So the usual defaults for
> > > > guessing the encoding don't really work.
> > >
> > > At least modifying 'auto-coding-alist takes effect.
> >
> > OK, but that cannot be done by default, since the right encoding is
> > not known in advance.
> 
> So is this a wontfix, then?

I guess so, yes.

Message #23 received at 65299 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65299 <at> debbugs.gnu.org, awrhygty <at> outlook.com
Subject: Re: bug#65299: 29.1;
 ZIP archived WEBP images can not be displayed correctly
Date: Sat, 2 Sep 2023 09:34:04 -0700

tags 65299 wontfix
close 65299
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> So is this a wontfix, then?
>
> I guess so, yes.

Thanks, closed as wontfix.

Previous Next

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