Bug #132346 for Graphics-TIFF: Enhancements to module

Tue Apr 14 20:12:18 2020 PMPERRY [...] cpan.org - Ticket created

Subject:

Enhancements to module

I use Graphics::TIFF in PDF::Builder to support TIFF images (what else?) and have a couple requests: 1. It appears that an existing libtiff.a library needs to exist, in a standard place. If you can't find one to build or copy in, or your version of Perl doesn't supply it (Strawberry Perl *does*), I guess you're out of luck. If anyone is casting about for a "fun" little Alien project, a new Alien::TIFF package might be useful, to search for a usable libtiff.a, and build it from official sources if it's not found. I have not used Alien myself, so at this point I'm not volunteering, but might change my mind if I can get some experience in using Alien myself. 2. The Graphics::TIFF wrapper provides everything I need for the replacement of the old and buggy pure Perl TIFF support in PDF::Builder, BUT for one thing. The old code permits the opening of both a file PATH/NAME (as does the new, using Graphics::TIFF), AND an already opened filehandle. I don't know what can be done with C code to handle a Perl filehandle, but that would be a nice addition if anyone knows how to do it. I hope it would be as simple as skipping the normal file "open" call, but at this point I don't know. Thanks much to anyone interested in providing either of these. I guess the first would be more important and general, for those poor souls whose system doesn't have a libtiff.a already.

Wed Apr 15 02:50:46 2020 jffry [...] posteo.net - Correspondence added

Subject:	Re: [rt.cpan.org #132346] Enhancements to module
Date:	Wed, 15 Apr 2020 08:45:35 +0200
To:	bug-Graphics-TIFF [...] rt.cpan.org
From:	Jeff <jffry [...] posteo.net>

Show quoted text

> 1. It appears that an existing libtiff.a library needs to exist, in a standard place. If you can't find one to build or copy in, or your version of Perl doesn't supply it (Strawberry Perl *does*), I guess you're out of luck. If anyone is casting about for a "fun" little Alien project, a new Alien::TIFF package might be useful, to search for a usable libtiff.a, and build it from official sources if it's not found. I have not used Alien myself, so at this point I'm not volunteering, but might change my mind if I can get some experience in using Alien myself.

Only Windows needs libtiff.a. POSIX systems prefer libtiff.so. Neither of these are supplied by Perl itself. Defining libtiff as a dependency is not a problem for Linux distros, which do it as part of the packaging process, so this is only a Windows problem. Unfortunately, I don't have access to a Windows machine. IIRC, there are several possible build systems on Windows, e.g. the MS tools, the GnuWin32 tools, etc. and the build recipe would be different, depending on the tools available. Perhaps an alternative would be to automatically download premade binaries from such as here (rather old, unfortunately): https://sourceforge.net/projects/gnuwin32/files/tiff/3.8.2-1/tiff-3.8.2-1-bin.zip Show quoted text

> 2. The Graphics::TIFF wrapper provides everything I need for the replacement of the old and buggy pure Perl TIFF support in PDF::Builder, BUT for one thing. The old code permits the opening of both a file PATH/NAME (as does the new, using Graphics::TIFF), AND an already opened filehandle. I don't know what can be done with C code to handle a Perl filehandle, but that would be a nice addition if anyone knows how to do it. I hope it would be as simple as skipping the normal file "open" call, but at this point I don't know.

It is certainly possible to pass an open filehandle to a C-library with PerlXS. IIRC, the problem was that libtiff itself doesn't accept an open filehandle. I suppose it might be possible to add C-code duplicating most of TIFFOpen(), (e.g. TIFFOpen_fh()), add support for filehandles there, and have a Perl wrapper call the correct method as appropriate.

Wed Apr 15 02:50:47 2020 The RT System itself - Status changed from 'new' to 'open'

Thu Apr 16 09:23:37 2020 PMPERRY [...] cpan.org - Correspondence added

On Wed Apr 15 02:50:46 2020, RATCLIFFE wrote: Show quoted text

> Only Windows needs libtiff.a. POSIX systems prefer libtiff.so. Neither > of these are supplied by Perl itself. Defining libtiff as a dependency > is not a problem for Linux distros, which do it as part of the > packaging process, so this is only a Windows problem.

If Linux is guaranteed to have an up-to-date libtiff.so, that's great if Windows is then the only platform to worry about (Mac?). Windows is far too large a market to ignore, though. Show quoted text

> Unfortunately, I don't have access to a Windows machine.

If you want to provide trial Alien::TIFF builds for me to test install on Windows, I'll be happy to try to help out here. Show quoted text

> IIRC, there are several possible build systems on Windows, e.g. the MS > tools, the GnuWin32 tools, etc. and the build recipe would be > different, depending on the tools available.

Perhaps the Alien owner could provide some guidance here. In the end, the tools available for CPAN (GNU?) are very Linux-like, and certainly, native MS tools can be ignored. I think that only one recipe needs to be dealt with. The resulting libtiff.a (or whatever) might only be usable with Perl, but that's life. Show quoted text

> Perhaps an alternative would be to automatically download premade > binaries from such as here (rather old, unfortunately): > > https://sourceforge.net/projects/gnuwin32/files/tiff/3.8.2-1/tiff- > 3.8.2-1-bin.zip

I would be leery of this unless someone promises to maintain the package and keep it up to date. Presumably there is current TIFF library source available somewhere. I don't know if there are any licensing issues in grabbing and redistributing a current, premade libtiff.a from a distribution such as Strawberry Perl (which is where my copy came from). In the end, we may just have to write off anyone who doesn't have an up-to-date Perl that includes libtiff. That would certainly be the easiest approach, but some platforms such as ActiveState may be well behind the times. Strawberry Perl is leading edge and has had libtiff.a for a while, but who knows about other distros, which is why being able to build a missing libtiff would be nice. Show quoted text

> It is certainly possible to pass an open filehandle to a C-library > with PerlXS. IIRC, the problem was that libtiff itself doesn't accept > an open filehandle. > > I suppose it might be possible to add C-code duplicating most of > TIFFOpen(), (e.g. TIFFOpen_fh()), add support for filehandles there, > and have a Perl wrapper call the correct method as appropriate.

Well, this is more in the "nice to have" category rather than "must have", so if it isn't something easily done (i.e., requires extension of libtiff itself, rather than just something added to the wrapper), it can go on the back burner. I was hoping that libtiff accepted a handle (provided by the wrapper) instead of opening the file itself, but it sounds like that's not the case. TIFF support in PDF::Builder is a "nice" thing, and a few people actually build things with it using TIFF, but that image format appears to be rather niche and not worth putting tremendous effort into. If it sounds like a fun little project for you, Alien::TIFF would be a great addition, but if you have no experience with Alien and don't have the time to learn, don't sweat it.