EP1749257A2 - Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom - Google Patents

Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom

Info

Publication number
EP1749257A2
EP1749257A2 EP05735960A EP05735960A EP1749257A2 EP 1749257 A2 EP1749257 A2 EP 1749257A2 EP 05735960 A EP05735960 A EP 05735960A EP 05735960 A EP05735960 A EP 05735960A EP 1749257 A2 EP1749257 A2 EP 1749257A2
Authority
EP
European Patent Office
Prior art keywords
data
data stream
line
print
structured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP05735960A
Other languages
English (en)
French (fr)
Inventor
Werner Engbrocks
Matthias Fromm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Production Printing Germany GmbH and Co KG
OC Printing Systems GmbH
Original Assignee
Oce Printing Systems GmbH and Co KG
OC Printing Systems GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oce Printing Systems GmbH and Co KG, OC Printing Systems GmbH filed Critical Oce Printing Systems GmbH and Co KG
Publication of EP1749257A2 publication Critical patent/EP1749257A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation

Definitions

  • the invention relates to a method, a device and a computer program product for generating a page and / or area-structured data stream from a line data stream.
  • line data streams are widely used in the digital printing sector and in particular as an Advanced Function Presentation (AFP) Line Data Stream, which was developed by the International Business Machine Corporation (IBM) or as a Line Coded Data Stream (LCDS), which was developed by the Xerox Cooperation , educated.
  • AFP Advanced Function Presentation
  • IBM International Business Machine Corporation
  • LCDS Line Coded Data Stream
  • line data streams also called line data-based print data streams
  • corresponding printing applications are still used to this day because they have been maintained and developed over decades with great expenditure of time and personnel and the effort for a new development would be unreasonably high and risk of incorrect programming.
  • print applications so-called legacy applications, are still widely used to this day, although modern print data languages are available today which offer a wide range of options for document preparation, document formatting and document structuring.
  • IBM publication number S544-5284-06 entitled “IBM page printer for matting aid: user guide, seventh edition (May 2002), describes a computer program with which complex pagedef files and corresponding page assignment files (formdef files) are generated with which complex documents can be produced.
  • a corresponding software program known as Oce SLE (Smart Layout Editor) for creating Formdef files and pagedef files is known by the applicant.
  • FIG. 14 shows such an application in which a line data print data stream 134 is generated from data from a database 130 in a customer-specific application.
  • the line data print data stream 134 is then further processed using an editing program and using the pagedef file 132 and possibly the formdef file 133 to form an output data stream which, for example, is sent to a printing device or to an archive system.
  • the resources Pagedef 132 and Formdef 133 in turn call up other resources such as font data 135, overlay data 136, code pages 137 and page segments 138.
  • DE-Al-101 23 376 discloses a method for processing document data in which control data are added to the document data in a processing module.
  • DE-C2-100 17 785 discloses a method for processing line data print data, in which index data is added to the line data print data in a processing module
  • DE-Al-102 35 254 discloses a method in which a Finishing commands can be added to the document data stream, which can be used for processing correspondingly printed documents on finishing devices such as cutters, stackers, etc. for device control.
  • AFP data stream into other page definition languages (PDLs) such as PDF or Post Script
  • PDLs page definition languages
  • ww .mpitech is available at the Internet address.
  • various conversion programs offered by MPI Tech e.g. the software ACM-AFP2PDF Conversion Module.
  • a method for converting an input document into an output document is known from ÜS-Bl-6, 336, 124, in which the document is divided into blocks.
  • the print data are from a print data source 25 with a sample data set to an editor, such as. B. sent the Smart Layout Editor (SLE), which the applicant sells.
  • the layout (forms, data placement, fonts, etc.) is defined for printing on the basis of this sample data record and an AFP resource data stream with a Formdef file and Pagedef file is generated.
  • the AFP resource data stream 27 comprises only a few tens to a maximum of a few hundred kilobytes and contains forms, fonts, page definitions and form definitions as commands.
  • the AFP resource data stream 27 is then sent to a print preparation computer (print server) 28 and stored there.
  • the print server 28 When printing the print data later, it is sent directly to the print server 28 via the print data path 29 sent, which in turn connects the print data to the AFP resource data stream and generates an IPDS data stream therefrom, which is sent to one or more printing devices 31, 32 for printing.
  • This method of processing is based on the concept that there is a separation between the variable data to be printed and the resource data stream.
  • the advantages of this AFP-based procedure are a high processing speed and a high degree of compression, since the resource data can be transmitted once as a relatively small file and the majority of the data (print data) without additional information such as layouts, forms, fonts ) etc., can be sent directly from the print data source 25 to the print server 28.
  • a disadvantage of this method based on the IBM product Page Printer Formatting Aid is that only the print data provided in PPFA and the specified formatting principles can be used.
  • Personalized documents can be generated by so-called "conditional processing", but a new document page must be described for each branch. This makes the application design very lengthy and complex. In particular, the generation of cake or bar diagrams is not possible in this way This would only be possible through special functions in a correspondingly expanded printer driver, but the printing of such applications would be restricted to manufacturer-specific systems, which would be relatively inconvenient.
  • FIG. 3 shows data processing based on the so-called formatter principle.
  • the complete print data stream is fed from the print data source 25 to a formatter 35, which creates a layout and integrates the layout information, such as form information, written form information and other format information, directly into the print data stream.
  • the complete print data stream prepared in this way is then sent to the print server 28 and from there forwarded to a printer 31, 32.
  • Such processing corresponds to many of the procedures introduced in the so-called small office home office (SOHO) area. For example, print data in the Microsoft Office products WinWord TM, Access TM and Excel TM under the Windows 2000 TM operating system are processed in this way.
  • SOHO small office home office
  • An advantage of this type of data preparation is that practically any complex instructions or rules can be integrated into the print data stream.
  • tables with a dynamic length including subtotals and grand totals are possible, as well as the graphic preparation of print data using pie or bar diagrams etc.
  • different print data can be loaded via input filters. a. also so-called RDI data from database programs from SAP AG, Walldorf, Germany.
  • the disadvantage of this procedure is that the print data stream is very extensive due to the formatting information and thus the transfer of the print data from one computer to another computer or to the printer takes a relatively long time. Furthermore, the print preparation must be carried out individually for each print job. Computer programs that apply this principle to AFP print data must generate a complete AFP data stream for each print job, even if no dynamics are to take place. These AFP data streams are to be converted into corresponding IPDS data streams for the printing devices for printing. The disadvantage here is that the smallest changes The print job is forced to completely regenerate the AFP data stream.
  • dynamic graphics are embedded in customer applications, for example, directly in the line data print data stream, special data fields for controlling "conditional processing" are inserted and so on. Both this and fonts with customer-specific code pages sometimes result in complex dependencies between the customer applications, the Formdef or Pagedef file and the other resources used in the printing process such as fonts, code pages, overlays, page segments and so on that changes and extensions to the layout or to the Formdef or Pagedef files are very complex and prone to errors.
  • FIG. 16 shows the various known process sequences for generating documents from databases.
  • the database data can be imported from the database 130 into a line data generator 90 of a host computer 3, which forms a line data print data stream therefrom.
  • This print data stream is loaded in the host computer 3 into a job entry system (JES), from which the print data stream is optionally supplied to a device driver 33 in the host computer 3 or to a print job.
  • the device data driver 33a converts the print data stream into a format adapted to the device connected in each case, for example into an AFP or MO: DCA print data stream for an AFP data archive 34 or into an IPDS print data stream for an IPDS -Printer 31.
  • the print jobs can again be fed to one or more devices, one or more device drivers 33b being used on the print server 28.
  • the output can in turn take place on an AFP data archive 34 or on one or more printing devices 31.
  • the invention has for its object to enable a migration of line data print data streams, which allows extended formatting options. This object is achieved by the invention specified in the independent patent claims. Advantageous embodiments of the invention are specified in the subclaims.
  • a predetermined structure description file assigned to the line-by-line structured data stream is used.
  • a design data record can be defined that corresponds to the output data structure.
  • the mapping rule can then be generated in such a way that it describes a mapping between entries in the structure description file and entries in the design data record.
  • a method for generating a page and / or area-structured output data stream from a line-by-line structured line data input print data stream is specified, with a structure description file being permanently assigned to the line data input print data stream.
  • a page and / or area-structured data stream from a line-by-line structured line data print data stream from line data print data of the line data print data stream use At least one structure description file assigned to them automatically generates an automatic design data record in which structurally related print data and / or characteristic data assigned to them are rarely and / or regionally structured. Furthermore, by means of a design data record that describes a predetermined data structure and the automatic design data record, a mapping rule is generated that describes the mapping of data from the automatic design data record onto the design data record. Finally, the page and / or area-structured data stream is generated using the design data record, the mapping rule and the line data print data.
  • the invention is based on the knowledge that a page and / or area-structured data stream is suitable as an input data stream for format-based solutions for the preparation of document data streams, or that a corresponding data stream such as a comma-separated values is relatively easy from such a data stream - Data stream can be generated.
  • the page and / or area-structured data stream essentially contains data which represent the variable information of documents, field names for explaining the respective date can be included, but in particular no formatting instructions such as fonts, position information and so on are included.
  • the method according to the invention represents, in particular, a preliminary stage for generating print and / or document data streams using a format.
  • a structure description file used for formatting line data such as a Formdef file, a Pagedef file or a PPFA Script file of an advanced function presentation line data stream, possibly with associated other resources for interpreting the line data, is suitable to the extent that the page and / or area-by-line data structure of the line data can be determined and from it automatically the mapping rule and / or the automatically generated design data record can be generated.
  • the invention is further based on the knowledge that pagedef files in AFP line data printing applications often determine the layout of the documents produced with them and that they can then be used as a structure description file to form the mapping rule and / or the automatically generated design data record.
  • the mapping rule can be stored in a rule file, which is automatically called up and processed in a productive printing process phase.
  • the design data record in particular designates an output structure of the print data and the mapping rule is converted into instructions for a computer that processes the print data, in particular by means of the rule file.
  • Heuristics that analyze and / or interpret print instructions of the structure description file and / or characteristic data assigned to them in accordance with their actual calls when processing line data of the input data stream can be used in particular for the automatic creation of the mapping rule.
  • the Formatter-based solutions can be integrated into the workflow without the need for extensive changes to the line data generators.
  • the line data print data when forming the page and / or richly structured data streams are processed in exactly the same sequence as in their standard printout.
  • the invention in particular simplifies the structural processing of line data applications, human intervention being simplified compared to previously known methods and essentially restricted to the specification of assignment rules.
  • the invention enables a clear assignment between sample data that correspond to the automatic design data set and the design data set.
  • the structure description file in particular comprises a page definition file and can furthermore comprise a page assignment file.
  • these can be an AFP Formdef resource or an AFP Pagedef resource.
  • Resources in turn assigned to these, such as fonts, code pages, overlays and / or page segments, can also be used to generate the automatic design data record.
  • Field positions that are specified in the structure description file can in particular be assigned to corresponding data records of the line data print data stream. Furthermore, it is possible to generate an intermediate file before generating the structured data record, in which line data print data belonging together in terms of content and / or structure are summarized within a structure bracket. Advanced function presentation line data print data can be used in particular as line data print data.
  • the output data stream can in particular be encoded in Unicode.
  • code pages of font assignments from the structure description file are checked for consistency with the Unicode coding and conflicts, in particular those caused by symbols specific to the individual case or assignments deviating from the norm of the code pages exist, resolved by code-specific mappings according to Unicode.
  • a comma-separated value print data stream (CSV print data stream) and / or an extensible markup language data stream (XML data stream) can be generated in particular as the page and area-structured print data stream.
  • CSV print data stream and / or an extensible markup language data stream (XML data stream) can be generated in particular as the page and area-structured print data stream.
  • XML data stream extensible markup language data stream
  • These in turn can in particular be used as an input data stream for a formatter by forming a complexly formatted print data stream which contains structure and / or formatting elements which are not available in line data streams.
  • the formatter particularly adds such elements to the formatter input data stream. In particular, they can be entered or selected by an operator.
  • the invention makes it possible, in particular, to reconstruct the original database structure from line data print data streams which were formed from a database query and thus to form an optimal input data stream for format-based methods.
  • a device according to the invention is set up to carry out the method according to the invention.
  • a computer program product according to the invention generates a method sequence according to the invention when it is loaded and executed on a computer.
  • the output data stream is generated directly from a line data input print data stream with the aid of the mapping rule previously generated and the structure description file. Furthermore, it may be possible to obtain mapping instructions directly from the structure description file, in particular the pagedef file of an AFP line data stream, with which the line data input data print data stream can be used output data stream structured in pages and / or regions.
  • the line data input Print data stream in particular assigned formatting elements with an editor.
  • FIG. 2 shows the known procedure for processing print data in accordance with the AFP and IPDS specifications
  • FIG. 3 the known procedure for processing print data according to the so-called formatter principle
  • FIG. 4 shows a method for preparing print data with additional structure and formatting elements
  • FIG. 5 shows the processing of database data in a document processing system
  • FIG. 6 the processing of a sample data record and an application data record
  • FIG. 7 different print data structures
  • FIG. 8 different print data structures
  • FIG. 9 data structures from FIG. 7 provided with example data records
  • FIG. 10 shows a line data print data stream
  • Figure 11 is automatically generated, with structural elements verse- 'hene data obtained from the data of Figure 10,
  • FIG. 12 shows a page and area structured print data stream which was obtained from the data in FIG. 11,
  • FIG. 13 shows a software structure for generating a complexly formatted print data stream
  • FIG. 14 shows a legacy application
  • FIG. 15 shows a generalized procedure
  • FIG. 16 various known method sequences for generating documents from database data
  • FIG. 17 shows an extract from a Pagedef file that is human-readable.
  • FIG. 1 shows a document print production system 1 which on the one hand comprises a main frame architecture 2 and on the other hand a network architecture 5 in which document data or document print data streams are generated in each case by means of user programs (tools).
  • these print data are generated by a host computer 3, for example as an AFP print data stream or as a line print data stream.
  • the print data can optionally be transmitted directly from the host computer 3 via a so-called S / 370 channel 14a to one or more printing devices 6a, 6b.
  • the print data can also be Computer 3 are transmitted via a network 13 or a direct data connection 14b to a processing computer 4, in which the print data is temporarily stored (for example in an associated file server) and processed for subsequent output steps.
  • print data streams are generated which regularly compile list printouts, invoices, consumption overviews (for telephone bills, gas bills, bank accounts) etc. from larger databases (databases).
  • databases databases
  • legacy applications have often been in use for many years and are still required in a more or less unchanged manner (so-called legacy applications).
  • the print production process is monitored by a monitoring system 7 within the main frame architecture 2. It comprises a monitoring computer 7a, which is coupled to a database 7b and contains various computer program modules 7c.
  • the monitoring system 7 is connected to the host computer 3 via a device control network 15 and a print manager module 8 and via a converter 9 to e.g. a V24 data line, which couples to the two pressure devices 6a, 6b.
  • the converter 9 converts the V24 signals into DMI protocol signals of the device control network 15.
  • SNMP protocol signals can be provided to the Device Manager DM in the form of DMI protocol signals or transferred directly as SNMP protocol signals.
  • Print material 19 which was generated in the printers 6a, 6b from the document print data stream and on which barcodes are printed, can each be scanned with a manually movable, radio-controlled barcode reader 11a.
  • the signals are transmitted by radio to the reading station 10a and transmitted to the device control network 15 or to the monitoring system 7.
  • Readers for one-dimensional and / or two-dimensional barcodes can be used as barcode readers, so that different barcode systems can be read with one and the same reading device.
  • the barcode reading system is particularly configurable, that is, applicable to various, application-specific codes or the respectively suitable control methods.
  • document data are generated by means of user programs in client computers 12, 12a, which are connected to one another and to the processing computer (file server) 4 via a client network 13.
  • the file server thus serves as the central processing and processing interface for print data of the entire print production system 1.
  • Various control modules (software programs) run on it, through which the entire print production process or the entire document processing can be optimally adapted to the respective circumstances on the application, production technology and device control side ,
  • control data that have been supplied in the input data stream from the host computer 3 or user computer 12 to the processing computer 4 can be filtered in such a way that those control data that are not required in the given overall system arrangement are removed .
  • the output devices involved printingers 6a to 6d, cutting device (cutter) 18a, inserting device 18b
  • the overall data stream can be reduced, in particular if only empty field entries for corresponding control data are contained in the input data stream.
  • Print data which have been completed by the processing computer 4 are sent to a print server 16 via the print data line 14c. Its task is essentially to relieve the processing computer 4. This is done by temporarily storing the finished print data until it is called up via the data line 14d to one or both printers 6c, 6d.
  • the print server 16 is therefore primarily integrated into the overall system for reasons of performance (speed). In systems whose print speed is less high, the print server 16 can also be omitted.
  • Document data that are transmitted to the printer 6c or to a 6b and printed there on a recording medium are fed to further processing steps in the overall system, namely the cutting device 18a and the inserting device 18b for further processing.
  • a recording medium e.g. paper web
  • the printed documents are tested on their processing path between the printing device 6 and the last post-processing device 18b with regard to various criteria with a test system 17, namely by an optical test system 17a with regard to their optical print quality, with a barcode test system 17b with regard to their presence, their consistency and / or their sequence and with a MICR test system 17c, provided the print was printed using magnetically readable toner (Magnetic Ink Character Recognition Toner).
  • the data of the different test systems supplied by the test system 17 are shared by a common rial data acquisition module (Serial Data Acquisition Module) 17d transmitted to the device control network 15 and fed to the monitoring system 7. The respective system data are recorded there, the devices are checked in real time and the respective positions of the documents are tested for correctness with regard to the print job.
  • a test system 17 namely by an optical test system 17a with regard to their optical print quality, with a barcode test system 17b with regard to their presence, their consistency and / or their sequence and with a MICR test system 17c, provided the print
  • the finished printed documents 23 can in turn be scanned with a barcode reader 11b which e.g. Radio-controlled is connected to an associated control device 10b, which in turn supplies its data to the monitoring system 7 via the device control network 15.
  • a barcode reader 11b which e.g. Radio-controlled is connected to an associated control device 10b, which in turn supplies its data to the monitoring system 7 via the device control network 15.
  • FIG. 4 shows a method for preparing print data with additional structure and formatting elements, as described in the applicant's unpublished WO-Al-2004/040432. The content of this patent application is hereby incorporated by reference into the present description.
  • static resources are created based on a complete print data pattern.
  • These are the standard resources known in the AFP data stream, such as overlays, page segments, fonts, pagedef and formdef files.
  • print data that are not included in the formatting offered as standard in the AFP range of functions are not written to an AFP resource file, but rather to an extended print data file that contains all variable print data.
  • This file is used for individual design with special formatting elements, eg. B. graphic elements such as pie charts or bar charts.
  • the editor 26 is expanded in such a way that such formatting can be carried out.
  • the basic concept of the AFP data structure namely the data separation between variable and static data is largely retained.
  • the formatter principle maintains that the print data is complete be transferred to an intermediate stage.
  • this intermediate stage - as provided for in the processing of AFP print data - resources are assigned to the print data and thus forms, fonts etc. are standardized and converted into a relatively small AFP resource data stream.
  • This resource data stream is transmitted via an AFP channel 36.
  • variable print data those data that are already formatted elsewhere or for which no high-performance conversion or assignment of AFP resources is possible are selected from the variable print data.
  • This print data is expanded accordingly by the required commands (data enrichment).
  • This print data expansion takes place in a so-called design phase by means of a suitable editor, in which corresponding sample data sets or automatic design data sets are examined and corresponding assignments are made.
  • a data table could be used and the command assigned that a pie chart is to be generated as a graphic element from the numbers in the data table.
  • a suitable new computer program can optionally be made available as an editor, or an already existing editor for a specific print language, for example an AFP editor, such as the above-mentioned Smart Layout Editor (SLE) by the applicant, can be expanded by corresponding functions.
  • SLE Smart Layout Editor
  • the correspondingly expanded print data stream is sent to the print server or printer via the data channel 37.
  • the print server 28 or printing device 31, 32 the prepared print data stream is combined with the AFP resources transmitted once and the data stream thus combined is finally sent to the printer as an IPDS data stream.
  • a printout can also be made as a fax to a fax machine, the data via an e-mail computer, for example via the client Computer 12 can be sent as an email or placed on the Internet via a www server.
  • the processing method known from AFP environments is expanded by at least one functionality by means of which formatting instructions, such as the representation of graphic data, e.g. the conversion into cake or bar diagrams or the addition of components such as barcodes, images and other objects can be transferred.
  • formatting instructions such as the representation of graphic data, e.g. the conversion into cake or bar diagrams or the addition of components such as barcodes, images and other objects can be transferred.
  • An advantage of the solution described here is on the one hand the work compatibility with the known environments and on the other hand the possibility of being able to continue to use existing, recurring print jobs. This ensures 100% downward compatibility of the process in print production environments.
  • FIG. 5 shows how computer program products interact in such a way that data originating from a SAP database application is processed with formatting information and processed in a print production system in such a way that it can be sent to a printing device.
  • SAP-specific RDI print data is transferred to an output data management system 41 (output management system) and an SAP interface 42 (SAP connector) Print production system 43 sent.
  • print orders are managed by an order distribution system 44 for further processing.
  • Each print job is individually identified by means of a print job manager 45 (PrintJob Manager) and provided with print job data, for example for a desired output printer or a certain priority.
  • This data is in a print job accompanying file 46 (job ticket).
  • a data expansion module 47 is used to prepare print data from a user database. This includes two computer program modules 48, 49, which are required at different times.
  • a data preparation phase the data of a sample data record from an application database 50 (e.g. SAP database) are used and suitable formatting and other supplementary data are appended to the sample data record by means of the designer module 48, in order to prepare this as desired by a user.
  • Suitable extension data 51 are then transmitted to the document generator computer program 49 via the order distribution system 44.
  • the RDI data and the associated formatting data are also converted into an internal predetermined print data format that is coupled to a printing system or selected by a user.
  • the conversion can be done e.g. B. in an AFP data stream, a PCL data stream, a PostScript data stream or a PDF data stream.
  • the computer program module 49 uses the extension data in a second processing phase, in which the complete database data are transmitted from the SAP database application 40 via the SAP interface 42 to enrich the extension data record by record.
  • personalized documents 52 are created, which are sent via the order processing system 44 as print files 53 to a collection program 54 (spool) or as direct print data Printer driver module 56 are output to a printer (not shown in FIG. 5).
  • FIG. 6 shows the data processing operations that are carried out on the one hand in the preparation phase (design phase) and on the other hand in the productive phase (print phase) in order to be able to prepare print data from any source.
  • a sample data record or a sample document 60 which originates from the line data data stream, is loaded into the designer computer program 48 via the import module 61 as a design data record 62. With the aid of this program 48, any formatting or supplementary information is added to the design data record 62 and the design information file 63 is thus formed.
  • an automatic design data record is also automatically generated using the pagedef file and sample data, and a mapping rule is generated manually, semi-automatically or fully automatically on the basis of a logical comparison of the automatic design data record and the design data record 62.
  • application data records 64 of the line data print data stream are read in record by record and translated into an internal data format 66 by means of a translation computer program module 65 of the document generator computer program 49.
  • the translator 65 uses the mapping rule obtained in the design phase or the rule file containing this mapping rule to form the application record 64 from the application data record 64 in the internal data format 66, onto which a computer program module "Formatter" of the document generator Computer program 49 is used using the design information file 63.
  • the formatter computer program module 67 generates the personalized data from the print data in the internal data format and the formatting instructions defined by the design process and stored in the design information file 63.
  • te document 68 The formatter computer program module 67 generates the personalized data from the print data in the internal data format and the formatting instructions defined by the design process and stored in the design information file 63.
  • a data transformation module 69 (AFP transformer) converts the personalized document file 68 into a print file 70.
  • a translation stage module 94 which is controlled by the control file 77, is used to convert the input data 105 into the standardized data 104.
  • the rule file 77 contains mapping rules in the form of mapping rules which, in the design phase, are derived from the input document data 105 or from the automatic design data record derived therefrom and the design data record 62 also created and, if appropriate, from input data-specific auxiliary files 119 were formed. Both the design data record 62 and the rule file 77 can be freely editable.
  • the design data record 62 can be used in the formation of a document template 112 that controls the formatting of the standardized data stream 104 (in step 113). As shown by the arrows Ai and A 2 , the design data record 62 and from this the control file 77 can also be generated from the document template 112.
  • the mapping rules specified in the rule file 77 are specific to the input document data stream 105. They indicate which element of the input document data stream 105 is to be assigned to which element of the design data record.
  • the design data record 62 contains the structure definition of the standardized data, with type declarations being provided for various structure elements, for example for customer numbers, names, logos, images, etc. Data groups that belong together, in particular all, can then also be formed in the standardized raw data 104 those data that belong to a document. Thus, all associated data are available in the standardized raw data stream 104 for each document.
  • a document template 112 serves as a structure template for the documents to be generated and describes which formatting instructions are to be added in the standardized data stream. It can be made up of items contain the design data record 62 and / or contain freely programmed static or dynamic elements 96 93, 15. The document template 112 is thus dependent on document formatting and serves to control the format formation device 113 (formatter or document composition engine).
  • the formatting device 113 forms a resource-oriented data stream from the standardized raw data stream 104. Insofar as formatting was already contained in the raw data, this is retained, and as long as the raw data is unformatted and formatting information is included in the document template for the corresponding data fields, it is added in a resource-oriented manner in the formatting device 113, resources which are present multiple times within a data stream Performance-optimized processing is required, that is, they are inserted into the resource-oriented data stream mainly by calling the resources, the resources themselves only being available internally, or loaded externally from a resource file or even referenced. For processing document template 112, design data record 62 and rule file 77, it may be advantageous to couple these files in such a way that a change in one of the files leads to a consistency, checking and, if necessary, modification in the other two files leads.
  • the formatted document data stream 114 is then fed to a backend device 118, in which it can be selected in the output language controlled by an output selection file 119 as a print data stream 120 or via an interface 121 for an output device (fax, email server, www server, monitor) ) is processed.
  • the standardized data stream 104 and / or the formatted data stream 114 can already be optimized device-specifically. Details on this are described in WO-A2-01 / 78000, which is hereby incorporated by reference into the present description.
  • FIGS. 7 to 13 and 17 explain the method for generating a page and / or area-structured data stream from a line-by-line structured line data print data stream. In FIG.
  • a line-by-line structured AFP line data print data stream is structurally shown, the line data (Line 01, Line 02, ...) 80 following one another line-structured.
  • a structure description file "Pagedef" is assigned to the AFP line data, which defines the arrangement of the respective data on the page when the line data 80 is printed out. If this Pagedef file is used, the line data 80 structured line by line can be used automatically using the instructions from the Pagedef file a new data structure 81 is generated, in which on the one hand related page groups and individual pages are displayed, and on the other hand the line descriptors (LND) originating from the Pagedef file are assigned to the respective fields from the line data structure within each page. Structure can then be formed by means of data entered or selected by an operator into a rule file (assignment file) with which the data stream structured from page to page
  • 82 can be generated, in which a field of the input data stream 80 is assigned to each field identifier.
  • the automatically generated, labeled data structure 81 is a first exemplary embodiment of an automatically generated design data record. In the present case, it mainly contains field names as information. However, it can contain additional further characteristic data, such as font information and position information, which can be obtained in particular from the pagedef file.
  • the automatically generated, identified data structure 81 or the automatically generated design data set provides structural information of the pagedef file again, especially with regard to data fields that need to be recognized.
  • the finally identified data structure 82 has a content structure.
  • the content structure corresponds to a flight overview of a passenger, with various content structure criteria being represented by the field names "Customer”, “Street”, ... “Connection”, ... "Flight NO” etc.
  • the finally marked data structure 82 represents a structured sample data record in which structurally related line data print data are compiled in terms of content in a structured manner.
  • the page and / or area-structured data stream which is suitable as an input data stream for a formatter can then be generated on the basis of this sample data record and the line data print data.
  • FIG. 8 shows a data stream structure similar to that in FIG. 7, where the line data 80a is divided into two page types by the structure description file (Pagedef) and different line descriptors are used in each page type. This can, for. For example, the type and address of the flight customer are given for page type 1, while only the customer number and flight connections are specified for page type 2, but not the customer name etc.
  • the data structure 82a of the sample data record which reflects the structure of the content, is however, identical to the corresponding data structure 82 in FIG. 7.
  • the automatically generated, marked data structure 81a is a further exemplary embodiment of an automatically generated design data record.
  • FIG. 9a shows a line data stream 83 which contains three flight connections for Mr.
  • the marked data stream 84 is automatically generated from the interpretation of the associated pagedef, with each date of the row data stream 83 being assigned the corresponding row descriptor (LND) of the pagedef that processes this row date.
  • LND row descriptor
  • FIG. 9c shows the data stream 85 structured in terms of content and area, which is formed from the automatically generated, identified data stream 84 and a rule file which contains the respective mapping rule of the data fields both for a field name and for one or more group names (customer, connection). contains.
  • the control file is generated fully automatically, partially automatically or manually, the data structure of the automatic design data record preferably being used.
  • a flight connection has eight entries each, ie each ninth entry in turn represents a new flight connection.
  • channel control character 1 which means that a new document is beginning.
  • FIG. 9c shows a corresponding data stream 85 structured in terms of content, which can be generated directly from the input line data stream 83 using the corresponding rule file.
  • a page definition file such as, for example, B. a conventional and e.g. Pagedef file known from the prior art documents mentioned in the introduction or a corresponding script file from a page formatting tool such as the IBM Page Printer Formatting Aid.
  • resources assigned to them such as fonts, code pages or page segments
  • a page mapping file such as an AFP formdef, possibly with resources assigned to them, such as fonts, code pages, overlays or page segments, can be used.
  • FIG. 10 shows a somewhat more complex line data stream 83a, which contains data from other passengers in addition to various connections of a passenger.
  • FIGS. 11a, 11b and 11c show how a page structure is generated using a corresponding page description file, in which a new page is started for each person and the flights of a person are shown on one or more pages.
  • FIGS. 12a, 12b and 12c show the finally marked data stream 85a, which is formed from the line data stream 83a and is structured in groups in regions.
  • the field "Customer" contains the salutation, first name and surname of the passenger and is managed as one field with these three details. However, such a combined field can be broken down into its individual components at any time and multiple fields can be generated from such a field, which each correspond to a corresponding entry in a database
  • the data stream 85a serves for further processing as an input data stream of a formatter.
  • FIG. 13 shows an exemplary embodiment in which a line data print data stream is generated from a database 130 by means of a line data generator, with the measures described above being fed to a line data preprocessor 91, in which the line data print data stream is made into a page and / or area-structured data stream is converted and this data stream is fed to a formatter 92, in which additional formatting elements are added to the data stream.
  • the data stream completely formatted in this way is then fed to an output device 93, it being possible for various resources 94, such as overlays and fonts, to be added to the data stream.
  • These resources can be generated with known resource generators 95 and are also used to control the line data preprocessor 91 (line data import dialog) and to control the layout generated in the formatter 92 (layout import dialog).
  • FIG. 14 shows a so-called legacy application in which AFP line data print data 134 are generated in a customer-specific application 131, raw data being extracted from a database 130 and output line and / or page oriented.
  • accompanying files such as a pagedef file 132 and a formdef file 133 and possibly other resources such as fonts 135, overlays 136, code pages 137, page segments 138 and so on.
  • an output print data stream is to be generated from the line data print data stream 134, for example for output on a printing device or in an archive, then the line data with the accompanying files or resources are processed by means of a preparation program 104, such as the Oce PRISMAproduction TM program mentioned at the beginning merged or combined again.
  • FIG. 17a shows an extract from a pagedef file “PI redbar” that is prepared for human readability and with which a legacy print data application is generated from the line data shown in FIGS. 7 to 12.
  • the first column 100 of the extract contains the continuous ones Structured field numbers specified in the pagedef file.
  • LNDs line descriptor structured fields
  • a line data stream is processed line by line with the machine commands.
  • the printing method described is not limited to certain printing materials such as paper or to certain forms of recording media such as continuous webs or single sheets.
  • the invention is particularly suitable for being implemented as a computer program (software). It can thus be distributed as a computer program module as a file on a data carrier such as a floppy disk, DVD or CD-Rom or as a file via a data or communication network.
  • a data carrier such as a floppy disk, DVD or CD-Rom
  • Such and comparable computer program products or computer program elements are embodiments of the invention.
  • the corresponding computer on which the invention is applied other technical devices known per se, such as input means (keyboard, mouse, touchscreen), a microprocessor, a data or control bus, and a display device (monitor, display ) as well as RAM, hard disk space and a network card.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Record Information Processing For Printing (AREA)
  • Stored Programmes (AREA)

Abstract

In einem Verfahren, einer Vorrichtung und einem Computerpro­grammprodukt zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdaten­stroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetz­bar sind, wird eine vorgegebene, dem zeilenweise strukturier­ten Druckdatenstrom zugeordnete Strukturbeschreibungsdatei verwendet.

Description

Verfahren, Vorrichtung und Computerprogrammprodukt zum Erzeugen eines Seiten- und/oder bereichsstrukturierten Datenstroms aus einem Zeilendatenstrom
Die Erfindung betrifft ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem Zeilen- datenstrom. Derartige Zeilendatenströme sind im digitalen Druckbereich vielfach verbreitet und insbesondere als Advanced Function Presentation (AFP) Line Data Stream, der von International Business Machine Corporation (IBM) entwickelt wurde oder als Line Coded Data Stream (LCDS) der von der Xe- rox Cooperation entwickelt wurde, ausgebildet.
Obwohl Zeilendatenströme, auch zeilendatenbasierte Druckdatenströme genannt, aus den Anfangszeiten des digitalen Drückens stammen, in denen mit mechanischen Druckköpfen Zeichen nur zeilenweise ausgegeben werden konnten, werden entsprechende Druckanwendungen vielfach bis heute benutzt, weil sie mit großem zeitlichen und personellen Aufwand über Jahrzehnte hinweg gepflegt und weiterentwickelt wurden und der Aufwand für eine Neuentwicklung unangemessen hoch und mit Risiken von Fehlprogrammierung behaftet wäre. Deshalb werden solche Druckanwendungen, sogenannte Legacy-Anwendungen, bis heute noch vielfach verwendet, obwohl heute moderne Druckdatensprachen zur Verfügung stehen, die vielfältige Möglichkeiten der Dokumentenaufbereitung, Dokumentenformatierung und Dokumen- tenstrukturierung bieten.
Aus dem von der International Business Corporation (IBM) herausgegebenen Dokument S544-3884-02 „Advanced Function Pre- sentation-Programming guide and Line Data Reference", dritte Ausgabe (Oktober 2000), die zum Beispiel unter http: //publib.boulder . ibm. com/prsys/pdfs/54438842.pdf zugänglich ist, ist der Zeilendatencode beschrieben. In Kapitel 3 ist darüber hinaus beschrieben, wie aus dem ursprünglichen Zeilendatencdde mittels der sogenannten Page-Definition-Datei (pagedef) ein Ausgangsdatenstrom erzeugt wird.
In der IBM-Veröffentlichung Nummer S544-5284-06 mit dem Titel „IBM page printer for matting aid: user guide , siebte Ausgabe (Mai 2002) ist ein Computerprogramm beschrieben mit dem komplexe Pagedef-Dateien und entsprechende Seitenzuordnungsdateien (formdef-Dateien) erzeugt werden können, mit denen komplexe Dokumente produziert werden können. Von der Anmelderin ist ein entsprechendes Softwareprogramm unter der Bezeichnung Oce SLE (Smart Layout Editor) zur Erstellung von Formdef-Dateien und pagedef-Dateien bekannt.
Ausgabe und Kodierung der AFP Zeilendaten erfolgt häufig auf Großcomputern (Main Frames) in speziell dafür erstellten Anwendungen. Figur 14 zeigt eine derartige Anwendung, bei der aus Daten einer Datenbank 130 in einer kundenspezifischen Anwendung ein Zeilendaten-Druckdatenstrom 134 erzeugt wird. Der Zeilendaten-Druckdatenstrom 134 wird dann im weiteren Verlauf mittels eines Aufbereitungsprogramms und unter Verwendung der Pagedef-Datei 132 und ggf. der Formdef-Datei 133 zu einem Ausgangsdatenstrom aufbereitet, der z.B. an ein Druckgerät oder an ein Archivsystem gesandt wird. Die Ressourcen Pagedef 132 und Formdef 133 rufen ihrerseits wiederum andere Ressourcen wie Font-Daten 135, Overlaydaten 136, Codepages 137 und Pagesegmente 138 auf.
Von der Anmelderin wird ein mit dem Handelsnamen PRISMApro- duction™ bezeichnetes Datenverarbeitungs-System für Hochleistungsdrucksysteme angeboten, welches in der Lage ist Druckdatenströme aus verschiedenen Anwendungen zu verarbeiten, unter verschiedenen Betriebssystemen wie MVS™ oder Linux™ zusammen zu tragen (spoolen) und in einen geräteori- entierten Ausgangsdatenstrom wie zum Beispiel IPDS™ (Intelligent Data Stream) umzuwandeln. Aus der DE-Al-101 23 376 ist ein Verfahren zur Verarbeitung von Dokumentendaten bekannt, bei dem den Dokumentendaten in einem Bearbeitungsmodul Steuerungsdaten hinzugefügt werden. Aus der DE-C2-100 17 785 ist ein Verfahren zur Verarbeitung von Zeilendaten-Druckdaten bekannt, bei dem den Zeilendaten- Druckdaten in einem Bearbeitungsmodul Indexdaten hinzugefügt werden und aus der DE-Al-102 35 254 ist ein Verfahren bekannt, bei dem einem Dokumentendatenstrom Finishing-Befehle hinzugefügt werden können, die für die Verarbeitung entspre- chend gedruckter Dokumente an Finishinggeräten wie Schneidern, Staplern etc. zur Gerätesteuerung nutzbar sind.
Zur Umwandlung eines AFP-Datenstroms in andere Seitendefinitionssprachen (Page Description Languages, PDLs) wie PDF oder Post Script werden unter der Internetadresse ww .mpitech . com von der Firma MPI Tech verschiedene Konvertierungsprogramme angeboten, z.B. die Software ACM-AFP2PDF Conversion Module.
Aus der ÜS-Bl-6, 336, 124 ist ein Verfahren zum Umwandeln eines Eingangsdokuments in ein Ausgangsdokument bekannt, bei dem das Dokument in Blöcke eingeteilt wird.
In den Figuren 2 und 3 sind bekannte Verfahrensweisen zum Verarbeiten von Druckdaten dargestellt. Die Druckdaten werden dabei von einer Druckdatenquelle 25 mit einem Musterdatensatz an einen Editor, wie z. B. den Smart Layout Editor (SLE) , den die Anmelderin vertreibt, gesandt. Anhand dieses Musterdatensatzes wird das Layout (Formulare, Datenplatzierung, Schriften etc.) zum Ausdruck festgelegt und ein AFP-Ressourcen- Datenstrom mit einer Formdef-Datei und Pagedef-Datei erzeugt. Der AFP-Ressourcen-Datenstrom 27 umfaßt nur einige zig- bis maximal einige hundert Kilobyte und enthält Formulare, Schriften, Seiten-Definitionen und Form-Definitionen als Befehle. Der AFP-Ressourcen-Datenstrom 27 wird dann an einen Druckaufbereitungscomputer (Printserver) 28 gesandt und dort abgespeichert. Beim späteren Ausdrucken der Druckdaten werden diese über den Druckdatenweg 29 direkt an den Printserver 28 gesandt, welcher die Druckdaten wiederum mit dem AFP- Ressourcen-Datenstrom verbindet und daraus einen IPDS- Datenstrom generiert, der an ein oder mehrere Druckgeräte 31, 32 zum Ausdruck gesandt wird.
Dieser Verarbeitungsweise liegt also das Konzept zugrunde, daß eine Trennung zwischen den zu druckenden variablen Daten und dem Ressourcen-Datenstrom erfolgt. Vorteile dieser auf AFP beruhenden Verfahrensweise sind eine hohe Verarbeitungs- geschwindigkeit und ein hoher Kompressionsgrad, da die Ressourcen-Daten als relativ kleine Datei einmalig übermittelt werden können und der Großteil der Daten (Druckdaten) ohne belastende Zusatzinformationen, wie Layouts, Formulare, Fonts (Schriften) etc., von der Druckdatenquelle 25 direkt an den Printserver 28 gesandt werden kann.
Nachteilig bei diesem auf dem IBM-Produkt Page Printer For- matting Aid (PPFA) basierenden Verfahren ist, daß nur die in PPFA vorgesehenen Druckdaten und vorgegebenen Formatierungs- prinzipien verwendet werden können. Personalisierte Dokumente können zwar durch sogenannte „conditional processing" erzeugt werden, hierzu muß aber für jede Verzweigung eine neue Dokumentenseite beschrieben werden. Dadurch wird die Applikationsgestaltung sehr langwierig und komplex. Insbesondere ist auf diese Art und Weise die Generierung von Kuchen- oder Balkendiagrammen nicht möglich. Dies wäre nur durch Sonderfunktionen in einem entsprechend erweiterten Druckertreiber möglich. Der Ausdruck solcher Applikationen wäre damit aber auf herstellerspezifische Systeme beschränkt, was relativ ungüns- tig wäre.
Ressourcen sind statisch, das heißt sie werden bei der Ausführung eines Druckauftrags weder generiert noch verändert. Weiterhin enthalten sie keine Druckdaten, beim Entwurf der Ressourcen können jedoch Druckdatenmuster verwendet werden. In Figur 3 ist eine Datenaufbereitung nach dem sogenannten Formatter-Prinzip dargestellt. Der komplette Druckdatenstrom wird dabei von der Druckdatenquelle 25 einem Formatter 35 zugeleitet, welcher ein Layout erstellt und die Layoutanga- ben, wie Formularangaben, Schriftformangaben und andere Formatangaben, direkt in den Druckdatenstrom integriert. Der komplette so aufbereitete Druckdatenstrom wird dann an den Printserver 28 gesandt und von diesem an einen Drucker 31, 32 weitergeleitet. Eine derartige Verarbeitungsweise entspricht vielen im sogenannten Small-Office Home-Office (SOHO) -Bereich eingeführten Verfahrensweisen. Beispielsweise werden Druckdaten in den Microsoft-Office-Produkten WinWord™, Access™ und Excel™ unter dem Betriebssystem Windows 2000™ auf diese Weise verarbeitet.
Vorteilhaft bei dieser Art der Datenaufbereitung ist, daß praktisch beliebig komplexe Anweisungen bzw. Regeln in den Druckdatenstrom integriert werden können. Insbesondere sind Tabellen mit dynamischer Länge einschließlich Zwischen- und Endsummen möglich sowie die grafische Aufbereitung von Druckdaten durch Kuchen- bzw. Balkendiagramme etc.. Der Darstellung von Druckdaten sind dabei prinzipiell keine Grenzen gesetzt. Zudem sind über Eingangsfilter unterschiedliche Druckdaten ladbar, u. a. auch sogenannte RDI-Daten von Daten- bank-Programmen der Firma SAP AG, Walldorf, Deutschland.
Nachteilig bei dieser Verfahrensweise ist, daß der Druckdatenstrom durch die Formatierungsangaben sehr umfangreich wird und damit die Übertragung der Druckdaten von einem Computer an einen anderen Computer oder an den Drucker relativ lange dauert. Weiterhin muß die Druckaufbereitung für jeden Druckauftrag einzeln erfolgen. Computerprogramme, die dieses Prinzip auf AFP-Druckdaten anwenden, müssen für jeden Druckauftrag einen vollständigen AFP-Datenstrom erzeugen, auch wenn keine Dynamik erfolgen soll. Zum Ausdrucken sind diese AFP- Datenströme in entsprechende IPDS-Datenströme für die Druckgeräte umzuwandeln. Nachteilig ist dabei, daß kleinste Ände- rungen am Druckauftrag eine völlige Neugenerierung des AFP- Datenstroms erzwingen.
Um die im Vergleich zu formatterbasierten Lösungen sehr ein- geschränkte Formatiermöglichkeit mittels Formdef- und Pagedef-Dateien wenigstens teilweise auszugleichen werden in Kundenanwendungen beispielsweise dynamische Grafiken direkt in den Zeilendaten-Druckdatenstrom eingebettet, spezielle Datenfelder zur Steuerung von „conditional processing" eingefügt und so weiter. Sowohl dadurch als auch durch Fonts mit kundenspezifischen Codepages entstehen mitunter komplexe Abhängigkeiten zwischen den Kundenanwendungen, der Formdef- beziehungsweise- Pagedef-Datei und den anderen, in Druckprozeß benutzten Ressourcen wie Fonts, Codepages, Overlays, Pageseg- mente und so weiter. Dies führt dazu, daß Änderungen und Erweiterungen am Layout beziehungsweise an den Formdef- beziehungsweise Pagedef-Dateien sehr aufwendig und fehleranfällig sind.
Es ist daher ein Bedürfnis, für zeilendatengenerierende Anwendungen Möglichkeiten zu schaffen, möglichst ohne Änderung der Anwendung den Zeilendatenstrom beziehungsweise die zur Bildung des Zeilendatenstroms notwendigen Ressourcen statt wie bisher über die Formdef-Datei beziehungsweise die Page- def-Datei über andere, zum Beispiel formatterbasierte Lösungen aufzubereiten und hierbei die vielfältigeren Möglichkeiten der Formatter ausschöpfen zu können.
In Figur 16 sind die verschiedenen, bekannten Verfahrensab- laufe zum Erzeugen von Dokumenten aus Datenbanken dargestellt. Die Datenbankdaten können dabei von der Datenbank 130 in einen Zeilendatengenerator 90 eines Host-Computers 3 eingespielt werden, der daraus einen Zeilendaten-Druckdatenstrom bildet. Dieser Druckdatenstrom wird im Host-Computer 3 in ein Auftragseingangs-System (Job Entry System, JES) eingespielt, von dem aus der Druckdatenstrom wahlweise einem Gerätetreiber 33 im Host-Computer 3 zugeführt werden oder einem Druckauf- tragssammelmodul 38 eines Druckservers 28. Von dem Gerätetreiber 33a wird der Druckdatenstrom in ein an das jeweils angeschlossene Gerät angepaßtes Format umgesetzt, beispielsweise in einen AFP bzw. MO: DCA-Druckdatenstrom für ein AFP- Datenarchiv 34 oder in einen IPDS-Druckdatenstrom für einen IPDS-Drucker 31. Wenn die Druckdaten dem Druckauftragssammelmodul 38 zugeführt worden sind, können die Druckaufträge wieder einem oder mehreren Geräten zugeführt werden, wobei ein oder mehrere Gerätetreiber 33b auf den Druckserver 28 verwen- det werden. Die Ausgabe kann wiederum auf einem AFP- Datenarchiv 34 oder auf einem oder mehreren Druckgeräten 31 erfolgen.
Alternativ zu den oben beschriebenen Druckdaten- Verarbeitungsverfahren ist es bekannt, Datenbankdaten aus einer Datenbank 130 feldweise an ein Formatierungs- Computerprogramm 20a im Host-Computer oder an einen Formatierungs-Computer 20b im Druckserver 28 zu übertragen und dort mit Formatierungselementen zu versehen, so dass ein Ausgangs- Druckdatenstrom entsteht, der wiederum dem Auftragseingangs- System 39 im Host-Computer 3 bzw. dem Druckauftragssammelmodul 38 im Druckserver 28 zugeführt wird.
Von der Firma Elixir Technologies Cooperation, Ventura, CA (USA) ist ein Computerprogramm mit der Bezeichnung „Pagemi- ner™Λ zur Extraktion von Daten aus legacy Druckdatenströmen bekannt geworden, bei dem die Nutzdaten aus AFP-Zeilen- datenströmen gemäß speziell zu kodierender Regeln wieder extrahiert werden können und in einer separierten Werte-Datei abgespeichert werden können, so daß formatterbasierte Lösungen diese als Eingangdatenstrom verwenden können.
Der Erfindung liegt die Aufgabe zugrunde, eine Migration von Zeilendaten-Druckdatenströmen zu ermöglichen, die erweiterte Formatierungsmöglichkeiten erlaubt. Diese Aufgabe wird durch die in den unabhängigen Patentansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüchen angegeben.
Gemäß einem ersten Aspekt der Erfindung wird in einem Verfahren zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdatenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, eine vorgegebene, dem zeilenweise strukturierten Druckdatenstrom zugeordnete Strukturbeschreibungsdatei verwendet. Dabei kann insbesondere ein Design-Datensatz festgelegt werden, welcher der Ausgangs-Datenstruktur entspricht. Die Abbildungsvorschrift kann dann derart erzeugt werden, dass sie ei- ne Abbildung zwischen Einträgen der Strukturbeschreibungsdatei und Einträgen des Design-Datensatzes beschreibt.
Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren zum Erzeugen eines Seiten- und/oder bereichsstrukturierten Ausgangs-Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom angegeben, wobei dem Zeilendaten-Eingangs-Druckdatenstrom eine Strukturbeschreibungsdatei fest zugeordnet ist. Dabei wird ein Design- Datensatz erzeugt, der die Ausgangs-Datenstruktur beschreibt, eine Abbildungsvorschrift zwischen der Strukturbeschreibungsdatei und dem Design-Datensatz gemäß dem oben genannten ersten Aspekt der Erfindung erzeugt und mittels der Abbildungsvorschrift aus dem zeilenweise strukturierten Zeilendaten- Eingangs-Druckdatenstrom der Seiten- und/oder bereichsstruk- turierten Ausgangs-Datenstrom erzeugt.
Gemäß einem dritten Aspekt der Erfindung, der in Kombination oder auch unabhängig von den beiden zuvor genannten Aspekten gesehen werden kann, wird zum Erzeugen eines Seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Druckdatenstroms aus Zeilendaten- Druckdaten des Zeilendaten-Druckdatenstroms unter Verwendung mindestens einer ihnen zugeordneten Strukturbeschreibungsdatei automatisch ein Automatik-Design-Datensatz erzeugt, in dem strukturell zusammengehörige Druckdaten und/oder ihnen zugeordnete Kenndaten selten- und/oder bereichsweise struktu- riert zusammengestellt sind. Weiterhin wird mittels eines Design-Datensatzes, der eine vorbestimmte Datenstruktur beschreibt und des Automatik-Design-Datensatzes eine Abbildungsvorschrift erzeugt, die die Abbildung von Daten des Automatik-Design-Datensatzes auf den Design-Datensatz be- schreibt. Schließlich wird unter Verwendung des Design- Datensatzes, der Abbildungsvorschrift und der Zeilendaten- Druckdaten der seiten- und/oder bereichsstrukturierte Datenstrom erzeugt.
Die Erfindung beruht auf der Erkenntnis, daß ein seiten- und/oder bereichsstrukturierter Datenstrom als Eingangsdatenstrom für formatterbasierte Lösungen zum Aufbereiteten von Dokumenten-Datenströmen geeignet ist, beziehungsweise, daß aus einem solchen Datenstrom relativ leicht ein entsprechen- der Datenstrom wie zum Beispiel ein kommaseparierter Werte- Datenstrom erzeugt werden kann. Der seiten- und/oder bereichsstrukturierte Datenstrom beinhaltet dabei im wesentlichen Daten, die die variable Information von Dokumenten darstellen, wobei Feldbezeichnungen zur Erklärung des jeweiligen Datums eingeschlossen sein können, wobei aber insbesondere keine Formatierungsanweisungen wie Fonts, Positionsangaben und so weiter eingeschlossen sind. Das erfindungsgemäße Verfahren stellt insoweit insbesondere eine Vorstufe zum Erzeugen von Druck- und/oder Dokumentendatenströmen mittels For- matter dar. Insbesondere wurde erkannt, daß eine zur Formatierung von Zeilendaten verwendete Strukturbeschreibungsdatei wie zum Beispiel eine Formdef-Datei, eine Pagedef-Datei oder eine PPFA Skript-Datei eines Advanced Function Presentation Zeilendatenstroms, gegebenenfalls mit zugehörigen anderen Ressourcen zur Interpretation der Zeilendaten insoweit geeignet ist, daß die seiten- und/oder bereichsweise Datenstruktur der Zeilendaten ermittelt werden kann und daraus automatisch die Abbildungsvorschrift und/oder der automatisch generierte Designdatensatz erzeugt werden kann.
Der Erfindung liegen weiterhin die Erkenntnisse zugrunde, dass Pagedef-Dateien in AFP Line Data-Druckanwendungen vielfach das Layout der mit ihnen produzierten Dokumente bestimmen und dass sie dann als Strukturbeschreibungsdatei zur Bildung der Abbildungsvorschrift und/oder des automatisch generierten Designdatensatzes verwendet werden können.
Die Abbildungsvorschrift kann insbesondere in einer Regeldatei hinterlegt werden, die in einer produktiven Druckprozessphase automatisch aufgerufen und abgearbeitet wird. Der Design-Datensatz bezeichnet insbesondere eine Ausgabestruktur der Druckdaten und die Abbildungsvorschrift wird insbesondere mittels der Regeldatei in Anweisungen für einen Computer umgesetzt, der die Druckdaten verarbeitet. Zum automatischen Erstellen der Abbildungsvorschrift können insbesondere Heuristiken angewendet werden, die Druckanweisungen der Struk- turbeschreibungsdatei und/oder ihnen zugeordnete Kenndaten exakt gemäß ihren tatsächlichen Aufrufen beim Abarbeiten von Zeilendaten des Eingangsdatenstroms analysieren und/oder interpretieren.
Durch die Erfindung, insbesondere durch die Nutzung einer dem Eingangs-Zeilendatenstrom zugeordneten Strukturbeschreibungsdatei wie einer Pagedef-Datei kann ein maximaler Kompatibilitätsgrad erreicht werden hinsichtlich der Druckergebnisse bei einem konventionellen Legacy-Zeilendatendruck und dem erfin- dungsgemäßen, Formatter-unterstützten Verarbeiten der Druckdaten, wobei die Formatter-basierten Lösungen in den Workflow integriert werden können, ohne dass aufwendige Änderungen an den Zeilendatengeneratoren nötig sind.
In einer Druckumgebung ist insbesondere vorteilhaft, dass die Zeilendaten-Druckdaten beim Bilden des seiten- und/oder be- reichsstrukturierten Datenstroms exakt in der gleichen Folge verarbeitet werden wie bei ihrem standardmäßigen Ausdrucken.
Mit der Erfindung wird insbesondere die strukturmäßige Aufbe- reitung von Zeilendatenanwendungen vereinfacht, wobei das menschliche Eingreifen gegenüber bisher bekannten Verfahren vereinfacht ist und sich im wesentlichen auf die Angabe von Zuordnungsregeln beschränkt. Insbesondere ermöglicht die Erfindung eine anschauliche Zuordnung zwischen Musterdaten, die dem Automatik-Design-Datensatz entsprechen und dem Design- Datensatz .
Die Strukturbeschreibungsdatei umfaßt insbesondere eine Sei- tendefinitions-Datei und kann weiterhin eine Seitenzuord- nungs-Datei umfassen. Diese können insbesondere eine AFP Formdef-Ressource beziehungsweise eine AFP Pagedef-Ressource sein. Diesen wiederum zugeordnete Ressourcen wie zum Beispiel Fonts, Codepages, Overlays und/oder Pagesegmente können ebenfalls zum Erzeugen des Automatik-Design-Datensatzes verwendet werden.
Feldpositionen, die in der Strukturbeschreibungsdatei angegeben sind, können insbesondere entsprechenden Datensätzen des Zeilendaten-Druckdatenstroms zugewiesen werden. Weiterhin ist es möglich, vor dem Erzeugen des strukturierten Datensatzes eine Zwischendatei zu erzeugen, in der inhaltlich und/oder strukturell zusammengehörige Zeilendaten-Druckdaten innerhalb einer Strukturklammer zusammengefaßt werden. Als Zeilendaten- Druckdaten können insbesondere Advanced Function Presentation Zeilendaten-Druckdaten verwendet werden.
Der Ausgangsdatenstrom kann insbesondere Unicode codiert sein. In einem bevorzugten Ausführungsbeispiel der Erfindung werden Codepages von Fontzuweisungen aus der Strukturbe- schreibungsdatei auf Konsistenz mit der Unicode-Kodierung ü- berprüft und Konflikte, insbesondere solche, die durch einzelfallspezifische Symbole oder normabweichende Belegungen der Codepages bestehen, durch codespezifische Abbildungen nach Unicode aufgelöst.
Als seiten- und bereichsstrukturierter Duckdatenstrom kann insbesondere ein kommaseparierter Werte-Druckdatenstrom (CSV- Druckdatenstrom) und/oder ein Extensible Markup Language- Datenstrom (XML Datenstrom) erzeugt werden. Diese können wiederum insbesondere als Eingangsdatenstrom für einen Formatter verwendet werden, indem ein komplex formatierter Druckdaten- ström gebildet wird, welcher Struktur- und/oder Formatierungselemente enthält, die in Zeilendatenströmen nicht zur Verfügung stehen. Der Formatter fügt insbesondere solche Elemente dem Formatter-Eingangsdatenstrom hinzu. Sie können insbesondere von einer Bedienperson eingegeben oder ausgewählt werden.
Mit der Erfindung wird es insbesondere möglich, aus Zeilendaten-Druckdatenströmen, die aus einer Datenbankabfrage gebildet wurden, die ursprüngliche Datenbankstruktur zu rekon- struieren und damit einen optimalen Eingangsdatenstrom für formatterbasierte Verfahren zu bilden.
Eine erfindungsgemäße Vorrichtung ist zur Durchführung des erfindungsgemäßen Verfahrens eingerichtet. Ein erfindungsge- mäßes Computerprogrammprodukt erzeugt bei seinem Laden und Ausführen auf einen Computer einen erfindungsgemäßen Verfahrensablauf.
In einer weiteren, vorteilhaften Weiterbildung der Erfindung wird aus einem Zeilendaten-Eingangsdruckdatenstrom direkt mit Hilfe der zuvor erzeugten Abbildungsvorschrift und der Strukturbeschreibungsdatei der Ausgangsdatenstrom erzeugt. Weiterhin kann es möglich sein, direkt aus der Strukturbeschreibungsdatei, insbesondere der pagedef-datei eines AFP- Zeilendatenstroms, Abbildungsvorschriften zu gewinnen, mit denen aus dem Zeilendaten-Eingangsdatendruckdatenstrom der seiten- und/oder bereichsweise strukturierte Ausgangsdatenstrom erzeugt werden kann.
In einem weiteren Aspekt der Erfindung, der alleine oder in Kombination mit den zuvor beschriebenen Aspekten der Erfindung gesehen werden kann, werden zum Erzeugen eines seiten- und/oder bereichsstrukturierten Ausgangs-Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Eingangs- Druckdatenstrom dem Zeilendaten-Eingangs-Druckdatenstrom ins- besondere mit einem Editor Formatierungselemente zugeordnet.
Nachfolgend werden Ausführungsbeispiele der Erfindung anhand einiger Figuren näher erläutert.
Es zeigen:
Figur 1 ein Hochleistungsdrucksystem,
Figur 2 die bekannte Verfahrensweise zur Verarbeitung von Druckdaten gemäß den AFP- und IPDS Spezifikationen,
Figur 3 die bekannte Verfahrensweise zur Verarbeitung von Druckdaten gemäß dem sogenannten Formatter-Prinzip,
Figur 4 ein Verfahren zum Aufbereiten von Druckdaten mit zusätzlichen Struktur- und Formatierungselementen,
Figur 5 die Aufbereitung von Datenbank-Daten in einem DokumentenverarbeitungsSystem,
Figur 6 die Verarbeitung eines Musterdatensatzes und eines Applikationsdatensatzes,
Figur 7 verschiedene Druckdatenstrukturen,
Figur 8 verschiedene Druckdatenstrukturen, Figur 9 Datenstrukturen der Figur 7 mit Beispiel- Datensätzen versehen,
Figur 10 einen Zeilendaten-Druckdatenstrom,
Figur 11 automatisch erzeugte, mit Strukturelementen verse-' hene Daten, die aus den Daten der Figur 10 gewonnen wurden,
Figur 12 einen seiten- und bereichsstrukturierten Druckdatenstrom, der aus den Daten der Figur 11 gewonnen wurde,
Figur 13 eine Softwarestruktur zum Erzeugen eines komplex formatierten Druckdatenstroms,
Figur 14 eine Legacy Anwendung,
Figur 15 einen verallgemeinerten Verfahrensablauf,
Figur 16 verschiedene bekannte Verfahrensabläufe zum Erzeugen von Dokumenten aus Datenbankendaten und
Figur 17 ein für den Menschen lesbar aufbereiteter Auszug aus einer Pagedef-Datei .
In Figur 1 ist ein Dokumenten-Druckproduktionssystem 1 gezeigt, das zum einen eine Main-Frame-Architektur 2 umfasst und zum anderen eine Netzwerk-Architektur 5, in denen jeweils Dokumentendaten bzw. Dokumentendruckdatenströme mittels Anwenderprogrammen (Tools) erzeugt werden. In der Main-Frame- Architektur 2 werden diese Druckdaten von einem Host-Computer 3, z.B. als AFP-Druckdatenstrom oder als Zeilendruckdaten- strom, erzeugt. Vom Host-Computer 3 können die Druckdaten wahlweise über einen sog. S/370-Kanal 14a direkt an einen o- der mehrere Druckgeräte 6a, 6b übertragen werden. Alternativ zu diesem Ausgabekanal können die Druckdaten auch vom Host- Computer 3 über ein Netzwerk 13 oder eine direkte Datenverbindung 14b zu einem Bearbeitungscomputer 4 übertragen werden, in dem die Druckdaten zwischengespeichert (z.B. in einem zugehörigen File-Server) und für nachfolgende Ausgabeschritte bearbeitet werden. In derartigen Host-Computern 3 werden insbesondere Druckdatenströme erzeugt, die aus größeren Datenbeständen (Datenbanken) regelmäßig Listen-Ausdrucke, Rechnungen, Verbrauchsübersichten (für Telefonrechnungen, Gasrechnungen, Bankkonten) etc. zusammenstellen. Derartige Anwen- düngen sind häufig bereits seit vielen Jahren im Einsatz und werden nach wie vor in mehr oder weniger unveränderter Weise benötigt (sog. Legacy-Anwendungen) .
Innerhalb der Main-Frame-Architektur 2 wird der Druckproduk- tionsablauf von einem Überwachungssystem 7 überwacht. Es um- fasst einen Überwachungscomputer 7a, der mit einer Datenbank 7b gekoppelt ist und verschiedene Computerprogrammmodule 7c enthält.
Das Überwachungssystem 7 ist über ein Gerätesteuerungsnetzwerk 15 und ein Printmanager-Modul 8 mit dem Host-Computer 3 verbunden sowie über einen Konverter 9 mit z.B. einer V24- Datenleitung, die an die beiden Druckgeräte 6a, 6b ankoppelt. Der Konverter 9 setzt die V24-Signale in DMI-Protokollsignale des Gerätesteuerungsnetzwerkes 15 um. SNMP-Protokollsignale können dem Device Manager DM als DMI-Protokollsignale umgesetzt bereitgestellt werden bzw. direkt als SNMP- Protokollsignale übergeben werden.
Druckgut 19, das in den Druckern 6a, 6b aus dem Dokumenten- Druckdatenstrom erzeugt wurde und auf dem Barcodes aufgedruckt sind, kann jeweils mit einem manuell bewegbaren, funkgesteuerten Barcode-Leser 11a abgescannt werden. Die Signale werden per Funk an die Lesestation 10a übertragen und in das Gerätesteuerungsnetzwerk 15 bzw. an das Überwachungssystem 7 übermittelt. Als Barcode-Leser können Leser für ein-dimensio- nale und/oder zwei-dimensionale Barcodes eingesetzt werden, sodass verschiedene Barcode-Systeme mit ein und derselben Lesevorrichtung gelesen werden können. Das Barcode-Lesesystem ist insbesondere konfigurierbar, d.h., auf verschiedene, anwendungsspezifische Codes bzw. die jeweils geeigneten Kon- trollverfahren anwendbar.
In der Netzwerk-Architektur 5 werden Dokumentendaten mittels Anwenderprogrammen in Client-Computern 12, 12a erzeugt, die über ein Client-Netzwerk 13 untereinander sowie mit dem Bear- beitungscomputer (File-Server) 4 verbunden sind. Der File- Server dient damit als zentrale Verarbeitungs- und Bearbeitungsschnittstelle für Druckdaten des gesamten Druckproduktionssystems 1. Auf ihm laufen diverse Steuerungsmodule (Softwareprogramme) , durch die der gesamte Druckproduktionsablauf bzw. die gesamte Dokumentenbearbeitung anwendungsspezifisch, produktionstechnisch und gerätesteuerungsseitig an die jeweiligen Gegebenheiten optimal angepasst wird.
Im File-Server lassen sich Steuerungsdaten, die im Ein- gangsdatenstrom vom Host-Computer 3 bzw. Anwender-Computer 12 an den Bearbeitungscomputer 4 geliefert worden sind, dahingehend filtern, dass solche Steuerungsdaten, die bei der gegebenen Gesamtsystemanordnung nicht benötigt werden, entfernt werden. Durch die Verbindung aller beteiligten Ausgabegeräte (Drucker 6a bis 6d, Schneidegerät (Cutter) 18a, Kuver- tiergerät 18b) über das Gerätesteuerungsnetzwerk 15, kann bereits im Bearbeitungscomputer 4 entschieden werden, welche Steuerungsdaten des Eingangsdatenstroms von keinem der angeschlossenen Geräte benötigt wird. Durch Entfernen dieser Da- ten aus dem Datenstrom kann der Datenstrom insgesamt reduziert werden, insbesondere dann, wenn lediglich leere Feldeinträge zu entsprechenden Steuerungsdaten im Eingangsdatenstrom enthalten sind.
Wenn im Zuge der Weiterverarbeitung der Daten, insbesondere bei der Ausgabe der Daten auf einem der Druckgeräte 6a, 6b, 6c oder 6d, in einem der Nachverarbeitungsgeräte 18a, 18b o- der auch im Druckcomputer 16, ein Fehler auftritt, so kann dies durch das Überwachungssystem 7 anhand der im Bearbeitungscomputer 4 eingefügten Steuerungs-Barcodes festgestellt werden und der Nachdruck der von der Störung betroffenen Do- kumente (Seiten, Blätter, Mail-Pieces) angefordert werden. Diese Wiederholungsdruck-Anforderung wird maßgeblich im Bearbeitungscomputer 4 gesteuert.
Druckdaten, die vom Bearbeitungscomputer 4 fertiggestellt wurden, werden über die Druckdatenleitung 14c an einen Druckserver 16 geleitet. Dessen Aufgabe ist es im wesentlichen, den Bearbeitungscomputer 4 zu entlasten. Dies erfolgt durch Zwischenspeicherung der fertiggestellten Druckdaten bis zu deren Abruf über die Datenleitung 14d an einen oder beide Drucker 6c, 6d. Der Druckserver 16 ist somit in erster Linie aus Gründen der Performance (Geschwindigkeit) im Gesamtsystem integriert. Bei Systemen, deren Druckgeschwindigkeit weniger groß ist, kann auf den Druckserver 16 auch verzichtet werden.
Dokumentendaten, die an die Drucker 6c bzw. auf eine 6b übermittelt und dort auf einen Aufzeichnungsträger (z.B. Papierbahn) gedruckt werden, werden im Gesamtsystem weiteren Bearbeitungsstufen, nämlich dem Schneidegerät 18a und dem Kuver- tierungsgerät 18b der weiteren Verarbeitung zugeführt. Damit ist der Druckproduktionsprozess abgeschlossen.
Die gedruckten Dokumente werden auf ihrem Verarbeitungsweg zwischen dem Druckgerät 6 und dem letzten Nachverarbeitungsgerät 18b hinsichtlich verschiedener Kriterien mit einem Testsystem 17 getestet, nämlich durch ein optisches Testsystem 17a hinsichtlich ihrer optischen Druckqualität, mit einem Barcode-Testsystem 17b hinsichtlich ihres Vorhandenseins, ihrer Konsistenz und/oder ihrer Reihenfolge sowie mit einem MICR-Testsystem 17c, sofern der Druck mittels magnetisch les- barem Toner (Magnetic Ink Character Recognition Toner) gedruckt wurde. Die vom Testsystem 17 gelieferten Daten der verschiedenen Testsysteme werden von einem gemeinsamen se- riellen Datenerfassungsmodul (Serial Data Aquisition Modul) 17d an das Gerätesteuerungsnetzwerk 15 übermittelt und dem Überwachungssystem 7 zugeführt. Dort werden die jeweiligen Systemdaten erfasst und in Echtzeit die Geräte überprüft so- wie die jeweiligen Positionen der Dokumente hinsichtlich ihrer Korrektheit bezüglich des Druckauftrages getestet.
Die fertig gedruckten Dokumente 23 können wiederum mit einem Barcode-Leser 11b erfasst werden, der z.B. funkgesteuert mit einer zugehörigen Steuerungseinrichtung 10b verbunden ist, welche wiederum über das Gerätesteuerungsnetz 15 ihre Daten an das Überwachungssystem 7 liefert.
In Figur 4 ist ein Verfahren zum Aufbereiten von Druckdaten mit zusätzlichen Struktur- und Formatierungselementen dargestellt, wie es in der nicht vorveröffentlichten WO-Al- 2004/040432 der Anmelderin beschrieben ist. Der Inhalt dieser Patentanmeldung wird hiermit durch Bezugnahme in die vorliegende Beschreibung aufgenommen.
Mit Hilfe des Layout-Editors werden dabei statische Ressourcen anhand eines vollständigen Druckdatenmusters erstellt. Dies sind die im AFP-Datenstrom bekannten Standardressourcen, wie Overlays, Pagesegmente, Fonts, Pagedef- und Formdef-Dateien. Druckdaten, die jedoch mittels der standardmäßig im AFP-Funktionsspektrum angebotenen Formatierungen nicht enthalten sind, werden jedoch nicht in eine AFP- Ressourcen-Datei geschrieben sondern in eine erweiterte, alle variablen Druckdaten enthaltende Druckdaten-Datei. Diese Da- tei wird zur individuellen Gestaltung mit besonderen Formatierungs-Elementen, z. B. grafischen Elementen wie Kuchendiagrammen oder Balkendiagrammen herangezogen. Dazu ist der Editor 26 derart erweitert, daß solche Formatierungen durchgeführt werden können. Das Grundkonzept der AFP-Datenstruktur, nämlich die Datentrennung zwischen variablen und statischen Daten wird dabei dennoch weitgehend beibehalten. Vom Formatter-Prinzip wird beibehalten, daß die Druckdaten vollständig an eine Zwischenstufe übertragen werden. In dieser Zwischenstufe werden - wie bei der Verarbeitung von AFP-Druckdaten vorgesehen - den Druckdaten Ressourcen zugeordnet und somit Formulare, Schriften etc. vereinheitlicht und in einen rela- tiv kleinen AFP-Ressourcen-Datenstrom umgesetzt. Dieser Ressourcen-Datenstrom wird über einen AFP-Kanal 36 übertragen.
Weiterhin werden aus den variablen Druckdaten diejenigen Daten herausgesucht, die bereits anderweitig formatiert sind oder bei denen keine performante Umwandlung bzw. Zuordnung von AFP-Ressourcen möglich ist. Diese Druckdaten werden dementsprechend um die benötigten Befehle erweitert (Data En- richment) . Diese Druckdatenerweiterung findet in einer sogenannten Design-Phase mittels eines geeigneten Editors statt, in dem entsprechende Musterdatensätze bzw. Automatik-Design- Datensätze untersucht werden und entsprechende Zuordnungen getroffen werden. Beispielsweise könnte eine Datentabelle herangezogen werden und der Befehl zugeordnet werden, daß aus den in der Datentabelle stehenden Zahlen ein Kuchendiagramm als grafisches Element zu erzeugen ist. Als Editor kann wahlweise ein geeignetes neues Computerprogramm zur Verfügung gestellt werden oder ein bereits bestehender Editor für eine bestimmte Drucksprache, beispielsweise ein AFP-Editor, wie der oben erwähnte Smart Layout Editor (SLE) der Anmelderin, um entsprechende Funktionen erweitert werden.
In einer produktiven Phase, das heißt während der variable Druckdatenstrom von der Datenquelle 25 an den Druckserver o- der direkt an eines der Druckgeräte 31, 32 übertragen wird, wird der entsprechend erweiterte Druckdatenstrom über den Datenkanal 37 an den Druckserver bzw. Drucker gesandt. Im Druckserver 28 bzw. Druckgerät 31, 32 wird der aufbereitete Druckdatenstrom mit den einmalig übertragenen AFP-Ressourcen kombiniert und schließlich der so kombinierte Datenstrom an den Drucker als IPDS-Datenstrom gesandt. Ein Ausdruck kann auch als Telefax an ein Faxgerät erfolgen, die Daten über einen E-Mail-Computer, beispielsweise über den Client- Computer 12 als E-Mail versandt werden oder über einen www- Server in das Internet gestellt werden.
Somit ist es einerseits möglich, Standard-Daten performant zu übertragen, weil diese Daten nicht durch Formatierungsanweisungen überladen sind und andererseits, diejenigen Datenformate, welche nicht oder nur umständlich in AFP beschreibbar sind, einfach und schnell an den Druckserver zu übertragen.
Bei der oben beschriebenen Verfahrensweise ist vorgesehen, die aus AFP-Umgebungen bekannte Verarbeitungsweise um mindestens eine Funktionalität zu erweitern, durch die innerhalb der Druckdaten Formatierungsanweisungen, wie die Darstellung grafischer Daten, z.B. der Umwandlung in Kuchen- bzw. Balken- diagramme oder der Hinzufügung von Komponenten, wie Barcodes, Bilder und anderer Objekte übertragen werden können.
Ein Vorteil der beschriebenen Lösung ist dabei einerseits die Arbeitskompatibilität zu den bekannten Umfeldern und zum an- dern die Möglichkeit, bestehende, immer wiederkehrende Druckaufträge weiterhin verwenden zu können. Somit kann eine 100%- ige Abwärtskompatibilität des Verfahrens in Druckproduktionsumgebungen gewährleistet werden. Druckdatenströme, die unter früheren Editoren erzeugt wurden, wie z. B. Zeilendatenströme (Line Data Streams) können weiterhin direkt über ein erweitertes Layout bzw. Editormodul an den Printserver bzw. Drucker übertragen werden. Dazu wird lediglich eine früher erzeugte pagedef-Datei in ein Dokument-Template übernommen.
In Figur 5 ist gezeigt, wie Computerprogrammprodukte so zusammenwirken, daß Daten, die aus einer SAP-Datenbankanwendung stammen, mit Formatierungsinformationen aufbereitet und in einem Druckproduktionssystem so aufbereitet werden, daß sie an ein Druckgerät gesandt werden können. Von der SAP- Datenbankanwendung 40 werden SAP-spezifische RDI-Druckdaten über ein Ausgabedaten-Managementsystem 41 (Output Management System) und eine SAP-Schnittstelle 42 (SAP Connector) an ein Druckproduktionssystem 43 gesandt. Dort werden Druckaufträge von einem Auftragsverteilungssystem 44 (Order Distribution System) für die weitere Verarbeitung verwaltet. Jeder Druckauftrag wird dabei mittels eines Druckauftragsmanagers 45 (PrintJob Manager) individuell gekennzeichnet und mit Druckauftragsdaten, beispielsweise für einen gewünschten Ausgabedrucker oder einer gewissen Priorität, versehen. Diese Daten stehen in einer Druckauftrags-Begleitdatei 46 (Jobticket) . Zur Aufbereitung von Druckdaten aus einer Anwenderdatenbank dient ein Datenerweiterungs-Modul 47. Dieses umfaßt zwei Computerprogramm-Module 48, 49, die zu verschiedenen Zeitpunkten benötigt werden.
In einer Datenvorbereitungsphase werden die Daten eines Mus- terdatensatzes aus einer Anwendungsdatenbank 50 (z.B. SAP Datenbank) herangezogen und mittels des Designer-Moduls 48 geeignete Formatierungs- und sonstige Ergänzungsdaten an den Musterdatensatz angehängt, um diesen nach Wunsch eines Anwenders aufzubereiten. Geeignete Erweiterungsdaten 51 werden dann über das Auftragsverteilungssystem 44 an das Dokumenten- Generator-Computerprogramm 49 übermittelt. Mit dem Dokumen- ten-Generator-Computerprogramm 49 werden zudem die RDI-Daten sowie die zugehörigen Formatierungsdaten in ein internes vorgegebenes, an ein Drucksystem gekoppeltes oder von einem An- wender ausgewähltes Druckdatenformat umgewandelt. Die Umwandlung kann dabei z. B. in einen AFP-Datenstrom, einen PCL- Datenstrom, einen PostScript-Datenstrom oder auch einen PDF- Datenstrom erfolgen.
Das Computerprogramm-Modul 49 verwendet die Erweiterungsdaten in einer zweiten Verarbeitungsphase, in der die vollständigen Datenbankdaten von der SAP-Datenbankanwendung 40 über die SAP-Schnittstelle 42 übermittelt werden, Datensatz für Datensatz mit den Erweiterungsdaten anzureichern. Auf diese Weise entstehen personalisierte Dokumente 52, die über das Auftragsverarbeitungssystem 44 als Druckdateien 53 an ein Sammelprogramm 54 (Spool) oder als direkte Druckdaten über ein Druckertreiber-Modul 56 an einen Drucker (in Figur 5 nicht gezeigt) ausgegeben werden.
In Figur 6 sind die Datenverarbeitungsvorgänge dargestellt, die einerseits in der Vorbereitungsphase (Design-Phase) und andererseits in der produktiven Phase (Druckphase) durchgeführt werden um Druckdaten aus beliebigen Quellen aufbereiten zu können. Ein Probedatensatz bzw. ein Probedokument 60, das aus dem Zeilendaten-Datenstrom stammt, wird zur Design-Phase über ein Import-Modul 61 als Design-Datensatz 62 in das Designer-Computerprogramm 48 geladen. Anhand dieses Programms 48 werden beliebige Formatierungs- bzw. Ergänzungsinformationen zu dem Design-Datensatz 62 hinzugefügt und somit die Design-Informationsdatei 63 gebildet. In der Design-Phase wird außerdem mittels der pagedef-Datei und Musterdaten automatisch ein Automatik-Design-Datensatz gebildet und manuell, teilautomatisch oder vollautomatisch anhand eines logischen Vergleichs des Automatik-Design-Datensatzes und des Design- Datensatzes 62 eine Abbildungsvorschrift erzeugt.
Zur Druckphase werden Applikations-Datensätze 64 des Zeilendaten-Druckdatenstroms Datensatz für Datensatz eingelesen und mittels eines Übersetzungs-Computerprogramm-Moduls 65 des Do- kumenten-Generator-Computerprogramms 49 in ein internes Da- tenformat 66 übersetzt. Der Translator 65 bildet mittels der in der Design-Phase gewonnenen Abbildungsvorschrift bzw. der diese Abbildungsvorschrift enthaltenden Regeldatei aus dem Applikations-Datensatz 64 den Applikations-Datensatz im internen Datenformat 66, auf das dann ein Computerprogramm- Modul "Formatter" des Dokumenten-Generator-Computerprogramms 49 unter Verwendung der Design-Informationsdatei 63 angewandt wird.
Das Formatter-Computerprogramm-Modul 67 erzeugt aus den Druckdaten im internen Datenformat und den durch den Design- Prozess definierten Formatierungsvorschriften, die in der Design-Informationsdatei 63 hinterlegt sind, das personalisier- te Dokument 68. Ein Datentransformations-Modul 69 (AFP- Transformer) wandelt die personalisierte Dokumentendatei 68 in eine Druckdatei 70 um.
In Figur 15 ist der oben beschriebene Verfahrensablauf nochmals verallgemeinert dargestellt. Zur Umwandlung der Eingangsdaten 105 in die normierten Daten 104 dient ein Übersetzungsstufenmodul 94, das von der Regeldatei 77 gesteuert wird. Die Regeldatei 77 enthält Abbildungsvorschriften in Form von Mapping-Regeln, die in der Design-Phase aus den Ein- gangsdokumentendaten 105 bzw. aus dem daraus abgeleiteten Automatik-Design-Datensatz und dem ebenfalls erstellten Design- Datensatz 62 und ggf. aus eingangsdatenspezifischen Hilfsdateien 119 gebildet wurden. Sowohl der Design-Datensatz 62 als auch die Regeldatei 77 können frei editierbar sein. Der Design-Datensatz 62 kann bei der Bildung eines Dokumententemplates 112 verwendet werden, das die Formatierung des normierten Datenstroms 104 (in Stufe 113) steuert. Wie mit den Pfeilen Ai und A2 dargestellt, kann der Design-Datensatz 62 und aus diesem die Regeldatei 77 auch aus dem Dokumententemplate 112 erzeugt werden.
Die in der Regeldatei 77 angegebenen Mapping-Regeln sind spezifisch für den Eingangsdokumentendatenstrom 105. Sie geben an, welches Element des Eingangsdokumentendatenstroms 105 zu welchem Element des Design-Datensatzes zuzuordnen ist. Der Design-Datensatz 62 enthält die Strukturdefinition der normierten Daten, wobei Typ-Deklarationen vorgesehen sind für verschiedene Strukturelemente, z.B. für Kundennummern, Namen, Logos, Bilder usw. In den normierten Rohdaten 104 können dann auch Datengruppen gebildet werden, die zusammengehören, insbesondere all diejenigen Daten, die zu einem Dokument gehören. Somit sind für jedes Dokument alle dazugehörigen Daten im normierten Rohdatenstrom 104 verfügbar. Ein Dokumenten- Template 112 dient als Strukturvorlage für die zu erzeugenden Dokumente und beschreibt, welche Formatierungsanweisungen im normierten Datenstrom hinzuzufügen sind. Es kann Elemente aus dem Design-Datensatz 62 enthalten und/oder frei programmierte statische oder dynamische Elemente 96 93, 15 enthalten. Das Dokumenten-Template 112 ist somit dokumentenformatierungsab- hängig und dient dazu, die Formatbildungseinrichtung 113 (Formatter oder document composition engine) zu steuern.
Aus dem normierten Rohdatenstrom 104 wird durch die Formatierungsbildungseinrichtung 113 dokumentenweise ein ressourcenorientierter Datenstrom gebildet. Soweit bereits in den Roh- daten Formatierungen enthalten waren, werden diese beibehalten und soweit die Rohdaten unformatiert sind und im Dokumenten-Template zu den entsprechenden Datenfeldern Formatierungsangaben enthalten sind, werden diese ressourcenorientiert in der Formatbildungseinrichtung 113 hinzugefügt, wobei Ressourcen, die mehrfach innerhalb eines Datenstromes benötigt werden performanceoptimiert weiterverarbeitet werden, d.h., daß sie im ressourcen-orientierten Datenstrom hauptsächlich durch Aufrufen der Ressourcen eingefügt werden, wobei die Ressourcen selbst nur einmal intern vorhanden sind, oder extern von einer Ressourcen-Datei geladen oder auch nur referenziert werden können. Zur Bearbeitung von Dokumenten- Template 112, Design-Datensatz 62 und Regeldatei 77 kann es vorteilhaft sein, diese Dateien in der Weise zu koppeln, daß eine Veränderung in einer der Dateien zu einer Konsistenz-, Prüfung und ggf. Modifikation in den beiden anderen Dateien führt.
Der formatierte Dokumentendatenstrom 114 wird dann einer Ba- ckend-Einrichtung 118 zugeführt, in der er in den durch eine Ausgabeselektionsdatei 119 gesteuerte Ausgabesprache wahlweise als Druckdatenstrom 120 oder über eine Schnittstelle 121 für ein Ausgabegerät (Telefax, email-Server, www-Server, Monitor) aufbereitet wird. Desgleichen kann der normierte Datenstrom 104 und/oder der formatierte Datenstrom 114 bereits gerätespezifisch optimiert werden. Details hierzu sind in der WO-A2-01/78000 beschrieben, die hiermit durch Bezugnahme in die vorliegende Beschreibung aufgenommen wird. In den Figuren 7 bis 13 und 17 wird das Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten- Druckdatenstrom näher erläutert. In Figur 7a ist ein zeilenweise strukturierter AFP-Zeilendaten-Druckdatenstrom strukturell gezeigt, wobei die Zeilendaten (Line 01, Line 02,...) 80 zeilenweise strukturiert aufeinanderfolgen. Den AFP Zeilendaten ist eine Strukturbeschreibungsdatei „Pagedef" zugeordnet, die beim Ausdrucken der Zeilendaten 80 die Anordnung der jeweiligen Daten auf der Seite festlegt. Verwendet man diese Pagedef-Datei, kann aus den zeilenweise strukturierten Zeilendaten 80 anhand der Anweisungen aus der Pagedef-Datei automatisch eine neue Datenstruktur 81 erzeugt werden, in der einerseits zusammengehörige Seitengruppen sowie einzelne Seiten dargestellt werden, und andererseits innerhalb jeder Seite die aus der Pagedef-Datei stammenden Zeilendiskriptoren (LND) den jeweiligen Feldern aus der Zeilendatenstruktur zugeordnet sind. Anhand dieses seitenweisen Aufbaus der Daten- Struktur läßt sich dann mittels von einem Bediener eingegebenen oder ausgewählten Daten eine Regeldatei (Zuordnungsdatei) bilden, mit der aus dem seitenweise strukturieren Datenstrom
81 ein bereichsweise strukturierter, mit Feldkennungen 82 (Customer, Street, City, ... ) versehener endgültig gekenn- zeichneter Datenstrom mit der in Figur 7c gezeigten Struktur
82 erzeugt werden kann, bei dem jeder Feldkennung ein Feld des Eingangsdatenstroms 80 zugeordnet ist.
Die automatisch erzeugte, gekennzeichnete Datenstruktur 81 ist ein erstes Ausführungsbeispiel für einen automatisch er- zeugten Design-Datensatz. Sie enthält im vorliegenden Fall v.a. Feldnamen als Information. Sie kann jedoch zusätzliche weitere Kenndaten enthalten wie z.B. Fontinformationen und Positionsinformationen, die insbesondere aus der pagedef- Datei gewonnen werden können. Die automatisch erzeugte, ge- kennzeichnete Datenstruktur 81 bzw. der automatisch erzeugte Design-Datensatz gibt Strukturinformationen der pagedef-Datei wieder, insbesondere im Hinblick auf Datenfelder, die erkannt werden müssen.
Während die automatisch erzeugte, gekennzeichnete Datenstruk- tur 81 hinsichtlich der Dateninhalte strukturlos ist, weist die endgültig gekennzeichnete Datenstruktur 82 eine inhaltliche Struktur auf. Im vorliegenden Beispiel entspricht die inhaltliche Struktur einer Flugübersicht eines Fluggastes, wobei verschiedene inhaltliche Strukturkriterien durch die Feldnamen „Customer", „Street",... „Connection" , ... „Flight NO" usw. repräsentiert werden.
Die endgültig gekennzeichnete Datenstruktur 82 stellt einen strukturierten Musterdatensatz dar, in dem strukturell zusa - mengehörige Zeilendaten-Druckdaten bereichsweise inhaltlich strukturiert zusammengestellt sind. Anhand dieses Musterdatensatzes und der Zeilendaten-Druckdaten kann dann der Seiten- und/oder bereichsstrukturierte Datenstrom erzeugt werden, der als Eingangsdatenstrom für einen Formatter geeignet ist.
In Figur 8 ist eine ähnliche Datenstromstruktur dargestellt wie in Figur 7, wobei dort die Zeilendaten 80a durch die Strukturbeschreibungsdatei (Pagedef) in zwei Seitentypen auf- geteilt wird und wobei in jedem Seitentyp unterschiedliche Zeilendiskriptoren zum Einsatz kommen. Dadurch kann z. B. bewirkt werden, daß beim Seitentyp 1 jeweils Name und Anschrift des Flugkunden wiedergegeben werden, während beim Seitentyp 2 nur die Kundennummer und die Flugverbindungen angegeben sind, aber nicht der Kundenname usw. Die Datenstruktur 82a des Musterdatensatzes, die die inhaltliche Struktur wiedergibt, ist dabei jedoch identisch zur entsprechenden Datenstruktur 82 der Figur 7. Die automatisch erzeugte, markierte Datenstruktur 81a ist ein weiteres Ausführungsbeispiel für einen auto- matisch generierten Design-Datensatz. In Figur 9a ist ein Zeilendatenstrom 83 dargestellt, der für Herrn Heinz Mustermann drei Flugverbindungen, München - Singapur, München - New York und München - Wien enthält. Aus der Interpretation der zugehörigen Pagedef wird automatisch der gekennzeichnete Datenstrom 84 erzeugt, wobei jedem Datum des Zeilendatenstroms 83 der entsprechende Zeilendiscriptor (LND) der Pagedef zugeordnet ist, die dieses Zeilendatum verarbeitet. Zusätzlich ist im Datenstrom 84 die Seitenstruktur gekennzeichnet (Figur 9b) . In Figur 9c ist der inhaltlich und bereichsweise strukturierte Datenstrom 85 dargestellt, der aus dem automatisch erzeugten, gekennzeichneten Datenstrom 84 sowie einer Regeldatei gebildet wird, welche die jeweilige Abbildungsvorschrift der Datenfelder sowohl zu einem Feldnamen als auch zu einem oder mehreren Gruppennamen (Customer, Connection) enthält. Die Regeldatei wird vollautomatisch, teilautomatisch oder manuell erzeugt, wobei vorzugsweise die Datenstruktur des Automatik-Design-Datensatzes verwendet wird. Im vorliegenden Beispiel ist erkennbar, dass eine Flugverbindung jeweils acht Einträge hat, d. h. jeder neunte Ein- trag wiederum eine neue Flugverbindung darstellt. Zur Erkennung einer solchen Struktur kann genauso gut auch nach gewissen Kanalsteuerzeichen gesucht werden, beispielsweise das Kanalsteuerzeichen 1, welches bedeutet, dass ein neues Dokument beginnt. Sobald für alle Bereiche des Datenstroms derartige Regeln bzw. Triggermechanismen zur Erkennung der Bereiche festgelegt worden, kann aus einem Zeilendaten-Druckdatenstrom direkt ein inhaltlich bereichsstrukturierter Datenstrom automatisch erzeugt werden. Um sicherzustellen, dass alle denkbaren Datenkonstellationen, die mit einer vorgegebenen Struk- turbeschreibungsdatei zu verarbeiten sind, in einen inhaltlich bereichsstrukturierten Datenstrom umgesetzt werden können, kann insbesondere maschinenunterstützt geprüft werden, ob alle Formatierungsvorschriften, insbesondere Zeilen- diskriptoren, der Strukturbeschreibungsdatei zu einer ent- sprechenden Bereichserkennungs- bzw. Gruppenerkennungsregel in der Regeldatei umgesetzt worden ist. In Figur 9c ist ein entsprechender, inhaltlich bereichsstrukturierter Datenstrom 85 gezeigt, der mit der entsprechenden Regeldatei direkt aus dem Eingangszeilendatenstrom 83 erzeugt werden kann.
Zum Erzeugen des automatisch generierten Designdatensatzes wird als Strukturbeschreibungsdatei insbesondere eine Seitendefinitionsdatei wie z. B. eine an sich übliche und z.B. aus den in der Einleitung genannten Dokumenten des Stands der Technik bekannte Pagedef-Datei oder eine entsprechende Skript-Datei aus einem Seitenformatierungstool wie dem IBM- Page Printer Formatting Aid verwendet. Zusätzlich können ihnen zugeordnete Ressourcen wie Fonts, Codepages oder Pagesegmente verwendet werden sowie eine Seitenzuordnungsdatei wie ein AFP Formdef, ggf. mit ihr zugeordneten Ressourcen wie Fonts, Codepages, Overlays oder Pagesegmente verwendet werden.
In Figur 10 ist ein etwas komplexerer Zeilendatenstrom 83a dargestellt, bei dem zusätzlich zu verschiedenen Verbindungen eines Fluggastes noch Daten von anderen Fluggästen enthalten sind.
Die Figuren 11a, 11b und 11c zeigen, wie mittels einer ent- sprechenden Seitenbeschreibungsdatei eine Seitenstruktur erzeugt wird, bei der für jede Person eine neue Seite begonnen wird und die Flüge einer Person auf einer oder mehreren Seiten dargestellt sind.
In dem Zeilendatenstrom 83a benutzte, kundenspezifische Codepages können im Zuge der Bildung des seiten- und/oder bereichsweise strukturierten Datenstroms umkodiert, zum Beispiel nach Unicodes konvertiert werden. Weiterhin können grafische Objekte, Bilder und so weiter in entsprechend typi- sierte, normierte Nutzdatenfelder des seiten- und/oder bereichsweise strukturierten Datenstroms konvertiert werden. In den Figuren 12a, 12b und 12c ist der endgültig gekennzeichnete Datenstrom 85a dargestellt, der aus dem Zeilendatenstrom 83a gebildet wird und gruppenweise bereichsweise strukturiert ist. Das Feld „Customer" enthält dabei jeweils Anrede, Vorname und Nachname des Fluggastes und wird jeweils mit diesen drei Angaben als ein Feld geführt. Ein derartiges kombiniertes Feld kann jedoch jederzeit in seine Einzelbestandteile zerlegt werden und somit aus einem solchen Feld mehrere Felder erzeugt werden, die jeweils einem entsprechen- den Eintrag in einer Datenbank entsprechen. Der Datenstrom 85a dient für die weitere Verarbeitung als Eingangsdatenstrom eines Formatters.
In Figur 13 ist ein Ausführungsbeispiel dargestellt, bei dem ein Zeilendaten-Druckdatenstrom mittels eines Zeilendatenge- nerators aus einer Datenbank 130 erzeugt wird, mit den zuvor beschriebenen Maßnahmen einem Zeilendaten-Vorprozessor 91 zugeführt wird, in dem der Zeilendaten-Druckdatenstrom zu einem seiten- und/oder bereichsstrukturierten Datenstrom umgewan- delt wird und dieser Datenstrom einem Formatter 92 zugeführt wird, in welchem dem Datenstrom zusätzliche Formatierungselemente hinzugefügt werden. Der so vollständig formatierte Datenstrom wird dann einem Ausgabegerät 93 zugeführt, wobei dem Datenstrom verschiedene Ressourcen 94 wie Overlays und Fonts hinzugefügt werden können. Diese Ressourcen können mit bekannten Ressourcegeneratoren 95 erzeugt werden und werden zudem genutzt um den Zeilendaten-Vorprozessor 91 zu steuern (Linedata Import Dialog) und das im Formatter 92 erzeugte Layout zu steuern (Layout Import Dialog) .
In Figur 14 ist eine sogenannte Legacy Anwendung dargestellt, bei der AFP Zeilendaten-Druckdaten 134 in einer kundenspezifischen Anwendung 131 erzeugt werden, wobei Rohdaten aus einer Datenbank 130 entnommen und zeilen- und/oder seitenorien- tiert ausgegeben werden. Zusätzlich werden Begleitdateien wie eine Pagedef-Datei 132 und eine Formdef-Datei 133 und ggf. weitere Ressourcen wie Fonts 135, Overlays 136, Codepages 137, Pagesegmente 138 und so weiter bereitgestellt. Wenn aus dem Zeilendaten-Druckdatenstrom 134 ein Ausgabedruckdaten- strom erzeugt ' werden soll, z.B. zur Ausgabe auf einem Druckgerät oder in ein Archiv, dann werden die Zeilendaten mit den Begleitdateien bzw. Ressourcen mittels eines Aufbereitungsprogramms 104 wie z.B. dem eingangs genannten Programm Oce PRISMAproduction™ wieder zusammengeführt bzw. kombiniert.
In Figur 17a ist ein für den Menschen lesbar aufbereiteter Auszug aus einer Pagedef-Datei „Pl redbar" dargestellt, mit der eine Legacy-Druckdatenanwendung aus den in Figuren 7 bis 12 dargestellten Zeilendaten erzeugt wird. In der ersten Spalte 100 des Auszugs sind die fortlaufenden Nummern der structured fields in der pagedef Datei angegeben.
Die Parameter, die in den einzelnen structured fields enthalten sind, werden hinter den Gleichheitszeichen hexadezimal (in Maschinencode) aufgelistet. In dem Ausschnitt sind Line- Descriptor structured fields (LNDs) zu sehen, die als Quellen zur Erstellung des Automatic Design Datensatzes verwendbar sind.
Ein Zeilendatenstrom wird mit den Maschinenbefehlen Zeile für Zeile abgearbeitet.
Die Erfindung wurde anhand von Ausführungsbeispielen beschrieben. Dabei ist klar, daß der Fachmann jederzeit Abwandlungen angeben kann. Insbesondere sind die genannten Druckdatensprachen nur beispielhaft zu verstehen, da diese sich ste- tig weiterentwickeln wie zum Anmeldezeitpunkt der vorliegenden Anmeldung an den beiden Druckdatensprachen Extensible Mark-up language (XML) und Personalized Printer Mark-up Lan- guage (PPML) deutlich wird.
Die Erfindung wurde insbesondere anhand von AFP- Beispielsdatenströmen und Dateien beschrieben. Es ist jedoch klar, dass die Erfindung auch für andere Zeilendatenströme mit dort entsprechenden Daten bzw. Dateien anwendbar ist und nicht auf AFP-Datenströme beschränkt ist.
Weiterhin ist das beschriebene Druckverfahren nicht auf be- stimmte Bedruckstoffe wie Papier oder auf bestimmte Aufzeichnungsträgerformen wie Endlos-Bahnen oder Einzelblätter beschränkt .
Die Erfindung ist insbesondere dazu geeignet, als Computer- programm (Software) realisiert zu werden. Sie kann damit als Computerprogramm-Modul als Datei auf einem Datenträger wie einer Diskette , DVD- oder CD-Rom oder als Datei über ein Daten- bzw. Kommunikationsnetz verbreitet werden. Derartige und vergleichbare Computerprogramm-Produkte oder Computerpro- gramm-Elemente sind Ausgestaltungen der Erfindung. Dabei ist klar, daß entsprechende Computer, auf denen die Erfindung angewandt wird, weitere, an sich bekannte technische Einrichtungen wie Eingabemittel (Tastatur, Mouse, Touchscreen) , einen Mikroprozessor, einen Daten- bzw. Steuerungsbus, eine An- Zeigeeinrichtung (Monitor, Display) sowie einen Arbeitsspeicher, einen Festplattenspeicher und eine Netzwerkkarte enthalten können.
Bezugszeichenliste
la...lc erste Gruppe von Dokumenten
2a...2c zweite Gruppe von Dokumenten 3a...3c mailpieces (Sendungen)
3 Host Computer
4 Bearbeitungscomputer (File Server)
5 Netzwerk-Architektur
6 Ausgabegerät 7 Überwachungssystem
7a Überwachungscomputer
7b Datenbank
7c Computerprogramm-Modul
8 Print Manager 9 Konverter
10a, 10b Lesestation
11a, 11b Hand-Barcodeleser
12, 12a Client-Computer (Anwendernetzwerk)
13 Netzwerk für Client 14a...14d Druckdatenleitung
15 Gerätesteuerungsnetzwerk
16 Druckserver 16a Bildschirm
17 Testsystem 17b Barcode Testsystem
17c MICR-Testsystem
17d Datenerfassungs-Modul
18a Schneidegerät
18b Kuvertierer 19 Druckgut
20a, 20b Formatierungs-Computerprogramm
23 gedruckte Dokumente
25 Druckdatenquelle
26 Editor
27 AFP-Ressourcen-Datenstrom Print Server Druckdatenweg „Muster"-Weg Druckgerät Druckgerät Gerätetreiber Datenarchiv Formatter AFP-Kanal Data Enrichment Kanal Druckauftragssammelmodul Auftragseingangssystem (JES) SAP-Datenbankanwendungen SAP-Ausgabedaten-Management-System SAP-Schnittstelle Druckproduktionssystem Auftragsverteilungssystem Druckauftragsmanager Druckauftragsbegleitdatei Datenerweiterungs-Modul Designer-Computerprogramm Dokumenten-Generator-Computerprogramm SAP-Anwenderdatenbank Erweiterungsdaten Personalisierte Dokumente Druckdatei Spool-Computerprogramm Druckdaten Druckertreiber
Probedatensatz Import-Modul Designdatensatz Design-Informations-Datei Applikationsdatensatz Übersetzung Applikationsdatensatz mit internen Datenformat Formatter-Computerprogramm-Modul Personalisiertes Dokument Transformations-Modul Druckdatei Dokumenten-Template Formatbildungseinrichtung Formatierter Dokumentendatenstrom PPML-Daten Seitenextraktions-Modul Ausschießprogramm Backend-Einrichtung Hilfsdatei , 80a Zeilendatenstruktur, 81a automatisch erzeugte, gekennzeichnete Datenstruktur, 82a endgültig gekennzeichnete Patenstruktur, 83a Zeilendatenstrom, 84a automatisch erzeugter gekennzeichneter Datenstrom, 85a endgültig gekennzeichneter Datenstrom Zeilendatengenerator Zeilendaten- Vorprozessor Formatter Ausgabegerät Ressourcen Ressourcengenerator 0 Zeilennummern-Spalte 4 Aufbereitungsprogramm5 6 Strukturfenster7 Deskriptor-Fenster8 Seitendeskriptor9 Zeilendeskriptor-Tabelle 130 Datenbank
131 kundenspezifische Anwendung
132 pagedef-Datei
133 formdef-Datei
134 Zeilendaten
135 Fonts
136 Overlays
137 Codepages
138 pagesegmente

Claims

Patentansprüche
1. Verfahren zum Erzeugen einer AbbildungsVorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druck- datenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, wobei eine vorgegebene, dem zeilenweise strukturierten Druckdatenstrom zugeordnete Strukturbeschreibungsdatei verwendet wird.
2. Verfahren nach Anspruch 1, wobei ein Design-Datensatz festgelegt wird, welcher der Ausgangs-Datenstruktur entspricht und die Abbildungsvorschrift derart erzeugt wird, dass sie eine Abbildung zwischen Einträgen der Strukturbeschreibungsdatei und Einträgen des Design-Datensatzes beschreibt.
3. Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Ausgangs-Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom, dem eine Strukturbeschreibungsdatei fest zugeordnet ist, wobei ein Design-Datensatz erzeugt wird, der die Ausgangs- Datenstruktur beschreibt, eine Abbildungsvorschrift zwischen der Strukturbeschreibungsdatei und dem Design- Datensatz gemäß Anspruch 1 oder 2 erzeugt wird und mit- tels der Abbildungsvorschrift aus dem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom der Seiten- und/oder bereichsstrukturierten Ausgangs-Datenstrom erzeugt wird.
4. Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Druckdatenstrom, wobei
- aus Zeilendaten-Druckdaten des Zeilendaten- Druckdatenstroms unter Verwendung mindestens einer ihnen zugeordneten Strukturbeschreibungsdatei ein Automatik- Design-Datensatz automatisch erzeugt wird, in dem struk- turell zusammengehörige Druckdaten und/oder ihnen zugeordnete Kenndaten seiten- und/oder bereichsweise strukturiert zusammengestellt sind,
- mittels eines Design-Datensatzes, der eine vorbestimmte Datenstruktur beschreibt und des Automatik-Design- Datensatzes eine Abbildungsvorschrift erzeugt wird, die die Abbildung von Daten des Automatik-Design-Datensatzes auf den Design-Datensatz beschreibt und
- unter Verwendung des Design-Datensatzes, der Abbildungsvorschrift (77) und der Zeilendaten-Druckdaten der seiten- und/oder bereichsstrukturierte Datenstrom erzeugt wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei als Strukturbeschreibungsdatei eine Seitendefinitions-Datei (pagedef) verwendet wird.
6. Verfahren nach Anspruch 4 und Anspruch 5, wobei zum Erzeugen des Automatik-Design-Datensatzes und/oder zur Bildung der Abbildungsvorschrift zusätzlich zur Seitendefi- nitions-Datei (pagedef) , eine ihr zugeordnete Seitenzuordnungsdatei (formdef) und/oder zugeordnete Ressourcen, insbesondere Fonts, Codepages, Overlays und/oder Pagesegmente und/oder ihnen zugeordneten Ressourcen verwendet werden.
7. Verfahren nach Anspruch 4 und insbesondere einem der vor- hergehenden Ansprüche, wobei zur Erzeugung des Automatik- Designdatensatzes Feldpositionen aus der Strukturbeschreibungsdatei entsprechenden Datensätzen des Zeilendaten-Druckdatenstroms zugewiesen werden.
8. Verfahren nach Anspruch 4 und insbesondere einem der vorhergehenden Ansprüche, wobei vor dem Erzeugen des Automatik-Designdatensatzes eine Zwischendatei erzeugt wird, in der inhaltlich und/oder strukturell zusammengehörige Zeilendaten-Druckdaten innerhalb einer Strukturklammer zu- sammengefasst werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei als Zeilendaten-Druckdaten Advanced Function Presentation Zeilendaten-Druckdaten verwendet werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Ausgangsdatenstrom in Unicode kodiert wird.
11. Verfahren nach Anspruch' 10, wobei Code Pages von FontZuweisungen aus der Strukturbeschreibungsdatei auf Konsistenz mit der Unicode-Kodierung überprüft werden und Kon- flikte, insbesondere solche, die durch kundenspezifische Symbole oder normabweichende Belegungen der Code Pages entstehen, durch codespezifische Abbildungen nach Unicode aufgelöst werden.
12. Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei zum Erzeugen der Abbildungsvorschrift die Strukturbeschreibungsdatei (pagedef, formdef, PPFA Skript Datei) , zumindest Teile des Zeilendatenstro s und/oder von einem Bediener eingegebene und/oder ausgewählte Daten verwendet werden und eine Regeldatei gebildet wird, die die Abbildungsvorschrift enthält und die zum Erzeugen des seiten- und/oder bereichsstrukturierten Druckdatenstroms verwendet wird.
13. Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Datenstrom Datenpaare aus Feldken- nungen und zugehörigen Feldwerten enthält.
14. Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Datenstrom Gruppen zusammengehöriger Datenfelder enthält.
15. Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Druckdatenstrom als kommaseparierter Werte-Druckdatenstrom oder als Extensible Markup Lan- guage Datenstrom erzeugt wird.
16. Verfahren zum Erzeugen eines formatierten Druckdatenstroms, wobei nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche aus einem Zeilendatenstrom ein seiten- und/oder bereichsstrukturierter Datenstrom gebildet wird, der seiten- und/oder bereichsstruk- turierte Datenstrom oder ein davon abgeleiteter Datenstrom als Eingangsdatenstrom für einen Formatter (67) verwendet wird und im Formatter (67) der formatierte Druckdatenstrom gebildet wird.
17. Verfahren nach Anspruch 16, wobei als formatierter Druckdatenstrom ein MO: DCA-Daten-Strom gebildet wird.
18. Verfahren nach Anspruch 16 oder 17, wobei dem Formatter- Eingangsdatenstrom durch den Formatter (67) insbesondere von einer Bedienperson eingegebene oder ausgewählte Struktur- und/oder Formatierungselemente hinzugefügt werden.
19. Verfahren nach einem der Ansprüche 16, 17 oder 18, wobei dem Formatter (67) ein Dokumenten-Template (112) zugeführt wird, wobei der seiten- und/oder bereichsstrukturierte Datenstrom in ein internen Datenformat (66) umgewandelt wird, den Daten im internen Datenformat (66) bedarfsweise, gesteuert durch das Dokumenten-Template (112) , eine Dokumentenformatierungsinformation hinzugefügt wird, die festgelegt, wie der Inhalt des Datenstroms im internen Datenformat im formatierten Druckdatenstrom dargestellt wird, und die Daten als formatierter Druckdatenstrom ausgegeben werden.
20. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Abbildungsvorschrift automatisch erstellt wird und wobei Heuristiken angewendet werden, die Druckanweisungen der Strukturbeschreibungsdatei und/oder ihnen zugeordnete Kenndaten gemäß ihren tatsächlichen Aufrufen beim Abarbeiten von Zeilendaten des zeilenweise strukturierten Druckdatenstroms analysieren und/oder interpretieren.
21. Verfahren nach einem der vorhergehenden Ansprüche, wobei dem Zeilendaten-Eingangs-Druckdatenstrom Formatierungselemente zugeordnet werden, bevor der seiten- und/oder bereichsstrukturierten Ausgangs-Datenstrom erzeugt wird.
22. Verfahren nach Anspruch 21, wobei die Zuordnung der Formatierungselemente mit einem Editor (26) erfolgt.
23. Verfahren nach Anspruch 21 oder 22, wobei die Formatierungselemente grafische Elemente sind.
24. Verfahren nach Anspruch 23, wobei die grafischen Elemente Kuchendiagramme oder Balkendiagramme sind.
25. Vorrichtung zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 24.
26. Vorrichtung nach Anspruch 25, umfassend einen Computer, auf dem ein Softwareprogramm abläuft, mit dem zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdatenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, eine vorgegebene, dem zeilenweise strukturierten Druckda- tenstrom zugeordnete Strukturbeschreibungsdatei verwendet wird.
27. Drucksystem, das eine Vorrichtung nach einem der Ansprüche 25 oder 26 enthält.
28. Computerprogrammprodukt, das beim Laden und Ablaufen auf einen Computer ein Verfahren auch einen der Ansprüche 1 bis 24 bewirkt.
EP05735960A 2004-04-30 2005-04-27 Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom Ceased EP1749257A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004021269A DE102004021269A1 (de) 2004-04-30 2004-04-30 Verfahren, Vorrichtung und Computerprogrammprodukt zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem Zeilendatenstrom
PCT/EP2005/004527 WO2005106641A2 (de) 2004-04-30 2005-04-27 Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom

Publications (1)

Publication Number Publication Date
EP1749257A2 true EP1749257A2 (de) 2007-02-07

Family

ID=34969336

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05735960A Ceased EP1749257A2 (de) 2004-04-30 2005-04-27 Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom

Country Status (4)

Country Link
US (1) US20080158605A1 (de)
EP (1) EP1749257A2 (de)
DE (1) DE102004021269A1 (de)
WO (1) WO2005106641A2 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007014043A1 (de) * 2007-03-23 2008-09-25 OCé PRINTING SYSTEMS GMBH Verfahren zur Steuerung mindestens eines Nachbearbeitungsgerätes für eine Bedruckstoffbahn
US8418135B2 (en) * 2007-05-31 2013-04-09 Red Hat, Inc. Method and apparatus to abstract away rule languages
JP5374932B2 (ja) * 2008-06-18 2013-12-25 セイコーエプソン株式会社 プリンタ、プリンタの制御方法及び動作制御プログラム
US8533675B2 (en) * 2009-02-02 2013-09-10 Enterpriseweb Llc Resource processing using an intermediary for context-based customization of interaction deliverables
WO2012167361A1 (en) * 2011-06-10 2012-12-13 Jeffrey Laporte System and method for augmentation of retail pos data streams with transaction information
WO2013142433A2 (en) 2012-03-19 2013-09-26 Enterpriseweb Llc Declarative software application meta-model and system for self-modification
US8860994B2 (en) 2012-08-10 2014-10-14 Ricoh Production Print Solutions Electronic replacement of pre-printed forms
US9147091B2 (en) 2013-03-01 2015-09-29 Hewlett-Packard Development Company, L.P. Printing barcodes from an enterprise resource planning (ERP) system

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4870611A (en) * 1983-11-15 1989-09-26 International Business Machines Corporation Apparatus and method for system printing mode control
US5845302A (en) * 1995-12-29 1998-12-01 Moore Business Forms, Inc. Method and system for producing high-quality, highly-personalized printed documents
JPH10307816A (ja) * 1997-05-08 1998-11-17 Just Syst Corp 構造化文書処理装置、構造化文書処理方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体
US6097498A (en) * 1997-09-12 2000-08-01 International Business Machines Corporation Thin layer protocol™ for printer management
US6205452B1 (en) * 1997-10-29 2001-03-20 R. R. Donnelley & Sons Company Method of reproducing variable graphics in a variable imaging system
US6266150B1 (en) * 1998-08-24 2001-07-24 International Business Machines Corporation Virtual printer
US5993088A (en) * 1998-09-30 1999-11-30 International Business Machines Corporation Method for improving print performance and quality by accumulating, storing and using resource accounting information with a print job
US6336124B1 (en) * 1998-10-01 2002-01-01 Bcl Computers, Inc. Conversion data representing a document to other formats for manipulation and display
US6910182B2 (en) * 2000-01-31 2005-06-21 Xmlcities, Inc. Method and apparatus for generating structured documents for various presentations and the uses thereof
DE10017785C2 (de) * 2000-04-10 2002-04-18 Oce Printing Systems Gmbh Verfahren und System zur Verarbeitung eines Druckdatenstroms
EP1290628B1 (de) * 2000-04-11 2004-02-11 Océ Printing Systems GmbH Verfahren zum erstellen und ausgeben mindestens einer druckseite
US20020111963A1 (en) * 2001-02-14 2002-08-15 International Business Machines Corporation Method, system, and program for preprocessing a document to render on an output device
DE10123376B4 (de) * 2001-05-14 2004-12-02 OCé PRINTING SYSTEMS GMBH Verfahren, Gerätesystem und Computerprogrammsystem zur Verarbeitung von Dokumentendaten
DE10123411A1 (de) * 2001-05-14 2002-11-28 Oce Printing Systems Gmbh Verfahren, Gerätesystem und Computerprogrammsystem zum visuellen Überprüfen eines Druckdatenstroms
US7142326B2 (en) * 2001-05-16 2006-11-28 Xerox Corporation Method and apparatus for variable data document printing
DE10235254A1 (de) * 2002-08-01 2004-02-19 OCé PRINTING SYSTEMS GMBH Verfahren, Gerätesystem und Computerprogrammprodukt zum dokumentenbezogenen Erweitern eines resourcenstrukturierten Dokumentendatenstroms
US7069504B2 (en) * 2002-09-19 2006-06-27 International Business Machines Corporation Conversion processing for XML to XML document transformation
DE10245530B4 (de) * 2002-09-30 2006-04-27 OCé PRINTING SYSTEMS GMBH Verfahren, Softwareprodukt und Computer zum Erzeugen eines IPDS-Datenstromes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Elixir Technologies Gives New Life To Legacy Documents", INTERNET CITATION, 12 November 2001 (2001-11-12), XP007909040, Retrieved from the Internet <URL:http://www.ssc-online.com/epn/december01%20articles/elixir.htm> [retrieved on 20090702] *

Also Published As

Publication number Publication date
WO2005106641A3 (de) 2006-06-01
DE102004021269A1 (de) 2005-11-24
WO2005106641A2 (de) 2005-11-10
US20080158605A1 (en) 2008-07-03

Similar Documents

Publication Publication Date Title
EP1579309B1 (de) Verfahren, computerprogrammprodukt und vorrichtung zum verarbeiten eines dokumentendatenstroms eines eingangsformates zu einem ausgangsformat
EP1669852B1 (de) Verfahren und Computerprogramm zum Umwandeln eines Eingangs-Dokumentendatenstroms mit einem oder mehreren Dokumenten in eine strukturierte Datendatei
DE10123376B4 (de) Verfahren, Gerätesystem und Computerprogrammsystem zur Verarbeitung von Dokumentendaten
EP1749257A2 (de) Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom
EP1353276A2 (de) Drucken mit variablen Daten unter Verwendung einer dynamischen Ausschiessvorlage
WO2001077807A9 (de) Verfahren und system zur datenverarbeitung
EP1451766B1 (de) Verfahren, gerätesystem und computerprogrammprodukt zur erzeugung eines gedruckten dokuments aus mehreren eingangsdateien
EP1943618A2 (de) Verfahren, computerprogramm und vorrichtung zur erstellung individualisierter medien-druckexemplare
EP1161731B1 (de) Verfahren, computerprogrammprodukt und system zur übertragung von computerdaten an ein ausgabegerät
EP1393157B1 (de) Verfahren, geratesystem und computerprogramm-produkt zur verarbeitung von dokumentendaten
EP1532514B1 (de) Verfahren, gerätesystem und computerprogrammprodukt zum dokumentenbezogenen erweitern eines resourcenstrukturierten dokumentendatenstroms
DE10252797B4 (de) Verfahren und System zum Erstellen von Dokumentenvorlagen mit Ressourcenverwaltung
DE10158419A1 (de) Verfahren zum digitalen Drucken von zusammengesetzten Dokumenten
WO2009019248A2 (de) Verfahren zum erzeugen eines templates
WO2009112352A2 (de) Verfahren, drucksystem und computerprogramm zum erzeugen und verarbeiten von dokumentendatenströmen
DE102007036985B4 (de) Verfahren, System und Computerprogrammprodukt zum automatischen Aufbereiten von Dokumentenbearbeitungsdaten
DE10325843B4 (de) Verfahren, Drucksystem, Computer und Computerprogramm zum Verwalten von Resourcen zur Verwendung in einem resourcenbasierten Dokumentendatenstrom
EP1470472B1 (de) Verfahren zur automatisierten annahme und weiterleitung von dokumentenbearbeitungsaufträgen
DE102007036986B4 (de) Verfahren zum automatischen Aufbereiten und Trennen von in einem Dokumentendatenstrom enthaltenen Dokumentenbearbeitungsdaten
DE20221943U1 (de) Gerätesystem zur Verarbeitung von Dokumentendaten
EP1163574B1 (de) Verfahren, computerprogrammprodukt und system zur übertragung von computerdaten an ein ausgabegerät
DE10223926A1 (de) Verfahren, Computersystem und Computerprogrammprodukt zum Übertragen eines Druckauftrages von einem Host Computer an einen Druckserver
DE102005030645A1 (de) Verfahren und Computerprogramm-Produkt zum Umwandeln eines Eingangs-Dokumentendatenstroms mit einem oder mehreren Dokumenten in eine strukturierte Datendatei und Computerprogramm-Produkt sowie Verfahren zum Erstellen eines Regelsatzes für ein solches Verfahren
DE102004059120A1 (de) Verfahren zum Umwandeln eines Eingangs-Dokumentendatenstroms mit einem oder mehreren Dokumenten in eine strukturierte Datendatei und Computerprogramm-Produkt zum Erstellen eines Regelsatzes für ein solches Verfahren
WO2007110389A1 (de) Verfahren, computerprogramm und computersystem zum erzeugen einer treiber-steuerungskomponente für ein ausgabegerät in einem dokumenten output management system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061117

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20071022

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ENGBROCKS, WERNER

Inventor name: FROMM, MATTHIAS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20130129