In /lib/PDF/API2/Win32.pm, there is the following method:
sub enumwinfonts {
my $self = shift;
return map { $_ => $wf->{$_}->{'display'} } keys %$wf;
}
/examples/027_winfont fails to run: the first thing it does is call this method to get a list of fonts:
%wxf = PDF::API2::Win32->enumwinfonts();
but nothing is returned. %wxf should be a hash of font names and information set at the top of Win32.pm. Looking at the code,
my $fontdir = $Registry->{'HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/Shell Folders'}->{'Fonts'};
appears to work OK, returning (in my case), $fontdir set to C:\Windows\Fonts. In the registry editor, HKEY…Folders is a leaf node, with "Fonts" one of the elements. So, $Registry->{} must be returning a hash reference, one of whose elements is named "Fonts" and has a value "C:\Windows\Fonts".
The next line does not seem to work:
my $subKey = $Registry->{'HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Fonts'};
HKEY…Fonts is a leaf node (the original code was Fonts/), whose elements are font names such as 'Aharoni Bold (TrueType)', whose value is 'ahronbd.ttf'. So, $Registry->{} should be returning a hash reference to $subKey, and that should be able to reference an element by name such as 'Aharoni Bold (TrueType)'. Unfortunately, $subKey is unset (%{$subKey} has a scalar value of 0), so nothing is processed and nothing gets built into $wf.
A possible workaround might be to directly read the font directory $fontdir, and process the file names to build the list, assuming that the .otf and .ttf extensions are correct. However, it would be better to understand why the registry is not returning the expected hash reference.
There is another registry reference further along,
$subKey = $Registry->{'HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Type 1 Installer/Type 1 Fonts/'};
which I have not explored yet. Also, the winfont() method presumably doesn't work, either (again, called by 027_winfont).