| Subject: | Windows: write_objects() tripped up by humourless findTTFont() |
On Windows, application code for resolving font names such "Arial" may look like this:
$fontpath = File::Spec->catdir($ENV{SYSTEMROOT}, "Fonts");
$fontfile = File::Spec->catfile($fontpath, "ARIAL.TTF"); # "C:\Windows\Fonts\ARIAL.TTF"
However, the application could conceivably accept user input such as this:
$fontfile = "c:/windows/fonts/arial.ttf";
On Windows, these are functionally equivalent. findTTFont() accepts different kinds of arguments but treats them as a very literal hash key. So, for path names it will create a separate hash key for each of the above examples. Eventually, this breaks PDF::Reuse::DocProxy::write_objects() which fails with the cryptic
Can't use an undefined value as an ARRAY reference at Reuse.pm line 1464.
Fix for findTTFont:
sub findTTFont
{
my $selector = shift;
# argument was a file path: normalize
if(defined($selector) && $selector =~ m|\.ttf$|i){
$selector =~ s|\\|/|g;
$selector = lc $selector;
}
$selector ||= $aktuellFont[foEXTNAMN];