Re: Curse you, PDF!
Re: Curse you, PDF!
- Subject: Re: Curse you, PDF!
- From: Greg Titus <email@hidden>
- Date: Tue, 12 Jun 2001 17:42:27 -0700
On Tuesday, June 12, 2001, at 03:32 PM, email@hidden wrote:
>
When I'd first heard we were going to have some kind of PDF technology
>
underlying the graphics in OSX, I asked around and generally heard
>
that this meant any app would be able to read, write, and edit PDF
>
files. That's really great, I thought, because it truly would be a big
>
step towards a paperless office.
Hiya Chilton,
Any app can read, write, but not really directly edit PDF. I guess it
depends on how you define "directly" or "edit", since the whole display
architecture of Quartz is built around the same assumptions as PDF. I
guess you could say that writing an app to edit PDF should be much
easier with OS X than with any previous OS.
>
But now that OSX is here, I see a distinct lack of support for PDF.
>
I'd heard one Mac author say that any web page could be instantly
>
converted into a pdf, but I can't find a browser that does this. Am I
>
missing something?
Print preview? It's also really simple to write the code to do 'Export
To' as PDF, no matter what app you are writing, but I admit that we
haven't added that for OmniWeb since you can do it via print preview and
our menus are pretty crowded already.
>
Are there apps out there that let me edit PDF
>
documents easily and intuitively, with the exception of Acrobat?
Nope. (At least, not that I know of.)
>
Can an app I write instantly gain the ability to edit a PDF document
>
via some Cocoa library? If so, that's great, and where is the API? If
>
not, can someone please explain the benefit of having PDF underlying
>
the graphic display in OSX?
You can write an app that instantly gains the ability to display a PDF:
look at NSPDFImageRep.
But the major benefit of having PDF underlying the graphic display in OS
X comes when you write your printing code. Almost every app needs to be
able to print. Almost no extra code needs to be written in Cocoa in
order to do so. Absolutely no new code needs to be done to then print to
PDF. Because the assumptions of the display system are the same as the
assumptions behind PDF, there will almost never be any issue of things
showing up differently on a printer than they did on screen. The
assumptions are the same, and the code is the same - you just reuse
exactly the same code as you drew your app with in the first place.
The only possible issues are in places where there need to be
differences because of the different mediums, like with pagination. Even
things like pagination can be handled automatically be Cocoa, unless you
want to take control and do something more complicated.
For instance, the first version of OmniOutliner (the app I'm working on
at the moment) had zero lines of code for printing. And yet, you could
print just fine, you could save as PDF, and what appeared on the printed
page was _exactly_ what was on the screen, automatically paginated and
laid out with appropriate margins on the printed page.
Too exactly as the screen, it turned out. So the latest version has
about 40 lines of code related to printing. It resizes the view to fit
the page instead of being exactly the size it was on screen. It doesn't
print things like the highlight for the current selection. And so on -
things where you actually _want_ the print job to look different than
how the document appeared on screen.
So Cocoa does provide quite a bit less than you were hoping for. There
isn't a set of objects that describe a PDF document and let you modify
pieces in easy ways. You can't write a PDF editor in 10 minutes. You
can, though, add world-class WYSIWYG printing support to your
application in about that long.
Hope this helps,
--Greg