[Phil]

In /lib/PDF/API2/Win32.pm, there is the following method:

Code: [Select]

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:

Code: [Select]

%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,

Code: [Select]

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:

Code: [Select]

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,

Code: [Select]

$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).

[Phil]

 PhilterPaper commented on Jul 21

I investigated this some more, and traced down the failure to read the Registry (Windows) to a permissions problem. The default TieRegistry access to the Windows Registry is Read-Write, but starting in Windows 7 (or maybe back in XP), this is denied (Read-Only is OK). I had to add an explicit Access=>KEY_READ() to the code.

Having gotten past that, at the moment the code is confused over what classes and objects are in use and available for methods such as ttfont() (when invoked from Win32.pm). I'm still looking at it.

Win32 seems to have only enumwinfonts() and winfont() methods to list all TTF/OTF/T1 fonts on a Windows system, and open and list the glyphs in a PDF document, respectively. Only examples/027_winfont appears to use either of these methods, and it works only on a Windows machine. As winfont() overlaps various existing examples (020_corefonts, 022_truefonts), I'm not sure there's any need for either 027_winfont as a separate example, or even PDF::Builder::Win32 for that matter. Does anyone know of any code making use of Win32?

The code in enumwinfonts() might be of future use in any cross-platform utility or method to list available fonts. Also see "Font families" discussion on the forum, a request for a standardized interface to list and select font variants (bold, italic, etc.) given the base name. This functionality might be extended to also list available fonts (and types).

 PhilterPaper commented on Jul 23

I went ahead and removed Win32.pm and 027_winfont example from the next release (3.006, date TBD). Actually, they're squirreled away (hi, Johan!) in examples/Windows/, in case anyone wants to look at the code or is actually using that functionality. Win32::TieRegistry has been disabled in the build, so you will have to manually install that package.