[Mac OS X TeX] Print and crash problems
sherlock at rna.nl
Wed Oct 17 22:25:58 CEST 2001
<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
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;
> 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
67 ?? Ss 3:51.39 /System/Library/CoreServices/WindowServer
That last one probably is the process which has problems.
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.
More information about the macostex-archives