bug#6837: Cannot view PNG images

[Andy Moreton <andrewjmoreton@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

On 24 September 2010 22:19, Juanma Barranquero <lekktu@gmail.com> wrote:

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

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.
>
[snipped]

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

    AndyM

[-- Attachment #2: Type: text/html, Size: 3424 bytes --]