From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#6837: Cannot view PNG images Date: Sat, 25 Sep 2010 19:40:48 +0100 Message-ID: References: <4C62161A.8040701@gnu.org> <8439um16qi.fsf@aol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e64c26a47258d4049119d5cb X-Trace: dough.gmane.org 1285441885 13328 80.91.229.12 (25 Sep 2010 19:11:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Sep 2010 19:11:25 +0000 (UTC) Cc: Andy Moreton , 6837@debbugs.gnu.org To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 25 21:11:23 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oza9Y-0007Ge-RB for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Sep 2010 21:11:21 +0200 Original-Received: from localhost ([127.0.0.1]:48809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oza9Y-0001EZ-2r for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Sep 2010 15:11:20 -0400 Original-Received: from [140.186.70.92] (port=49026 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oza9P-0001CY-GO for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2010 15:11:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oza9O-0001oA-8C for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2010 15:11:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49210) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oza9O-0001o6-6B for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2010 15:11:10 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OzZj8-0002BK-1d; Sat, 25 Sep 2010 14:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andy Moreton Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Sep 2010 18:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6837 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6837-submit@debbugs.gnu.org id=B6837.12854402178380 (code B ref 6837); Sat, 25 Sep 2010 18:44:02 +0000 Original-Received: (at 6837) by debbugs.gnu.org; 25 Sep 2010 18:43:37 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzZih-0002B7-Vc for submit@debbugs.gnu.org; Sat, 25 Sep 2010 14:43:36 -0400 Original-Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzZig-0002B2-AH for 6837@debbugs.gnu.org; Sat, 25 Sep 2010 14:43:35 -0400 Original-Received: by wwb13 with SMTP id 13so858422wwb.15 for <6837@debbugs.gnu.org>; Sat, 25 Sep 2010 11:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y2eO6aEROF0ZgphnOs5RaLK0Sy7VvNyVwlSk81f6t3o=; b=GIhTAAWW0qqMlWvRX0hoe2llOKtSwnnzi0VCV/nDYLOiap5X7MZFnZJZkBxmkkPalZ Ygks4w692iqUW862tUwDZM7Q7z62ZpEZUe7DASQOlXA1MhCjpE3CiSbcLfmD0ctPsfGg dbAXPydXjgaQ6vEfhn6Xyhe4vS7PYd2quDydk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pD7gqypzye5SzH78J+tawhKqRW5BdHjRkFXfyJeML9rTi0HUwloNFLeVOM8IP7fI2C VF04No5OJ81iEOOaPjZuYdhD3qvbRIFmC8DxDFiS1yPtP5OgUkQhRQxzYvXzOAdYbpds 9gByJdbVDIN9EA7BW6Atikh99nsC1DSQaQcAw= Original-Received: by 10.216.188.211 with SMTP id a61mr10904832wen.15.1285440048093; Sat, 25 Sep 2010 11:40:48 -0700 (PDT) Original-Received: by 10.216.170.21 with HTTP; Sat, 25 Sep 2010 11:40:48 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 25 Sep 2010 14:44:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:40431 Archived-At: --0016e64c26a47258d4049119d5cb Content-Type: text/plain; charset=ISO-8859-1 On 24 September 2010 22:19, Juanma Barranquero wrote: > On Fri, Aug 13, 2010 at 11:12, Andy Moreton > 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 --0016e64c26a47258d4049119d5cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 ge= t
> 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 th= e
variable is for.

I didn't imply it was a bug, = but that some user configuration was required.
=A0It 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<= br> > 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<= br> and/or timestamp) on *every* access to one of the library's functions.<= br> 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<= br>> version of the DLL they need to build.
[snippe= d]

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 ma= y not solve the problem, it help to know which version of the DLL to look f= or.

=A0=A0=A0 AndyM
--0016e64c26a47258d4049119d5cb--