Scott Pellicone, VP, Digital Publishing, Quebecor World, Magazine Business

The costs associated with managing this process were quite expensive. Following our deployment of a global DAM strategy, we were able to centralize the process into one or two of our premedia centers and actually separate the image only once. Further, we took a look at Avon’s budget, and identified what it had cost to process each individual image in 28 different countries. We then identified what it would cost to do it very well once, and even spent a little bit more money so Avon could actually improve their quality. Finally, we then shared that asset across those 28 countries.

We saved Avon seven figures each year for the last seven or eight years, so the hosted DAM solution the model definitely does work. However, what happens as technology changes is, there’s been a tremendous devaluation of asset management.

There are a number of different DAM solutions available in the marketplace today which run the gamut, from the very high end which provides enterprise content management to fortune 500 companies; to the off the shelf applications that live on your local desktops; to the content management systems that are integrated into your computers operating system. Probably, dollar-for-dollar, they’re the most robust, because you’re paying a couple hundred dollars and getting a lot of features and functionality. But you don’t have the check-in-check-out, the versioning, renditions and the relational database (Oracle/SQL/etc.).

MM: You were describing this digital media operation or digital asset operation. How do you characterize it in Quebecor?

SP: It’s digital publishing.

MM: So you said that initially you started off with something and then there was MediaBank and then there was the Telescope. Has that continued to evolve in terms of your technical platform?

SP: At Quebecor we have standardized on two asset management solutions, Xinet WebNative Venture and NorthPlains Telescope. Xinet solutions touch almost every customer, and have become an integral part of our value proposition.

The other solution is based on North Plains Telescope and provides our customer with both asset and content management. We typically create an enterprise model, and use a cooperative deployment strategy to share each system across a number of customer installations.

MM: One of the things I’ve heard about the deployment down there in Orlando is that when you had a new client, you had to create a new instance of Telescope on its own server. Have we consolidated those now? Or are we still doing multiple instances of a DAM?

SP: I believe we make another instance on the database. But they all share the same [SAN]. I think that has a lot to do with the licensing fees for Oracle.

MM: We also wanted to talk a little bit here in terms of what you were doing with the Xinet platform.

SP: I love the Xinet platform. Xinet is an interesting player in the market as their solutions touch the entire production value chain from customer facing web-based tools such as WebNative and Portal, to workflow, OPI (Open Prepress Interface), content repurposing, DAM, online approvals, file delivery and archiving. We have standardized our entire premedia production workflow on these tools, and I have not come across another developer who has such a wide array of technology that fits so perfectly into our supply chain.

I’m a big proponent of it on the workflow side through the years. They were the first to run an Apple talk stack on a UNIX platform (SGI, SUN, LINUX), as well as having one of the most reliable OPI solutions on the market.

MM: For those that aren’t familiar with the OPI workflows how would you describe that?

SP: Basically, way back when…

MM: You mean ten years ago?

SP: Yes. I’d say ten years ago when we were very limited by processor speed, disk space and bandwidth. Xinet created technology that supported OPI.

Basically, it creates a low-resolution proxy image of a high-resolution asset that lives on a file system. It allows a creative person to place it in a document. When they print this document to their PostScript printer, Xinet’s FullPress application provides OPI print queues, which sit in front of the PostScript printer that actually capture the PostScript stream with the low-resolution image in it. FullPress then replaces the low resolution proxy image with the high resolution image and sends the high resolution postscript stream to the RIP.

MM: The RIP meaning the Raster Image Process of the high-resolution image type and everything.

SP: Correct.

MM: That then becomes the basis for making the plates.

SP: Correct. So typically, if you had a 40-megabyte image, you’d probably place a 300k image in your page, and you would have a very, very small file to go through the wire to the RIP. Xinet would capture the tin postscript stream (300k) and replace the low resolution image with the high resolution image, and send the Fat postscript stream (40mb) to the RIP.

MM: Right.

SP: It would actually alleviate a lot of transmission time across the local area network, as the operators computer is usually tied up while spooling print data to the RIP. So by incorporating the Xinet technology into the premedia equation, we become more productive as the operator can begin working on their next job, rather than watch their computer spool print data.

Nowadays, it’s not really that much of a requirement because of digital switching hubs and gigabit networks. You could place the high resolution in the page and send it to the RIP rather quickly.

MM: Or send a properly distilled Acrobat PDF.

SP: Exactly. You can actually generate reliable PDFx1a output directly from the layout application.

MM: Are a lot of magazines now published from PDFs? Or is Quebecor still receiving Quark and InDesign documents and then generating printing plates or film from that?

SP: I would say it’s probably about 50/50 right now. The advent of Adobe’s Creative Suite. The migration of Photoshop and PageMaker to create InDesign — where you actually have some of those PhotoShop-like features built into one application. It does however required publishers to work in a high-resolution workflow.

The fact that InDesign can generate reliable and predictable output (if your setting are correct) has allowed publishers to internalize a lot of their prepress functions. I’m seeing many publishers going in-house. They’re partnering with vendors to do their overflow as they have limited resources and capacity.

If they have 13 titles, maybe they’ll try to do five titles in-house. They will cherry pick the ones that make sense for them and the ones that are the easiest, and require the least amount of time and effort. Then they’ will outsource the ones that are more difficult and require the most skill.

MM: From a really ruthless spreadsheet, what are we talking about, in terms of a net cost difference between doing it in-house or sending it out? Is there that much of a savings?

SP: There isn’t always that much of a savings. There are certain ancillary savings like time, and more control over the entire production process. But there’s definitely an intersect point where it makes sense to do it in-house need where it makes sense to actually outsource it.

MM: If I understand you right, it’s not so much a cost initiative, but it’s a control and time-to-market factor that argues for them to take the stuff inside.

SP: That’s absolutely correct. A lot has to do with the size of the publisher, the page count and the number of titles. Based on the urgency of the title, the schedule and the deliverables to the plants, it really is a factor of how many people you need on staff.

For example, QW Premedia could have 20 people working on 50 different titles. But a publisher may need 20 different people at one time — during one week each month — to close the magazine on schedule. So then they’re still paying those 20 people for the three other weeks, that they are just waiting around for pages to arrive from the creative departments.

MM: That, or they hire a bunch of temps. Right?

SP: Yes. But it is really difficult to get temp or freelance people on an ongoing regular basis.

MM: Yes.

SP: The same thing happens in catalogue. It is pretty much feast or famine in the catalogue business. There’s not a routine schedule where every month they are publishing a catalog. Catalogs are typically published a few times a year.

MM: One of the things, Scott that has begun to really mix that up… And I’d like you to comment on this…. A lot of magazines and catalogue companies basically are publishing first to the web. As a function of really structuring their workflow, by publishing first to the web, and because they’re publishing XML content or they’ve got an XML workflow, they then can pour the material that would normally take a week or two weeks to print. They can take that from the web and then pour it into their print production workflows.