[comp.fonts] Request help with mf, gftopk

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (03/29/91)

I've hit the wall in frustration; there just doesn't seem to be a
document that explains in cookbook fashion how to get from metafont
source files to all the files at various resolutions as needed by the
display devices. More frustrating, I made this all work two years ago,
and now the method has escaped me.

This is a cry for help; email would be fine, if someone wants to put
together a .mf_to_device man page and post it, all the better.

The situation:

I have (long ago) designed a logo file, company_name.mf, that contains
the instructions for drawing a moderately complex logo symbol.

For a set of point sizes from 6 to 54, I have created headerfiles
company_name6.mf to company_name54.mf.  Each of these is meant to create
a font with one entry, character #1, the logo symbol.

Once I get out the pk files, I'm moderately successful at pulling them
into TeX or LaTeX and using them; I don't think I need help there, but
that should be part of an manual page created, anyway.

Several problems occur.  When I say

	mf
	**\mode=CanonCX            <- defined in a clone of the Washington
        *input company_name6          University mode definiton file

I don't get "company_name6.300gf", I get "mfput.300gf"; how do I make the
name come out right.

Also, when I say

	mf
	**\mode=CanonCX
	*input company_name8

I get "mfput.240gf".  I have not one clue why one is at 300dpi and another
at 240dpi.

The creation of the correct resolution gf (and thence pk) file is voodoo
magic to me.  And even once the proper resolution pk files are created,
from the last time around, they don't always get accepted as the correct
ones by dvips or whatever displayer is being used.  Can anyone help _lots_?

Thanks!

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

karl@apple-gunkies.gnu.ai.mit.edu (Karl Berry) (04/03/91)

> together a .mf_to_device man page and post it, all the better.
Did you read the mf(1) man page in the Unix TeX distribution?  It has
quite a bit of information in it.

> 	mf
> 	**\mode=CanonCX            <- defined in a clone of the Washington
>         *input company_name6          University mode definiton file
> I don't get "company_name6.300gf", I get "mfput.300gf"; how do I make the
Because Metafont assigns the jobname on the first line of input.
mf
**\mode=CanonCX; input company_name6
would work better.  Use of = in this context is confusing, if not wrong.
Also, you can give all this command line:

mf '\mode:=CanonCX; input company_name6'

In fact, if we add an assignment to the magnification:

mf '\mode:=<whatever>; mag:=magstep(x); input fontname'

we have the canonical Metafont input line.

> 	mf
> 	**\mode=CanonCX
> 	*input company_name8
Me neither.  There must be something in the sources which is setting the
resolution, directly or indirectly.  

> The creation of the correct resolution gf (and thence pk) file is voodoo
> magic to me.  
It's the value of hppp (horizontal pixels per point), scaled to be
pixels per inch, and rounded, at the time the gf file is opened.  hppp
is set by the plain Metafont macro mode_setup according to the
pixels_per_inch value in the mode.

karl@cs.umb.edu

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (04/06/91)

Well, I got some help via email and here on the net, and here is a part
of a posting I stuck in comp.sys.amiga.applications explaining what worked,
in case the information is of interest to others.

u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes:

[...]

>> You can try ftp'ing the bitmapped fonts from labrea.stanford.edu; or
>> making your own with MetaFont.

> I'm looking into the ftp'ing the fonts I'll need but I'm hoping some
> reader out there can give some tips on "using" PasTeX's CALLMF
> feature. If you have Arexx and set the CALLMF environment variable
> then a script gets called to tell you what parameters you should call
> the MetaFont program with to build the required fonts.

> Well...I've RTFM'ed (I think EnglishDoc.dvi was the appropriate doc)
> but I guess I'm just that extra little bit thick in that I don't see
> what command (in detail) I should give to MetaFont to build what I'd
> need.

> The nicest solution would be to modify the callmf.rexx Arexx script,
> so that it would call MetaFont to make the font ...

Last things first; creating a whole rasterized metafont in a nice
selection of sizes can take literal days; I ran mine overnight to get
just a few sets of fonts built. You _really_, _really_ don't won't this
overhead in your printing loop, which is why TeX/Metafont users have
megabytes of already rasterized fonts online and ready to use. Metafont
makes lovely fonts, but it makes a snail look turbocharged.

Since I luckily don't have your implementation, I get to wave my hands
and be unspecific a lot in answering.  I had to relearn this stuff all
in the past six days, with a little help from a nice guy in comp.fonts,
so let's see how much I can remember.

To make a Metafont accessible for printing, you must

1) create an object called plain.base, using initmf; this is a file that
adds a lot of higher level commands to raw metafont, which is a pretty
primitive interpreter.

The command I used to make this looked something like

            initmf
            ** plain
            * dump

(Different systems look a little different; I pulled mine out of page
279 of The METAFONTbook, except omitting "local", which was not needed
for what I did.)

and was run where plain.mf was visible; the output was plain.base, and
got stuck in a directory where metafont expected to see base files; on
the Sun where I was working ../bases from mf/lib/inputs.

2) Have available a metafont source file of mode definitions that
includes one for your printer. If it doesn't come with your metafont
implementation, the university of washington (state) has an FTPable file
that seems to be the stand set of mode definitions for lots of printer
types. These define things like resolution, write white or write black
corrections, and so on.

My choice of modes was the mode_def for CanonCX, a common laser printer
engine, from a file we'll call CorpModeDefs.mf.

3) Have available a metafont source header file that defines the point
size, extra blackening, and so forth used to parameterize your font
definition for this point size. In my case call this CorpLogo6.mf,
CorpLogo8.mf, etc. This set of metafont commands finishes by invoking
the next file.

4) Have available the source file of metafont commands that describe the
character shapes. In my case, call this CorpLogo.mf.

The commands to make a six point corporate logo were then:

    mf
    ** CorpModeDefs; \mode:=CanonCX; \mag:=magstep(0); input CorpLogo6

(the "**" is a prompt from mf) and after a certain amount of blathering,
metafont produced CorpLogo6.300gf and CorpLogo6.tfm. The first is a file
of the rasters for the characters in a format comfortable for mf to
produce, the second is a file of the character dimensions for each
character, used by TeX to size and space characters, without having to
deal with their raster representations.

CorpLogo6.tfm is ready to use, so I moved it to the .../tex/lib/tfm
directory where all the font character shape tables were stored.

The printer driver (dvi2ps or whatever) doesn't want to deal with the
...gf files though, it wants to use a faster, smaller form.  A program
called gftopk makes this new format:

    gftopk CorpLogo6.300gf

creates CorpLogo6.300pk, which should then be moved to a directory where
TeX expects to find fonts at 300 dpi, on the system I was using, this
was .../tex/lib/pk/pk300. You can then throw away CorpLogo6.300gf; it
serves no further purpose.

That should make the fonts accessible, as long as the right environment
variables are set for your TeX implementation to point to their
directories.

To use this example in TeX, I then made a file that contained lines like

   \font\Corpsizesix=CorpLogo6  at 6truept
   \def\Corpsixpointlogo{\hbox{\Corpsizesix\char1}}

as a header file and pulled it into TeX, then used it in text like

   exampling we will go\Corpsixpointlogo , exampling we will go!

Pretty obviously, my "font" contained only character number 1, but this
is the general process for a non-alphabetic font; an alphabetic one is
simpler, you need merely define that "\Corpsizesix" is a font, then turn
on the font like the embedded "\Corpsizesix" command, and it is modal
until overridden or the current context ("{","}" pair) is exited.

Enough.  Hope any of that makes sense, it's almost 4AM.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

ken@csis.dit.csiro.au (Ken Yap) (04/08/91)

>Last things first; creating a whole rasterized metafont in a nice
>selection of sizes can take literal days; I ran mine overnight to get
>just a few sets of fonts built. You _really_, _really_ don't won't this
>overhead in your printing loop, which is why TeX/Metafont users have
>megabytes of already rasterized fonts online and ready to use. Metafont
>makes lovely fonts, but it makes a snail look turbocharged.

Yes, running MF to make fonts is slow, especially if you don't have a
workstation, but many DVI to foo converters have scripts that will run
MF on the fly and *thereafter the filter uses the newly made pk file*.
So if the users are happy to wait a little while on their first print
run, you're ok. Otherwise, the installer should run a bunch of
documents through the system (you don't actually have to print the
documents, just redirect the PDL output to /dev/null) to make the most
commonly occuring fonts.

dhosek@euler.claremont.edu (Don Hosek) (04/09/91)

In article <1991Apr7.231813.10310@csis.dit.csiro.au>, ken@csis.dit.csiro.au (Ken Yap) writes:
>>Last things first; creating a whole rasterized metafont in a nice
>>selection of sizes can take literal days; I ran mine overnight to get
>>just a few sets of fonts built. You _really_, _really_ don't won't this
>>overhead in your printing loop, which is why TeX/Metafont users have
>>megabytes of already rasterized fonts online and ready to use. Metafont
>>makes lovely fonts, but it makes a snail look turbocharged.
 
> Yes, running MF to make fonts is slow, especially if you don't have a
> workstation, but many DVI to foo converters have scripts that will run
> MF on the fly and *thereafter the filter uses the newly made pk file*.
> So if the users are happy to wait a little while on their first print
> run, you're ok. Otherwise, the installer should run a bunch of
> documents through the system (you don't actually have to print the
> documents, just redirect the PDL output to /dev/null) to make the most
> commonly occuring fonts.

It's not too bad on my 25mhz 386 messy dos box.

I do strongly recommend the approach of only generating fonts as
they're needed. If you primarily use LaTeX and are willing to
assume that few documents will load fonts (which is not that
unreasonable of an assumption) a fairly small archive can be
created. For an in-house pc TeX distribution I did recently, I
created a font set containing all the fonts referred to in
fontdef.ori (M&S font selection ymir.claremont.edu
[anonymous.tex.inputs.latex-contrib]), all the CM fonts at
magstep0, all the preloaded magnifications of plain.tex and all
the actually defined fonts of plain.tex at magsteps 0, half, 1
throught 5. The whole thing lharc'd was almost small enough to
fit on a single 1.4M floppy (six archives of 300-359K each).
Unpacked it took around 2.5M. My personal system currently has a
mere 815K of fonts in 143 files which has covered a very large
variety of documents.

Incidentally, this approach also makes it practical to do things
like arbitrary scaling of MF-based fonts (I'm currently making
Kanji fonts with the jemtx package (see ymir.claremont.edu
[anonymous.tex.babel.japanese]) at sizes from 6 to 10pt with
1/30pt intervals as necessary in an application where text must
be fit into an arbitrarily sized region (bottle labels).

-dh

-- 
Don Hosek                  | To retrieve files from ymir via the mailserver,
dhosek@ymir.claremont.edu  | send a message to mailserv@ymir.claremont.edu 
Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME
714-625-0147               | where DIRECTORY is the FTP directory (sans 
---------------------------+ "anonymous") and FILENAME is the filename, e.g. 
"send [tex]00readme.txt". There is a list of files in each directory under the 
name 00files.txt. Binary files are not available by this technique.