How to find fonts

[perl@nevcal.com]

Solution on my system:
It works with that font (without error) if I copy an old package of the Ghostscript fonts to a gs\fonts subdirectory. But that works only if IM can access the Windows registry. (My Ghostscript 8.71 installation specifies a "GS_LIB" value with that directory.)
Of course, with Win7, that could be a bit more difficult. (I'm still on Windows XP.)

Thanks again for all your help, Drarakel. I re-read what you said, including the above quoted statements and their implications that I missed the first time around. So after some fiddling, I guess I figured out what you meant. At least I got something that works on Win7.

My GS_LIB registry value points to C:\Program Files\gs\gs8.71\lib

So I tried making a fonts\ directory there with the old package of Ghostscript fonts... but no joy.
Then I put the font files themselves in the lib directory (moved them up a level) and then it works.

It would be nice if

(1) IM actually looked at GS_DLL as one of the options to find Ghostscript, if it can't find it on the PATH, or if the IM installer would volunteer to copy it there.
(2) IM installer noticed that the GS fonts aren't found and offer to install them, or tell you where and how to install them.
(3) if the fonts really are built-in to the DLL, it would be nice if IM could use them from there, rather than needing step 2

Well at least this posting will document the necessary steps.

I like to use the GS fonts rather than the Windows fonts (the command worked fine after the last round if I used Times-New-Roman instead of Times-Roman) because that keeps the command more portable to other platforms.

[perl@nevcal.com]

I added

C:\Program Files\gs\gs8.71\bin

...
So I tried adding instead

C:\Program Files\gs\gs8.71\bin

I don't see a difference?

Oops, sorry, the second one was supposed to be edited to

C:\Program Files (x86)\...

[Drarakel]

My GS_LIB registry value points to C:\Program Files\gs\gs8.71\lib

My value is "C:\Programme\gs\gs8.71\lib;C:\Programme\gs\fonts". So, you can add several directories. I even think that this was the default with my Ghostscript installation. But not sure anymore.

It would be nice if

(1) IM actually looked at GS_DLL as one of the options to find Ghostscript, if it can't find it on the PATH

It does. It first looks at the registry (if Windows doesn't prohibit that), and only after that calls the exe and uses the PATH.
You can even check if IM finds the registry entries by adding "-debug configure" to a command line that needs GS.

(3) if the fonts really are built-in to the DLL, it would be nice if IM could use them from there

Well, I thought that IM does that. (The error messages are different if the DLL is not there.)
But after another test, I now see that IM currently can't use ANY of the Ghostscript fonts in the normal GS DLL. I don't know what's the problem here.
At least, there is a workaround.

So, I'm glad that it works now for you. (My post from before wouldn't have been needed anymore, as it seems.)

[perl@nevcal.com]

My GS_LIB registry value points to C:\Program Files\gs\gs8.71\lib

My value is "C:\Programme\gs\gs8.71\lib;C:\Programme\gs\fonts". So, you can add several directories. I even think that this was the default with my Ghostscript installation. But not sure anymore.

Interesting that you can have several directories. My Ghostscript installation didn't have such. That would have kept stuff separate, had I known that, and if it still works to do that in 8.71.

It would be nice if

(1) IM actually looked at GS_DLL as one of the options to find Ghostscript, if it can't find it on the PATH

It does. It first looks at the registry (if Windows doesn't prohibit that), and only after that calls the exe and uses the PATH.
You can even check if IM finds the registry entries by adding "-debug configure" to a command line that needs GS.

Well, if it does, it should have found it, eh? But it didn't, so I guess it can't. Whether it has something to do with invoking 64-bit and 32-bit executables, I couldn't say, but I have 64-bit IM and 64-bit GS. (and 32-bit GS, for IrfanView, I think its registry variables get put somewhere else, for 32-bit compatibility mode).

(3) if the fonts really are built-in to the DLL, it would be nice if IM could use them from there

Well, I thought that IM does that. (The error messages are different if the DLL is not there.)
But after another test, I now see that IM currently can't use ANY of the Ghostscript fonts in the normal GS DLL. I don't know what's the problem here.
At least, there is a workaround.

So, I'm glad that it works now for you. (My post from before wouldn't have been needed anymore, as it seems.)

Yeah, dunno if it _can't_ use them, but if it can, it hides it well. And if it can find the DLL from the registry, it hides that pretty well too, as it seems necessary to have that on the PATH.

Thanks for helping me figure out the workarounds, I had no clue where to start, and have no clue how you knew, but am sure glad you did. Nice to have things working again.

[Drarakel]

All I can say is: Personally, I installed Ghostscript and ImageMagick - and ImageMagick could execute Ghostscript without problems - with the help of the registry (and GS was NOT in the path). So it CAN work!
But I know that some people (with different Windows versions and/or different Ghostscript versions) have problems with that..

The Ghostscript fonts issue however seems to be more problematic. Well, perhaps IM always expects them in the separate fonts directory (and doesn't know that the fonts are now in the DLL).

[perl@nevcal.com]

Yes, 32-bit versions of Ghostscript and ImageMagick worked fine for me on Windows XP too, straight out of the boxes.

When I downgraded to 64-bit Windows 7 is when I encountered these problems. But how else to get 16GB RAM, and still be able to run most Windows software?

So it seems that there are a few rough edges introduced by 64-bit Windows 7 that sadly, in time, developers of all other software will likely have to compensate for.

The font-rearrangement in newer Ghostscript versions might be specific to that, and the way ImageMagick works... I was running an old version of Ghostscript as it did the job fine, but to get the 64-bit version, which looked helpful for a 64-bit machine, I had to get the newer version. This is something that it seems that ImageMagick is digging into Ghostscript internals to find, and they should track and compensate for changes in newer versions of Ghostscript to keep it seemless... or figure out how to achieve the same results using documented interfaces... or something along that line, depending on the current technology.

Thanks again for your help.