Brian has a blog called “Assistive Technology” which focuses on “assistive technology, eLearning, mind mapping, project management, visual learning, collaborative tools, and educational technology”. A few weeks ago, the Acrobat Team had the opportunity to sit down with Brian briefly and share with him some the new features in Acrobat 9. He recently published two articles on two of his favorite features, PDF Portfolios and Adobe Presenter.

About PDF Portfolios, I think he really captured well the essence of PDF Portfolios:

“I’m sure that if you are like me, you often get emails with several PDF attachments. When the email is delivered into your inbox you have no idea which one to open first and once they are opened you then have to save them to a folder and organize them in some way so that they are useful to you…Now imagine that you can now take your existing PDF files, SWF files, Word files, Excel documents, and picture files and create one unitary portfolio which stores all of your documents…now imagine that you have the ability to craft the portfolio so that it has the look and feel that you hope to achieve for your communication.”

Brian also posted some creative examples of the PDF Portfolio and the Adobe Presenter document which he created, as well as a video of his step-by-step creation experience.

Check out Brian’s blog if you get a chance and leave him a comment if you like what you see.

Thanks.

Dave Stromfeld, Acrobat Product Manager

Richard Wright, the keyboardist responsible for the band’s distinctive sound, passed away at the age of 65 after a battle with cancer. He was an original member of the group joining founding members David Gilmour, Roger Water, and Nick Mason on stage in a reunion performance at Live 8 in 2005. He remained close to band mate David Gilmour participating in recent collaborations like On an Island and, just announced this morning, Live in Gdansk.

The reason that David Gilmour and Richard Wright are relevant to us today is that David chose, as part of the Live in Gdansk announcement, to share a live performance of “A Great Day for Freedom” with his fans in a PDF document. The PDF file contains a full video performance as well as a photo gallery and lyrics sheet.

Click on image to see it larger.

While it’s a great example of the new ability to combine multiple media types, it also demonstrates the option to either embed multimedia for offline playback or stream it to the file in order to minimize file size.

Take a few minutes, download the PDF file, and rediscover two great musicians of our era.

Thank you, Richard.

Chris French, Acrobat Product Manager

In Acrobat 8, we released redaction features which allow you to mark and remove sensitive content from your documents prior to distributing them. This included "search-and-redact", which allowed you to search through one or many PDF files for a particular sensitive word or phrase.  In Acrobat 9, we enhanced this with pattern-based search-and-redact, which allowed you to search for a sensitive pattern such as social security numbers or phone numbers.

However, when we released Acrobat 9, we were only able to complete US-centric patterns.  (For example, searching for a U.S. social security number pattern isn’t as valuable in the U.K.)  About a week ago, we were able to post a small update which provides additional patterns relevant for UK, Canada, Japan, France and Germany customers.

Get this small update and read more about it here.  And let us know what you think and if you’d like to see more in this area.

Regards,

Dave Stromfeld, Product Manager

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.

1. 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?
2. Is supporting the browser on Mac/Win (and Linux for Reader) justified based on #1?
3. 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.
4. What are the specific features of the browser that we would have to support?
5. 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 Zone
• ZD Net’s Review
• Wired’s Review

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:

• http://acroeng.adobe.com/byteserving/opt/starr.pdf
• http://acroeng.adobe.com/byteserving/opt/95annrep.pdf
• http://acroeng.adobe.com/byteserving/opt/tequila.pdf

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.

Going Forward…

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?

Cheers,

Jeff Moran

Acrobat Product Manager

MDI: Multiple Document Interface is when windows reside under a single parent application window.

SDI: Single Document Interface is when all document windows are separate from each other.

MDI is not applicable on the Mac OS. On Mac OS X, an MDI mode does not "save screen real estate" by eliminating redundant menu bars, because the Mac OS X graphical user interface is application-centric instead of window-centric. As opposed to Windows, all windows belonging to an application share the same menu. Therefore, when discussing MDI and SDI it is a Windows specific conversation.

Some of our customers have noticed a change in the viewing modes of Acrobat and Adobe Reader on Windows over the last two versions. Acrobat and Adobe Reader had long displayed documents in MDI mode. In Acrobat and Adobe Reader 7 we introduced the ability to view documents in SDI mode. This was not the default view mode, but a user could enable it in the preferences. In Acrobat and Adobe Reader 8 we made the default mode SDI and still allowed users to choose MDI in the preferences.

Acrobat and Adobe Reader said good-bye to MDI mode in version 9. Probably not noticed by most of you, but some of you have noticed and asked why we did this. The Acrobat Product Management team wanted to share our reasoning with you for this change.

There were several contributing factors that led to this decision.

1. Feature Parity with Macintosh was desired. As stated before, the Mac OS does not have this option. While I will be the first to admit that feature parity is not 100% between Windows and Macintosh, it is a goal that we aim for.
2. In version 8, we made SDI the default in the viewing mode. Making SDI default, but still providing MDI in version 8 was done to start the deprecation of MDI.
3. Microsoft advised that to work as good as possible on Vista, applications should avoid MDI.
4. Acrobat and Adobe Reader’s new UI modes would not work with MDI. Form editing mode, portfolio mode, and portfolio preview mode all wanted a complete refresh of the UI. MDI mode always left a bit of the UI skin under the care of an MDI main frame, so there would have had been no way for those UI modes to re-skin that part of the UI if MDI mode was left in place.
5. A cost compelling reason was that MDI and SDI mode essentially became another view mode in which all work flows had to be tested. This increases the cost of testing the product and the cost of fixing bugs. Often a fix to a bug in one view mode would cause adverse reactions in the other view mode. The decision to support only one view mode on Windows was made to simplify this. Furthermore, more time spent in this area could mean less time spent developing and fixing bugs in other areas.

MDI mode seems to have been loved for the aspect of keeping all documents opened by a single application contained tightly together. However, in a world where larger screen resolutions, multiple monitors and the need to see multiple documents at one time has increased, SDI mode offered higher benefits. Couple all this with the requirements coming from Windows Vista and the decision was made to drop MDI mode.

Going forward the Acrobat Product Management team has started exploring alternative ways to accomplish some of what is so loved about MDI mode. While we can’t comment publicly on that at this time, please know that we have heard you. I hope the reasoning I provided helps you understand the choices we made a little bit better as well. Please let us know your thoughts about the removal of MDI support. Let us know what you feel the benefits of MDI are and how it helps you get your work done. We would love to hear from you.

Jeff Moran

Acrobat Product Management

source:  http://en.wikipedia.org/wiki/Multiple_document_interface

Cheers
Jeff Moran
Acrobat Product Manager