[Top][All Lists]

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

bug#6837: Cannot view PNG images

From: Andy Moreton
Subject: bug#6837: Cannot view PNG images
Date: Sat, 25 Sep 2010 19:40:48 +0100

On 24 September 2010 22:19, Juanma Barranquero <address@hidden> wrote:
On Fri, Aug 13, 2010 at 11:12, Andy Moreton <address@hidden> 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.

I didn't imply it was a bug, but that some user configuration was required.
 It would be helpful to add the new DLL name to the list.

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

Sorry, I did not express myself clearly here. The case I considered was when image DLL lookup fails, and emacs no longer bothers looking. It would be helpful if emacs tried to locate the image DLL again the next time image display is required.

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

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.

This is exactly what I was suggesting. Once you know the versions of the headers that emacs was built with, you can then search the web to discover if the installed DLL is compatible. While this still may not solve the problem, it help to know which version of the DLL to look for.


reply via email to

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