# [Fontinst] Mapping all diacritics to actual glyphs rather than composites

Sun Jan 17 11:09:38 CET 2010

I've finally pieced together that the solution is to write my own encoding
vector.

Is there a good tutorial about how to do this?

As a test I simply made a copy of 8r.enc and 8r.etx. In the .enc file I
replaced one of the /.notdef's with /eogonek, and then added a \setslot for
this glyph in the .etx file. Then I changed \reencodefont{8r} to refer to my
renamed, modified copy, ran the files through TeX and updated all the map
files.

Sure enough, the correct *eogonek* comes out in the PDF (it's even
serchable). Perfect!

I finally understand the reason that *eogonek* wasn't working is that it
isn't defined by 8r.

I still have some questions.

1) What's the best way to do what I need?
2) If I need a glyph that is not in T1, like *iogonek*, in addition to the
above, do I then simply have to modify t1.etx and add a slot for that glyph?
3) If I need a glyph that doesn't even have a TeX command, such as
scommaccent, what do I have to do to get access to it in my latex document?
I know someone has written a \cb{} command that fakes comma below. Can I
write my own \cb{} command? What would it look like? I really only need to

Fortunately, because I'm doing book work, I can make room in the encoding
vector by discarding some math symbols and analphabetics.

Reinhard, thanks for the link to the T1 spec. Based on certain aesthetic
considerations, I cannot use either Pagella or FPLNeu [
http://home.vrweb.de/~was/x/FPL/ <http://home.vrweb.de/%7Ewas/x/FPL/>].

—Christopher

2010/1/17 Lars Hellström <Lars.Hellstrom at residenset.net>

>
>  What I don't understand is why A/E/a/eogonek and gbreve are not being
>> taken
>> directly from the font, while, for example, iacute and acircumflex are.
>>
>
> First note that "the font", as it gets defined in a PS or PDF file, is the
> *base* font; all glyphs will have to be expressed in terms of slots in this
> font.
>
> Second, look in the MTX file for the base font you're feeding into
> \installfont, and compare the entries for e.g. iacute and eogonek. Most
> likely, one is like
>
>  \setscaledrawglyph{iacute}{...}{...}{...}{237}{...}{...}{...}{...}
>
> and the other is either missing or like
>
>  \setscalednotglyph{eogonek}{...}{...}{...}{-1}{...}{...}{...}{...}
>
> The first says an iacute glyph appears in slot 237 of that font (named in
> second argument). The second says an eogonek glyph is currently unencoded
> (but might become available if the font is reencoded). The first really
> defines an iacute glyph to fontinst, and the second doesn't. Hence
> llbuild.mtx will later find eogonek undefined, and do its best to provide
> one.
>
> (For various arcane reasons, which are related to the AFM CC commands
> Hilmar wrote about off-list, the \setscalednotglyph command *does* define a
> pseudoglyph eogonek-not, but that's probably of no use to you. There's still
> no slot in a font defined through any .map file which corresponds to the
> proper eogonek defined in the PFB.)
>
>
> The main point is that fontinst can't reach into the bowels of a font and
> access arbitrary fonts therein, it can only make use of glyphs that the DVI
> drivers assign to some slot of some font.
>
> This point is somewhat blurred by the fact that it is often fontinst that
> manufactures the mapfile lines that told the drivers about the fonts in the
> first place, but in this area fontinst merely follows orders, so if you
> didn't tell it to reencode a base font so that its eogonek appears in some
> slot, then the eogonek of that base font won't be available (as far as
> \installfont is concerned).
>
> Lars Hellström
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/fontinst/attachments/20100117/7ea9ea40/attachment.html>