Post-press data standards emerge.
Post-Press Data Interchange Guidelines Version 1.0 was released at Nexpo June 25.
Amid its often dense and arcane discussion of "Body checksum field," "hexadecimal number system" and "node addressing" is the promise that mailroom and other post-press equipment will finally be able to converse, regardless of manufacturer.
This small -- but important -- breakthrough in computer protocol will help speed the advance to a targeted newspaper, said Eric Wolferman, the Newspaper Association of America's new senior vice president/technology.
"We will soon be working on a complete model for post-press equipment to accommodate the production and distribution of targeted products," Wolferman said. "And we will act as a catalyst to encourage vendors to develop the necessary technology to make targeting a reality. This is a large and complex undertaking. But our industry has identified the ability to target our products as its number one priority. And we believe it is achievable."
The just-announced guidelines apply only to data interchange between stackers, a mailroom machine often operated on a stand-alone basis.
And NAA post-press manager Harshad D. Matalia noted that the guidelines need further testing. During development, the guidelines were tested by IBM Corp. in a simulation mode, and parts of the format were tested at the Sacramento Bee by AM Graphics.
Nevertheless, the industry is hurrying to extend the guidelines to other post-press equipment.
At a meeting June 26, the Post-Press Data Interchange Task Force agreed to develop similar guidelines for inserters and onserters, which promises to be a complex task.
"The inserter is probably the machine that requires the most processing speed," said Jere Moter, engineering director of GMA.
"Now that sounds odd because you are only talking of speeds of about 35,000 or 40,000 copies an hour. But if you have 30 hoppers on the inserter now, it's 30 times 40,000. That will blow out any PLC," Moter said. PLC refers to programmable logic controls, the control and reporting systems commonly used for inserting equipment outside the newspaper industry.
Identifying a standard that allows real-time communication for newspaper equipment is especially daunting because of the unique time constraints of newspaper production.
"Electronics will fail and you have to have a way to get back up and running quickly at a newspaper," Moter said.
"That's a little different than a Campbell's soup packaging line where if you are down a couple of hours you miss a couple hundred gross of labels. But it doesn't matter because the soup would just sit on the shelf for a couple of weeks anyway."
NAA's Matalia notes, however, that the stacker guidelines give the industry a big push ahead toward taking on inserters and onserters.
"An advantage we have is that we have now settled on a format. So work should go more rapidly," Matalia said.
The scanner guidelines in many ways simply adopt the move to off-the-shelf, non-proprietary platforms that has transformed newspaper front-end systems in the last decade.
Early on, the task force decided to develop an open-system architecture and a standard protocol.
And at the core of the new guidelines is a simple conceptual breakthrough: The unified message format will have two "tiers" of complexity.
The first tier sends and receives the full version of the message format, with all its 19 "identified header fields" that can be as long as 1,492 bytes, a variable length body including up to 6 fields and a trailer to indicate the end of the message. (A field is a byte or group of bytes, that is binary digits, assigned to convey specific information inside a given format.)
This complex tier would be used to communicate along a network.
A second, simpler, tier provides only a brief version of the full message. This tier is used for point-to-point device links, essentially in stand-alone situations where there is no need, for example, to identify a machine, address it specifically or identify its capabilities.
All header and trailer fields will contain binary codes. Data fields can be written in binary, ASCII or other formats.
The guidelines are voluntary, but vendors -- whose representatives comprised about half of the task force -- appear to accept them.
There were concerns among some vendors at first that the emphasis on open architecture was straying towards requiring manufacturers to reveal their source codes. Not surprisingly, no such requirement made it to the draft stage.
But mailroom equipment vendors know that the days of offering proprietary microprocessors are long gone.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||computer communications in newspaper mailrooms|
|Publication:||Editor & Publisher|
|Date:||Jul 2, 1994|
|Previous Article:||Newspapers and the superhighway.|
|Next Article:||Newspapers urged to be more creative.|