[Mac OS X TeX] Print and crash problems

[Gerben Wierda]

<x-flowed>On Wednesday, October 17, 2001, at 06:22 , Alessandro Languasco wrote:

> But I have two questions for the TeXShop-tetex developers:

Dick is swamped with real work at the moment, so I'll answer these.

> 1) why don't you  add the possibility to choose a previewer different
> from the apple one?

TeXShop does not use a previewer, it *is* a previewer (in combination 
with code to run tex and friends). TeXShop for instance does not use 
Apple's Preview.app.

What is the case is that *all* Apple Cocoa apps share the code for PDF 
display, this is because it is a nice OO system. That means that 
applications like Mail.app, Create.app, etc. all use the same basic 
mechanism which is somewhere in a 'Framework' in the system. This is 
also a very simple mechanism, because it just sends the PDF on to the 
display environment which does the actual PDF rendering into pixels. 
This is also where Apple puts its effort to make stuff look right. Ever 
wonder why Omniweb looks so much better than IE? That is because OW uses 
those new display mechanisms with all the latest developments in display 
algorithms (font smoothing for example) that are not available in IE, 
which uses statically linked older QuickDraw code afaik).

Simply said: Applications like IE and Acrobatr create their own bitmaps 
and then pack them in very simple PDF and send that to the display 
environment. There the PDF is unpacked to the bitmap that is displayed.

(Sharing this framework code has big advantages amongst others, the 
option to dynamically alter the behaviour of all apps without 
recompiling them. On NEXTSTEP, there was only support for TIFF and EPS 
in the TextView class, but someone wrote a filter that translated all 
formats to tiff in the background. As a result, all applications that 
use TextView suddenly can display JPG, BMP etc, but the applications 
themselves have not changed. The framework in the background has. In 
other words, NeXT never created a Mail.app on NEXTSTEP that can display 
inline JPEG images, but my Mail.app on NEXTSTEP can display them anyway.)

> I don't know if it's an hard thing to do, but since there's a bug in 
> the apple machinery...

Well, it can be done of course. One could, instead of creating a PDF 
display window, open another application and tell it to open the pdf 
file just created. There are drawbacks. For instance, as soon as you go 
to your display window, your menu changes to that application, two 
applications, remember? TeXShop would than only be a frontend to running 
the TeX compile commands.

Actually if you're not afraid of the command line, you can do that. Use 
your favourite command line editor, make Acrobat your default PDF viewer 
and run pdflatex or altpdflatex by hand. Then, when the pdf file has 
been created, run 'open pdf-file'.

> 2) the .pdf generation you use is quite different from the one used
> by macps2pdf. The dimension of the files is very different (8KB with
> macps2pdf against 52KB with the translation used in texshop-tetex)
> and also the displaying speed  is very different (in Acrobat reader; 
> using
> preview the os 10.1 always crashes). why?

TeXShop is a front end, you must remember that. It is entirely not to 
blame for whatever output is generated. It just runs a command in the 
background (either pdflatex or altpdflatex). Pdflatex immediately 
compiles your tex code into pdf code. Altpdflatex first creates 
DVI-ouput, then uses dvips to compile that into PostScript and finally 
uses ghostscript 6.01 (an older version) to produce PDF from PS. The 
older version is used because there is *another* bug in Apple's PDF 
display that gives problems with displaying certain types of PDF files 
with multiple types of fonts.

The later route is only there for older projects which include eps files 
(which pdflatex cannot handle by itself).

Sizes of PDF files which look the same may vary. The code inside may be 
compressed in a binary format. There may or may not be fonts in it, etc.

> It's a very strange thing, isn't it ?

No. It is rather simple.

Acrobat doesn't have these display problems because it does not use the 
Mac OS X builtin shared Cocoa machinery, but it has its own. It just 
sends bitmaps to the display. Apple's Cocoa PDF framework send PDF to 
the display where it is rendered by the display server (Window Server). 
This Window Server has the bug (as it is the one that crashes) which is 
triggered by PDF sent to it by the Cocoa PDF image class.

Since this is a nasty bug (or bugs) in the *heart* of Apple Mac OS X's 
display system we can hope that they will fix it fast. On the other 
hand, the fact that the previous bug (not so nasty) was not fixed and 
that the new bug appeared shakes my confidence in the quality of the 
code of Mac OS X's display environment. That stuff should be written 
such that it cannot crash.

A listing of processes reveals:

[dumbledore:local/src/INSTALL.TeX.macosx] root# ps axww
   PID  TT  STAT      TIME COMMAND
     1  ??  SLs    0:00.02 /sbin/init
     2  ??  SL     0:02.36 /sbin/mach_init
    41  ??  Ss     0:01.11 kextd
    65  ??  Ss     0:02.45 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/
ATS.framework/Versions/A/Support/ATSServer
    67  ??  Ss     3:51.39 /System/Library/CoreServices/WindowServer

That last one probably is the process which has problems.

Gerben


-----------------------------------------------------------------
To UNSUBSCRIBE, send email to <info at email.esm.psu.edu> with
"unsubscribe macosx-tex" (no quotes) in the body.
For additional HELP, send email to <info at email.esm.psu.edu> with
"help" (no quotes) in the body.
This list is not moderated, and I am not responsible for
messages posted by third parties.
-----------------------------------------------------------------

</x-flowed>