[Fontinst] A question about reglyphfont

kmc kmc.best at gmail.com
Wed Oct 7 13:02:14 CEST 2009

2009/10/7 Lars Hellström <Lars.Hellstrom at residenset.net>

> 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.
Yes, I can now recall how Minion Pro support package works in a similar way

>  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.
No, that ways a typo, I meant "reglyph it to dtprc8r using

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):
Thanks, your method worked (*\textsc() produce REAL small caps glyphs*) but
I still have some questions.

> \transformfont{dtprcjq8t}{\reencodefont{t1cj}{\fromafm{dtpr8a}}}
> Here, is it that you kind of "borrowed" this t1cj.etx (which is seldom
used), then \etxtoenc{}{} will be call when processing the 2nd file?

>        {T1}{dtp}{m}{n}{}
 Why did you use two fonts for dtpr8t? I though all glyphs necessary for
dtpr8t are in dtpr8r?

>        {T1}{dtp}{m}{sc}{}
** This is the most "magic" thing that I don't understand, apparently
t1c.etx is used, but isn't it supposed to be used when creating fake small
caps? I checked the resulting pdf, apparently the Smallcaps are the real
Asmall, Bsmall in the pfb. How is it possible?

> 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.
> I think I now understand the concept, so if I'm curious enough, I can write
my own enc file (like Minion Pro's base-MinionPro-a[a/b/c/d/e].enc, instead
of 'hijacking' the seldom used t1cj.etx and let fontinst generate t1cj.enc?
Well I think it will require much care, for the moment *if I can understand
how the t1cj.etx and why t1c.mtx can access REAL smallcaps glyphs, I'll be

> Lars Hellström
Many thanks Lars!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/fontinst/attachments/20091007/e0728925/attachment.html>

More information about the fontinst mailing list