[OS X TeX] Mysterious behavior of Preview.app

Bruno Voisin bvoisin at mac.com
Thu May 15 05:35:26 EDT 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  
directory becomes


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 MacOSX-TeX mailing list