Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.
Fixing Save as Adobe PDF Crashes
There have been many reported instances of the "Save as Adobe PDF" workflow crashing regardless of application, but precious few workarounds or resolutions. In troubleshooting, I discovered that there were three instances of the "Save as Adobe PDF.action" in three different locations: /Library/Automator; ~/Library/Automator; and /System/Library/Automator. By eliminating all except the version in /System/Library/Automator, the workflow started behaving, and I was able to cut PDFs directly from the Print dialog.
Submitted by
John Zielinski
Recent TidBITS Talk Discussions
- Alternatives to MobileMe for syncing calendars between iPad/Mac (1 message)
- Free anti-virus for the Mac (20 messages)
- iTunes 10 syncing iPod Touch 4.1 (2 messages)
- Thoughts about Ping (16 messages)
Acrobatic Dead Horses
Acrobatic Dead Horses -- Michael J. Tardiff <mjt@westernstar.com> writes with one final comment about Acrobat:
Ray Davis's comments in NetBITS-016 brought to mind my past experiences in dealing with the "structure vs. presentation" issue. Back at the turn of the decade, I led a team developing what was then called an "online documentation tool." The goal was to put the truckloads of software documentation my company produced onto CD-ROMs and read it using clients that looked a lot like today's browsers. In fact, the documents were coded using a subset of the then still-developing SGML standard. And our goal was to code for content, so as to be able to display on different screens, or even different media (we had a version of the reader that'd read the books out loud to the sight-impaired).
But it wasn't long before technical writers started using tags to "fake out" the reader so that their book would "look right" online. I had an opportunity to raise the content-versus-presentation conundrum once with John Warnock, founder of Adobe, when we were looking at a preliminary version of what came to be Acrobat. John answered without hesitation, "Content is all well and good, but everyone we talk to wants their stuff to look the same onscreen as it does on paper." And that's exactly what Acrobat did.
Recently, I had an opportunity to work for a year with a bunch of traditional advertising and marketing folks. They had clients who wanted to move into Web-based marketing, and I was to help the agency understand what was different and special about the Web. Again, I stressed content and flexibility, and the Web's ability to reach a huge range of platforms with well-coded content. Yet every client was most concerned about their online stuff looking just so, and both they and our designers were frustrated at not being able to place items in exactly the spot they wanted.
Given that paper has been the medium that's been used since the Middle Ages for presenting information, plus television's consistent standards (every screen in a 4:3 ratio, with very similar capabilities, at least in the U.S.), I think it's going to take a lot more than an abstract argument that it's the "right" thing to code for content to enable an infinite range of display possibilities. Instead of efforts to move Web authoring in that direction, we see style sheets and absolute placement. Even WebTV doesn't encourage coding for content, but coding for their version of a "page."
Theory's a great thing, but it's safer to bet one's money on what the people want, and people want what they've known since they became sentient - control and conformity in presentation. Otherwise, wouldn't the saying be, "The man makes the clothes" instead of the other way around?
Still, it was nice to see my favorite dead horse beaten a few more times.
![](/file/11593/db.tidbits.com.tar/db.tidbits.com/images/badges/StuffItDeluxe2010.gif)
share, and compress all of your photos, audio and documents.
Compress it. Secure it. Send it. Try StuffIt Deluxe 2011 today!
Click here for a free 30-day trial: <http://stuffIt.com/tidbits/>