Comments on: XML Processing for VDP http://thedigitalnirvana.com/2009/07/xml-processing-for-vdp/ Transpromo, Short-Run Book Publishing, Inkjet and other Printing Industry Issues Mon, 06 Feb 2012 23:01:03 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Michael J http://thedigitalnirvana.com/2009/07/xml-processing-for-vdp/comment-page-1/#comment-2124 Michael J Wed, 05 Aug 2009 11:34:10 +0000 http://thedigitalnirvana.com/?p=698#comment-2124 Elliot, You say "XML provides a level of flexibility, but I’m not convinced it’s suitable as a VDP data source." Your point would be more reasonable if it included "suitable for X". If X= printers, I tend to agree. But not because of the capabilities of XML. It's because of the natural experience and skills of printing craftspeople. Back in the day I worked on a project for Grow Network. All XML all the time. The company produced among other things, 1000's of customized workbooks for students in Texas. The content was based on what they got wrong on the standardized tests. The delivery of personalized review material resulted in about a 15% increase in students passing the retest. It was all XML. All open source.The page layout was done with XFlo (I think. I'm not a software geek. Just a printing advisor. )At the time it also took the dedicated efforts of some of the best software engineers I've ever met. In my not so humble opinion, for most printers most of the time, mail merge on steroids are plenty good enough. If you, a printer, want to do more, instead of buying tools I would recommend having the tech smart skills on staff or spending the money to partner with an outfit that is expert at all the stuff you have to be expert in to make this practical and margin producing. Elliot,

You say “XML provides a level of flexibility, but I’m not convinced it’s suitable as a VDP data source.” Your point would be more reasonable if it included “suitable for X”. If X= printers, I tend to agree. But not because of the capabilities of XML. It’s because of the natural experience and skills of printing craftspeople.

Back in the day I worked on a project for Grow Network. All XML all the time. The company produced among other things, 1000′s of customized workbooks for students in Texas. The content was based on what they got wrong on the standardized tests. The delivery of personalized review material resulted in about a 15% increase in students passing the retest.

It was all XML. All open source.The page layout was done with XFlo (I think. I’m not a software geek. Just a printing advisor. )At the time it also took the dedicated efforts of some of the best software engineers I’ve ever met.

In my not so humble opinion, for most printers most of the time, mail merge on steroids are plenty good enough. If you, a printer, want to do more, instead of buying tools I would recommend having the tech smart skills on staff or spending the money to partner with an outfit that is expert at all the stuff you have to be expert in to make this practical and margin producing.

]]> By: Nick Barzelay http://thedigitalnirvana.com/2009/07/xml-processing-for-vdp/comment-page-1/#comment-2118 Nick Barzelay Tue, 04 Aug 2009 15:55:35 +0000 http://thedigitalnirvana.com/?p=698#comment-2118 Let me net it out. All this post says is that the combination of XML-tagged record-organized repeating data and a text-oriented programming language like Perl or Ruby is an excellent way to prepare a data stream (including digital asset URIs) for generating VDP documents with Adobe InDesign. I am over half way along in writing a book that addresses this and related technical topics in considerable detail. Regarding XMPie, that VDP application (according to a trainer from XMPie) uses a scaled-down version of the Adobe InDesign Server Engine. If you follow their process, they convert data to XML before feeding it into the InDesign engine. If there is a problem with the data, one has to revert to the raw data to make the correction and then convert to XML again in order to run the corrected data stream. My point is that the XML data stream can be managed directly without going back to the raw data. The other thing that I've found (and this has been confirmed to me by others in print and graphic design) is that the XML automation capabilities of Adobe InDesign (as far back as CS2) tend to be misunderstood, unexplored, or unknown. The common thinking is that one has to have a plug-in in order to use InDesign to create VDP, otherwise it is just a layout application. Let me net it out. All this post says is that the combination of XML-tagged record-organized repeating data and a text-oriented programming language like Perl or Ruby is an excellent way to prepare a data stream (including digital asset URIs) for generating VDP documents with Adobe InDesign. I am over half way along in writing a book that addresses this and related technical topics in considerable detail.

Regarding XMPie, that VDP application (according to a trainer from XMPie) uses a scaled-down version of the Adobe InDesign Server Engine. If you follow their process, they convert data to XML before feeding it into the InDesign engine. If there is a problem with the data, one has to revert to the raw data to make the correction and then convert to XML again in order to run the corrected data stream. My point is that the XML data stream can be managed directly without going back to the raw data.

The other thing that I’ve found (and this has been confirmed to me by others in print and graphic design) is that the XML automation capabilities of Adobe InDesign (as far back as CS2) tend to be misunderstood, unexplored, or unknown. The common thinking is that one has to have a plug-in in order to use InDesign to create VDP, otherwise it is just a layout application.

]]> By: Eliot Harper http://thedigitalnirvana.com/2009/07/xml-processing-for-vdp/comment-page-1/#comment-2099 Eliot Harper Sat, 01 Aug 2009 05:47:13 +0000 http://thedigitalnirvana.com/?p=698#comment-2099 XML provides a level of flexibility, but I'm not convinced it's suitable as a VDP data source. While it might be common practice to use a delimited text files for VDP, these delimited files are easy to view and edit as tabular text (i.e. open the in Excel) and only contain field names in the first line. Yes, I know you can open an XML file in Excel, but remember that XML contains a tag for every single field in each record, which when you have thousands of records, produces an unnecessarily long text file to parse. If you really want to use flat text file data source, then I'd recommend sticking with good old delimited text. And if you really need to include relationships in your data source, then use a database connection to a relational database! I'm not saying XML doesn't have a place in VDP, it absolutely does--as a document format (like XMPie XLIM or XSL-FO used by Scriptura). And XML isn't really a suitable format for VDP output (i.e. PPML), but I'll save that discussion for another thread... XML provides a level of flexibility, but I’m not convinced it’s suitable as a VDP data source. While it might be common practice to use a delimited text files for VDP, these delimited files are easy to view and edit as tabular text (i.e. open the in Excel) and only contain field names in the first line. Yes, I know you can open an XML file in Excel, but remember that XML contains a tag for every single field in each record, which when you have thousands of records, produces an unnecessarily long text file to parse.

If you really want to use flat text file data source, then I’d recommend sticking with good old delimited text. And if you really need to include relationships in your data source, then use a database connection to a relational database!

I’m not saying XML doesn’t have a place in VDP, it absolutely does–as a document format (like XMPie XLIM or XSL-FO used by Scriptura). And XML isn’t really a suitable format for VDP output (i.e. PPML), but I’ll save that discussion for another thread…

]]> By: Todd Chronister http://thedigitalnirvana.com/2009/07/xml-processing-for-vdp/comment-page-1/#comment-2092 Todd Chronister Thu, 30 Jul 2009 00:20:31 +0000 http://thedigitalnirvana.com/?p=698#comment-2092 Shouldn't this entire blog post be the first paragraph? I was reading on hoping to gain some practical knowledge, but it is common. For those who find this to be insightful will have no understanding of how to implement something like Ruby to meet their ends. I do hope you plan to continue this topic in something like a 'part 2'. This reminds me of someone I met recently at the GUA in Orlando who told me he was using PHP to generate his impositions for press. Sounds logical doesn't it, until you really get to it and all of a sudden the frame widens and the ROI to actually build, test, revise, proof, and launch is an expensive excersize of reinventing the wheel. Shouldn’t this entire blog post be the first paragraph? I was reading on hoping to gain some practical knowledge, but it is common. For those who find this to be insightful will have no understanding of how to implement something like Ruby to meet their ends. I do hope you plan to continue this topic in something like a ‘part 2′. This reminds me of someone I met recently at the GUA in Orlando who told me he was using PHP to generate his impositions for press. Sounds logical doesn’t it, until you really get to it and all of a sudden the frame widens and the ROI to actually build, test, revise, proof, and launch is an expensive excersize of reinventing the wheel.

]]>