A New Web Browser Joins the Party – Google Chrome
On Monday September 1, 2008 Google announced a new web browser to customers. Google Chrome as it is called was released in beta. Read more about Chrome and PDFs in Chrome after the break…
Google produced a comic-strip technical document for customers to read over. With the power of Acrobat.com’s Create PDF and Adobe Acrobat’s Web Capture tool you can create a PDF version of the document to read off-line. Notable is that they hired Scott McCloud to produce the cartoon document.
Acrobat Product Management is pretty excited to see a new web browser enter the space. It seems it was just yesterday that IE was 98% of the market. Now Firefox has made significant gains on Windows and Macintosh. Safari still retains its Mac dominance. The buzz around Google Chrome is pretty big, it already has it’s own Wikipedia entry.
Supporting New Web Browsers
When a new web browser (or browser version) is introduced, the philosophy the team takes is a multi-approach. Let me try to explain.
- The team assesses the market share, or trending market share of the browser. Is it on the rise? How quickly? Are our customers requesting support?
- Is supporting the browser on Mac/Win (and Linux for Reader) justified based on #1?
- Does work on an existing supported browser help us support the new browser. An example is how traditionally supporting Netscape allowed us to quickly support Firefox on Windows early on.
- What are the specific features of the browser that we would have to support?
- Finally schedule and Eng/QE cost concerns will come into consideration.
PDF and Google Chrome
I started viewing PDF files with Adobe Acrobat 9 Pro Extended installed. Viewing PDF files generally worked right from the start. Performance ranged from good to bad during a series of tests, nothing unexpected for beta software.
It would seem that Google Chrome is either not supporting or not allowing a PDF’s "Fast Web View" setting, which in turn helps byteserve a PDF File. Byteserving allows the customer to hit page one of a PDF file and then jump to other pages without needing to download the pages in between. (see description of "fast web view" and "byteserving" below). At this time you have to wait for the entire PDF to be downloaded before you can sometimes see page 1 and at a minimum interact with the file.
Click on image to see it larger.
Google Chrome appears to be using the nppdf32.dll file, which is Windows Acrobat Firefox browser plug-in file that enables Acrobat/Reader to display PDF in Window Firefox. Historical props to you if you still call that the Netscape Plug-in, because indeed it was first developed to help display PDF in Netscape.
An interesting observation is that when I did manage to crash Adobe Acrobat, Google Chrome reported that the plug-in crashed and gave me an upside down smiley face leaving me to believe that Acrobat did some thing wrong. Both Firefox and IE6/7 view the same PDFs without issue. Who’s to say right now who is right here – Google’s Chrome or the other browsers. We’ll have to see how Google Chrome interacts with plug-ins going forward. Google talks about placing blame on the plug-ins instead of the web browser in their comic strip documentation. I guess this is an example of that.
Long time Adobe Acrobat customer, Duff Johnson, has already posted his experience of using Google Chrome with Adobe Reader. Read all about his findings, which are quite similar to my own quick tests.
Some other good links that I found on Google Chrome are below:
PDF Browser Techno-Speak
In my discussion above I mentioned a few terms that should be defined. Let me do that here:
Fast Web View: If a file is enabled for Fast Web View, the file has been optimized for viewing over the web. This means that the information for the page to which the file opens is at the beginning of the file, as is the cross-reference table, an index to all the objects in the file.
You can check if a file is enabled for Fast Web View by opening the file in Acrobat/Reader and selecting File > Properties. In the Properties dialog box on the Description tab the Fast Web View status is in the lower right hand corner.
Here are some links to good test files if you are interested:
Look for this setting when creating PDF files with Adobe PDF Creation tools. To enable this when you save PDF files make sure your Acrobat Document Preferences are set correctly for "Save as Optimizes for Fast Web View." Then when you perform a Save As action it will be set correctly. There is also a batch sequence created for you to use if you have multiple files.
Click on image to see it larger.
Byteserving: This terms is the ability for a web server to download a range of bytes in a file instead of having to download the entire file. If a file is being "byteserved," that means that the server which is sending Acrobat the file is able to give Acrobat specific bytes that Acrobat requests. For example, if a file is being byteserved, Acrobat can ask for the bytes for the 2nd page, and the server will send only the bytes for the 2nd page. This ability is a function of the web server and not of Acrobat.
Taking advantage of Byteserving by optimizing PDF files for Fast Web View has been something Acrobat has done since the early days. We’ve taken advantage of this long standing extension to the http protocol, and it is widely supported by many web servers and browsers.
A little history lesson for you; old school Acrobat/Reader users will often refer to the file as being "Linearized" or "Optimized" when Fast Web View is set to Yes. Many props if you still use either of these terms.
The Acrobat and Reader Product Management teams, Engineering and Quality Engineering team will continue to evaluate new versions of Google Chrome as they are released. At this time a final release has not been announced by Google. I’ll aim to post our findings and plans here on "Shredding the Document" as things move forward.
In the meantime, the Acrobat Product Management team would like to hear from you as well. What is your experience with Google Chrome and PDF?
Acrobat Product Manager