By now it's a familiar pattern: Camera makers release new models that can shoot photos in the high-quality but labor-intensive raw image format, and Adobe Systems periodically catches up with a release to support those proprietary formats.

So it's no surprise to owners of Olympus' E-P3, E-PL3, Panasonic's G3 and GF3, and Sony's Alpha NEX-C3 and SLT-A35 that the release candidate for Lightroom 3.5 adds support for their cameras. The closely related Photoshop Camera Raw plug-in 6.5 release candidate, also issued, follows suit; usually it's a few weeks before the test versions are replaced by final versions.

But the vastly larger number of existing Lightroom customers who have older cameras should pay attention to this release, too, because it attempts to fix a lot of bugs. Tom Hogarty, Lightroom's product manager, details them on his blog about Lightroom 3.5 and Camera Raw 6.5 today, but here are some that I found notable:

• Using the arrow keys to modify image adjustment settings lacked responsiveness

• Lightroom 3.2 introduced preview cache inefficiencies.

• Develop load time performance was inconsistent.

• GPS Altitude metadata was incorrectly excluded from files converted to DNG or exported as DNG files from Lightroom 3.4.1.

Another reason existing users might be interested: the new software can automatically correct some optical defects with lenses from Canon, Nikon, Sony, Hasselblad, Sigma, and Tamron.

Another close relative to the software is the DNG converter, which changes raw files into the Digital Negative format that Adobe is trying to standardize. DNG Converter 6.5, which uses the same raw conversion engine, no longer works on PowerPC-based Macs.

Hogarty's blog lists all the lenses, but here's the list of supported cameras for the Lightroom and Camera Raw release candidates, according to Adobe:

• Fuji FinePix F600EXR

• Olympus E-P3

• Olympus E-PL3

• Olympus E-PM1

• Panasonic DMC-G3

• Panasonic DMC-GF3

• Phase One IQ140

• Phase One IQ160

• Phase One P40+

• Phase One P65+

• Sony Alpha NEX-C3

• Sony SLT-A35

Hasselblad "FFF" files created by the Hasselblad Phocus software for currently supported models are also now supported. (FFF files created using the FlexColor software are not supported)

Originally posted at Deep Tech

Here's the problem with AirPrint: not nearly enough printers support it. Plus, there's that whole consumables thing. Aren't we supposed to be living in a paperless society?

Print to PDF for iOS solves both problems, allowing you to "print" e-mails, Web pages, and documents as PDFs right on your iDevice. It's a clever app, one that works much like PrimoPDF and other utilities for Windows.

In other words, it intercepts just about anything that uses the iOS print command and generates a PDF instead of a piece of paper.

All you do is run Print to PDF, then switch to any other app that supports printing. Tap the Print command, choose Print to PDF as your printer (a one-time task), and then tap Print again. The process may take a few seconds, depending on the length of the item. When it's done, you'll have the option of instantly switching to the app to view your new PDF.

Print to PDF cleverly organizes output into saved e-mails, saved Web pages, and "other" prints (i.e. stuff that comes from other apps, like, say, Documents To Go). If you need deeper organization, the app lets you add your own subfolders within these sections.

When viewing a PDF, you can switch to a text-only view, send it via e-mail, or open it in your preferred PDF viewer. (Hello, iBooks!)

The app automatically closes itself after a few minutes, so you do need to run it before pretty much every print job--a minor hassle.

In my tests, Web pages and e-mails converted to PDFs turned out beautifully. This is a great way to save items for later viewing or share them with others. Also, the app supports printing from one iDevice to another (via Wi-Fi), so you could print, say, an e-mail on your iPhone and view it on your iPad. I'm not sure how useful that is, but it's pretty cool.

Print to PDF costs $3.99 and works with most iDevices, not including the iPhone 3G and first/second-gen iPod Touch. I think business users in particular will find it a killer tool.

Originally posted at iPhone Atlas

Android's unbranded browser is coming back into the WebKit fold.

The software--called simply "Browser" on Android phones and tablets--is based on the open-source browser engine called WebKit. It's long been disassociated from it, though, and now Google is trying to reunite the projects in a move that could portend the arrival of a branded Chrome on Android.

"We're looking forward to a much better collaboration with the WebKit community," Google's Andrei Popescu said yesterday in a mailing list message flagged by new Chrome developer Peter Beverloo and spotted by TechCrunch.

Convergence between the Android browser and Chrome seems inevitable. Tablets bring a more PC-like experience to browsing, and Google is of course keen on tablets with the arrival of version 3 of Android, aka Honeycomb. Google TV, also based on Android, has a browser that sports the Chrome brand. But what's been keeping them apart?

At the Google I/O show in May, Chrome Senior Vice President Sundar Pichai said it's because, although the browsers share some common code, the Android browser is "not based on Chromium," the open-source version of Chrome. The implication was that the Chrome brand name carries a certain promise of Web page compatibility that the Android browser couldn't necessarily fulfill.

By merging with the WebKit project, though, that barrier will be overcome. "We're fully committed to maintaining this new flavor of the Chromium port of WebKit," Popescu said in the message.

And when Beverloo filed a WebKit but to track the project, he said, "The Android Browser has come to a point where it shares enough code with Chrome to entirely reuse the Chromium port of WebKit."

The change is good news, according to Dion Almaer, a browser and Web development expert who mentioned the move on the Function Source blog today.

"Having watched my team deal with painful Android WebKit bugs for the last few weeks, I am very glad to read more news that the Android WebKit is getting Chrome-ier," Almaer said. "When you go deep on making a rich Web application work there, you find sharp corners all over the shop."

In other words, he expects some of the compatibility issues separating Chrome and the Android browser to diminish.

Google wouldn't comment on its branding plans for the browser. In a statement today, the company said:

The Android Browser and Chrome already share a lot of code, such as the same WebKit rendering engine, V8 JavaScript engine, and HTTP [Hypertext Transfer Protocol] stack. We expect them to continue to share more code over time and have actually started harmonizing our efforts so that Google will have just one port of WebKit to maintain. Beyond that, we have nothing further to share at this time.

It seems to me the Ice Cream Sandwich version of Android, due later this year, would be a great time to make the branding change. This version of the mobile operating system is designed to bridge the current divide between Android 2.x for phones and Android 3.x for tablets and to make it easier for Android app programmers to support multiple devices.

But re-integrating the Android browser with WebKit will take time--and it requires more than just Google's Chrome programmers working with Google's Android browser programmers. WebKit began as an Apple project spawned from the earlier KHTML browser engine used in the KDE interface for Linux, so other developers are involved.

One potential benefit to Google's move is a more mature mobile browser for others. Safari on iOS uses WebKit, and so do browsers for new BlackBerry phones, Samsung Bada phones, Hewlett-Packard's ill-fated WebOS, and more. Open-source software makes sharing software easier, and Google's goals with browsers are not so much to profit directly from its own product as to improve browsing in general so the Web becomes more powerful.

Google sometimes keeps variations of open-source projects in-house. The Linux kernel used in Android, for example, is fairly detached from the mainstream Linux kernel project maintained by Linus Torvalds. That doesn't violate any laws and gives Google the ability to control its own destiny a bit better, but as a practical matter, the open-source philosophy works better when projects aren't fragmented and out of sync.

It's a two-way road, too: Google should have an easier time incorporating others' changes into the Android browser. If Apple comes up with a clever CSS feature, for example, it'll be less effort for Google to incorporate it.

Thus, overall, Google's WebKit move with its Android browser seems helpful for Web developers, browser makers, and Android users. And one last point: there's no doubt that Google, which is sensitive to branding issues, would love to see that Chrome icon publicized on millions of smartphones.

Originally posted at Deep Tech