bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6837: Cannot view PNG images


From: Juanma Barranquero
Subject: bug#6837: Cannot view PNG images
Date: Sat, 25 Sep 2010 02:23:02 +0200

On Fri, Aug 13, 2010 at 11:12, Andy Moreton <andrewjmoreton@gmail.com> wrote:

> I have also encountered this problem with the prebuilt Win32 binaries.
> I've built libpng14.dll and zlib1.dll from upstream sources. To get
> emacs to use the new DLLs, I had to update image-library-alist to
> include the new DLL name.

Having to set up `image-library-alist' is not a bug. That's what the
variable is for.

> 1) Display the image DLL version mismatch message in the minibuffer
> as well as in the *Messages* buffer, as it is not immediately obvious
> what the problem is.

Image error messages are not treated diferently than other errors.

> 2) Do not cache the results of the image DLL lookup. If the required
> DLLs are copied to the emacs/bin directory after emacs is started, it
> requires a restart to notice that the DLL is now available.

For this to work correctly, Emacs on Windows would be forced to check
(either unloading/loading the library or looking at the library's path
and/or timestamp) on *every* access to one of the library's functions.
It's much easier to live with this limitation (which is documented on
nt/INSTALL). BTW, not that it is relevant, but note that the image
libraries need not to be on the bin/ directory of Emacs, they could be
anywhere in the PATH (which is not limited to the setting of the PATH
environment variable; it's also affected by the App Paths registry
entry, etc.), or even outside the PATH if the relevant
image-library-alist entry has been added.

> 3) Make the required image DLL version number available at the lisp
> level alongside image-library-alist, so the user can determine which
> version of the DLL they need to build.

How do you determine the required image DLL version? Emacs is compiled
with a given set of #includes, but there's no general way to determine
whether older or newer releases will be compatible or not. If the
library is able to determine that it is not, and gives an error
message (like the one originating this bug report), it's easy to
determine that there's a version mismatch.

It could be possible to make available the version of each library
used to compile the running binary, but again, that does not offer
much information about which versions are compatible.

    Juanma





reply via email to

[Prev in Thread] Current Thread [Next in Thread]