[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
\reglyphfont{dtprc8r}{dtpr8r}".
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?
\installfont{dtpr8t}{dtpr8r,dtprcjq8t,newlatin}{t1}
> {T1}{dtp}{m}{n}{}
>
Why did you use two fonts for dtpr8t? I though all glyphs necessary for
dtpr8t are in dtpr8r?
\installfont{dtprc8t}{dtpr8r,dtprcjq8t,newlatin}{t1c}
> {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
grateful.*
> Lars Hellström
>
>
Many thanks Lars!
--
kmc
-------------- 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