7

Suppose we need to go all the way from METAType1 sources for LM-fonts

http://www.gust.org.pl/projects/e-foundry/latin-modern/download/lm2004mt1.zip

up to these two files: lmr10.pfb and rm-lmr10.tfm

Can anybody give some tips or recommendations for further reading on how to achieve this?

Igor Liferenko
  • 7,063
  • 2
  • 14
  • 47
  • 1
    Ask GUST: http://www.gust.org.pl/projects/e-foundry/latin-modern – egreg Oct 27 '15 at 14:57
  • 3
    They are available from GUST as @egreg observes: see http://www.gust.org.pl/projects/e-foundry/latin-modern/download. That might be an answer: not sure (seems perhaps too obvious). – Joseph Wright Oct 27 '15 at 14:59
  • @JosephWright: I hoped somebody already did something similar and will share a complete step-by-step example how to change the glyph which I specified in the example. I cannot find instructions how to change what I need and recompile from scratch... – Igor Liferenko Oct 28 '15 at 01:04
  • 1
    Al: I don't see that this is OT at all! What's the issue with the question? – Joseph Wright Oct 28 '15 at 07:04
  • The question has changed and now it is interesting. – egreg Oct 28 '15 at 22:01
  • 1
    Maybe this article and this one would be helpful. Note that there is not a 1-1 relationship between .pfb and.tfm files as there is between .pfb and .afm files, for example. – cfr Oct 28 '15 at 22:17
  • @cfr: In the first link it's just common phrases - no specific explanation of the core process of compiling. The most relevant parts from it are: "... METAType1 sources that can be maintained — adjusted, augmented, improved ... it is relatively simple to modify existing sources..." The second link is more interesting... – Igor Liferenko Oct 29 '15 at 00:59
  • 1
    It depends what you know and where you're starting. I don't know what you know or where you're starting, so I posted both ;). – cfr Oct 29 '15 at 01:01
  • 1
    @cfr: In the second document the info seems outdated: it is said about mpe file, but sel file is used now instead. Also, in current sources there is pfcommon.dat, which is not described in the second link. And pfcommon does not occur in any file from the bundle, so it is not clear how it is used... – Igor Liferenko Oct 29 '15 at 01:27
  • I said it might be helpful. I am not sure that you are going to find a step-by-step guide for this. (Unless somebody writes one as an answer.) If you don't find it helpful, I'm afraid I've wasted your time. – cfr Oct 29 '15 at 01:47

1 Answers1

7

Assuming you have the required programs installed (metapost, gawk and t1utils), and regardless of your OS or TeX distro, the following should work:

  1. Dump the contents of the Latin Modern sources and metatype1 in the same directory.

  2. Go to the working directory, start a shell session, and copy the file e-rm.mp into lm-tex.mpe.

  3. Enter an interactive session of metapost: mpost -jobname=lmr10. Once inside, type \relax to enter interactive mode. then issue the statements generating:=0; input lmr10.

  4. That should generate all the glyphs and get you back to the shell. Once there, process the output files (lmr10.*) with the following commands.

gawk -f mp2pf.awk -vCD=pfcommon.dat -vNAME=lmr10 gawk -f packsubr.awk -vVERBOSE=1 -vLEV=5 -vOUP=lmr10.pn lmr10.p t1asm -b lmr10.pn lmr10.pfb

  1. To generate the tfm file, run step (3) with -jobname=rm-lmr10 and generating:=1; instead.

Metatype1 includes the batch files mkfont1.bat, mkt1.bat and mktfm.bat that should do the job on windows; in fact, I got all the instructions from those scripts. You may try to translate the scripts for [b|a]sh.

jarnosc
  • 4,266
  • For the first part of the question it works - pfb file is produced, which is great. But no tfm... – Igor Liferenko Oct 30 '15 at 22:50
  • It is not the same which tftopl rm-lmr10 produces in TeX Live. Notably, the generated tfm is lacking "LIGTABLE"... – Igor Liferenko Oct 30 '15 at 22:59
  • it works now, but with qx- encoding, instead of rm- – Igor Liferenko Oct 30 '15 at 23:05
  • In your command there is missing mpout.afm. Using pltotf rm-mpout gives errors; vptovf rm-mpout.vpl works. Still, the pl file is not the same which tftopl rm-lmr10 produces. How to specify encoding properly in step 3? – Igor Liferenko Oct 31 '15 at 00:31
  • In the sources there is e-rm.sel, so the answer remains incomplete. The ultimate test must be the (almost) zero difference between tftopl rm-lmr10 and tftopl mpout.tfm. – Igor Liferenko Oct 31 '15 at 00:55
  • I found a hint: "...in order to generate a TeX font metrics with a given encoding, the respective encoding file should be placed in the current directory and renamed to lm-tex.mpe; otherwise a default encoding (QX) will be used..." – Igor Liferenko Oct 31 '15 at 01:44
  • Yes, it seems to work. One final problem to resolve: take for example CHARACTER O 375 - in system it has "CHARHT R 0.688875", in generated it has "CHARHT R 0.0". In reality this glyph is "ý", which cannot have zero height. Do you get the same results? – Igor Liferenko Oct 31 '15 at 02:02
  • indeed: there are subtle differences throughout the two files... the heights seem to be systematically wrong... – jarnosc Oct 31 '15 at 02:09
  • I think it's worth to see which slots "misbehave" and try to establish a pattern between them, which may give an idea why they are generated incorrectly... – Igor Liferenko Oct 31 '15 at 02:13
  • But the rm-lmr10.tfm in the distribution does exist, nevertheless. You cannot argue that. – Igor Liferenko Oct 31 '15 at 02:21
  • The rm-lmr10.tfm exists, thus there does exist some sequence of commands which leads to it. This is what the question is all about. – Igor Liferenko Oct 31 '15 at 02:34
  • @erreka: See http://tex.stackexchange.com/help/privileges/chat-rooms – Martin Schröder Oct 31 '15 at 12:35
  • @IgorLiferenko You shouldn't end up needing vptvf because Latin Modern does not use virtual fonts at all. It is all done with .tfm. Also, you cannot, in general, expect a perfect match in the .pl you produce and one you get from running tftopl. If I generate a .pl file and then run pltotf followed by tftopl I will not get back an identical file. That said, the metrics for the glyphs should match, at least to a reasonable approximation. – cfr Nov 08 '15 at 03:11
  • @IgorLiferenko Yes, I know. I just meant that you can't expect the files to be almost identical in any case. Obviously it is wrong if the metrics are giving the height of letters as zero. But even if the metrics were correct, the files might still differ significantly in other ways. That is, that the files differ is not just in itself evidence of a bug. In this case, it is the nature of the differences which constitutes evidence of the bug i.e. you have to look at the content of the differences. – cfr Nov 08 '15 at 18:56
  • @cfr: It is not clear what you mean - please explain with an example. – Igor Liferenko Nov 09 '15 at 00:36
  • @cfr if you compile, say, cmr10 from sources with metafont, you expect to get the same tfm consistently; we found that modern metapost not only does not produce the same tfm for lmr10, but it also fails to produce the tfm correctly. – jarnosc Nov 09 '15 at 01:57
  • @erreka Yes. But the process of going from .pl to .tfm and back to .pl does not necessarily take you back to an identical file. Of course, the metrics should not differ in any significant way. But that does not guarantee an identical .pl. .pl files can differ in other ways. Depending on how the .pl file is produced, it may contain information which will be stripped by the conversion process. In that case, that information is lost. Converting the .tfm back to .pl will not restore it and the file will not be the one you started with. – cfr Nov 09 '15 at 02:08
  • @erreka The files will not be the same. At least theoretically, the code should be effectively the same. But PL -> TFM -> PL will not necessarily get you a file much like the one you started with. (If you diff, for example.) This is expected: pltotf strips elements which make the .pl more readable for human beings but which TeX doesn't need. At least, this is how it has always worked for me. – cfr Nov 09 '15 at 23:29
  • @cfr: Committed revision 2073. – Igor Liferenko Nov 11 '15 at 00:42
  • Is there a way to regenerate the otf files for Latin Modern? I would like to generate blacker versions so that the prints look better on paper. MathJax does exactly that, through the use of FontForge, however, in MathJax the Latin Modern otf is chopped into many pieces, which is not what I am after, and I cannot really understand how to generate a single file from the scripts at https://github.com/mathjax/MathJax-dev/tree/master/fonts/OTF/TeX ---any comments, tips would be greatly appreciated. – Ekin Apr 16 '18 at 01:04
  • @Ekin: that's a different question. You should open a new question separately. I think you could adjust the thickness directly on the MetaPost sources, without going through FontForge, but I don't know if that's what you want. – jarnosc Apr 25 '18 at 17:39
  • @erreka I just opened a new question where I provide more information on what I would like to do: How to compile thicker OTF version of Latin Modern fonts? – Ekin Nov 18 '18 at 17:32