Feed fontdimen parameters to TeX

Question

I have decided to use \fontdimen parameters as an array of numbers (to store data about Unicode Character Properties). The question now is to fill in those \fontdimen parameters in the most efficient way. I would much prefer methods that work for pdfTeX, XeTeX and LuaTeX.

The most efficient way is to load a tfm file unicodedata.tfm defining a font with many \fontdimen parameters. The tfm file format begins with two bytes declaring its size in words (= 32 bits) as a signed integer (see texdoc tftopl or an old TUGBoat paper), so the maximum number of \fontdimen parameters declared through a tfm file is 32738 (slightly less than 2^15 because of some header information). I need around 2^17.

Maybe there exists a file format other than tfm to provide font metric to TeX?

The other approach, much slower, is to do it inside TeX: something like

\font\foo=cmr10 at 1sp
\fontdimen 1\foo = 13459847sp
\fontdimen 2\foo = 14839847sp
% ...
\fontdimen 1114111\foo = 10872349sp

This is (presumably) slower because TeX has to parse each of these dimensions, and each entry takes around 10 characters in a file. Space-wise, this can be improved and reduced to 4 bytes per entry, but that then requires even more work from TeX to decode.

Is there \fontdimen0? I don't think so. However, I think that the answer to your question is no. Split the information across eight TFM files to overcome the limitation. — egreg, Jun 11 '15 at 18:03
@egreg -- correct, no \fontdimen0. from appendix g, p.441: ",,, at least 22 \fontdimen parameters. For brevity we shall call these parameters \sigma_1 to \sigma_{22} ..." — barbara beeton, Jun 11 '15 at 19:45
The TeXbook, page 277: When a \fontdimen value is assigned, the <number> must be positive and not greater than the number of parameters in the font’s metric information file, unless that font information has just been loaded into TeX’s memory — egreg, Jun 11 '15 at 20:07
@JosephWright Providing access to Unicode Character Properties in a cheap way, for use in regexps, for the collation algorithm, to get the correct choice of medial/final sigma when lowercasing, etc. Basically, \fontdimen <char-num>\unidatafont gives a 25 bit integer (maximum providable through a tfm), where I can hopefully compress all Character Properties of that character. — Bruno Le Floch, Jun 11 '15 at 20:34
You know that we have LuaTeX since 2007, which offers real data structures with Lua? :-) — Martin Schröder, Jun 16 '15 at 21:17
@MartinSchröder Of course, but users are still using pdfTeX for good reasons (stability) and less good reasons (habit), or XeTeX for fonts. — Bruno Le Floch, Jun 17 '15 at 19:30

score 1 · Accepted Answer · answered Jul 14 '17 at 11:34

If this is something that you want loaded into memory every time someone compiles a document, then I think what you want to do is to load the font before dumping the format. As you know, the TFM limitation on the number of \fontdimen parameters is purely a file format limitation.

Here's my special format.

\font\unicodedata=cmtt6 at 1sp
\count0=0
\loop\ifnum\count0<"20000
    \advance\count0 by1
    \fontdimen\count0 \unicodedata=\count0 sp\relax
\repeat
\dump
\end

I can run¹ pdftex -ini '&plain' special and it'll dump a special.fmt with the \unicodedata font metrics loaded. The output will contain the line

\font\unicodedata=cmtt6 at 0.00002pt

Now, in testspecial.tex, I have

\def\X#1{%
    \message{^^JUnicode data #1=\number\fontdimen#1\unicodedata}%
}

\X{42}
\X{65536}
\X{"20000}
\end

Running pdftex '&special' testspecial produces²

(./testspecial.tex
Unicode data 42=42
Unicode data 65536=65536

Unicode data "20000=131072 )

¹ I'm not sure why running pdftex -ini '&plain' special fails to find plain.fmt. I'm pretty sure I've used this successfully in the past. TeX by Topic says to use initex, but that also fails to find plain.fmt and then tries initex.fmt which also fails.

² I'm also unsure what caused the extra line break in the output of testspecial.tex.

Thanks! I had no issues reproducing your answer and it's a good plan, although for now I might just use a bunch of separate TFM's. About the linebreak: since plain has no new line char setup, ^^J is just a normal char and TeX simply decides to break the line before your last \message because from its point of view the line is getting pretty long by then; of course the terminal displayed ^^J as a line-break so the result looks odd. — Bruno Le Floch, Jul 17 '17 at 23:27

Feed fontdimen parameters to TeX

1 Answers1