I'd like to understand MikTeX's mechanism for finding files, in particular PostScript font outlines (pfb). I'm running MiKTeX on an old Windows 98 box, and on my system, issuing the command

% findtexmf --show-path=.pfb

yields a number of directories inside MiKTeX's hierarchy (as expected) and 2 extra ones:

C:\psfonts\ C:\Program Files\Adobe\Acrobat3\Reader\FONTS

I wonder

1) where these directories come from. Sure, they contain PFB files, but they are not the only ones: C:\PSFONTS contains more subfolders (which aren't searched, I tested), and there is another Acrobat version installed in another folder, which also contains (different) fonts, but MiKTeX doesn't notice.

2) How can I change the search path? In particular, I would like to have MiKTeX search C:\PSFONTS recursively, so that it can locate all the PostScript outlines arranged in a hierarchy.

Are there any files I should tweak? I bluntly grepped all of MiKTeX's directories for occurrences of relevant strings (ACROBAT3 and PSFONTS, for example) -- even binary files! -- but I wasn't able to spot anything that helped me understand. Can some kind reader steer me in the right direction?

Thanks in advance!

Such are the joys of using undocumented things:
Reading core.ini was removed in the source code
on oct 7 and distributed with version 2.5.2471
There is still miktexstartup.ini, but that's also undocumented, so it might go away.

Right now the only option for the problem of configuring multiple programs in one place seems to be via environment variables.
Note that TEXFONTS is NOT listed in the documentation ( http://docs.miktex.org/manual/envvars.html ) so there is no way to know if the documentation is incomplete or if it is considered "undocumented", which means it might go away without notice at any time.

For users on Win2000 and higher, there is another solution for the original problem (adding an external fonts hierarchy into the tex search path). By using NTFS junction points (directory symbolic links), you could create a link to the non-tex fonts folder in any one font directory in anyone of the TEXMF roots

To create the link you could use this:
http://www.sysinternals.com/Utilities/Junction.html

I think the search path for type 1 fonts is now in dvips.ini: here is the relevant extract from this file:

[ft.PostScript header]

path=.
path;=%R/dvips//
path;=%R/fonts/afm//
path;=%R/fonts/enc//
path;=%R/fonts/map//
path;=%R/fonts/type1//
path;=$(psfontdirs)

Try to append // to the last line (that's the way to indicate recursive search. I'm not sure it works, as $(psfontdirs) is an environment variable (I think to denote non-TDS directories).

Then put the extra dvips.ini (with just this
modified line) in:

C:\Documents and Settings\All Users\Application Data\MiKTeX\2.5\miktex\config

This should work (after updating the filenames database as usual. Let me know if there is any problem, as I may have the same difficulties sooner or later.

Best regards,
B.A.

Hm, no way. In more detail, here's what I found out.

> I think the search path for type 1 fonts is now in dvips.ini:

But also dvipdfm(x), pdf(e)tex and others need to access .pfb outlines. There's probably some other mechanism going on, too.

> here is
> the relevant extract from this file:
>
> [ft.PostScript header]
>
> path=.
> path;=%R/dvips//
> path;=%R/fonts/afm//
> path;=%R/fonts/enc//
> path;=%R/fonts/map//
> path;=%R/fonts/type1//
> path;=$(psfontdirs)

This section is, I think, for PostScript headers (.pro files and such; look up findtexmf to know more).

However I see what you mean, I'd thought along the same lines already -- and failed.

I did add the // to a local copy of dvips.ini and even to a local copy of config.ps (the file that pops up in the editor when I say

% initexmf --edit-config-file dvips

After this, I experimented with

% findtexmf --show-path=.pfb
% findtexmf --show-path=.pro (PostScript header files)

but the search path never changed,
not even c:\psfonts -> c:\psfonts\
(which is what this whole thread boils down to).

I even tried mentioning dummy directories in the .ini's -- actually creating them and populating them with nice-looking .pfb, .pfm, .afm, .pro, .enc, .ps files, whatever!

> I'm not sure it works, as $(psfontdirs) is an environment
> variable (I think to denote non-TDS directories).

It sure looks like one, but I don't have any such external env. variable. Of course, I tried

SET PSFONTDIRS=c:\dummydir
SET PSFONTDIRS=c:/dummydir
to no avail.

> Let me know if there is any problem, as I may have the same difficulties
> sooner or later.

I guess the only serious alternative is to RTFS. Frankly, I'm not looking forward to it. :-(

Thanks very much for your helpful answer anyway; I've done my best to share what I found, so that no one has to re-invent the wheel again.

I tested my own system and found that miktex knows where pfb's are installed (I mean those that are not in a TDS hierarchy). I guess it's given by the value of $(psfontsdir). So I compiled a document with Stempel Garamond (known as Original Garamond in Corel Draw's distribution): the pfb's were in C:\psfonts, and everything was OK.

However, I have just one difference with you, as I see it : all my 'external' (= non-TeX) psfonts are under C:\psfonts (or whatever you want, but it's not organized in subdirectories.Perhaps it is the only problem.

Finally I wrote a dvips.ini with C:\psfonts\ explicitly in the search paths and put it in C:\Documents and Settings..., It also worked fine, but didn't when I compiled with pdflatex, having modified pdfetex.ini. I must say I don't understand very well the new inis.

Regards,

B. A.

> I tested my own system and found that miktex knows where pfb's are
> installed (I mean those that are not in a TDS hierarchy).

Yes, here too -- some directories seem to be hardcoded (c:\psfonts and
the Acrobat Reader program directory), but I can't find WHERE they're
mentioned in MiKTeX's tree.

> I guess it's
> given by the value of $(psfontsdir). So I compiled a document with
> Stempel Garamond (known as Original Garamond in Corel Draw's
> distribution): the pfb's were in C:\psfonts, and everything was OK.

My MiKTeX can find the pfb in c:\psfonts too (but not in
subdirectories), so my experience agrees with your hypothesis that
MiKTeX can find fonts but not recursively.

> Finally I wrote a dvips.ini with C:\psfonts\ explicitly in the search
> paths and put it in C:\Documents and Settings..., It also worked fine,
> but didn't when I compiled with pdflatex, having modified pdfetex.ini. I
> must say I don't understand very well the new inis.

Exactly the same here: DVIPS can find the PFBs but pdfetex can't.

One experiment that I made is moving some PFBs somewhere (say,
c:\morefonts) and adding that directory to my local dvips.ini's search
path. It didn't work, even for dvips. Does it work on your system?

this notes resulted from reading the source and tracing the files used:

a) the name of the file type which includes .pfb is "type1 fonts"

b) in the default installation, no config file holds values for the "type1 fonts" file type

c) if not config file has values for the file type, a default is used

d) For the type in discussion the default is:
.;%R/fonts/type1//;$(psfontsdir)
(from %src%\Libraries\MiKTeX\Core\filetypes.cpp, line 800)

where %R will expand to a list of all registered TEXMF roots, including the package manager virtual one
psfontsdir is somehow determined in code.

e) if a config file has specified the search path for a file type, the defaults are not used.

f) setting environment variables adds to the search path, after values read from config files

g) for "type1 fonts" (i.e. files with .pfb and .pfa extensions) the env vars that checked are:
T1FONTS, T1INPUTS, TEXFONTS, TEXPSHEADERS, PSHEADERS

h) From b) and e) results that you can't just add to the default search path in a config file, the default also has to be set

i) A sensible entry for "type1 fonts" would be:

======== cut =============
[ft.type1 fonts]

extensions=
extensions;=.pfb
extensions;=.pfa

;;; defaults
path=.
path;=%R/fonts/type1//
path;=c:/apps/fonts//
path;=$(psfontdirs)
;;; customized
;;; - no recursion
path;=c:/mydir
;;; - recursive search
path;=c:/mydir//
============== cut ==============

j) different miktex executables seeem to read different ini files, but all of them seem to read some files:
%INSTALLDIR%\miktex\config\miktexstartup.ini
%r\miktex\config\core.ini
where %r expands to the list of registered TEXMF roots, without the package manager one

I created and added the above to core.ini in the CommonConfig.

I'm sorry, but I have no miktexstartup.ini nor core.ini. Maybe it's only in the source code?

B.A.

> I'm sorry, but I have no miktexstartup.ini nor
> core.ini. Maybe it's only in the source code?

Yes, it must be hardwired in the sources, because while I watched some trace output in Dbgview, a (virtual) core.ini was read by many different processes.

Ervinf: thanks! You've been kind enough to figure out some real info by digging into the sources. So I created core.ini and copied the code you mentioned (properly modified for my own directories of course).

After doing this, c:\psfonts\ (2 slashes! Ha!) is searched, but now the %R/fonts/type1 directories aren't -- neither do they appear in the .pfb search path as reported by

findtexmf -show-path=.pfb

Any idea what's going on?

• line 10 of my suggested core.ini:
  path;=c:/apps/fonts//

is of course useless (it was there as part of my tests)

• core.ini and miktexstartup.ini do no exist in the default installation. The code looks for them and reads them if found. So you need to create the file(s).

- on my machine, core.ini is

[ft.type1 fonts]

extensions=
extensions;=.pfb
extensions;=.pfa

;;; defaults
path=.
path;=%R/fonts/type1//
path;=$(psfontdirs)

;;; customized

;;; - no recursion
;;; path;=e:/

;;; - recursive search
path;=e:/LocalTeXmf/fonts//

=======================================

and running findtexmf.exe results in:

C:\tmp\tex>findtexmf -show-path .pfb

C:\tmp\tex;E:\LocalTeXmf\ervin\config\fonts\type1//;E:\LocalTeXmf\ervin\data\fon
ts\type1//;E:\LocalTeXmf\common\config\fonts\type1//;E:\LocalTeXmf\common\data\f
onts\type1//;E:\LocalTeXmf\local\fonts\type1//;c:\apps\miktex25\fonts\type1//;C:
\apps\adobe\acrobat7\Resource\Font;e:\LocalTeXmf\fonts//

It simply didn't work for me (details posted in previous messages), until I uninstalled and reinstalled MiKTeX 2.5. I guess something was messed up (I also found corrupted files in other application folders besides MiKTeK).

BEWARE - if you uninstall MiKTeX and choose to "clean up thoroughly", your configuration files are GONE! BACK THEM UP!

Now the search path can be set up correctly, and findtexmf uses an updated path instantly, even before I use initexmf to remake the file database.

Thank you very much for your continued help!

Again not working!

core.ini appears not to be read by any program in the MiKTeX suite (from pdflatex to findtexmf).

The only systems that works now is setting an environment variable (I use TEXFONTS).

The only thing I did was update MiKTeX yesterday.

After several years and MikTeX versions, this solution stopped working, but
now I found a workaround and I will post it here for future reference - hoping
the next MikTeX version or Windows version doesn't break it. At the moment,
the current versions are Windows 7 and MikTeX 2.9, but I won't update until
I'm really forced to do it. My motto is: if it works, don't update!

The following hack works with Windows XP SP3 and MikTex 2.7

In order to have recursive search for pfb font files (type 1 Postscript
fonts), set the following environmental variable in Windows,

set TEXFONTS=c:/../PSFONTS//

(using a SET command in the shell or the "Environment Variables" dialog in
Computer Properties or System Properties -> advanced).

The C:/../ trick is necessary to bypass/override the default value in the font
search path (that is,c:/psfonts) which doesn't have a trailing double slash
and therefore isn't searched recursively. If you just set TEXFONTS to
"c:/psfonts//", the value "c:/psfonts" in the default search path is NOT
overriden, and the c:/psfonts// value is NOT appended to the default search
path. How is the default search path determined? My guess it that it's
hardcoded, but I don't know for sure. I haven't found a way to change it.