Asset management
By aron | December 10, 2007
Does anyone have experience with asset management systems?
Which ones?
What did you like / dislike?
We’re also looking at storage systems that have redundancy and safe guards.
All ideas and advice welcome.
Topics: Uncategorized | 2 Comments »
PDF Print Engine effect on Variable Data Printing
By Printologist | December 7, 2007
PDF Print Engine will replace the need for various other specialized VDP (Variable Data Printing) formats. PostScript does not fit so well the plethora of uses that PDF has. And PostScript never has really fit the idea behind VDP in the cases where transparency and complex object behaviour is needed.
Now exists so many proprietary and open VDP formats just to handle the shortcoming of PostScript, they were existed prior to, or they were a offspring of older system oriented formats. So we ended up with a lot of different formats ranging from: PPML, VDX, VPS, AFP, AFPDS/ACIF, DJDE, Metacode, IPDS, RJE, PCL, Optimized PS, XPS, IJPDS, JLYT, TIFF Streams, and … The key factor and goal behind so many of these formats is to handle processing document in a fashion where the the results are predictable and they print at acceptable speeds without loss of quaility.
Regarding the predictability of a document. With those older formats, what was being printed has fewer factors to consider. It was not so long ago that one of five or so font were loaded directly on the printing device. Now documents are designed in much more complicated ways. Often times, these days a document is design for a single purpose and has a collection of fonts, graphics, and images often placed differently on each printed version or page. Graphic designers use PDF natively and ubiquitously. It has become a large part of the design, archival, and proofing process for any digital document. One reason, the output on display and on paper is close enough to what is expected or designed.
In order to print at acceptable speeds is a large issue. One problem is that the PDF are getting bigger with the availability of easily transferring and storing larger amount of data in desktop and server environments. It seems the Moore’s Law plays on both sides of this coin; as computing processing quickens the amount of data to crunch also grows. The pure object oriented design of PDF prevents from steaming unique objects quickly–at least as quickly as raw er and potentially lower-level PostScript instructions. Right now PDF on RIPS without PDF Print Engine convert PDF objects to PostScript prior to rastering these. If is was not necessary to do this, then the native cache mechanisms already available as part of the PDF specification (form objects) could reference items and quicken their recall.
In theory PDF native RIP technology, like the PDF Print Engine, eliminates the need for these other formats. It generally takes a long time for VDP RIP vendors to catch up with these movements in technology. And still, it may be some time before the PDF Print Engine is mature enough to deliver the promise. Nevertheless, this is the next new solution for VDP that will soon make these other formats history.
Topics: VDP, Digital Press, Software | 1 Comment »
Editing XPS: why?
By nixps | December 6, 2007
XPS is intended to be a fixed representation of a printed page. Which means the layout is fixed, the typesetting is fixed, it contains all the resources and information required to represent the document exactly like the author intended. So if the recipient opens the document the text won’t reflow, the fonts stay exactly the same the layout will not change, etc… Really a good format for sharing and printing.
But why would you want to edit this? You can always go back to the original file, do the modification, publish back to XPS, and done!
Let me give you a first good reason: time.
It’s a cliche, but it makes perfect economical sense: time is money. Or more precise, time costs money.
If you have an XPS file with a small text error in it, and you want to modify it by going back to the original file, you risk losing more time than really needed.
You could have the original file on your computer, and the original software you used to create the document - then you’re lucky, it’s the best case: you created the XPS file yourself, and you are using it right away, it is probably not so much of a hassle to do the modification and export it back to XPS.
But what if you didn’t create the XPS file? If you are receiving this XPS to print, you need to contact the person that supplied you this file, ask him to do the modifications, re-export the XPS file and send you this one back. This takes time, by blocking your planning and by going back to the creator for a new file.
Same scenario if you are responsible for publishing the XPS file on the site. If you notice an error in the document, you need to go all the way back to the creator to ask to do the modifications and regenerate the XPS file, run through the required procedures, etc… This takes again more time than it should.
An application that allows you to do small, corrective edits on XPS files saves you time, and money. When you notice the error, either as printer or publisher, you fire up the editor, make a quick change, save, and continue your work without losing valuable time.
Topics: xps, Software | 3 Comments »
Web enabled, on demand calendars
By aron | November 28, 2007
Has anyone implemented a web driven, customizable on demand calendar solution?
Can you write a little about it?
What were some of the challenges? How did it do? Is it still running? Pros and cons?
Topics: Uncategorized | 2 Comments »
NiXPS
By nixps | November 17, 2007
Let me introduce myself - I’m Nick De Roeck, a software engineer working already a couple of years in the graphic arts software business (working for Artwork-Systems & Enfocus). This year I started my own company, NiXPS, specializing in software for Microsoft’s new XPS file format.
There are various reasons why XPS could become a factor of significance in the printing world at large - I’ll go into these in another post. Fact is: we’ve just release a first beta of our upcoming NiXPS v2.0 (yes: the app has the same name as the company - don’t ask).
If you’re interested in playing around with it, we’re always looking for people eager to test. Send a mail to info-at-nixps-dot-com. You can also read more about it in my blog.
Intellectually it might be very rewarding, as you’re working with software for one of the more obscure areas of print, and maybe one day you could say: ‘hey, I beta tested that popular software when it was still very unknown’. Gives you the chance to be very avant-garde in the not so distant future!
Anyway, Printologist tested our software already a couple of times, that’s how I got to know him. And we both share the passion for print!
Topics: xps, Software | 6 Comments »
Is LAB Color Space Best for Digital Print?
By Printologist | November 11, 2007
Is the use of L*A*B color space best for digital print even when the device actually uses a CMYK based technology? First, we must answer the question, “do digital printing devices really use CMYK?” My answer is no–I will soon explain. Secondly, we have to weigh the Pros and Cons of adapting a very different color model from additive nature of RGB, subtractive nature of CMYK, and the perceptive model of LAB. Finally, we will see that LAB is not only the best for Digital Print, its also best for Display.
A = L*A*B ; B = rgb, C = cmyk (credit: Adobe Photoshop Manual)
Do Digital Printing device, even those with four named inks CMYK, really print in the same model as traditional CMYK. No. For example, many top digital presses, like Xerox’s iGen, do not use CMYK the same way as what was done in the past. You do not achieve Rich Black by adding all colors, the K is a rich black. The Black does not go down last, but first. Obviously, any spot color will be an emulation. What others may not realize at first, even CMYK is an emulation. Even with other presses that may now contain a fifth color, like Kodak’s NexPress, the fifth color can add color gamut shift. With all shifts, the color CMYK colors again become emulated in relationship relative to subtractive proportions. Hence, in digital print, CMYK still does not mean the same thing as it did with convention four-color process printing. Even with HP Indigo, just like most other digital presses but uses liquid ink, has a significantly larger color gamut over traditional four color printing. The color gamut is larger in all of these three cases of digital printing (and with most digital printing) so the CMYK can become limiting. Inkjet that uses RGB, too, can be very limiting.
So now we have suggested why CMYK and RGB may be limiting, we need to explain why LAB may be a better choice. LAB color is better data because its perceptive and not tied to a device. LAB is more data–16 bits/channel (although this is common in many RGB and CMYK image data, now too, preventing loss). The ‘L’ is for luminance and the ‘A’ and ‘B’, are coordinate data much like x and y would be on a plotted graph. In simple terms, LAB is more three dimensional. The wider gamut of color, even that outside of visible range, provides a closer approximation simply because more meaningful data is available to crunch. And the effects are visible in practice, too. For Prepress and Graphic artists alike, I suggest reading the Photoshop LAB Color: The Canyon Conundrum and Other Adventures in the Most Powerful Colorspace by Dan Margulis The examples will convince a non-believer.
I recall asking a PDF and Color expert why they used LAB color as the substitute color for spot colors in the PDF. Although, the supstitute colors are not what is meant to be used when using spot (the device should use its own name-based matching) the expert said it was a good question. They explained that the LAB color space was best for Display and for Print. I now agree.
Topics: Digital Press, Prepress, Color | 6 Comments »
DMA 07 Roundup: Data Lists still King, but something else next…
By Printologist | October 16, 2007
While attending the DMA07 exhibit hall today the prevalent message decipherable form the thick marketing slang was that, once again, database (lists) elements are still the most importance element in to the world of print for marketing. The mailing list vendors have the largest and highest number of booths geared toward different aspects of list procurement, cleansing, and analytics.
Is this the trend and will it continue?
No and No, not necessarily. There are other areas that are seemingly increasing faster than database lists. One increasing area is in the area of purely web related technologies, like: web advertising, placement, and analytics. This area fights against print directly.
Another area on the increase is the area that may compliment printing directly is with cross-media technology. Those booths are held by the number of companies that are providing Personalized URLs, 800 call centers, fulfillment services, and email marketing.
All these growth areas have less to do with database list and more to do with what to do with building solutions integrated across list; hence, cross media communication.
Since cross media communication may be the next new marketable thing to the marketers, where does this leave the technologist who build solutions?
A problem that persists in any realm of commercial software is no different here, integration between one software application with another. Technologist can try to explain why interpolation is important across systems. They can encourage that groups publish open API. They can even ask they they use published standards like JDF. Nevertheless, the business persons who go to these events and often lead the purchase decision cycles do not know (or care to understand) they must ask these questions and demand interoperability.
By the third or so booth that claims they offer the solution for Personalized URLs, I could not hesitate to ask: Why do I care so much about the web interface when I its an API I want?, Why would you sell Software as a Service and charge per click model? and, Why couldn’t we easily build this technology on our own?
The last question can generally get us into a bit of trouble from time to time. The obvious answer they will (and should) give is “why re-invent the wheel?” Sometimes, the fact of the matter is that some wheels are easily re-invented–they are not rocket science.
Still, was DMA 07 successful?
Overall, yes, the show was worthwhile. The speakers seemed to deliver the same message as always. The change was on the exhibit floor. This time, it looks as if some of the technology behind the ideas in the marketing arena are reaching a new maturity level. Several years ago, we may not have been complaining so much about interpolation, but, instead, some of the products were not even mature enough to sell. Unlike, GraphExpo, most of the products pitched by the software vendors were actually in production and use (not prototypes we may or may not see a year or so later). As you can imagine, this provides a sigh of relief. Now, let’s concentrate on interpolation issues between products.
Topics: Direct Marketing, Marketing, Software, Direct Mail | No Comments »
Esko does VDP, and why
By Printologist | October 15, 2007
Packaging design software company EskoArtwork, announced last month at Labelexpo that they too would be adding Variable Data Printing (VDP) capabilities in the press release “EskoArtwork introduces Variable Data Printing“. It’s our responsibility as experts on the technology side to try and figure out why, technically, another VDP software package may or may not be justified.
“The Esko Variable Data Printing is part of Esko Software Suite 7, and is available as an Adobe Illustrator plug-in within Esko DeskPack, or as an extension of Esko PackEdge and Esko Plato.”
The target market for the software is those who already produce labels and want to add variable number and/or barcodes. Workflow is the most critical element when producing packaging because of the complexity found in the end product. For example: imposition, die-cutting, and ganging of jobs, are often elements that all need to come together at once for successful prepress. Does the value found by not having to going outside of this workflow justify using less-established (new) VDP software built into the other tools from Esko?
To answer this question, first, we need to do a little research. We reviewed the press release and tool a look at the http://eskoartwork.com website and I only found pieces of information from either of these sources. No prices, screenshots, diagrams, product specifications, and no specific VDP product was found from the site. Mostly, there was an indication that the software does what is needed while integrating into their existing product line–no separate software package for VDP. If this is the case, why was a press release needed, couldn’t they just email their existing client base. From the press release, we started to try and decipher what this VDP software actually accomplishes.
The data input format are xml and csv, not unusual for VDP software. Usually, VDP support additional formats for input of data. Although, many will find these as a starting points as suitable, some may want more formats.
The press release references support for “HP IndiChrome,” for help with emulating Pantone colors. It does not state whether the software supports this in conjunction with specialized VDP output format. While its helpful to state support for IndiChrome that will allow a six color process on the HP Indigo, its hard to validate how any output format is optomized for VDP from Esko.
Finally, there are too many questions on how VDP is done with Esko to make a fair technical assessment. We do encourage that they update their website with screenshots, white papers, and more information on feature they choose to post across the internet world. Meanwhile, we emailed the address found on their website, info.usa@esko.com, asking for someone technical help in answering some of these questions. We will post a follow-up in case they get back to us and answer some questions. Just like the rest of world, they are free to post comments and help carlify the details of this enigmatic VDP product.
Topics: VDP, Packaging, Software, workflow, Prepress, Color | No Comments »
Do printers even need to know JDF, PPML, PDF…
By Printologist | October 10, 2007
It occurred to me after reading Top Midwest Print Service Provider Prints to Win with Industry EFI Fiery-Driven Konica Minolta Color Production System that there really is no need for a printer to know or need to know JDF, PPML, and PDF. The company who purchased this printer and RIP are a small family owned envelope printer from Lincoln Nebraska. Do we really expect them to write their own JDF? The press release is a case study from EFI for their RIP. Their remains a missing link between these acronyms, probably enigmatic to the startup consumers, and a logic explanation on what they may do for their business. Meanwhile, the truth of the matter is these formats will do very little on their own without a lot of supporting software surely not included in the deal.
I have attended developer meetings with PODI for PPML and still remain heavily involved with CIP4 and JDF, and I am getting a little tired of RIP manufactures using the names of the formats for selling. Its not that they should not support these formats, they should. However, they need to reel in the sales pitch a bit so they can put this into context. For example, one can say that the press may integrate with a particular MIS system allowing the consumer to send jobs directly from the system instead of manually loading them to the printer. They can say that they can do personalization with PPML from FusionPro. There must be some reason why a RIP manufactures chooses to ignore the application in their pitch.
One reason why JDF, PPML, and VDX (and so on…) remain as bullet points on sell sheets from manufacturers is that their real value must be put into context with ofter software and hardware–a situation causing a business relationship to get in the way. No major manufacture is willing to commit to a statement where they give specific examples with territorial inner workings of horizontal technologies. In other words, nobody is stepping up to the plate and providing a complete package.. not Kodak, not Xerox, not Canon, and certainly not Konica Minolta. Instead, they all prefer to continue mystifying their purchasers with a list of acronyms that only hint at the possibility of interpolation and scalability.
Topics: Partnerships, Digital Press, Software | 1 Comment »
Datalogics’ .NET binding to Adobe PDF Library
By Printologist | October 9, 2007
I saw on the PDF Developer Junkie Blog Entry that Datalogics Inc has released a .NET binding along with updates to Java bindings.
This further shows how many .NET programmers are out there and looking for suitable faster low-level libraries to use in the high level languages in Microsoft’s CLR. When I mentioned this press release to someone else in the industry, there reply was, “yeah, imagine trying to write a PDF Library in VB or C#, what a joke!” I am sure it could be done, but there is certainly an advantage using resources from a proven and stable source.
Another suitable replacement for writing your own PDF Library, is PDFLib for the .NET Bindings–they have been there for a long time, maybe 5 or more years I am guessing. They come with a lot of other bindings, as well, such as Python, Ruby, and C++. It looks like from looking at the open source version of PDFLib (PDFLib Lite), that the library is written “C,” hence probably making it easy to port bindings to other languages.
On a similar note, I have been looking for someone to help me port CIP4’s JDFLib to .NET. Its open source and if someone gets it done, I am sure this would make some of the .NET world happy.
Topics: Dev Resources, Software | No Comments »