PDFv2Plugin had broken on Windows at some point after testing SampleDoc.pdf (converted variant) with paged_pretty_html. Back then, it still used to produce a proper bg image with the graphic vector art in SampleDoc.pdf. In the 5Mar and 5Apr binaries however, the background images went missing on Windows when the PDF was converted with PDFv2Plugin's paged_pretty_html setting, resulting in broken img icons in the html. Dr Bainbridge tracked this to the $base_dir in HTMLPlugin's add_file() looking wrong (something like ./ resulting in image paths like .\C:\some\path\imagefile.ext). Comparing the same collection Linux, the basedir value is simply the empty string. $base_dir is passed around throughout HTMLPlugin, where it starts off still with the correct of empty string on Windows, but in HTMLPlugin::process() it starts acquiring the wrong value after a call to util::upgrade_if_dos_filename(). The code for that util subroutine was modified in the about 6 weeks ago to be more robust. However, I think it should produce empty string output for empty string input, and not just test for whether the input file/dir exists before converting to LongPathName on Windows. So now, in util::upgrade_if_dos_filename(), if filename_full_path is empty, it is returned as empty even on windows, as that's what happens on linux and anything else breaks PDF bg image assoc files on Windows. This seems to have fixed the PDFv2Plugin problem. Still need to run it by Dr Bainbridge since Kathy's away, to make sure it is the correct thing to do.