I want to use the font Junicode with pdfTeX. Unfortunately, there is no Type1 version, so I had to manually convert it using the otftotfm utility. Unfortunately, while I can get it to show up, it evidently doesn't convert the kerning tables correctly. While I could just LuaTeX instead, I would like to be able to use the microtype package, without restrictions. Also, pdfTeX seems to compile much faster, and the project I'm working on is very large, so compile times can be prohibitive. One thing to note also: pdfTeX evidently has a a problem with the version of Junicode available from the website, it doesn't like the fact that its "OS/2 Table" is version 4, so I used FontForge to convert the font to use version 3.

First of all, here's the process I used. I made a directory ~/juni

In this directory, I downloaded a copy of the Cork Encoding. Then, I ran the following command:

otftotfm -e cork.enc Junicode.ttf > junicode.map

which generated the following output (in the junicode.map file)

Junicode--cork--base Junicode "AutoEnc_ibcpqz6zekpiklslxaemqnuq2b ReEncodeFont" <[a_ibcpqz.enc <Junicode.ttf

Next, for my custom encoding, I made a file uenc.def:


Then, I made a file UJunicode.fd:

\DeclareFontShape{U}{Junicode}{m}{n}{ <-> Junicode--cork--base }{}

Finally, here's the test document:


% Loading the fonts for LuaTeX:
% \usepackage{fontspec}
% \setmainfont{Junicode.ttf}

\title{Lorem Ipsum Dolor Sit}
\author{John Doe}
\date{January 1, 2016}

Now, this works. Or at least, the characters show up in the font. However, the kerning is incorrect (and in fact, I'm not sure if there is any kerning at all.) Here's a comparison of kerning between LuaTeX (loading the font using the commented out lines) and pdfTeX:

enter image description here

I'm not sure how to get this to work. None of the instructions I could find online seem to reference this problem.

  • Note that what you've shown doesn't involve conversion to type1. It is using the .ttf. – cfr Oct 3 '16 at 2:45
  • @cfr well I did want to customize it down the road, since Junicode does some things differently. – junius Oct 3 '16 at 2:54
  • Well, in any case. Using the T1 encoding didn't help, kerning still doesn't work. – junius Oct 3 '16 at 17:06
  • I tidied up most of my comments after writing the answer below. I'm not sure how much help it might be, but it was getting too much for comments. – cfr Oct 4 '16 at 0:49
  • Did you try otftotfm -fkern ...? – Robert Oct 9 '16 at 0:39

otftotfm is stripping out kerning information: there are no kerning pairs in the resulting TFM etc. files. ttf2afm does the same.

This is, I suspect, because the font specifies kerns by classes rather than kerning individual characters. I'm not at all certain of this - it is just a guess.

One way to work around this issue is to open the TTF in FontForge (or similar) and convert the font to type1 format, checking the option to output an AFM. This AFM should include the kerning pairs.

You can then discard the type1 PFB if you prefer to use the TTF, while using the AFM to generate the TFMs, VFs etc.

You will get some complaints from FontForge when generating the type1 font. It will also tell you that the resulting font has errors. The warning about the 256 slot limit can be safely ignored as it will not apply to you anyway. You can probably ignore much of the rest.

Alternatively, you can generate a TTF with an 'old style' kerning table. When generating the font, set the option in the options dialogue. You'll get some warnings again. The resulting TTF (Junicode2.ttf, say) will recover kerning pairs when tools such as ttf2afm are applied so you should be able to use otftotfm with this version.

However, my attempts to use this font were not at all successful and my attempts to use the generated PFB did better, but omitted the kerning again.

Probably down-grading the OS/2 table would do better. If not and if I really needed to use this font - rather than just wanting to - then I would take the PFB and AFM and try using fontinst to generate the TFMs and VF(s) required. This would require being rather careful about glyph names to ensure they matched the .etx file used for encoding. For T1, fontinst provides t1.etx which is not bad but may not fit exactly. Take a look at, for example, source/fonts/cfr-lm for details of how to adapt an ETX file and how to write appropriate input files for fontinst.

[Disclaimer, I wrote or adapted the files in source/fonts/cfr-lm.]

To use the font in TeX, you will need to use a proper TeX encoding which is recognised. T1 would be a good place to start - hence my suggestions above.

If you must declare a local custom encoding, you will have to do it properly. Moreover, it should be named according to the appropriate conventions and certainly should not use the name of the Unencoded or raw encoding used for symbol fonts such a dingbats.

However, before you think about any of that, I recommend trying to get something more basic working since Junicode is not at all a cooperative font, and you might want to consider whether sticking to one of the newer typesetting engines might not be the wisest course. Certainly it is likely to be the path of least resistance.

Note that I have a suspicion that I tried to prepare this font for use with pdfTeX some years ago and think I may have given up. However, I'm not certain of this and, besides, doubtless the font has been modified since then so any such lack of success need not predict failure now. This surely isn't a straightforward font to deal with, though, so I hope that it is not your first such attempt!

[And I doubt I tried down-grading the OS/2 table the way you did, which is probably key.]

On the plus side, at least the licence allows you to edit and modify it freely, which does give you more options in terms of resolving the problems.

| improve this answer | |
  • on the font you said works with ttf2afm, do you get ligatures? I just noticed that Junicode.ttf doesn't get those either when converted. – junius Oct 4 '16 at 0:50
  • @KevinKeith I didn't check. Does that matter? I'm not sure how otftotfm works exactly, but the ligatures in the font are usually irrelevant for these purposes. You can specify whatever ligatures you like. – cfr Oct 4 '16 at 0:55
  • Ah okay. That makes sense. Unfortunately, it looks like this font just isn't going to cooperate. Thanks for the answer in any case. It looks like the best option, should I choose to revisit this down the road, would be to rebuild it for TeX from the ground up, somehow. – junius Oct 4 '16 at 0:58
  • That is, certainly fontinst will ignore what is in the AFM in terms of ligatures. I have not used otftotfm as much, but I think it will ignore the ligatures in the font as well. You specify these in different ways - in the .enc file for otftotfm, if I remember correctly, or in the .etx for fontinst. – cfr Oct 4 '16 at 0:59
  • @KevinKeith However, it may be that otftotfm can take ligatures from the OTF and put them into the .enc since it is designed to convert in that way. Maybe you need to tell it to do that with an option of some kind? – cfr Oct 4 '16 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.