On Feb 19, 2010, at 22:24, Philippe Sismondi wrote: > > On 2010-02-19, at 11:29 AM, t wrote: > >> On Fri, Feb 19, 2010 at 3:44 PM, Christiaan Hofman <[email protected]> >> wrote: >>> >>> On Feb 19, 2010, at 15:28, Marc H. Scholl wrote: >>> >>>> >>>> On 19.02.2010, at 14:37h, t wrote (with possible deletions): >>>> >>>>> [...] >>>> >>>>> Yes- I suspect it wont do any good either. You might be better filing >>>>> a bug report against emacs- I would guess the issue is something to do >>>>> with fonts where the apple system is a bit different to ghostscript- >>>>> perhaps the emacs guys can easily fix it to work on osx? >>>>> >>>>> regards >>>> >>>> >>>> ... actually a very good comment, especially, since the original post was >>>> talking about *Aquamacs*, a Mac-only version of emacs. It should be a >>>> peace of cake for them to make the ps-print suitable for preview/skim. >>>> >>>> --Marc >>> >>> Aquamacs already does this. In fact, it does not expose the PS print >>> functions, but instead a print function that sends PDF for printing to >>> Preview. >>> >>> BTW, I cannot reproduce it. When I try something like ps-spool-buffer, I >>> have no problems with the generated PS. But perhaps when you're using >>> non-standard fonts, I can imagine that this indeed is a problem. When fonts >>> are not included in the PS (and it seems that the ps-print-... and >>> ps-spool-... functions indeed don't include them), then the PS is not >>> guaranteed to be readable, and I can imagine that Apple's CoreGraphics >>> conversion API (which is what Skim and almost certainly Preview and the >>> pstopdf CLT use) cannot find some non-standard fonts. I don't think that >>> would qualify of a bug of either tools, but I would rather blame the PS >>> generator than Apple. I don't know if fonts is the problem, but I cannot >>> imagine it's in the PS that's used itself, because the PS syntax is pretty >>> much fixed (unlike PDF, which keeps being messed with by Adobe, and is much >>> more messy than PS as a result). >>> >>> Christiaan >>> >>> >> >> I can reproduce the problem here (osx 10.6) using whatever the default >> font settings are (since I haven't changed them)- if I use >> emacs/aquamacs ps-spool-* functions and apple's pstopdf then I get a >> pdf with no (visible) text. Its not clear (to me) who's at fault- but >> the likelihood of apple patching their pstopdf is v.v.small- besides >> there are lots of tools which do the same job (like enscript) and work >> perfectly well on osx- so your best bet is to ask the emacs guys to >> fix their psprint code to work with osx. >> >> By the way, Aquamacs has another way to print 'M-x aquamacs-print' >> which uses another method and brings up the apple print dialog so you >> can 'Save to PDF'. Use this, or ghostscript to produce your pdf's if >> the other ways don't work. >> >> regards, >> > > > Perhaps I should explain what I set out to do. > > I still occasionally print out source code. I know this identifies me as an > old timer, since hardly any of the programmers I know ever look at hardcopy. > However, on rare occasion I still do so. > > And, I liked the headers/footers that the emacs ps-* stuff did. The aquamacs > print does not provide such a thing, as far as I know. > > Thus, I tried ps-* + Skim. (I really like Skim and always use it to look at > pdf in preference to Preview. I always use it with TeX.) > > This morning I set out to do a standalone program that uses Apple's > CGPSConverter calls to see whether the callbacks would report any problems > with postscript created by aquamacs. So far I have not succeeded; I have not > done any objc or c programming in many moons and seem to have lost the knack. > It may not report anything interesting anyway. I'll plug away and see if I > can get it to work. >
I don't get any messages from CGPSConverter when converting PS with this problem, so there's no need fpr you to test that. > I appreciate that there are other ways to skin this cat, e.g. with > ghostscript. enscript also can add those headers. I don't know too much about emacs, but there is an enscript.el package that probably does that. > However, I think there is something fundamentally interesting here, for me at > least. As I said in an earlier post on this thread, if Apple s/w is broken, > that's interesting. If aquamacs/emacs is producing bad postscript, that's > interesting too, although not to the Skim crowd probably. I already explained that. If the problem is really the non-embedded font, than neither is buggy. It's more a compatibility problem. Rather I should say that both are imperfect. The problem I think is that emacs does not include the fonts in the PS file, while Apple's CoreGraphics does not handle PS without embedded fonts (at least not always). Both could be improved, but neither is wrong. > > More important, from a Skim point of view, is it ok that the Apple's > postscript conversion api/utility *silently* produces a file with no text? If > the postscript is bad, should there not be some error reporting of this? > > - Phil - I agree that this is not nice, but the problem is also that CGPSConverter does not really have a good way to report errors. Christiaan Christiaan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Skim-app-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/skim-app-users
