Editor's Note: Before we finally had the opportunity to meet Dov Isaacs face-to-face a number of years ago in his office at Adobe Systems, we'd come to recognize -- and respect -- his name in the same way most users of Adobe products, at least those who spend time online looking for help with problems, probably have. While it's not actually part of his official job duties, Isaacs spends a considerable amount of time trolling the online discussion forums and email lists to not only monitor end-user issues and experiences with the company's products, but frequently responding and helping to troubleshoot recurring and unusual problems. Some answers are simple, while other solutions require considerable offline investigation. He's also a frequent speaker at industry conferences, dispensing hard-earned experience on Acrobat/PDF best practices and related topics. And then there's his 'day job' at Adobe as a "Principal Scientist, Workflow and Interoperability." Planet PDF caught up with Isaacs earlier this month to talk about his varied efforts and responsibilities, and frankly to commend him for setting a high standard for how companies interact with end users for mutual benefit.
Dov, it's great to have this opportunity to talk with you about your role as a "Principal Scientist, Workflow and Interoperability" at Adobe Systems. Users of Adobe software who frequent popular online discussion areas focused on products like Acrobat, FrameMaker, Illustrator and InDesign certainly will recognize your name -- if not your job title -- from your seemingly omnipresent availability and steady flow of helpful responses. Frankly, we want to know how you do it! But first, let's find out a bit more about you and what your official job title and description entails.
PLANET PDF: Tell us a little about any relevant experience you had prior to working for Adobe -- anything in your work background that's helped you build this depth and breadth of experience on which you frequently draw in helping people troubleshoot problems (or in some cases, perceived problems)?
Dov Isaacs: "I have very wide-ranging academic and professional experience before Adobe. My academic experience includes electrical engineering, business school and a doctorate in computer science. Professionally I've been involved in operating systems development, accounting software, word processing and office automation application development, etc. I have more than 30 years of technical management experience in the software industry.
One of the most important things in terms of providing me the experience I'm using now is my science and engineering background. Key to that is a disciplined approach to solving problems: Analyzing them and proposing solutions. That's in contrast to a very 'wild west' approach; many computer science programs today don't tend to have as much of an emphasis on the discipline of engineering.
When I was an undergraduate, I had the privilege of having as one of my professors Dr. Harold Edgerton of MIT, the inventor of the commercial strobe unit and founder of EG&G, a wonderful teacher and the type of person who on the first day of class led you into a lab and had you disassemble and reassemble a strobe unit while blindfolded. He had a can-do, learn-by-doing approach to engineering, a practical and disciplined approach. I was very lucky to have someone like that as a role model.
And there are other people like that down through my career -- people like Dr. An Wang of Wang Labs, whom I worked with in a previous professional position. And of course there is Dr. John Warnock here at Adobe. I've worked with some exceptional people who provided me some really tremendous role models."
PLANET PDF: When did you begin working for Adobe -- what was the job, and what were the duties? What other positions and relevant responsibilities have you held within the company, leading up to your current job?
ISAACS: "When I got out of school I worked for a number of years at Wang Labs, then moved out to California in 1983. I first worked for a number of what I now call 'startup-and-shutdown' companies, and in 1990, I joined Adobe.
I was looking for a position managing a technical group, and at the time Adobe was mainly in the PostScript business with a few applications such as Illustrator and a little startup application called Photoshop -- release 2.x was coming out at the time. I met the head of what was the OEM PostScript group, and he said that what he really needed ... 'temporarily' ... was somebody to run a Quality Assurance (QA) group for PostScript development.
I had never done any QA in my life, but he wanted someone who could basically set up a QA group to counter some engineers who didn't believe in or trust QA, and who often tried to pull the wool over the eyes of QA personnel. He wanted someone with the technical and managerial credentials and experience who could stand up to the development engineers and for the quality Adobe needed to represent.
So I came in and initially had a group of five people. By the time I left that group nearly seven years later we had about 50 people in the group certifying literally hundreds of Adobe PostScript-labelled OEM products per year as well as PostScript driver releases under Windows and the Macintosh. I had the management responsibility for building the group and its infrastructure by hiring people and leading the development of the testing methodology -- the overall responsibility for the quality of the Adobe PostScript product.
I came in at the time PostScript Level 2 was being conceptualized and then announced. We recognized at the time that when you have a product with a ROM in it that if you had to go out in the field to replace that ROM on a daughterboard that was soldered into a motherboard in a laser printer, that you could lose your profits for hundreds of units in having to replace that one ROM. So you had to assume there was no release 2 of a ROM-based product. The quality had to be there at the very beginning; you couldn't count on 'dot' releases.
Primarily the group that I put together was responsible for developing tests and certifying products. Part of the game plan was effectively to have the testing be as automated as possible and to be taken on by the development engineers and our OEMs. I developed a group of test developers and certifiers, not a bunch of 'crank turners.' This worked very well. We had the authority to say 'Yes' or 'No' in terms of any product bearing the "Adobe PostScript" label. In other words, as we joked in paraphrasing an old Hanes underwear commercial: 'It didn't say Adobe PostScript until I said it should say Adobe PostScript.'
When one looks back at the initial Adobe PostScript implementation all the way through PostScript 3, you typically do not see people complaining about Adobe's implementation. We were reasonably anal about our testing and certification requirements so that we knew our applications would be able to reliably print to these devices. If there were problems, it might be in the print engines of our OEMs or suppliers, something that had nothing to do with Adobe's software implementation itself.
In terms of hiring, I did something very different for Quality Assurance: I didn't look for people that necessarily had QA as their background. I myself came into this particular position without that experience. I had the engineering discipline and the science background, as well as some experience in dealing with laser printers, graphics and PostScript, and software development in general To be able to make educated decisions as to whether something met requirements or not, as well as to analyze where a problem might be. I was more interested in finding people who were experts in their fields. Just as you don't hire judges who aren't attorneys, you don't hire QA engineers who do not have significant experience in software and the products they are effectively judging. I was hiring people with PhDs and other advanced degrees in Physics, color science, graphics, and Computer Science -- people who were every bit as good and qualified as the people in the development organization.
This contrasts quite starkly with many organizations throughout the industry that, when it comes to QA, if someone walks, talks and can fog a piece of glass put under their nose, then they're material for QA. It's the 'monkeys behind the Selectric typewriter' type of approach to QA. We tried to work smart and to look at ways of having a very professional organization rather than just crank turners. One thing that was very important -- I did get full support from within Adobe for hiring the very best people, and many of these people have gone on to positions in marketing, development, engineering and project management within the organization.
In 1997 I actually had a marketing position in the OEM PostScript group. I founded and directed what we called our Technology Analysis group, which really was a performance and competitive analysis Group, objectively examining performance and quality of our PostScript products in contrast to competing products in the marketplace at the time. We provided feedback to product development, marketing, and sales. This group existed for about a year and a half, but it came to an end in the summer of 1998 as part of a major reorganization."
PLANET PDF: What specifically does a "Principal Scientist, Workflow and Interoperability" do at Adobe Systems? Does it entail all Adobe software products, or a subset? What sorts of things do you do to ensure interoperability among the varied applications?
ISAACS: "The summer of 1998 was when there was a major reorganization within Adobe. A number of executives left at the time, Quark was making noise about wanting to acquire Adobe. We looked at where all of our resources were being used within the company, and at that time doing competitive analysis on PostScript was not considered probably the best use of our resources.
It was at this point I had my first really long conversation with John Warnock. Part of the change of emphasis in the summer of '98 was going from a group of somewhat disassociated graphics programs and this thing called PostScript into looking for end-to-end solutions for our customers. That meant the programs had to somehow work together, it meant there had to be compatibility -- you had to develop each software product with an eye toward how it worked with other products -- and out of the conversations with Warnock came the charter to set up the Product Interoperability Group. My title was Principal Scientist and Manager, Product Interoperability. Between 1998 and 2002, we hired about ten people. I eventually hired someone to manage the group on a day-to-day basis and I was able to dedicate my time to looking at the overall big picture.
The result of my work and that of this team, for the first time in Adobe's history, each product group became responsible for production of a 'Product Interoperability Plan' that would outline how changes in that particular product and/or its file formats would impact use of other Adobe products. Such a plan, open to review by the teams of all affected products as well as Adobe executive management, is now required within Adobe before approval is granted to proceed with a new product or a new release of an existing product.
Sometimes people would look at what I was doing -- I'd walk into a particular meeting within the company, some would run -- worrying 'what's he going to complain about now?' Often I would describe my role as that of an equal opportunity harasser of all product groups within Adobe. I didn't discriminate.
Immediately prior to the PDF Conference in June 2002, I was asked to rejoin the printing group, now known as the 'Print Workflow Products Group.' We were re-evaluating a number of things Adobe was doing in print publishing. I was asked to rejoin that group to help them look at the workflow and interoperability issues associated specifically with print publishing.
One thing that has changed dramatically during the past year in terms of my responsibilities is rather than just looking at existing products and their faults and problems, I'm helping define the opportunities going forward: What are the pain points in PostScript and PDF-based print publishing workflows that inhibit a reality of 'view and print anywhere?' How can we fix those pain points and fix such workflows with new and/or augmented products from Adobe?
It fits in quite well with my online activities. All these problems and questions I encounter, and discussions I engage in online and in public at conferences, are input into helping define 'what should we do to make it easier' for our customers via our products."
PLANET PDF: At an earlier PDF Conference in November 2001 (and again in 2002) you gave a keynote presentation titled "Reliable PDF Creation in the Enterprise" that my Planet PDF colleague Karl De Abrew described at the time as being "one of the most unique, on-point presentations of issues relating to PDF creation that I've ever seen." Leonard Rosenthol of PDF Sages added that "every single person using PDF should read this presentation, read it again, then read it a third time." Do the problems you discuss relating to 'reliable PDF creation' remain the same year-to-year, or do you find it necessary to significantly update this presentation from one year -- and one version of the product -- to the next?
ISAACS: "The problems tend to remain similar, if not the same. But the presentation does get significantly updated each time. The reason is that I learn more each year. By watching the reactions and listening to the questions, I try to better focus on new insights into the causes of problems and what the user can do to avoid the pitfalls to have reliable PDF creation workflows. It's not that the problems have changed, but that we're learning more about them, perhaps developing better ways of communicating causes and workarounds."
The recurring problems have to do with things such as fonts, installation of products, image compression, image formats, image resolution, etc. If you look at my presentations over time, you'll see that I cover a lot more about what you put in the original source document as opposed to options for creating PDF. You can't create a wonderful PDF file if you have garbage going into the process. Those are considerations and decisions you make very far upstream.
There's also a certain amount of snobbery about this whole process. You see some of this related to things like TrueType fonts. 'TrueType fonts don't work; TrueType fonts are no good for publishing workflows,' things like that. Those issues come up again and again and again."
PLANET PDF: In your presentations, you challenge some of the "conventional wisdom" about how people create PDF files and use Acrobat. Can you talk a little about that?
ISAACS: "Myths have a way of becoming institutionalized to the detriment of the user, whether those myths are associated with acceptable font types and color spaces, techniques for image capture and compression, or file creation options. And related to that, users can get caught in a rut, failing to modify their workflows and use of products to new capabilities and features of new versions of products that help eliminate problems; once a user tends to do something one way, they're very often afraid to change even though conditions and/or capabilities may have changed.
A primary example of this latter issue is that of the route that users take to produce PDF from an application. Since Acrobat 3, Adobe has provided an automated method under both Windows and MacOS via the print command from every application to produce PostScript, distill that PostScript into PDF, delete the PostScript file, and open the new PDF file in Acrobat in what appears to the user to be one step. Yet, we continually hear the most basic questions from licensed Acrobat users as to how to create PostScript files and then manually 'feed them' to the Distiller as if they were using Acrobat Release 1!
In some ways Acrobat is very similar to photography -- in teaching someone to take a picture. For a new user, you're probably better off giving them a point-and-shoot camera than giving them a Nikon F5. There are just too many dials (on the F5) to screw things up. Most casual picture takers will do very poorly with a professional camera. They'll do much better with something that has fewer choices and that makes some of the choices for you. Now consider the new user of Acrobat attempting to make their first PDF file, encountering a bewildering array of driver options, job options, Distiller options, etc., feeling a compulsion to fiddle with all those settings, often tempered by the sage advice of some self-appointed expert in the next cubicle. You don't have to wonder why that 'first picture' doesn't quite come out right! This is one of the challenges we have not only for Acrobat in particular and for Adobe as a company, but in the software industry in general.
Part of the talks that I give refer to my philosophy of 'Set it and Forget it,' comparable to the pitch that Ron Popeil gives in selling his rotisseries on late night TV infomercials. Set the driver options, Distiller options, and job options per my recommendations once and don't go mucking around with them subsequently. Trust me, and you will reliably get high quality, reasonably compact PDF files that will meet the highest percentage of your needs."
PLANET PDF: With the Acrobat 6.0 family of products due to begin shipping in late May, will there be some more things that users will discover to be "wrong" based on today's conventional product wisdom?
ISAACS: "Yes, absolutely. There are going to be more features and more options. I think this is part of the challenge of engineering a product -- users want more features and options. What happens is that you add more features, and options and permutations of same that can be invoked, and guess what, users will try them simply because they exist and not necessarily because they're rational or appropriate for the situation at hand.
I can give you an examples: In PDF 1.5 we have new forms of compression such as JPEG 2000 image compression and compressed object streams, and of course all the knobs and dials to go with these. If you don't choose compression options wisely, you're going to end up with a low quality PDF file that is not appropriate to your needs and that cannot be opened by users with anything less than Acrobat 6 or Adobe Reader 6. Unfortunately for the amateur user of Acrobat, the conventional wisdom that 'smaller is better' is pervasive, resulting in image compression and downsampling option choices that yield PDF files that are nearly useless other than for an on-screen approximation of what the author was trying to portray."
PLANET PDF: One area that over the years has caused people consternation is how Acrobat handles fonts, and what the implications are for a PDF file -- is it searchable, editable, etc -- depending on whether fonts get embedded or subsetted (or neither). Is this getting any easier with the development and increased use of OpenType fonts, and if so, why?
ISAACS: "OpenType's impact in terms of PDF and PDF workflows has less to do with issues of compatibility than it does with ability to express content and cross-platform compatibility. OpenType fonts are compatible on both Mac and Windows, you can just copy it back and forth between platforms, assuming you're licensed to do so -- the physical font file is the same. The issues related to embedding change a bit. There are some myths out there about when one should embed a full font or to subset a font. OpenType fonts can often be quite large. Instead of having at most 256 characters, some of these have in excess of 60,000 characters. For example, Arial and Times New Roman typefaces, which are OpenType fonts under Windows each have more than 1400 character definitions. If you could fully embed those fonts, you're talking about megabytes-worth of font data. So to some degree the issue of whether or not one embeds a font or not is handled by the fact that you really can't do that with these very large fonts. In fact, Distiller will not in fact embed a full font with these large OpenType fonts."
PLANET PDF: One font-related issue that hasn't gone away for creators of PDF files is the matter of licensing, or the existence of "embedding rights." As you're obviously well aware, a couple of font-developing companies have filed a lawsuit against Adobe (and Adobe has filed a countersuit) alleging that Acrobat (Distiller) violates some font licenses because it will allow a user to embed fonts when they may not have the legal right to do so. We realize you can't discuss the specifics of this pending legal matter, but what advice can you offer users -- who may be purchasing, acquiring or told to use specific fonts in PDF files -- to help protect themselves by ensuring their font usage is legal?
ISAACS: "First, users do not *buy* fonts, they license fonts. Secondly, the terms for use of a font is based upon the conditions in the end-user license agreement. When a user licenses a font, it's their responsibility to know what the terms are of that font licensing agreement. If they don't like those conditions, they should negotiate with the font foundries to change them if necessary. Otherwise, the user should send their font business someplace else. But they're responsible for following the conditions on that end-user license agreement."
PLANET PDF: Font problems are just one of the many things you routinely help online users troubleshoot. How do you find the time to be so helpful on so many discussion lists and forums? And likewise, how have you managed to develop such a depth of expertise on multiple platforms and products?
ISAACS: "It's not really officially part of my job. The reason I do this is that looking at the problems and the pain points for our end users to me represents the beginning of analyzing the opportunities to make Adobe products better for our customers. The fact that I solve problems online is only a by-product of my trolling out there for opportunities. In other words, I'm trying to be a good guy while at the same time taking advantage of all this wonderful feedback that's there.
I learn an awful lot. You have to understand that people may think I know all the answers, but in many cases what happens is that I see something I do not know and I use that as an opportunity to make other acquaintances within Adobe -- to quickly determine who it is I need to find out the information from in order to be able to quickly respond to the end user. That's really what the secret is, it's not a matter of me knowing everything. I'm good at looking things up and asking a lot of questions of other people. We have some *really* good people here at Adobe, and I take the best advantage as I can. I'm also very good at smelling rats, putting two and two together based upon my intuition and our prior experience with similar symptoms and problems, and then making educated guesses as to what the underlying cause of the problem is. From there, problem resolution or workaround is usually the easy part. It also doesn't hurt that I actively and intensively use many of our products on both Windows and Macintosh and have a passion for the technologies and high quality graphic presentation."
PLANET PDF: Your generous support of users may be considered a by-product of your 'day job,' but the other side of that is, from an external perspective, that what you do is so valuable to the company and its reputation with its customers -- that is, your activities online generate considerable goodwill for Adobe. And that's not just when or because you help someone successfully resolve a specific problem, but often simply because people see that Adobe is sincerely listening. We trust that somewhere within the company this goodwill is appreciated and duly noted. I've been online a long time and have watched a lot of company reps come and go, and many that never come, and others that are at best marginally helpful or who seem to disappear when the questions get difficult. The generous, helpful service you perform online and the effort you consistently put forth to assist users is highly commendable.
ISAACS: "Thanks. I most strongly believe that it's very important, in fact a corporate imperative, to provide real value to our current and prospective customers. To the degree I can acquire information from customers about what their true needs are and help them -- if they see that as part of what they're paying for, part of the value they get -- that's great!"
PLANET PDF: Software troubleshooting is one of those areas where you can only determine solutions if you have the proper information to begin with. Many users post insufficient details in citing a problem online, which either delays or precludes finding a solution. Do you have any suggestions for users who have problems they want to report as to what kinds of information they should be prepared to provide to Adobe technical support staff (or to post in other online support resources like the Planet PDF Forum in seeking help from others)? Likewise, for those wanting or needing to troubleshoot their own Acrobat problems or those within their sphere of influence, do you have any tips or advice on ways to hone in on the problem (or to determine if there *is* a bona fide problem)?
ISAACS: "The first thing is: Never assume the final result. Many times the assumption is 'there's something wrong with Acrobat' or 'There's something wrong with something' as opposed to 'I have a problem that has the following symptoms.' There's a tremendous difference between defining a bug versus 'I am seeing the following symptoms.' For example, saying 'a straight line occurs here on odd Thursdays on systems with so much memory and configured in the following way' is different from saying 'Acrobat doesn't print a straight line.' It may have nothing to do with Acrobat, but it may. But if you just tell me 'Acrobat doesn't work,' or 'it's busted,' I can't help you, no one can help you.
I think the most important thing is to gather the symptoms -- really look at 'where does it work and where doesn't it.' If you have something that's intermittent, try to see what's common with when it doesn't work versus when it does. If you have something that's causing some kind of anomaly, try to get it down to the smallest possible file that will exhibit that problem rather than sending in a 1,000 pages of convoluted PDF and saying 'it doesn't print.' No one is going to look at that. I could never go back to development engineering with a 1,000-page PDF file and say 'it doesn't work.' They'd ignore me. The more an end user can do to limit the variables and reduce the evidence to the minimum required to reproduce the problem, the more likely it is someone will take notice.
An additional end-user problem area is where you have computer systems for which you really don't have any control and you don't know then history of everything that's been put on or taken off or whatever, that's a disaster area. This goes back to discipline again -- discipline in how one installs software, discipline in terms of what one has on systems, etc. If you don't have that, it's very hard to debug stuff. If you have what we call a legacy system -- that's been passed from user to user to user without the system being 'refreshed,' so to speak (reinstall the OS, reinstall the apps, etc) -- you don't know what you have."
PLANET PDF: Is there any one Acrobat-related user problem that you wish you'd never have to deal with or respond to again?
ISAACS: "This is something I don't usually discuss at any of the presentations -- we get a tremendous number of questions that come up when somebody says 'I have a document in color and the PDF comes out in black-and-white. What's wrong with Acrobat?'
There's a group of people that still assumes you have to somehow produce a PostScript file in some sort of generic form and then run the Distiller on it. Typically whenever you hear this 'black-and-white printer should be color' it's because somebody's taken a printer that's been set up for LaserJet or LaserWriter or some other monochrome device, some generic PostScript printer that you get when you install the printer drivers, set up for a Level 1 printer from 198x and they're having the PostScript generated from those settings: Optimized for 300 dpi, letter- and legal-size only, wide margins, and monochrome.
For some unexplainable reason, these users don't want to believe that the process has been highly automated since Acrobat 3 on both Windows and Macintosh, that generating PostScript is only as a temporary product that they don't need to physically handle. The Distiller Assistant (Acrobat 3 Windows), Acrobat Distiller (Acrobat 4 and 5 Windows), Adobe PDF (Acrobat 6 Windows), Create Adobe PDF (Acrobat Macintosh), etc. provide all the plumbing for generating the correct device-specific PostScript for the Distiller, automatically feeding the PostScript to and parameterizing the Distiller, and then if desired, passing the resultant PDF file to Acrobat for display. In association with that silliness, sometimes we have to deal with the prepress service provider or service-bureau type who says that 'we're going to film ultimately with a Linotronic whatever and so you should produce PostScript by printing to the Linotronic PPD. It's something that I wish there was some way of us stopping it one way or another, but it just keeps on appearing and appearing.
I don't think we have any documentation that tells people to produce PostScript and then to run Distiller. But people seem to still be remembering that from Acrobat 1.0, even though we didn't sell all that many packages of that version."
OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.