[Fontinst] A question about reglyphfont

[Lars Hellström]

kmc skrev:
> Hi,
> 
> I've been playing with fontinst for a while, now I'm stuck on some converted
> font. When I convert (using Fontlab or Transtype) a complex opentype font to
> type1, the resulting pfb and afm will contain even the smallcap and oldstyle
> glyphs. In a traditional fontinst approach, however, one needs to have SC
> and OSF glyphs in separate pfb files to make them working.

No! I can think of some other font tools that would be troubled by 
this, but fontinst doesn't care how glyphs have been bundled into fonts.

What /could/ be troublesome is having a PFB with more than 256 glyphs, 
since you then have to use it with more than one encoding in order to 
make all the glyphs accessible, but that is a restriction imposed by 
the DVI driver and PS/PDF itself.

> It'll require
> much care if I try to extract these glyphs and create separate SC and OSF
> fonts, let alone extract the kerning info from afm file.
> 
> Then I came with the idea about reglyphfonts : Say I have a font DinTextPro
> (dtp) converted to Type1, named dtpr8a.pfb, which contains SC glyphs as
> Asmall, Bsmall, etc. What if I rename the [Asmall, Bsmall, ..., Zsmall] in

Did you mean to say "the PFB" here?

> to [a, b, ..., z] and reglyph it to dtprc8a.pfb?

So now you have two PFBs? That's going the wrong way; what you need is 
instead a second encoding vector.

> That goes like this in the
> drive file:
> 
> \reglyphfonts
>      \killglyph{a}
> \renameglyph{a}{Asmall}
>      \killglyph{b}
> \renameglyph{b}{Bsmall}
> ...
> \reglyphfont{dtprc8r}{dtpr8r}
> \endreglyphfonts
> 
> (I don't know if the killglyph command is necessary but I've tested w/ and
> w/o killglyph, none of them worked)

I'm not surprised it didn't work, since you're kind of making things 
worse rather than better: you're renaming Asmall to a, which makes it 
harder to distinguish from the real a.

But to answer the concrete matter of the \killglyph: it's needed when 
you do the above. Without it, the resulting dtprc8r.mtx would contain 
one \setscaledrawglyph{a}... command for the real a glyph (since a is 
not killed, it will just be copied) and one for the Asmall glyph, and 
there's no way of knowing (without looking into the AFM file) which 
comes first and therefore gets to define the "a" glyph to fontinst.

(There are other technicalities too, that involve notglyphs, but right 
now I'm too bored to comment upon those.)

> and install as
> 
> \installfamily{T1}{dtp}{}
> \installfont{dtpr8t}{dtpr8r,newlatin}{t1}{T1}{dtp}{m}{n}{}
> \installfont{dtprc8t}{dtprc8r,newlatin}{t1}{T1}{dtp}{m}{sc}{}
> 
> When compiling, the dtprc8r.mtx did came out, but once installed, it didn't
> work (\textsc{} command resulted in normal glyphs, not SC glyphs).

Hmm... I'd rather expect it to come out with a bunch of missing glyphs 
(or unfakable warnings) when you do that, but "normal glyphs" might 
have been your best result so far...

> Is what I did wrong? Please help me, thank you!

What you need to do is provide two base fonts that map to the same PFB, 
but using different encodings to provide different sets of glyphs. I 
think the following will be the easiest way to get it done (NOTE: I'm 
just typing this in the e-mail client, so watch out for typos):

% File make-dtp1.tex
\input fontinst.sty

\recordtransforms{make-dtp1.recs}

\transformfont{dtpr8r}{\reencodefont{8r}{\fromafm{dtpr8a}}}
\transformfont{dtprcjq8t}{\reencodefont{t1cj}{\fromafm{dtpr8a}}}

\installfonts
   \installfamily{T1}{dtp}{}
   \installfont{dtpr8t}{dtpr8r,dtprcjq8t,newlatin}{t1}
         {T1}{dtp}{m}{n}{}
   \installfont{dtprc8t}{dtpr8r,dtprcjq8t,newlatin}{t1c}
         {T1}{dtp}{m}{sc}{}
\endinstallfonts

\endrecordtransforms

\bye


% File make-dtp2.tex
\input finstmsc.sty

\resetstr{PSfontsuffix}{.pfb}
\adddriver{dvips}{dtp.map}
\adddriver{pltotf}{dtp.sh} % Shell script of necessary pltotf commands
% Add other drivers as necessary
\input make-dtp1.recs
\donedrivers

\bye


I believe dtp.map will come out with two lines

dtpr8r DinTextPro <[8r.enc <dtpr8a.pfb " ReEncodeFont TeXBase1Encoding "
dtprcjq8t DinTextPro <[t1cj.enc <dtpr8a.pfb " ReEncodeFont 
fontinst-autoenc-t1cj "

Notice how one uses 8r.enc, the other t1cj.enc (which fontinst should 
have generated when processing make-dtp2.tex). Together, they give 
access to more glyphs from dtpr8a.pfb than any single encoding could.

Now, even if I managed to avoid typos in the above, there is a risk 
that it will error out at some step while processing t1cj.etx or 
t1.etx; they're seldom used for reencoding, so there might be a piece 
of code somewhere that should be conditionalised. In that case, just 
report back what the error was.

Lars Hellström