#97 loading .otf through font map lines

[karl berry]

Consider this input file, call it tryot.tex, loading GFSBodoniBoldIt.otf through a map line:

\special{pdf:mapline md-grbbi7m GFSBodoni-BoldItalic
" AutoEnc_rl4tn2dr7yl7pvjznhtbna64dc ReEncodeFont "
<[a_rl4tn2.enc <GFSBodoniBoldIt.otf}
\font\test = md-grbbi7m
\test K
\nopagenumbers \end

Running xetex --no-pdf tryot.tex is fine; then
xdvipdfmx tryot.xdv
results in
xdvipdfmx:fatal: Not a CFF/OpenType font?

Using --kpathsea-debug -1 shows that the .otf file is being found; the immediately preceding line of debug output is:
kdebug:fopen(/home/texlive/karl/Master/texmf-dist/fonts/opentype/public/gfsbodoni/GFSBodoniBoldIt.otf, rb) => 0x9909ed0

However, the problem does not seem to be with the font, but rather somewhere else in the mapping mechanism, because the usual xetex syntax to access the otf directly works:

\font\test = "[GFSBodoniBoldIt.otf]"

then xdvipdfmx succeeds. The kpathsea-debug output in this case does not seem useful. At least it looks completely incoherent to me.

Any chance?

Thanks,
K

[karl berry]

hmm, after more investigation ... perhaps this is a compilation problem, where type1c.c is only being compiled once. more tomorrow.

[karl berry]

well, it is true that type1c.c was only being compiled once (without XETEX #defined) and then used for both dvipdfmx and xdvipdfmx. That seemed like a mistake to me, although I am rather surprised that anything worked, so I'm a bit puzzled about it.

In any case, after fixing the Makefile[.am] to get separate type1c.o's for dvipdfmx and x*x, the original problem remains -- GFSBodoniBoldIt.otf can't be loaded from a map line, but can from a \font. (Ulrike claims that this is so for all .otf's and .ttf's, which seems probable; I haven't investigated.)

Running under the debugger, the proximate cause is that the "font" structure has a NULL ft_face member; hence sfnt_open() returns immediately, hence pdf_font_open_type1c fails.

Why ft_face is null in the map case and not the \font case, I did not look into, since this whole bug only affects the mathdesign map entries for the gfs fonts which should be using the pfb's anyway, as far as i can see. but still, it does seem like a bug, so leaving it open for you to consider ...

(dvipdfmx works, by the way; this is specific to xdvipdfmx.)

[karl berry]

p.s. there is a long and rather frustrating thread, conflating a variety of issues, about this:
http://tug.org/pipermail/tex-live/2014-July/035749.html

Ulrike does say that her observation is that the problem is related to the encoding specification in the map line.

[Khaled Hosny]

This is because fonts loaded from map file don’t have an associated ft_face (only fonts loaded from XDV_NATIVE_FONT_DEF has one) and xdvipdfmx’s sfnt_open() operates on the ft_face and thus it fails.

I think most of the differences between dvipdfmx and xdvipdfmx in font loading can be eliminated now (they were probably relevant when xdvipdfmx supported loading fonts by file name, but this is gone for a while now). I’m working on that.

[karl berry]

with the recent changes (through r34738) i get a crash on the .xdv from the above .tex (attached), on 32-bit i386-linux (centos 5) compiled with gcc 4.8.2 (= tug.org).

glibc detected xdvipdfmx: free(): invalid pointer: 0x08c8fe50 ***

running under the gdb, the crash happens at the RELEASE(mrec); line 1844 of spc_pdfm.c. i'll attach the .xdv (do i need to remake with a new xetex? i didn't think so ...). sorry, can't debug further now (will be offline all next week, back aug 3).

[Khaled Hosny]

I don’t get crash but I get invalid memory access in valgrind. As it turns out some files need to be compiled with -DXETEX even if they don't check for such define, as they include other headers that does and we end up with different struct sizes. Now I wonder if the whole libutil.a idea is worth it...