[OS X TeX] Mysterious behavior of Preview.app
bvoisin at mac.com
Thu May 15 11:35:26 CEST 2008
Le 15 mai 08 à 11:12, Bruno Voisin a écrit :
> Le 15 mai 08 à 10:44, Jin-Hwan Cho a écrit :
>> Actually I'd like to know why Preview.app does not show nfssfont-
>> new-w-cidmap.pdf correctly
>> but Adobe Reader do show correctly.
> I would think one of the many bugs of PDFKit, the Cocoa framework
> (if that is indeed the correct term) used to display PDF files on OS
> X (by Preview, Mail, Safari, TeXShop, Finder, etc.) except by Adobe
> applications (which include their own PDF rendering routines).
A silly idea, but who knows: cid-x.map uses the ":" character, namely
pplr8r 8r :0:Palatino
possibly for path specification (I don't know what the above syntax
means, I imagined :0:Palatino meant "Palatino font in suitcase format
in the current directory").
But path specification changed in Mac OS with OS X. In OS 9 and
before, the path separator was ":" with an initial ":" for the current
directory, so that for example file Palatino in Fonts subdirectory of
the current directory was
In OS X, the path separator is "/" with no initial "/" for the current
directory, so that file Palatino in Font subdirectory of the current
OS X normally includes facilities for understanding both syntax and
translating automatically one into the other. For example if you
include "/" in a filename in the Finder, it will appear as / in Finder
but Terminal will revealed it's stored as ":". And Finder will refuse
to include ":" in a filename.
But it's possible that PDFKit has trouble with this somewhere, and is
misinterpreting :0:Palatino (assuming that string is stored somewhere
in the PDF output of dvipdfmx, which is a wild guess).
More information about the macostex-archives