Specify full path for imagemagick convert if using Windows

[carygravel]

I can't test this, as I don't have a windows machine, but if we can specify the full path of the convert executable, we should be able use if with windows.

[PhilterPaper]

I have to be VERY careful with this. Windows has a built-in convert command that re-does the HDD's filesystem! I have to make absolutely sure it can't pick up the Windows executable by mistake. I could hard-code the path to what it is on my Win10 system, but I don't know for sure that ImageMagick will install in the same place on other Windows versions (past and future). In fact, I don't see a "convert" or "tiffcp" in the ImageMagick installation! Maybe they're under different names, or aren't available on Windows. I could check that the path doesn't include "Windows" (]Windows\System32\, \Windows\SysWOW64\, and \Windows\WinSxS... on my box), but there's always the chance the HDD converter will get installed elsewhere.

In short, I'm very leery of trying to find convert and tiffcp on a Windows box. I would be much more comfortable if there was a generally accepted safe way of doing this.

[carygravel]

I could hard-code the path to what it is on my Win10 system, but I don't know for sure that ImageMagick will install in the same place on other Windows versions (past and future).

No you don't. If the logic is:

• the absolute path is hard-coded to yours for a Windows machine
• otherwise pick the system convert.
• only run the test if it can be executed.

In fact, I don't see a "convert" or "tiffcp" in the ImageMagick installation!

What version of ImageMagick do you have. If you have 7+, then you won't have a convert executable. They have optionally hidden everything behind a magick executable, presumably partly to solve your "convert.exe" problem.

I'll add some code and update the pull request.

[carygravel]

I've updated the path logic. Please feel free to adapt it so that it works on your Windows machine.

[PhilterPaper]

Let me look at the revision. In the meantime, here's what's available (executables) under ImageMagick on Windows:

 Directory of C:\Program Files\ImageMagick-7.0.10-Q16-HDRI

12/14/2020  11:24 PM           334,944 dcraw.exe
12/14/2020  11:24 PM        65,380,960 ffmpeg.exe
12/14/2020  11:24 PM           238,688 hp2xx.exe
12/14/2020  11:25 PM           170,080 imdisplay.exe
12/14/2020  11:25 PM            46,176 magick.exe
12/14/2020  09:23 PM         3,038,269 unins000.exe

Note that the directory name itself will likely change with each new release. There are also a bunch of .dll, .xml, and other files there.

[carygravel]

Before we get too cautious, bear in mind that these tests are run by developers not users.

[PhilterPaper]

What do you mean? Everyone runs the t-tests when they install or upgrade PDF::Builder, not just developers. I don't want to get into the position of ruining people's Windows installations because the t/tiff.t test ran the Windows "convert" instead of ImageMagick "convert". Even if it fails to run the Windows "convert" because the command line arguments are wrong, that's cutting it a bit close for me. Is "convert" even shipped with ImageMagick for Windows (maybe it's a separate package?), and is it under a different name? Ditto for "tiffcp".

[carygravel]

Everyone runs the t-tests when they install or upgrade PDF::Builder, not just developers.

Not with Linux. Most Linux users probably don't realise that my Perl applications are written in Perl. The package maintainers and all the CI ensures that everything the tests have been run beforehand. The users don't even have the tests on their computers unless they explicitly and additionally install the source.

Is "convert" even shipped with ImageMagick for Windows (maybe it's a separate package?), and is it under a different name?

As I mentioned earlier today, you have imagemagick 7, and therefore to run convert, you prepend magick, i.e.

magick convert -depth 1 -gravity center -pointsize 78 -size 1000x500 caption:'Lorem ipsum etc etc' test.tif

Ditto for "tiffcp".

Whilst convert could be ambiguous, I can't see that tiffcp could come from any other library. Certainly a quick internet search didn't find anything.

[PhilterPaper]

OK, if the actual Windows command is "magick convert", that sounds like it should be safe. I'll give it a try later today.

How about "tiffcp"? Is it "magick tiffcp" on Windows?

[carygravel]

How about "tiffcp"? Is it "magick tiffcp" on Windows?

No, because libtiff is not part of imagemagick. It is possible that your imagemagick installation is additionally shipping libtiff, as it needs it for TIFF support. Perhaps your Perl distro is shipping libtiff. Does tiffcp do anything on your computer?

[PhilterPaper]

OK, "magick convert..." appears to work OK on Windows (with ImageMagick installed). However, "tiffcp..." is unrecognized as a command. "magick tiffcp..." doesn't work, either (no harm in making sure). There is no "tiffcp.*" on my system. Any idea about another name it might be under? Anyway, two of the last three tiff.t tests can't be run, but the last one (convert only) might be.

[carygravel]

tiffcp won't have been renamed. It is possible that imagemagick or some other library is shipping something like libtiff.dll, but not the utilities that are also part of the project. Where is your libtiff.dll?

[PhilterPaper]

Here are all the .dll files:

 Directory of C:\Program Files\ImageMagick-7.0.10-Q16-HDRI

12/14/2020  11:24 PM            85,600 CORE_RL_bzlib_.dll
12/14/2020  11:24 PM         1,213,024 CORE_RL_cairo_.dll
12/14/2020  11:24 PM         3,296,352 CORE_RL_exr_.dll
12/14/2020  11:24 PM         1,068,640 CORE_RL_flif_.dll
12/14/2020  11:24 PM           659,552 CORE_RL_freetype_.dll
12/14/2020  11:24 PM         2,624,096 CORE_RL_glib_.dll
12/14/2020  11:24 PM         1,199,200 CORE_RL_harfbuzz_.dll
12/14/2020  11:24 PM           240,736 CORE_RL_jp2_.dll
12/14/2020  11:24 PM           563,296 CORE_RL_jpeg_.dll
12/14/2020  11:24 PM           346,208 CORE_RL_lcms_.dll
12/14/2020  11:24 PM         5,296,736 CORE_RL_libheif_.dll
12/14/2020  11:24 PM           161,376 CORE_RL_liblzma_.dll
12/14/2020  11:24 PM         1,072,736 CORE_RL_libraw_.dll
12/14/2020  11:24 PM           542,816 CORE_RL_librsvg_.dll
12/14/2020  11:24 PM           467,552 CORE_RL_libxml_.dll
12/14/2020  11:24 PM           111,200 CORE_RL_libzip_.dll
12/14/2020  11:24 PM            68,704 CORE_RL_lqr_.dll
12/14/2020  11:24 PM           502,368 CORE_RL_Magick++_.dll
12/14/2020  11:24 PM         1,998,432 CORE_RL_MagickCore_.dll
12/14/2020  11:24 PM         1,086,560 CORE_RL_MagickWand_.dll
12/14/2020  11:24 PM           288,352 CORE_RL_openjpeg_.dll
12/14/2020  11:24 PM           400,992 CORE_RL_pango_.dll
12/14/2020  11:24 PM           205,408 CORE_RL_png_.dll
12/14/2020  11:24 PM           429,152 CORE_RL_tiff_.dll
12/14/2020  11:24 PM           538,720 CORE_RL_webp_.dll
12/14/2020  11:24 PM            95,840 CORE_RL_zlib_.dll
12/02/2020  04:05 AM         5,639,560 mfc140u.dll
12/02/2020  03:58 AM           585,096 msvcp140.dll
12/02/2020  03:58 AM            23,944 msvcp140_1.dll
12/02/2020  03:58 AM           186,248 msvcp140_2.dll
12/02/2020  03:58 AM            41,352 msvcp140_atomic_wait.dll
12/02/2020  03:58 AM            20,360 msvcp140_codecvt_ids.dll
12/02/2020  03:58 AM           177,032 vcomp140.dll
12/02/2020  03:58 AM            94,088 vcruntime140.dll
12/02/2020  03:58 AM            36,744 vcruntime140_1.dll

Here are all the non .exe, non .dll files, to round things out:

12/14/2020  11:01 PM           109,070 ChangeLog.txt
12/14/2020  11:01 PM               922 coder.xml
12/14/2020  11:01 PM             1,411 colors.xml
12/14/2020  11:11 PM               754 configure.xml
12/14/2020  11:01 PM             9,993 delegates.xml
12/14/2020  11:01 PM            53,827 english.xml
12/14/2020  11:01 PM            22,382 ImageMagick.ico
12/14/2020  11:01 PM             7,527 ImageMagick.rdf
12/14/2020  09:24 PM    <DIR>          images
12/14/2020  11:01 PM            18,190 index.html
12/14/2020  11:01 PM            12,581 License.txt
12/14/2020  11:01 PM             2,509 locale.xml
12/14/2020  11:01 PM             1,722 log.xml
12/14/2020  11:01 PM           135,361 mime.xml
12/14/2020  09:24 PM    <DIR>          modules
12/14/2020  11:01 PM            66,671 NOTICE.txt
12/14/2020  11:01 PM             3,234 policy.xml
12/14/2020  11:01 PM             2,437 quantization-table.xml
12/14/2020  11:01 PM             4,557 QuickStart.txt
12/14/2020  11:01 PM             7,524 README.txt
12/14/2020  11:01 PM            60,960 sRGB.icc
12/14/2020  11:01 PM            11,630 thresholds.xml
12/14/2020  11:01 PM             9,470 type-ghostscript.xml
12/14/2020  11:01 PM               691 type.xml
12/14/2020  09:24 PM           101,673 unins000.dat
12/14/2020  09:23 PM         3,038,269 unins000.exe
12/14/2020  09:24 PM    <DIR>          uninstall
12/14/2020  09:24 PM    <DIR>          www

modules\coders:
12/14/2020  11:25 PM            23,136 IM_MOD_RL_aai_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_art_.dll
12/14/2020  11:25 PM            25,696 IM_MOD_RL_ashlar_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_avs_.dll
12/14/2020  11:25 PM            31,840 IM_MOD_RL_bgr_.dll
12/14/2020  11:25 PM            46,688 IM_MOD_RL_bmp_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_braille_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_cals_.dll
12/14/2020  11:25 PM            24,672 IM_MOD_RL_caption_.dll
12/14/2020  11:25 PM            31,840 IM_MOD_RL_cin_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_cip_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_clipboard_.dll
12/14/2020  11:25 PM            20,064 IM_MOD_RL_clip_.dll
12/14/2020  11:25 PM            33,888 IM_MOD_RL_cmyk_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_cube_.dll
12/14/2020  11:25 PM            30,304 IM_MOD_RL_cut_.dll
12/14/2020  11:25 PM           169,568 IM_MOD_RL_dcm_.dll
12/14/2020  11:25 PM            55,904 IM_MOD_RL_dds_.dll
12/14/2020  11:25 PM            22,112 IM_MOD_RL_debug_.dll
12/14/2020  11:25 PM            33,376 IM_MOD_RL_dib_.dll
12/14/2020  11:25 PM            19,552 IM_MOD_RL_djvu_.dll
12/14/2020  11:25 PM            29,792 IM_MOD_RL_dng_.dll
12/14/2020  11:25 PM            18,528 IM_MOD_RL_dot_.dll
12/14/2020  11:25 PM            18,528 IM_MOD_RL_dps_.dll
12/14/2020  11:25 PM            41,056 IM_MOD_RL_dpx_.dll
12/14/2020  11:25 PM            25,696 IM_MOD_RL_emf_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_ept_.dll
12/14/2020  11:25 PM            26,720 IM_MOD_RL_exr_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_farbfeld_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_fax_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_fits_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_fl32_.dll
12/14/2020  11:25 PM            26,720 IM_MOD_RL_flif_.dll
12/14/2020  11:25 PM            18,528 IM_MOD_RL_fpx_.dll
12/14/2020  11:25 PM            40,544 IM_MOD_RL_gif_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_gradient_.dll
12/14/2020  11:25 PM            28,256 IM_MOD_RL_gray_.dll
12/14/2020  11:25 PM            21,088 IM_MOD_RL_hald_.dll
12/14/2020  11:25 PM            28,256 IM_MOD_RL_hdr_.dll
12/14/2020  11:25 PM            31,840 IM_MOD_RL_heic_.dll
12/14/2020  11:25 PM            25,184 IM_MOD_RL_histogram_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_hrz_.dll
12/14/2020  11:25 PM            24,672 IM_MOD_RL_html_.dll
12/14/2020  11:25 PM            35,424 IM_MOD_RL_icon_.dll
12/14/2020  11:25 PM            20,064 IM_MOD_RL_info_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_inline_.dll
12/14/2020  11:25 PM            25,184 IM_MOD_RL_ipl_.dll
12/14/2020  11:25 PM            20,064 IM_MOD_RL_jbig_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_jnx_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_jp2_.dll
12/14/2020  11:25 PM            57,440 IM_MOD_RL_jpeg_.dll
12/14/2020  11:25 PM            52,832 IM_MOD_RL_json_.dll
12/14/2020  11:25 PM            19,040 IM_MOD_RL_jxl_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_kernel_.dll
12/14/2020  11:25 PM            23,648 IM_MOD_RL_label_.dll
12/14/2020  11:25 PM            20,576 IM_MOD_RL_mac_.dll
12/14/2020  11:25 PM           226,912 IM_MOD_RL_magick_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_map_.dll
12/14/2020  11:25 PM            21,088 IM_MOD_RL_mask_.dll
12/14/2020  11:25 PM            20,064 IM_MOD_RL_matte_.dll
12/14/2020  11:25 PM            37,984 IM_MOD_RL_mat_.dll
12/14/2020  11:25 PM            40,032 IM_MOD_RL_meta_.dll
12/14/2020  11:25 PM            48,736 IM_MOD_RL_miff_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_mono_.dll
12/14/2020  11:25 PM            36,448 IM_MOD_RL_mpc_.dll
12/14/2020  11:25 PM            19,552 IM_MOD_RL_mpr_.dll
12/14/2020  11:25 PM            94,816 IM_MOD_RL_msl_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_mtv_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_mvg_.dll
12/14/2020  11:25 PM            21,088 IM_MOD_RL_null_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_ora_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_otb_.dll
12/14/2020  11:25 PM            31,328 IM_MOD_RL_palm_.dll
12/14/2020  11:25 PM            28,256 IM_MOD_RL_pango_.dll
12/14/2020  11:25 PM            26,720 IM_MOD_RL_pattern_.dll
12/14/2020  11:25 PM            32,864 IM_MOD_RL_pcd_.dll
12/14/2020  11:25 PM            30,304 IM_MOD_RL_pcl_.dll
12/14/2020  11:25 PM            32,352 IM_MOD_RL_pcx_.dll
12/14/2020  11:25 PM            28,256 IM_MOD_RL_pdb_.dll
12/14/2020  11:25 PM            63,584 IM_MOD_RL_pdf_.dll
12/14/2020  11:25 PM            25,696 IM_MOD_RL_pes_.dll
12/14/2020  11:25 PM            23,648 IM_MOD_RL_pgx_.dll
12/14/2020  11:25 PM            46,688 IM_MOD_RL_pict_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_pix_.dll
12/14/2020  11:25 PM            22,112 IM_MOD_RL_plasma_.dll
12/14/2020  11:25 PM           164,448 IM_MOD_RL_png_.dll
12/14/2020  11:25 PM            47,200 IM_MOD_RL_pnm_.dll
12/14/2020  11:25 PM            36,448 IM_MOD_RL_ps2_.dll
12/14/2020  11:25 PM            42,080 IM_MOD_RL_ps3_.dll
12/14/2020  11:25 PM            63,584 IM_MOD_RL_psd_.dll
12/14/2020  11:25 PM            57,952 IM_MOD_RL_ps_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_pwp_.dll
12/14/2020  11:25 PM            25,184 IM_MOD_RL_raw_.dll
12/14/2020  11:25 PM            35,424 IM_MOD_RL_rgb_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_rgf_.dll
12/14/2020  11:25 PM            23,648 IM_MOD_RL_rla_.dll
12/14/2020  11:25 PM            29,280 IM_MOD_RL_rle_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_screenshot_.dll
12/14/2020  11:25 PM            22,112 IM_MOD_RL_scr_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_sct_.dll
12/14/2020  11:25 PM            24,672 IM_MOD_RL_sfw_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_sgi_.dll
12/14/2020  11:25 PM            32,864 IM_MOD_RL_sixel_.dll
12/14/2020  11:25 PM            22,112 IM_MOD_RL_stegano_.dll
12/14/2020  11:25 PM            28,768 IM_MOD_RL_sun_.dll
12/14/2020  11:25 PM            79,456 IM_MOD_RL_svg_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_tga_.dll
12/14/2020  11:25 PM            20,576 IM_MOD_RL_thumbnail_.dll
12/14/2020  11:25 PM            68,192 IM_MOD_RL_tiff_.dll
12/14/2020  11:25 PM            20,064 IM_MOD_RL_tile_.dll
12/14/2020  11:25 PM            27,232 IM_MOD_RL_tim2_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_tim_.dll
12/14/2020  11:25 PM            24,160 IM_MOD_RL_ttf_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_txt_.dll
12/14/2020  11:25 PM            23,648 IM_MOD_RL_uil_.dll
12/14/2020  11:25 PM            22,112 IM_MOD_RL_url_.dll
12/14/2020  11:25 PM            22,624 IM_MOD_RL_uyvy_.dll
12/14/2020  11:25 PM            24,672 IM_MOD_RL_vicar_.dll
12/14/2020  11:25 PM            26,720 IM_MOD_RL_video_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_vid_.dll
12/14/2020  11:25 PM            33,376 IM_MOD_RL_viff_.dll
12/14/2020  11:25 PM            29,792 IM_MOD_RL_vips_.dll
12/14/2020  11:25 PM            23,136 IM_MOD_RL_wbmp_.dll
12/14/2020  11:25 PM            33,376 IM_MOD_RL_webp_.dll
12/14/2020  11:25 PM            36,960 IM_MOD_RL_wpg_.dll
12/14/2020  11:25 PM            25,696 IM_MOD_RL_xbm_.dll
12/14/2020  11:25 PM            30,816 IM_MOD_RL_xcf_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_xc_.dll
12/14/2020  11:25 PM            32,864 IM_MOD_RL_xpm_.dll
12/14/2020  11:25 PM            24,672 IM_MOD_RL_xps_.dll
12/14/2020  11:25 PM            21,600 IM_MOD_RL_xtrn_.dll
12/14/2020  11:25 PM            51,808 IM_MOD_RL_yaml_.dll
12/14/2020  11:25 PM            31,840 IM_MOD_RL_ycbcr_.dll
12/14/2020  11:25 PM            29,792 IM_MOD_RL_yuv_.dll

modules\filters:
12/14/2020  11:24 PM            22,112 FILTER_analyze_.dll

uninstall:
12/14/2020  11:00 PM           122,279 PathTool.exe

There's also a lot of .html, .png, .xml, .c, and .txt files if you're interested.

[carygravel]

Your imagemagick installation seems to have libtiff statically compiled into CORE_RL_tiff_.dll

I thought you had libtiff before installing imagemagick? If so, perhaps you have another version of the library floating around somewhere, perhaps with the tools like tiffcp.

[PhilterPaper]

I copied in the libtiff.a from the latest Strawberry Perl image, which I think is 4.0.10. No tiffcp tool in sight, and is Graphics::TIFF picking up that libtiff.a? I don't know where else it would get it from, unless it built a new libtiff* during installation (and not just the Graphics::TIFF XS code). Things that might be of interest are:

 Directory of C:\Strawberry\c\lib

05/22/2019  04:15 PM           161,098 libtiff.a   <=== copied from Strawberry Perl 5.32.1
05/18/2017  08:26 AM             2,852 libtiffxx.a
05/18/2017  08:26 AM           155,104 libtiff_OLD.a  <=== came with Strawberry Perl 5.26.1
               3 File(s)        319,054 bytes

 Directory of C:\Strawberry\c\lib\pkgconfig

05/18/2017  08:26 AM               267 libtiff-4.pc
               1 File(s)            267 bytes

 Directory of C:\Strawberry\c\x86_64-w64-mingw32\lib

05/11/2017  10:32 PM            28,296 libfxstiff.a
               1 File(s)         28,296 bytes

[carygravel]

So you evidently have two copies of the libtiff library itself, one statically compiled into imagemagick, which imagemagick is using, one in the your Perl installation, which GT is using, and neither of them has the TIFF tools.

Assuming you like to try to install a third copy to use the tools, I have only found two options for Windows users:

• There is an ancient version here: http://gnuwin32.sourceforge.net/packages/tiff-win32.htm
• There are instructions on building it yourself here: http://www.simplesystems.org/libtiff/build.html

I admit that neither are particularly attractive. I'll see if I can update the tests to convince imagemagick to compress the TIFFs in the required manner without resorting to tiffcp.

[PhilterPaper]

I'd appreciate it if you could get by without tiffcp. I have got tiff.t working (further) with your "magick" prefix for "convert", although I do have to change the caption delimiters from ' to \" (caption:\"Ipsum lorem etc.\", otherwise the string stops at "Ipsum", and convert doesn't know what to do with "lorem"). Will that cause any problems running under Linux or other non-Windows? Other than that, "convert" seems to work OK. I'm playing with "tiffcp" (the 32 bit GNU version, per your suggestion), and it looks like I have to pull in "jpeg62.dll" and "zlib1.dll" from my copy of GIMP. It runs, but produces a corrupt "tmp.tif" that I can't display.

It looks like the only thing done with tiffcp is to change compression to G3 or LZW. Is that something "convert" could do?

[carygravel]

I've got a patch worked up to eliminate the need for tiffcp. I'll push it later.

I know how to solve your delimiter problem, too, but that will have to wait until tomorrow.

[carygravel]

It looks to me that the imagemagick version in the Ubuntu 18.04 that github still uses for CI has a bug with LZW compression. They are moving soon to Ubuntu 20.04 which should fix the problem.

The tests run on my systems - but fail because of the problem with inverted colours.

[PhilterPaper]

So you're saying that the "All checks have failed" can be ignored? After 24 hours or so with no more changes by you, I'll look at incorporating your changes.

[PhilterPaper]

I see that problem http://www.cpantesters.org/cpan/report/4d251f3c-5cc0-11eb-b8ae-81641fabc5a4 might be the same caption:'Lorem ispsum...' problem I mentioned above, even though this was supposedly on a Linux box. I was ignoring it, figuring it was just a random glitch, but just realized it might be the same quoted string problem.

[carygravel]

I've finished my changes. They work on my machines (the tests themselves fail due to the inverted colours problem). I can't test on Windows, so I'd be interested to hear how you get on.

If you can get the tests to run, I'll look at just turning them off for what seems to be the buggy version of imagemagick in Ubuntu 18.04.

[PhilterPaper]

I've gone over your t/tiff.t changes, but haven't had a chance to run them yet (later today... I have chores to run all afternoon). It looks like you were able to get rid of "tiffcp" usage (good!), but I'm a bit concerned about looking for "convert". It looks like it's looking for "convert" first (which could catch the Windows utility?) and if that fails, it uses "convert" for Linux and looks up ImageMagick's "convert" for Windows.

1. I think it may (try to) use the Windows HDD conversion utility if ImageMagick isn't installed.
2. What happens if the OS isn't Linux or Windows? Are all the BSD flavors left out in the cold?

What I'm thinking of is before this cluster of tests, do

if OS eq MsWin32 and can_run "magick"
    $convert = "magick convert";
elsif OS ne MsWin32 and can_run "convert"
    $convert = "convert";
else
    $convert = '';

Then SKIP "No convert utility" if $convert eq '', else run using $convert as the utility.

Does that sound reasonable? Unless there is a dangerous "convert" in other OS's (need to add another test case), I think that should handle it for Windows (use "magick convert" if available) and all other OS's (use "convert" if available). If nothing is available, just skip all the tests that use "convert".

[carygravel]

If you look carefully at the code, you will see that I check for magick to start with. This has nothing to do with Windows v6 uses convert, v7 uses magick convert.

If magick isn't available, then looks for convert on linux and guesses a path for Windows. I'm sure you could improve the path guess, but as you have v7, it isn't necessary.

[PhilterPaper]

I don't mind requiring v7, so that there's no risk of trying to run Window's "convert".

I put your changes into tiff.t along with some revisions, and it's not working. I had to back out your change to use "run", because it was complaining that test.tif (the output file) did not exist. Why would it think it was an input file?

Here is output test 9 (first one, "alpha"):

>>>>>>about to run convert to create $example
convert: FailedToExecuteCommand `"gswin64c.exe" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72"  "-sOutputFile=C:/Users/Phil/AppData/Local/Temp/magick-OnKy0537pgMwxUJOch57iLJr5mpDUlLS%d" "-fC:/Users/Phil/AppData/Local/Temp/magick-wXCSRlZu0cxEOcaCcWm_VISa42MRiOf_" "-fC:/Users/Phil/AppData/Local/Temp/magick-ZXn-9xeEfnEmhkpLZzVDBNkl377HuU-s"' (The system cannot find the file specified.
) @ error/delegate.c/ExternalDelegateCommand/475.
convert: PDFDelegateFailed `The system cannot find the file specified.
' @ error/pdf.c/ReadPDFImage/701.
convert: no images defined `txt:-' @ error/convert.c/ConvertImageCommand/3301.
>>>>>>about to run convert to create $expected
ok 9 - alpha

gswin64c.exe? I don't have such a file. Any idea where it comes from? Here is the full tiff.t:

#!/usr/bin/perl
use warnings;
use strict;
use English qw( -no_match_vars );
use IPC::Cmd qw(can_run run);
use File::Spec;
use Test::More tests => 12;

use PDF::Builder;

# Filename 3 tests
# tests 1 and 3 will mention TIFF_GT if Graphics::TIFF is installed and
# usable, otherwise they will display just TIFF. you can use this information
# if you are not sure about the status of Graphics::TIFF.

my $pdf = PDF::Builder->new('-compress' => 'none'); # common $pdf all tests
my $has_GT = 0; # global flag for all tests that need to know if Graphics::TIFF

# -silent shuts off one-time warning for rest of run
my $tiff = $pdf->image_tiff('t/resources/1x1.tif', -silent => 1);
if ($tiff->usesLib() == 1) {
    $has_GT = 1;
    isa_ok($tiff, 'PDF::Builder::Resource::XObject::Image::TIFF_GT',
        q{$pdf->image_tiff(filename)});
} else {
    isa_ok($tiff, 'PDF::Builder::Resource::XObject::Image::TIFF',
        q{$pdf->image_tiff(filename)});
}

is($tiff->width(), 1,
   q{Image from filename has a width});

my $gfx = $pdf->page()->gfx();
$gfx->image($tiff, 72, 144, 216, 288);
like($pdf->stringify(), qr/q 216 0 0 288 72 144 cm \S+ Do Q/,
     q{Add TIFF to PDF});

# Filehandle (old library only)  2 tests

$pdf = PDF::Builder->new();
open my $fh, '<', 't/resources/1x1.tif' or
   die "Couldn't open file t/resources/1x1.tif";
$tiff = $pdf->image_tiff($fh, -nouseGT => 1);
isa_ok($tiff, 'PDF::Builder::Resource::XObject::Image::TIFF',
    q{$pdf->image_tiff(filehandle)});

is($tiff->width(), 1,
   q{Image from filehandle has a width});

close $fh;

# LZW Compression  2 tests

$pdf = PDF::Builder->new('-compress' => 'none');

my $lzw_tiff = $pdf->image_tiff('t/resources/1x1-lzw.tif');
if ($lzw_tiff->usesLib() == 1) {
    isa_ok($lzw_tiff, 'PDF::Builder::Resource::XObject::Image::TIFF_GT',
        q{$pdf->image_tiff(), LZW compression});
} else {
    isa_ok($lzw_tiff, 'PDF::Builder::Resource::XObject::Image::TIFF',
        q{$pdf->image_tiff(), LZW compression});
}

$gfx = $pdf->page()->gfx();
$gfx->image($lzw_tiff, 72, 360, 216, 432);

like($pdf->stringify(), qr/q 216 0 0 432 72 360 cm \S+ Do Q/,
     q{Add TIFF to PDF});

# Missing file  1 test

$pdf = PDF::Builder->new();
eval { $pdf->image_tiff('t/resources/this.file.does.not.exist') };
ok($@, q{Fail fast if the requested file doesn't exist});

##############################################################
# common data for remaining tests
my $width = 1000;
my $height = 100;
$tiff = 'test.tif';
my $pdfout = 'test.pdf';

# NOTE: following 4 tests use Linux/TIFF utility 'convert'.
# They may require software installation on your system, and 
# will be skipped if the necessary software is not found.
# For Windows systems, it may be necessary to install the
# ImageMagick product.

my $convert;
if      ($OSNAME eq 'MSWin32' and can_run("magick")) {
    $convert = "magick convert";
} elsif ($OSNAME ne 'MSWin32' and can_run("convert")) {
    $convert = "convert";
} else {  # appropriate utility not found
    $convert = '';
}
print "###### has_GT = $has_GT, convert = '$convert'\n";

##############################################################
# convert not available on all systems. PDF::Builder itself
# doesn't seem to work well with this, so skip for time being.

SKIP: {
    skip "No 'convert' utility available.", 1 unless
        $convert ne '';

##run(command => [$convert, qw(-depth 1 -gravity center -pointsize 78 -size), $width.'x'.$height, 'caption:Lorem ipsum etc etc', $tiff], verbose => 0);
print ">>>>>>about to run convert to create $tiff\n";
system("$convert -depth 1 -gravity center -pointsize 78 -size ${width}x${height} caption:\"Lorem ipsum etc etc\" $tiff");
# ----------
print ">>>>>>about to run Builder to create $pdfout\n";
$pdf = PDF::Builder->new(-file => $pdfout);
my $page = $pdf->page();
$page->mediabox($width, $height);
$gfx = $page->gfx();
my $img = $pdf->image_tiff($tiff);
$gfx->image($img, 0, 0, $width, $height);
$pdf->save();
$pdf->end();

# ----------
print ">>>>>>about to run convert to create \$example\n";
my $example = `$convert $pdfout -depth 1 -resize 1x1 txt:-`;
print ">>>>>>about to run convert to create \$expected\n";
my $expected = `$convert $tiff -depth 1 -resize 1x1 txt:-`;
# ----------

is($example, $expected, 'alpha');
}

##############################################################
# convert and Graphics::TIFF not available on all systems.
# Graphics::TIFF needed or you get message "Chunked CCITT G4 TIFF not supported"
#  from PDF::Builder's TIFF processing library.

SKIP: {
    skip "No 'convert' utility available, or no Graphics::TIFF.", 1 unless
        $convert ne '' && $has_GT;

##run(command => [$convert, qw(-depth 1 -gravity center -pointsize 78 -size), $width.'x'.$height, 'caption:Lorem ipsum etc etc', qw(-background white -alpha off -compress Group4), $tiff], verbose => 0);
system("$convert -depth 1 -gravity center -pointsize 78 -size ${width}x${height} caption:\"Lorem ipsum etc etc\" -background white -alpha off -compress Group4 $tiff");
# ----------
$pdf = PDF::Builder->new(-file => $pdfout);
my $page = $pdf->page();
$page->mediabox($width, $height);
$gfx = $page->gfx();
my $img = $pdf->image_tiff($tiff);
$gfx->image($img, 0, 0, $width, $height);
$pdf->save();
$pdf->end();

# ----------
my $example = `$convert $pdfout -depth 1 -colorspace gray -alpha off -resize 1x1 txt:-`;
my $expected = `$convert $tiff -depth 1 -resize 1x1 txt:-`;
# ----------

is($example, $expected, 'G3 (not converted to flate)');
}

##############################################################
# convert not available on all systems.
# Graphics::TIFF not needed for this test

SKIP: {
    skip "No 'convert' utility available.", 1 unless
        $convert ne '';

##run(command => [$convert, qw(-depth 1 -gravity center -pointsize 78 -size), $width.'x'.$height, 'caption:Lorem ipsum etc etc', qw(-background white -alpha off -compress lzw), $tiff], verbose => 0);
system("$convert -depth 1 -gravity center -pointsize 78 -size ${width}x${height} caption:\"Lorem ipsum etc etc\" -background white -alpha off -compress lzw $tiff");
# ----------
$pdf = PDF::Builder->new(-file => $pdfout);
my $page = $pdf->page;
$page->mediabox( $width, $height );
$gfx = $page->gfx();
my $img = $pdf->image_tiff($tiff);
$gfx->image( $img, 0, 0, $width, $height );
$pdf->save();
$pdf->end();

# ----------
my $example = `$convert $pdfout -depth 1 -colorspace gray -alpha off -resize 1x1 txt:-`;
my $expected = `$convert $tiff -depth 1 -resize 1x1 txt:-`;
# ----------

is($example, $expected, 'lzw (converted to flate)');
}

##############################################################
# convert not available on all systems.
# Graphics::TIFF needed for this test

SKIP: {
    skip "No 'convert' utility available, or no Graphics::TIFF.", 1 unless
        $convert ne '' && $has_GT;

# .png file is temporary file (output, input, erased)
system("$convert rose: -type palette -depth 2 colormap.png");
system("$convert colormap.png $tiff");
$pdf = PDF::Builder->new(-file => $pdfout);
my $page = $pdf->page;
$page->mediabox( $width, $height );
$gfx = $page->gfx();
my $img = $pdf->image_tiff($tiff);
$gfx->image( $img, 0, 0, $width, $height );
$pdf->save();
$pdf->end();
ok(1, q{Successfully read TIFF with colormap});
}

##############################################################
# cleanup. all tests involving these files skipped?

unlink $pdfout, $tiff, 'colormap.png';

##############################################################

1;

If you have code which works under a Linux (or similar) system, and I can come up with something that works under Windows, I would have no serious objection to running half the tests for non-Windows and the other half for Windows, if it comes down to that.

Note that test 12 needed an ok(), not just a print. After that, all the other tests claim to "pass", although with those nasty error messages I'm not sure I believe that.

[carygravel]

I don't mind requiring v7, so that there's no risk of trying to run Window's "convert".

Please don't do that. Many Linux distros (including my test systems) aren't using v7 yet.

gswin64c.exe? I don't have such a file. Any idea where it comes from?

That is a Windows executable for ghostscript. Ghostscript started as a Postscript & printer viewer/creator utility, later gained some PDF (raster-only, I think) functionality, and is still used in various places for historical reasons.

If you have code which works under a Linux (or similar) system, and I can come up with something that works under Windows, I would have no serious objection to running half the tests for non-Windows and the other half for Windows, if it comes down to that.

I think that would make maintenance even harder, as each would only be able to check half the tests. It would be much better to get them working in a cross-platform manner.

Note that test 12 needed an ok(), not just a print. After that, all the other tests claim to "pass", although with those nasty error messages I'm not sure I believe that.

I'll take a look

[PhilterPaper]

That would be v7 only on Windows. Linux and other non-Windows platforms should still be able to use v6. By the way, I don't want to specify "linux" if that excludes the BSDs, etc. Since Windows seems to be the troublemaker, can it be split into MSWin32 ($convert = "magick convert";) and everything else ($convert = "convert";)? If there are other platforms that behave like Windows (Cygwin?), we can deal with them later.

Thinking about it a bit, I don't want to prereq ImageMagick or such tools (such as GhostScript) on a Windows box. If they happen to be present, fine, use them, but I'm not going to force the installation of anything just so one t-test can run. Although more complete testing of TIFF capabilities at installation/upgrade of PDF::Builder is nice, it's not like that's the only opportunity to test this code. Developers can test it (having an adequate tool kit), and users can run examples to see if and how it works. It's not a deal-breaker for the average user to not be able to fully test TIFF, if the alternative is to require the installation of multiple large applications. In other words, if there's no clean way forward for Windows, let's just go back to skipping those last four or so tests for OSNAME = MSWin32.

[carygravel]

That would be v7 only on Windows

Your current logic only looks for v7 on Windows. We should be looking for v7 on any platform first.

convert: FailedToExecuteCommand `"gswin64c.exe" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" "-sOutputFile=C:/Users/Phil/AppData/Local/Temp/magick-OnKy0537pgMwxUJOch57iLJr5mpDUlLS%d" "-fC:/Users/Phil/AppData/Local/Temp/magick-wXCSRlZu0cxEOcaCcWmVISa42MRiOf" "-fC:/Users/Phil/AppData/Local/Temp/magick-ZXn-9xeEfnEmhkpLZzVDBNkl377HuU-s"' (The system cannot find the file specified.

It looks to me that imagemagick is using Ghostscript to create images with text. Do you not have gswin64c.exe anywhere? If not, then that is a but in your imagemagick build.

The test with the alpha layer we were skipping anyway, as we didn't have a fix for it. Do the other magick convert calls give similar errors?

[PhilterPaper]

Tests 9, 10, and 11 fail this way when creating $example. Test 12 is structured differently and seems to run OK. We could resume skipping test 9 if it's not in shape yet.

I do not have ghostScript installed on this machine, and no gswin64c.exe anywhere. I suppose I could install GS just so I could test TIFF thoroughly (as a developer), but I'm not going to require it for random users. It sounds like gswin64c would have to be added to the list of executables to check for on those three tests.

[carygravel]

I've cleaned up the checks for convert, and updated the imagemagick calls to avoid using ghostscript. Please test!

[PhilterPaper]

Test 9 is skipped (as expected). Tests 10 and 11 are still failing with unable to run gswin64c.exe when creating $example.

Regarding the "skip" tests, I see you are still defining Linux. I'm worried about what this will do on BSDs and other non-Linux, non-Windows systems. I will put out a question under the "issues" and see if anyone has some ideas.

[carygravel]

Test 9 is skipped (as expected). Tests 10 and 11 are still failing with unable to run gswin64c.exe when creating $example.

Sorry. I've been stupid. imagemagick isn't using imagemagick for the tiff creation stage - but for examining the resulting PDF. I'll try and come up with an alternative.

Regarding the "skip" tests, I see you are still defining Linux. I'm worried about what this will do on BSDs and other non-Linux, non-Windows systems. I will put out a question under the "issues" and see if anyone has some ideas.

BSD, Mac and the others are all POSIX-based. The same rules apply as for Linux. Even on a (recent) Windows version, you'd have to be running the test as admin to actually do some damage.

[carygravel]

Can we force Builder to use one of the ASCII filters, and thereby compare the resulting PDF as a string?

[PhilterPaper]

Even on a (recent) Windows version, you'd have to be running the test as admin to actually do some damage.

Be careful about that. AFAIK, most Windows users are actually running as the admin account! I know I don't have a separate account for installing stuff and doing admin things. That's just the way Windows is set up by default, and is therefore dangerous. They make it inconvenient and even difficult to set up separate non-privileged accounts for day-to-day work.

Can we force Builder to use one of the ASCII filters, and thereby compare the resulting PDF as a string?

It should be possible, though I don't recall ever trying it. Does "stringify" work for this? I think that's used all over the t-tests to turn the PDF into ASCII text and permit comparison to strings.

[carygravel]

It should be possible, though I don't recall ever trying it. Does "stringify" work for this? I think that's used all over the t-tests to turn the PDF into ASCII text and permit comparison to strings.

stringify() gives you a string to compare, but doesn't force the filter first, so we still get binary in the middle of the string. How can we force a ASCII85 or ASCIIHex filter after the image compression filters like LZW or Group4?

[PhilterPaper]

Let's step back and look at this thing before plunging into ASCII filters, etc. What exactly are you trying to accomplish? Are you talking about binary data (such as the raster data itself) in the PDF, that you can't handle for some reason? You've created a PDF file, and maybe a TIFF file -- both contain binary data; where are you trying to go from there?

By the way, it's not a tremendous loss if full TIFF testing (tests 9-12) can only be done on Linux (and perhaps other non-Windows platforms). The code does get tested during development, so it's not like the t-tests are the only place it gets tested. Unless there is a reasonably clean way to test on Windows, I'm open to simply skipping Windows for those tests. Don't knock yourself out trying to get Windows testing working, unless you enjoy the challenge!

[carygravel]

What exactly are you trying to accomplish?

I'm trying to enable the possibility of testing all parts of the PDF on Windows. At the moment you have no way of automatically testing the binary (e.g. image) parts of the PDF.

By the way, it's not a tremendous loss if full TIFF testing (tests 9-12) can only be done on Linux (and perhaps other non-Windows platforms). The code does get tested during development, so it's not like the t-tests are the only place it gets tested.

I disagree. The only tests worth having are automatic tests. This is how CI/CD works. You yourself were looking for old images with which you test manually.

The situation might be slightly different if all the tests could be run on main development platform for the project (Windows), and only a portion on others, but if the test aren't possible for Windows, then you won't create them, and they won't exist on other platforms, either.

[PhilterPaper]

When I asked what you were intending to accomplish, I was asking where in the test process you got to, and were blocked by having the PDF (raster image data, I presume) in binary form. Then, step back and consider how you might get around this (as opposed to I MUST convert the image stream into ASCII). It appears that $expected (from the TIFF file) seems to be created OK, but converting the PDF file to whatever format you're looking for ($example) seems to be failing on Windows. Can I assume that the raster data is what you're trying to compare, and one or the other needs to be massaged into a new format in order to compare them?

Regarding automated testing, yes that is good (and CI testing is even more desirable). However, I think that many overdo it with t-tests. I look at t-tests as confirmation that the package installed correctly, and should run OK, rather than being an exhaustive test suite of every little thing. That's too much stuff for an installation or upgrade, and is better suited to being run by the developers, especially automated as CI. Anything in a t-test that requires a whole bunch of extra stuff be installed is probably a good candidate for developer testing instead. That's my take on it.

[carygravel]

Can I assume that the raster data is what you're trying to compare, and one or the other needs to be massaged into a new format in order to compare them?

Absolutely. The idea is to test the image in the PDF. So the options are:

• a tool like imagemagick which can convert the PDF into something we can compare. Imagemagick seems to use ghostscript for this, which cannot be automatically installed on Windows.
• a third-party tool which can extract the images from the PDF. Poppler is one for Linux, but I don't know of one for Windows.
• render the PDF and take a screenshot. Again, I know how to do this programmatically on Linux, but not Windows.

So if you have any ideas about how to achieve this with Windows, please try them out.

However, I think that many overdo it with t-tests. I look at t-tests as confirmation that the package installed correctly, and should run OK, rather than being an exhaustive test suite of every little thing. That's too much stuff for an installation or upgrade, and is better suited to being run by the developers, especially automated as CI. Anything in a t-test that requires a whole bunch of extra stuff be installed is probably a good candidate for developer testing instead. That's my take on it.

I see no difference between the tests carried out by the developer writing the software, and the developer packaging the software. Without exhaustive tests, information like

http://matrix.cpantesters.org/?dist=PDF-Builder+3.021

is useless. Indeed CPAN reports that less that 50% of Builder is covered by tests, and marks any module with less that 75% as red. I would also try to achieve a minimum of 75-80% test coverage.

And of course the tests and coverage reports themselves are useless unless the right things are being tested.

[PhilterPaper]

I see no difference between the tests carried out by the developer writing the software, and the developer packaging the software. Without exhaustive tests, information like

http://matrix.cpantesters.org/?dist=PDF-Builder+3.021

is useless. Indeed CPAN reports that less that 50% of Builder is covered by tests, and marks any module with less that 75% as red. I would also try to achieve a minimum of 75-80% test coverage.

My objection is to the end user (not a developer writing and/or packaging the software) being saddled with exhaustive tests to prove every little nook and cranny of the package. While that's "nice" (and gives everyone a warm, fuzzy feeling), when it starts requiring installation of foreign (non-CPAN) packages such as ImageMagick and ghostScript, I think it's getting out of hand. I feel that the t-tests should do no more than prove that the package arrived and installed intact, and that a quick survey of basic functions shows that everything seems to "be there", and seems to be working. Perhaps a second level of t-test-like tests could be provided for CPAN testing, but automating that in the style of t-tests seems a difficult task (e.g., requiring installation of foreign packages).

There's a lot of stuff that's hard to test, particularly when it involves graphical material (where the eye is the best judge of whether or not it's correct), or packages content to be displayed by Third Party systems (e.g., PDF). I used to develop a Geographical Information System for a large corporation, where the output was not to a file, but directly to various display devices. We were never able to come up with a test system better than just watching the graphics output being built, and noting any errors to be fixed. We would have loved to automate it, to fire it off overnight and see a Pass/Fail result in the morning, but we could never get there. Now, much of a PDF can be compared to desired patterns, but something needs to be done about embedded images, and how to automate comparison against some standard. The eye can do this quickly and easily, but graphics formats vary (including not just the raster data itself, but also the surrounding code), making automated comparison very difficult. If you don't have a reliable tool built into your testing platform, that's going to be a problem.

[PhilterPaper]

No one has responded to my query about whether "convert" is implemented on non-Linux (as well as non-Windows) systems. Should the OSNAME check be for Windows, Linux, and everything else; or Windows and non-Windows;, or something else? I don't want to specify that certain tests or code is for Linux, and leave BSD flavors, etc. out in the cold, if I don't have to.

I don't want for users to have to install ImageMagick or other "foreign" tools in order to run all the t-tests. So long as the developer(s) can do testing, and maybe Linux (and other non-Windows users?) can run t-tests, that's enough for me.

[PhilterPaper]

Good News, Everyone!

I installed ghostScript (64 bit version) and the t-tests all appear to run through properly (test 9 is still skipped). If we check for gswin64c in addition to magick (or just convert on non-Windows), it should work if that computer happens to have the right stuff installed (otherwise skip). I still have two issues before I pull in your changes:

1. I take it that gswin64c is the 64 bit version of gs. Would the 32 bit version be gswin32c? Would it be best to check if either of these utilities are available? We could still use tiffcp for non-Windows, if that's easiest (or keep using convert if that works just as well on non-Windows platforms).
2. If you check OSNAME for "linux", I don't think that will pull in various BSD flavors. Should we check Windows (MsWin32) and handle it one way, and assume all other platforms behave like Linux? If we get complaints about non-Windows, non-Linux platforms breaking, we can take them on a case-by-case basis. It might be good to go ahead and check for convert anyway, and not assume it's built-in.

If you want to poke around with other ways of doing it, be my guest, but it appears there is now a path forward for Windows. I'm not familiar with various flavors of ImageMagick, so if you want to be sure it works on either v6 or v7, that's fine. The only thing I must insist on is not running convert on Windows, as that is potentially dangerous.

Maybe something like:

on Windows,  $convert = 'magick convert' (if exists), else '' (will skip tests 9-12)
      else,  $convert = 'convert' (if exists), else '' (will skip tests 9-12)
on Windows,  $tiffcp = '' and $useconvert = $convert, else '' (will skip tests needing tiffcp)
      else,  $tiffcp = 'tiffcp' (if exists), else '' (will skip tests 9-12)

Skip a test if necessary routine name is ''. Some tests use $tiffcp and others use $useconvert (magick convert) 
depending on OS and availability.

[carygravel]

Glad to hear that you've got it working. I'll work on it ASAP.

[carygravel]

I've just updated the branch:

• rebased on your master branch following your recent tiff changes
• using ghostscript rather imagemagick to convert PDFs back to images to be able to compare them
• now passes in githubs CI framework (and locally on my machine, of course)

Please test.

[PhilterPaper]

OK, it claims to pass (or skip) all 12 tests on Windows 10 (64 bit), with all combinations of Graphics::TIFF, ghostScript, and ImageMagick enabled/disabled. I cannot test 32 bit (just gswin32c?), so fingers crossed on that. Thank you for your efforts on this!

Three things to note:

1. For some reason, when I installed ghostScript a while ago, it did not permanently update the %Path% system variable. I had to fix that. I might add a comment regarding that.
2. I see you have re-enabled test 9 (alpha). Running without Graphics::TIFF, I get **** Error: File encountered 'rangecheck' error while processing an image. Output may be incorrect. ok 9 - alpha. Since the non-Graphics::TIFF code doesn't support alpha channel, I suppose the best course is to add and $has_GT to the test.
3. What's with the caption:? If I change caption:Somelongtextwithnospaces to caption:\"Some caption text\", it works (or at least, I don't get an error message -- I didn't look at the resulting image file). Does that change fail on Linux? No one is going to see the created file anyway, but still, I would be a little more comfortable knowing what's going on.

Barring any objections on your end, I will go ahead and pull this in once you give your blessing to the changes (I'll make the changes on my end, no need for you to update the PR unless you want to).

[carygravel]

2. I see you have re-enabled test 9 (alpha). Running without Graphics::TIFF, I get `    **** Error: File encountered 'rangecheck' error while processing an image. Output may be incorrect. ok 9 - alpha`. Since the non-Graphics::TIFF code doesn't support alpha channel, I suppose the best course is to add `and $has_GT` to the test.

Thanks. Yes. I didn't test it without GT.

3. What's with the `caption:`? If I change `caption:Somelongtextwithnospaces` to `caption:\"Some caption text\"`, it works (or at least, I don't get an error message -- I didn't look at the resulting image file). Does that change fail on Linux? No one is going to see the created file anyway, but still, I would be a little more comfortable knowing what's going on.

Sure, that should work.

Barring any objections on your end, I will go ahead and pull this in once you give your blessing to the changes (I'll make the changes on my end, no need for you to update the PR unless you want to).

Please go ahead. When you close the pull request, I'll update #148.

Note that with imagemagick, you should now be able to create on-the-fly versions of your catalogue of TIFFs (and other image formats), and therefore make testing much easier.