Automatic compliance-testing system for desktop designed consumer packaging

Abstract

An automatic compliance testing system for evaluating the compliance of a graphic element with one or more conditions within desktop designed consumer packaging. The automatic compliance testing system includes an Encapsulated PostScript™ file that has an executable module which tests the commands geometrically defining the graphic element. The results of the self-checking operation are communicated to a checklist module. The checklist module is an executable module which generates a checklist that displays the test results. The checklist module may also test the compliance of the graphic element with predefined criteria, such as percentage of available display surface occupied, wherein the available display surface is defined using one or more Encapsulated PostScript™ files having a sizing module for calculating the area of the shape defined by the file. The checklist may be placed at any location, scaled, mirrored or rotated within the design document but in most cases adjacent to or outside the boundaries of the consumer packaging being designed.

Description

CROSS-REFERENCE

[0001] This patent application is a continuation-in-part of U.S. patent application Ser. No. 09/321,528 filed May 28, 1999.

FIELD OF THE INVENTION

[0002] The present invention relates to packaging design systems and more particularly to a self-checking system for digital images in packaging designs.

BACKGROUND OF THE INVENTION

[0003] The U.P.C. or Universal Product Code is very widely used in the retail and wholesale trades, usually being applied to packages or labels in the form of a printed barcode which is machine readable by suitable scanners. The barcode also incorporates the U.P.C. in human readable form along a lower margin so as to permit manual entry of the code in the event of a scanning failure. The U.P.C. in barcode form is used extensively in inventory management, and point-of-sales (POS) systems. Further details of the U.P.C. specification are found in the “U.P.C. Symbol Specification Manual” published by Uniform Code Council, Inc. (1986).

[0004] Many retailers now penalize suppliers heavily if a barcode does not scan properly. In some cases, retailers refuse to order stock from a supplier when barcode errors have occurred too many times, resulting in significant losses for the supplier. The supplier in turn may penalize a designer, film-house, plate maker, or printer for defectively printed barcodes. The extent of the problem is discussed in articles by the inventor published in the trade journal “Canadian Packaging”, namely “The Get-Tough Approach” (May, 1992); “UPC Barcodes and the Desktop Revolution” (February, 1993); and “Desk-top Barcodes Revisited” (May, 1994). The generally similar EAN coding system is widely used in Europe.

[0005] Barcodes are also used to encode many other types of data where machine readability of such data from printed material is required, and accurate printing of such data is essential to readability. There are many factors that can compromise the readability of barcodes during scanning. Most involve distortions introduced during press and pre-press operations used to apply the barcode to a substrate, and substrate based problems. Additionally, the master from which the barcode is reproduced may be incorrectly used or specified, e.g. it may have been prepared for a different printing process from that actually used.

[0006] In the art, there are commercially available desktop design computer software programs, for example Adobe Illustrator™, Adobe PageMaker™, and Quark XPress™, for designing consumer packaging. Such programs are run on a computer system commonly referred to as a packaging design system. The packaging design system typically comprises a personal computer, such as a PC or Macintosh, and a PostScript™ imaging device. The packaging design system allows a designer to create a design for a consumer package and also place barcode markings on the consumer package. The elements of the barcode are defined in terms of PostScript™ commands which are contained in an Encapsulated PostScript™ (EPS) file, which is part of a document file generated by the desktop design computer software program. The PostScript™ language is an industry standard page description language which was developed by Adobe. The EPS file is outputted to a Raster Image Processor (RIP) in the PostScript™ imaging device. The RIP interprets the commands and directs the imaging device to generate the barcode defined by the designer through the commands. The imaging device produces the film separations which are used to make printing plates. In known manner, the printing plates are used to print the packages with the integrated barcode markings on the packaging

[0007] Just as with barcode images, there are certain conditions and controls upon the appearance of other graphic elements of a consumer packaging design. For example, the Canadian and US governments have recently enacted regulations that make it a mandatory requirement that food consumer packaged goods be labeled with Nutrition Facts Tables (NFTs). The requirements impose restrictions as to the point size of type, leading, font, and overall size. In particular, the Canadian regulations stipulate that no more than 15 percent of a packages available display surface (ADS) need by occupied by the NFT.

[0008] The calculation of available display surface is individual to each packaging design, taking into account the area visible to the consumer and subtracting certain areas such as cutouts, U.P.C.s, etc. Accordingly, a package designer utilizing a packaging design system is faced with the difficulty of applying an NFT image to a packaging design and then ensuring that the NFT image, howsoever manipulated, continues to meet the appropriate conditions and requirements.

[0009] It would be advantageous to have a method and system for packaging design that automatically determines whether or not a graphical element complies with predefined standards or conditions, so as to avoid the necessity of the printing of the packaging design and manually measuring or testing the graphical element.

SUMMARY OF THE INVENTION

[0010] The present invention provides a mechanism for testing graphic images or elements placed within a packaging design in a packaging design system. The mechanism according to the invention permits a PostScript™ imaging device or PostScript™ RIP software package (e.g. Adobe Distillerm™) to check compliance of the defined image with predetermined specifications and to indicate problems with the image which would result in a failed Certificate of Conformity and/or attendant non-compliance penalties.

[0011] The present invention provides a system for self-checking the electronic file from which an image is generated for possible modifications to the configuration of the image.

[0012] In one aspect, the present invention comprises an Encapsulated PostScript™ barcode file which includes an executable self-checking module which tests the barcode file for specification violations to the UPC barcode definition. The results of the self-checking operation are communicated to a checklist module. The checklist module is an executable module which generates a-checklist that displays the test results. The checklist may be placed at any location, scaled, mirrored or rotated within the design document but in most cases adjacent to or outside the boundaries of the consumer packaging being designed.

[0013] In another aspect, the checklist may include additional information related to the barcode which is stored in the EPS file when it is created. The additional information includes Manufacturer, Date/Time created, Intended Printing Process, Product Description, Bar Color when created, Barcode Symbology, Size as Created, and Line Width Reduction specified or used. This information is also communicated to the checklist module and displayed by the checklist.

[0014] It is a feature of the present invention that the method of communicating and displaying the self-check test results is independent of the relative order of “placement” of the “checklist” and the EPS barcode file. Advantageously, this allows the desktop designer to create a packaging design and insert/delete checklists or barcodes at will.

[0015] In a first aspect, the present invention provides a method, for use in a packaging design system, for evaluating compliance of a graphic element within a packaging image. The method includes the steps of generating a digital file defining the packaging image, the digital file including commands geometrically defining the graphic element, testing the commands to determine the compliance of the graphic element with at least one geometric condition, thereby producing test results, and writing the test results to the digital file.

[0016] In another aspect, the present invention provides a self-checking module, for use in a packaging design system, for evaluating compliance of a graphic element within a packaging image, the packaging design system including a digital file defining the packaging image, the digital file including commands geometrically defining the graphic element. The self-checking module includes code means defining at least one geometric condition, code means for testing the commands to determine the compliance of the graphic element with the at least one geometric condition, thereby producing test results, and code means for writing the test results to the digital file.

[0017] In a further aspect, the present invention provides a packaging design system for evaluating compliance of a graphic element within a packaging image. The system includes a raster image processor, a digital file including commands geometrically defining the graphic element, and a self-checking module for execution by the raster image processor. The self-checking module includes code means defining at least one geometric condition, code means for testing the commands to determine the compliance of the graphic element with the at least one geometric condition, thereby producing test results, and code means for writing the test results to the digital file.

[0018] Other aspects and features of the present invention will be apparent to those of ordinary skill in the art from a review of the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Reference will now be made, by way of example, to the accompanying figures, which show a preferred embodiment of the present invention, and in which:

[0020] FIG. 1 shows a conventional barcode used to encode a Universal Product Code or UPC;

[0021] FIG. 2 shows a checklist generated by a self-checking system according to the present invention;

[0022] FIG. 3 shows a screen display which appears when a checklist is placed according to the present invention;

[0023] FIG. 4 shows the checklist which is displayed when a checklist is placed and a UPC barcode is not available for that checklist;

[0024] FIG. 5 shows an example of a non-compliant barcode;

[0025] FIG. 6 shows the checklist generated by the self-checking system according to the invention for the non-compliant barcode of FIG. 5;

[0026] FIG. 7 shows an example of a marginally compliant barcode (i.e. imaged at too low a resolution);

[0027] FIG. 8 shows the checklist generated by the self-checking system for the barcode of FIG. 7;

[0028] FIG. 9 shows an example of a consumer package design document in which two different and non-compliant barcodes and their associated checklists have been placed on the same page in the document;

[0029] FIG. 10 shows an embodiment of a packaging design system for automatically determining compliance of a graphic element with predefined criteria, according to the present invention;

[0030] FIG. 11 shows an image of a Nutrition Facts Table; and

[0031] FIG. 12 shows a further embodiment of a packaging design system for automatically determining compliance of a graphic element with predefined criteria, according to the present invention.

[0032] Similar references are used in different figures to denote similar components or features.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0033] Reference is first made to FIG. 1 which shows a standard UPC barcode 10 according to the art. As illustrated in FIG. 1, the barcode 10 comprises a series of n parallel bars 12 of varying width which are separated by n-1 spaces indicated by reference 14. The barcode 10 also includes two groups 16a and 16b of human readable characters which are disposed to both sides of tall center guard bars 18, and located to the right of left guard bars 20a and to the left of right guard bars 20b. The guard bars 20a, 20b provide respective data start and data stop boundaries for the barcode data. The two human readable character groups 16a, 16b provide manufacturer information and product information, respectively.

[0034] As also shown in FIG. 1, the barcode 10 includes a left light margin 22a to the left of the left guard bars 20a and a right light margin 22b to the right of the right guard bars 20b. The barcode 10 also includes a numeric figure in the left margin indicated by reference numeral 24 and another numeric figure in the right margin 22b indicated by reference numeral 26. The first numeric FIG. 24 provides a human readable reference to the numbering system which is utilized for encodification in the barcode 10. The second numeric FIG. 26 provides another human readable reference which is used as a check digit for the barcode 10.

[0035] In known manner, a barcode 10 of the type shown in FIG. 1 is generated using a film/print process, or by an electronic master in which the barcode is contained in an EPS (Encapsulated PostScript™) file which is stored on suitable data storage media. In the EPS file, the barcode is defined in terms of page description commands according to the industry standard PostScript™ language developed by Adobe.

[0036] Reference is now made to FIG. 10, which shows an embodiment of a packaging design system 300 for automatically determining compliance of a graphic element with predefined criteria, according to the present invention. As will now be described, the present invention provides a self-checking mechanism for ascertaining compliance of electronic barcodes, i.e. EPS barcode files, of the type generated by the packaging design system 300 running a desktop design computer software program according to the art. The packaging design system 300 includes a general purpose computer 302 (i.e. a PC or a Macintosh), a packaging design computer software program 308, and a PostScript™ imaging device 304, for example a PostScript™ capable printer. The PostScript™ imaging device 304 includes a Raster Image Processor 310 (RIP) which interprets PostScript™ language commands and directs the imaging device 304 to generate the defined images. In another embodiment, the packaging design system 300 includes a raster image processor computer software program 311, such as Adobe Distiller™, which performs functions equivalent to the RIP 310 in the imaging device 304.

[0037] The desktop design computer software program 308 comprises a commercially available software package, such as Adobe Illustrator™, Adobe PageMaker™, or QuarkXPress™, and enables a designer to create a consumer package design and place (i.e. image) barcodes on the consumer package. The consumer package created by the designer on the packaging design system 300 is stored in a document file 312 which includes Encapsulated PostScript™ or EPS files 314, 316. In known manner, the desktop design computer software program 308 places the Encapsulated PostScript™ (EPS) file 314 comprising PostScript™ commands which define the barcode for imaging into the document file 312. The imaged barcodes may be printed directly by the printer on paper, or a film sheet may be created which is used to make printing plates for printing the images with the barcode on the package panel. The EPS file 314 is outputted to the RIP 310 which interprets the commands and directs the imaging device 304 to generate the packaging with the barcode. Alternatively, the EPS file 314 may be outputted to the RIP software 311 which interprets the commands and directs a display device 306 to display the packaging with the barcode.

[0038] The self-checking mechanism according to the invention also provides for a directory of barcodes and checklists to allow for the management of multiple barcodes and checklists in a document as will be described in more detail below.

[0039] The self-checking mechanism according to the invention comprises two components: a self-checking module 318; and an automated checklist module 320. Each module 318, 320 is implemented as an Encapsulated PostScript™, or EPS, file. The self-checking module 318 is contained in the barcode EPS 314 which also includes code, i.e. PostScript™ commands, for generating the graphic elements comprising the barcode. As will be described in more detail below, the self-checking module 318 performs a self-check of criteria which define the barcode, and the checklist module 320 displays a checklist which shows the results of the self-checking operation. The self-checking EPS 314 and the checklist EPS 316 are placed in the document file 312 for the desktop design computer software program 308 as PostScript™ modules which are sent together with PostScript™ commands for generating the graphic elements of the entire page of the document containing the barcode to the RIP 310 in the PostScript™ imaging device 304.

[0040] As will be familiar to those skilled in the art, an EPS document file contains certain required elements in the body of the file including a header, a screen preview, and a body. In addition to these required elements both the barcode self-checking EPS module 318 and the checklist EPS module 320 contain specific code elements which, when both present in the document file 312, permit for the self-checking of the barcode criteria and display of the results in a checklist as will now be described in more detail.

[0041] The self-checking module 318 comprises code for performing the following operations:

[0042] (1) testing the defined barcode against predetermined criteria;

[0043] (2) creating a data dictionary which will hold results of the test;

[0044] (3) storing the test results in the dictionary;

[0045] (4) executing procedures to graphically display the results in checklist form regardless of the location, rotation or scale of the checklist.

[0046] The self-checking module 318 also includes code for managing multiple barcodes and checklists in a single document, i.e. a consumer package design, as will be described in more detail below.

[0047] The predetermined criteria against which the barcode (as defined or modified by the designer) is tested and flagged as an error or as a caution (as indicated below) by the self-checking module include the following:

[0048] (1) overall reduction of the UPC barcode to below 80% magnification of nominal dimensions is flagged as a failure;

[0049] (2) enlargement of the UPC barcode to over 200% magnification of nominal dimensions is flagged as a failure;

[0050] (3) alteration of the barcode in terms of color used for the bars is flagged as a caution to test again;

[0051] (4) output resolution which is less than the minimum required resolution is flagged as a caution;

[0052] (5) truncation of the barcode by more than ±2 millimeters is flagged as a failure;

[0053] (6) inadequately sized quiet zones are flagged as a failure;

[0054] (7) an altered aspect ratio is flagged as a caution;

[0055] (8) truncated or clipped human readable characters are flagged as a failure;

[0056] (9) the minimum allowable cylindrical package diameter is noted for the barcode's actual size; and

[0057] (10) skew checking is flagged as a caution

[0058] As will be described in more detail below, a failure flag results in a checklist 111 of the form shown in FIG. 6 being generated, while a caution flag results in a checklist 121 of the form shown in FIG. 8 being generated by the checklist module. A barcode EPS which meets or complies with the test criteria results in a checklist 100 of the form shown in FIG. 2 being generated.

[0059] Reference is now made to the accompanying pseudo code which describes the self-checking module 318 and checklist module 320 in further detail.

[0060] The self-checking module 318 for the barcode EPS 314 may be implemented as illustrated by the following pseudo code. In the pseudo code, data-structures and functions are denoted by italics. 1 1: <EPS Header> 2: if (RIP is Level 2 or higher) then 3: if (no barcodes and no check-lists have yet been placed in the PostScript ™ document) then 4: <declare the shared variables in global VM (i.e. number of barcodes, number of checklists, number of checklists completed, number of barcodes waiting to be documented)> 5: <define procedures in global VM called by both check-lists and barcodes> 6: end if 7: if (no other barcodes have been placed in the PostScript ™ document) then 8: <declare the barcode directory in global VM> 9: <define procedures in global VM for logging info into barcode directory> 10: end if 11: <define variables which contain this barcode's parameters (i.e. size, LWR (Line Width Reduction), printing process, bar colors, product description, etc.); this section is created when the barcode is generated.> 12: <write barcode's parameters into barcode directory> 13: <perform sizing tests and write test results into barcode directory> 14: end if 15: <image the barcode> 16: if (RIP is Level 2 or higher) then 17: <call check-list drawing procedure for all barcodes not yet check-listed while unused check-lists are available> 18: end if

[0061] Referring to the pseudo-code listing, the top portion of the self-checking module 318 comprises the EPS header (Line 1). The first operation in the self-checking module 318 involves checking if the Raster Image Processor (RIP) 310 in the PostScript™ imaging device 304 is Level 2 or higher (Line 2). (This particular implementation is only fully functional on a RIP with at least a Level 2 capability.) If the RIP 310 is not Level 2 or higher, the self-checking operations are bypassed and the barcode is simply imaged without performing a self-check or generating a checklist according to the invention (Line 15). On the other hand, if the RIP is Level 2, then the self-checking operations are performed as described below.

[0062] The first operation in the self-checking operation involves determining if any barcodes or checklists have been already placed in the document file 312 produced by the desktop design system 300 for the consumer packaging design (Line 3). If no barcodes or checklists have been placed in the document file 312, then the shared variables are declared in global virtual memory or VM (Line 4). The shared variables include the following: number of barcodes, number of checklists, number of checklists completed and number of barcodes waiting to be documented. Next, the procedures which will be called by the self-checking module 318 and the checklist module 320 are defined in global virtual memory (Line 5).

[0063] If there are no barcodes that have been placed in the barcode EPS file 314 (Line 7), i.e. this is the first barcode being placed in the document file 312, then a barcode directory is created (i.e. declared) in global VM (Line 8). The barcode directory provides the capability to manage multiple barcodes in the desktop consumer packaging design system 300, and as will be described, a checklist directory is also provided for managing corresponding multiple checklists. Accordingly, every time a barcode or checklist is encountered in the document file 312, a check is made if the barcode or checklist is the first entry in the respective directory. Next, the procedures for logging into the barcode directory are defined (Line 9).

[0064] Next, the variables which contain the parameters for the barcode are defined (Line 11). The barcode parameters include size, Line Width Reduction or LWR, printing process, bar colors, product description. The barcode parameters are defined when the barcode is generated. Next, the barcode parameters are entered for the barcode in the barcode directory (Line 12). The next operation in Line 13 involves performing the actual self-checking tests. The self-checking tests comprise checking the barcode specification against predetermined criteria, such as criteria (1) to (10) described above, and pseudo-code for the size test, the aspect ratio test, the skew test, the truncation test, the quiet zone test and the human readable test is provided below. The test results are written into the entry for the barcode in the barcode directory. The next step (Line 15) involves imaging the barcode. As described above, if the RIP is not Level 2 or higher, the self-checking module 318 moves directly to this step. Upon completion of the self-checking operations, control moves to the checklist module which generates a checklist as described below.

[0065] As described above, one of the tests performed by the self-checking module 318 is Size Check test which involves determining if the UPC barcode 10 (FIG. 1) has been scaled down to less than 80% or up to more than 200%. The Size Check test may be implemented as illustrated by the following pseudo code. 2 1: <define a length function L(V)> 2: <define a vector oriented in the X-axis; call it X> 3: <transform X by the CTM; call the resultant vector XR> 4: if (L(XR)/L(X)*mag>2.00) then 5: tooLargeFlag = TRUE 6: tooSmallFlag = FALSE 7: else 8: tooLargeFlag = FALSE 9: if (L(XR)/L(X)*mag<0.8) then 10: tooSmallFlag = TRUE 11: else 12: tooSmallFlag = FALSE 13: end if 14: end if

[0066] Referring to the above pseudo code listing, a vector length function is defined and called L(V) (Line 1), and a non-zero length X-axis test vector is constructed and called X (Line 2). The X-axis test vector is transformed by a current transformation matrix (CTM) and the transformed vector is called XR (Line 3). Next, the vector length function L(X) is executed and the length L(XR) is calculated (Line 4). Then the ratio L(XR):L(X) is calculated, and multiplied by the original magnification of the UPC barcode 10 when created (referred to as “mag” above) (Line 4). The result of this calculation is compared to 2.0 (i.e. 200%) as shown in Line 4. The result is also compared to 0.8 (i.e. 80%) in Line 9. The comparisons performed in Line 4 and Line 9 essentially determine the actual magnification of the UPC barcode 10 is determined after adjusting for the factor introduced by the transformation matrix CTM.

[0067] The UPC Aspect Ratio test involves determining if the aspect ratio for the UPC barcode 10 (FIG. 1) has changed. The UPC Aspect Ratio test may be implemented as illustrated by the following pseudo code. 3 1: <define a length function L(V)> 2: <define a vector oriented in the X-axis; call it X> 3: <transform X by the CTM; call the resultant vector XR> 4: <define a vector oriented in the Y-axis; call it Y> 5: <transform Y by the CTM; call the resultant vector YR> 6: squashedFlag = FALSE 7: tallFlag = FALSE 8: if (L(YR) = 0) then 9: squashedFlag = TRUE 10: else 11: if (L(XR)/L(YR)<1.00) then 12: tallFlag = TRUE 13: else 14: if (L(XR)/L(YR)>1.00) then 15: squashedFlag = TRUE 16: end if 17: end if 18: end if

[0068] Referring to the pseudo code listing shown above, a vector length function is defined as L(V) (Line 1) and a non-zero length X-axis vector is constructed and called X (Line 2). The X-axis vector X is transformed by the current transformation matrix CTM and called XR (Line 3). Another non-zero length test vector oriented in the Y-axis is constructed and called Y (Line 4). The vector Y is transformed by the transformation matrix CTM and the resultant vector is called YR (Line 5). Flags “squashedFlag” and “tallFlag” are cleared (Lines 6 and 7, respectively). If the length of the Y-axis vector Y is zero (Line 8), then the flag “squashedFlag” is set to TRUE to indicate that the UPC barcode 10 has been compressed. Otherwise, the ratio of the vector lengths L(XR):L(YR) is calculated (Line 11) and compared to 1.00 (i.e. equal distortions in both axis—Lines 11 and 14).

[0069] The UPC Skew test involves determining if a UPC barcode 10 (FIG. 1) is skewed. The UPC Skew test may be implemented as illustrated by the following pseudo code. 4 1: <define a dot-product function D(V1,V2)> 2: <define a vector oriented in the X-axis; call it X> 3: <transform X by CTM; call the resultant vector XR> 4: <define a vector oriented in the Y-axis; call it Y> 5: <transform Y by CTM; call the resultant vector YR> 6: if (D(XR,YR)≠0) then 7: skewedFlag = TRUE 8: else 9: skewedFlag = FALSE 10: endif

[0070] Referring to the pseudo code for the UPC Skew test, a vector dot-product function is defined as D(V1, V2) (Line 1), and a non-zero length X-axis test vector is constructed and called X (Line 2). The vector X is transformed by the current transformation matrix CTM (Line 3) and the resultant vector is called XR. Then a test vector Y oriented in the Y-axis is constructed (Line 4). The test vector Y is transformed by the transformation matrix CTM (Line 5) and the resultant vector is called YR. Next the dot-product function D(V1, V2) is calculated and compared to zero (Line 6). Since the dot-product of the two perpendicular vectors XR and YR will be zero, the result of the dot-product calculation provides an indication if the transformation matrix CTM skews the axis of the UPC barcode 10 away from orthogonal.

[0071] The Truncation test involves determining if a UPC barcode 10 (FIG. 1) is truncated. The Truncation test may be implemented as illustrated by the following pseudo code. 5 1: <test points 2mm below top of barcode for insideness using the “infill” command> 2: if (all test points are inside) then 3: truncatedFlag = FALSE 4: else 5: truncatedFlag = TRUE 6: endif

[0072] Referring to the above pseudo code, the Truncation test utilizes a native command, i.e. “infill”, in the PostScript™ level 2 language which allows a point be tested against the current clipping path to determine if the point is “inside” the path, i.e. visible or not (Line 2). The truncation testing involves determining if any of the points across the top of the bars in the UPC barcode 10 (FIG. 1) have been “cut-down” in height by the clipping path associated with the box/mask currently in use with the barcode 10. If the points are inside (Line 2), then the bars have not been clipped and a flag “truncatedFlag” is set FALSE (Line 3). If the points are outside, then the bars have been clipped and the flag “truncatedFlag” is set TRUE (Line 5).

[0073] The Quiet Zones test involves determining if the quiet zones in the UPC barcode 10 (FIG. 1) are adequately sized. The Quiet Zones test may be implemented as illustrated by the following pseudo code. 6 1: <test points across left side of the barcode for insideness> 2: if (all test points are inside) then 3: leftQzOkFlag = TRUE 4: else 5: leftQzOkFlag = FALSE 6: endif 7: <test points across the right side of the barcode for insideness> 8: if (all test points are inside) then 9: rightQzOkFlag = TRUE 10: else 11: rightQzOkFlag = FALSE 12: endif

[0074] Referring to the above pseudo code, the Quiet Zones test also utilizes the “infill” command which is native to the PostScript™ level 2 language. The Quiet Zones test determines if any of the points down the sides of the UPC barcode 10 have been clipped, i.e. by the clipping path associated with the box/mask currently in use with the barcode following the execution steps shown above.

[0075] The Human Readable Codes test involves determining if the human readable codes (i.e. 16a, 16b in FIG. 1) in the UPC barcode 10 have been clipped. The Human Readable Codes test may be implemented as illustrated by the following pseudo code. 7 1: <test points across bottom of the barcode for insideness> 2: if (all test points are inside) then 3: hrOkFlag = TRUE 4: else 5: hrOkFlag = FALSE 6: endif

[0076] Referring to the above pseudo code, the Human Readable Codes test also utilizes the “infill” command from the PostScript™ level 2 language. The Human Readable Codes test determines if any of the points across the bottom of the UPC barcode 10 have been clipped, i.e. by the clipping path associated with the box/mask currently in use with the barcode following the execution steps shown above.

[0077] The specific coding of the remaining operations, declarations, and definitions in the self-checking module 318 is within the understanding of one skilled in the art and therefore additional pseudo-code is not provided.

[0078] The checklist module 320 may be implemented as illustrated by the following pseudo code. In the pseudo code, data-structures and functions are denoted by italics. 8 1: <EPS Header> 2: if (RIP is Level 2 or higher) then 3: if (no barcodes and no checklists have yet been placed in the PostScript ™ document) then 4: <declare the shared variables in global VM (i.e. number of barcodes, number of checklists, number of checklists completed, number of barcodes waiting to be documented, etc.)> 5: <define procedures in global VM called by both checklists and barcodes> 6: end if 7: if (no other checklists have been placed in the PostScript ™ document then 8: <declare the checklist directory in global VM> 9: <define procedures in global VM for logging info into checklist directory> 10: <define checklist drawing procedure> 11: end if 12: <create a new entry in the checklist directory> 13: <log checklist's location into the new checklist directory entry> 14: <call checklist drawing procedure for all barcodes not yet check-listed while unused checklists are available> 15: else 16: <generate only a rudimentary checklist graphics and inform user that Level 2 is needed for self-check to function properly> 17: end if

[0079] Referring to the pseudo-code listing for the checklist module 320, the first portion of the module comprises an EPS header (Line 1). The first operation involves checking if the Raster Image Processor (RIP) 310 in the PostScript™ imaging device 304 is Level 2 or higher (Line 2). If the RIP is not Level 2 or higher, the check-listing operations are bypassed and only a rudimentary checklist graphic is generated, e.g. a checklist with outline and title bar only (Line 16) and the procedure is terminated. If the RIP is Level 2 (Line 2), then the checklist is generated as follows.

[0080] The checklist module 320 determines if any barcodes or checklists have been already placed in the document file 312 (Line 3). If no barcodes or checklists have already been placed in the document file 312 for the desktop designed consumer packaging, then the shared variables are declared in global virtual memory or VM (Line 4). The shared variables include the following variables: number of barcodes, number of checklists, number of checklists completed and number of barcodes waiting to be documented. Next, the procedures which will be called by both the checklist module 320 and the self-checking module 318 are defined in global virtual memory (Line 5).

[0081] If there no other checklists that have been placed in the document file 312 from the desktop consumer packaging design system 300 (Line 7), i.e. this is the first checklist which is being placed, then a checklist directory is declared in global VM (Line 8). The checklist directory provides the capability to manage multiple checklists in document file or files. The procedures for logging or entering information into the checklist directory are defined (Line 9). Next, a checklist drawing procedure or function is defined (Line 10). Next, a new entry is created for the checklist in the checklist directory (Line 12), and the checklist's location is logged with the new entry in the checklist directory (Line 13). Next, a checklist drawing procedure or function is called (Line 14). If the RIP is Level 2 or higher (Line 16), a procedure for drawing the checklist is called (Line 17). The checklist drawing procedure is coded to produce a compliant checklist 100 of the form shown in FIG. 2, a non-compliant checklist 111 of the form shown in FIG. 6, and a cautionary checklist 121 as shown in FIG. 8.

[0082] The specific coding of the operations, declarations, and definitions in the checklist module 320 is within the understanding of one skilled in the art and therefore additional pseudo-code is not provided.

[0083] Reference is next made to FIGS. 1 to 9, which show exemplary barcodes and checklists generated according to the present invention. Applying the self-check test to the barcode 10 shown in FIG. 1 results in the generation of the checklist 100 shown in FIG. 2. As shown, the checklist 100 includes a header 101, a self-check test result column 102, and an information 103 column. The self-check test column 102 includes fields 104 for the self-check criteria described above and comprises a field 104a for “Magnification”, a field 104b for “Skew”, a field 104c for “H/W Ratio”, a field 104d for “Quiet Zones”, a field 104e for “Bar Heights”, a field 104f for “HR Digits”, a field 104g for “Bar Color Altered”, a field 104h for “RIP Output Resolution”, and a field 104i for “Min Pkg Diam (picket)”. The information column 103 comprises a series of fields 105 for providing additional information and includes a field 105a for “Barcode Number”, a field 105b for “Regd Manufacturer Name”, a first field 105c for “Product Desc 1”, a second field 105d for “Product Desc 2”, and the other fields 105e to 105i as shown.

[0084] As also shown in FIG. 2, the checklist 100 includes a URL (Uniform Resource Locator) link or hypertext field 201 in the header 101. Once passed through Adobe Distiller™, clicking the URL link 201 launches a Web browser and takes the user to a homepage on the World Wide Web (i.e. the Internet) for the company.

[0085] When a checklist is first placed in a document, a notice 107 of the form shown in FIG. 3 is displayed on the screen (i.e. display monitor) for the packaging design system. The notice 107 informs the designer that the self-checking results can be viewed by the passing the document file through Level 2 (or 3) PostScript™ RIP or the Adobe Distiller™. As shown in FIG. 3, the notice 107 also includes a URL (Uniform Resource Locator) link 202.

[0086] Reference is next made to FIGS. 5 and 6. The barcode 110 shown in FIG. 5 is defective with the height of the UPC barcode (i.e. bars 14) being truncated as indicated by reference 113 and both the left 114a and right 114b quiet zones being clipped. As a result, the barcode 110 will fail the self-check test and a checklist 111 of the form shown in FIG. 6 is generated. The checklist 111 includes a prominent “NONCOMPLIANT!” overlay 115 to indicate that the barcode 110 has failed. To clearly indicate the defective nature of the barcode 110, the “NONCOMPLIANT” overlay 115 is printed across the checklist 110 as shown. Preferably, the overlay 115 comprises a tinted overlay so that the fields 104, 105 are still visible below the overlay 115. In the self-checking results column 102, the “Quiet Zones” field 104d and the “Bar Heights” field 104e display the respective nature of the failures in boldface, while the remaining fields 104 display test results which are acceptable or “ok”. As also shown in FIG. 6, the RIP Output Res (i.e. resolution) 104h is flagged as being “SMALL! (600.0)” in boldface because the samples were generated on a low resolution printer.

[0087] Reference is next made to FIG. 7 which shows a marginal barcode 120, and FIG. 8 which shows a checklist 121 for the marginal barcode 120. The barcode 120 shown in FIG. 7 is marginal because the output resolution is low, i.e. the designer has set the output resolution below 600 dpi. Otherwise, the barcode 120 is compliant. As a result of the low output resolution setting, the barcode 120 is flagged with a caution when the self-check test is run and the checklist 121 shown in FIG. 8 is generated. The checklist 121 includes a “CAUTION!” overlay 122 to indicate that the barcode 110 has been flagged with certain defects. Preferably, the “CAUTION!” overlay 115 is printed as a tinted overlay. The low output resolution setting is noted in the “RIP Output Res” field 104h which also includes the annotation “SMALL!” in boldface. The parameters in the remaining fields 104 display an acceptable value for the parameter in question, or the parameters 104 are specified as being “ok” indicating that the parameter in question is acceptable, for example, the H/W Ratio in field 104c and the Bar Color Altered 104g.

[0088] Reference is next made to FIG. 9 which shows an example of a document (denoted by 199) in which two barcodes 130 and 140 have been placed. Each of the barcodes 130, 140 are defective and result in respective checklists 131 and 141 being generated as also shown in FIG. 9. The first barcode 130 is defective because the height of the UPC barcode (i.e. bars 14) is truncated as indicated by reference 132 and both the left 133a and right 133b quiet zones are clipped. As a result, the barcode 130 will fail the self-check test and the checklist 131 is generated. The checklist 131 includes a prominent “NONCOMPLIANT!” overlay 134 to indicate that the barcode 130 has failed the self-check test. To clearly indicate the defective nature of the barcode 110, the “NONCOMPLIANT!” overlay 134 is preferably printed as a tinted overlay across the checklist 110 as shown. In the self-checking results column 102, the “Quiet Zones” field 104d shows “BOTH CLIPPED!” in boldface indicating that both right and left quiet zones are clipped, and the “Bar Heights” field 104e shows “TRUNCATED!” in boldface to indicate that the height of the barcode is truncated. In addition, the RIP Output Res field 104h is flagged as being “SMALL!” in boldface. The parameters in the remaining fields 104 display an acceptable value for the parameter in question (e.g. Magnification in field 104a) or the term “ok” indicating that the parameter in question is acceptable (e.g. the HR Digits are “ok” in field 104f).

[0089] Referring still to FIG. 9, the second barcode 140 is defective with a clipped right human readable digit 142 and a clipped right quiet zone 143b. As a result, the barcode 140 will fail the self-check test and the checklist 141 shown in FIG. 9 is generated. The checklist 141 includes a prominent “NONCOMPLIANT!” overlay 144 to indicate that the barcode 140 has failed. Preferably, the “NONCOMPLIANT!” overlay 144 is printed as a tinted overlay across the checklist 142 so that the fields 104, 105 are still visible. In the self-check test result column 102, the “Quiet Zones” field 104d and the “HR Digits” field 104f display the nature of the failure as shown in FIG. 9. In addition, the RIP Output Res field 104h is flagged as being “SMALL!” in boldface.

[0090] Reference is next made back to FIG. 4. If more checklists are placed than there are barcodes in the document file, then a checklist 109 of the form shown in FIG. 4 will be generated when the self-checking procedure is run. As shown in FIG. 4, the checklist 109 is blank, i.e. the self-test result column 102 and the information column 103 are empty, because there is no barcode associated with the checklist 109. The checklist 109 is displayed to inform the user, i.e. designer, the checklist is in excess of the number of barcodes, i.e. the checklist placed in the document file is surplus.

[0091] The present invention is not limited to a method and system for detecting the compliance of barcodes with predefined criteria. The present invention may be employed for testing the compliance of other graphic elements that are incorporated into a package design, including Nutrition Facts Tables (NFTs).

[0092] FIG. 11 shows an example of an NFT 350. Food and drug regulations in various countries can be very specific as to the presentation of information in the NFT 350. For example, regulations may specify the point type and font of text in the NFT 350. They may also specify the weight of lines and borders in the NFT 350. Regulations also govern the use of different versions of the NFT 350. In particular, the regulations may specify a standard format NFT 350 and a variety of other NFT formats that may be used under certain conditions. For instance, a variant NFT may be permitted if the standard format NFT 350 would occupy more than 15% of the available display surface (ADS) of a packaged product. Accordingly, it would be useful to be able to automatically assess whether or not a graphic element occupies more than a predefined percentage of the available display surface in a packaging design, without necessitating the printing and manual measurement of the package design.

[0093] Reference is made to FIG. 12, which shows an embodiment of a packaging design system 360 according to the present invention. The NFT 350 (FIG. 11) is defined in an NFT EPS file 364 within the document file 312 on the packaging design system 360. Within the NFT EPS file 364, the NFT 350 is defined in terms of page description commands using the PostScript™ language developed by Adobe. The NFT EPS file 364 includes a self-checking module 366. The self-checking module 366 performs operations to determine the geometric area of the NFT 350 image and stores the value of the area in a registry. The registry also contains information for determining the ADS for the package design, as is further described below.

[0094] The packaging design system 360 includes the checklist EPS file 316 having the checklist module 320. The checklist module 320 produces a checklist image, as described above, which includes information about the percentage of the ADS of the package occupied by the NFT 350 image. To calculate the required information, the checklist module 320 reads the registry to obtain the ADS and NFT area information and calculates a ratio or percentage. The checklist module 320 may then compare the calculated ratio or percentage with a predefined minimum or maximum limit to assess whether or not the NFT 350 image is compliant with the predefined limit.

[0095] The ADS may also be referred to as the copy safe area of the packaging design image. In the packaging design system 360, the ADS or copy safe area of a particular packaging design is defined through the use of one or more ADS EPS files 368. The packaging design system 360 includes a set of basic ADS EPS files 368 in various geometric shapes, including rectangles and triangles. The user of the packaging design system 360 defines the copy safe area by choosing an appropriate ADS EPS shape and placing it within the packaging design image. The user then stretches the shape to define the perimeter of the copy safe area. The user may use multiple ADS EPS shapes, each resulting in an ADS EPS file 368 within the document file 312, to define the total copy safe area of the packaging design image.

[0096] The ADS EPS shapes may be used to define positive additions to the copy safe area or they may define negative subtractions from the area, such as in the case of a cutout area. For example, the UPC image is a negative area in terms of the definition of the copy safe area, meaning that the area of the UPC image is subtracted from the ADS. The checklist module 320 totals together the areas of all the ADS EPS shapes based upon the values in the registry to determine the overall ADS for the packaging image. The checklist module 320 then compares the ADS to the area of the NFT 350 to assess the relative area occupied by the NFT image.

[0097] The ADS EPS file 368 includes a sizing module 370. The sizing module 370 in each ADS EPS file 368 includes code defining how the area of the shape is to be determined. It includes certain mensuration formulae for calculating the area of various shapes, including triangles, rectangles, circles, ellipses, parallelograms, and others. In a manner similar to that described above with reference to the barcode criteria, the sizing module 370 utilizes the current transformation matrix (CTM) within the RIP 310, 311 to determine the geometric attributes of the ADS EPS shape. For example, the sizing module 370 may test the x-axis length using the vector length function. It may assess the angle between sides of an ADS EPS shape using the dot-product function. Based upon the geometric data derived from the CTM and the appropriate mensuration formula, the sizing module 370 calculates a value for the area of the ADS EPS shape.

[0098] After calculating the area of the ADS EPS shape, the sizing module 370 writes the area of the shape to the registry and then triggers the checklist module 320 to recalculate the ADS and test the ratio of NFT area to ADS against the predefined limit. In this manner, with each ADS EPS file 368 the checklist is updated and redrawn.

[0099] The first EPS file 364, 316, 368 encountered by the RIP creates the registry in which the values for the areas are to be stored. Subsequent EPS files 364, 368 add calculated values to the registry.

[0100] As will be understood by those of ordinary skill in the art, the present invention is not limited to evaluating the compliance of barcode images or NFT images within a packaging design system. The present invention may be used to evaluate the compliance of other graphic elements with a set of geometric criteria within a packaging design system.

[0101] The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

1. A method, for use in a packaging design system, for evaluating compliance of a graphic element within a packaging image, the method comprising the steps of:

(i) generating a digital file defining the packaging image, said digital file including commands geometrically defining the graphic element;

(ii) testing said commands to determine the compliance of said graphic element with at least one geometric condition, thereby producing test results; and

(iii) writing said test results to said digital file.

2. The method as claimed in claim 1, wherein said step of testing includes calculating a copy safe area, calculating the area of said graphic element, determining a proportion of said copy safe area occupied by said graphic element, and comparing said proportion with a value, said value being said geometric condition.

3. The method as claimed in claim 1, wherein said step of generating includes placing at least one shape within said packaging image and adjusting the geometry of said at least one shape to define a copy safe area within said packaging image.

4. The method as claimed in claim 3, wherein said step of testing includes calculating the area of said at least one shape, calculating the area of said graphic element, and comparing a ratio of said areas with a limit condition.

5. The method as claimed in claim 4, wherein said at least one shape includes at least one positive display surface shape and at least one negative cutout shape, and said step of calculating the area includes totaling the area of said at least one positive display surface shape and subtracting the area of said at least one negative cutout shape.

6. The method as claimed in claim 1, wherein said commands alter a transformation matrix, and wherein said step of testing includes testing said transformation matrix.

7. The method as claimed in claim 1, wherein said graphic element includes a nutrition facts table image.

8. The method as claimed in claim 1, wherein said graphic element includes a barcode image.

9. The method as claimed in claim 1, wherein said step of writing includes incorporating said results into a checklist image, said checklist image being included in said packaging image.

10. A self-checking module, for use in a packaging design system, for evaluating compliance of a graphic element within a packaging image, the packaging design system including a digital file defining the packaging image, the digital file including commands geometrically defining the graphic element, the self-checking module comprising:

(i) code means defining at least one geometric condition;

(ii) code means for testing said commands to determine the compliance of said graphic element with said at least one geometric condition, thereby producing test results; and

(iii) code means for writing said test results to said digital file.

11. The module as claimed in claim 10, wherein said code means for testing includes code means for calculating a copy safe area, code means for calculating the area of said graphic element, code means for determining a proportion of said copy safe area occupied by said graphic element, and code means for comparing said proportion with a value, said value being said geometric condition.

12. The module as claimed in claim 10, wherein said digital file includes at least one shape within said packaging image geometrically arranged to define a copy safe area within said packaging image, and wherein said code means for testing includes codes means for calculating the area of said at least one shape, code means for calculating the area of said graphic element, and code means for comparing a ratio of said areas with a value, said value being said geometric condition.

13. The module as claimed in claim 12, wherein said at least one shape includes at least one positive display surface shape and at least one negative cutout shape, and said code means for calculating the area includes code means for totaling the area of said at least one positive display surface shape and subtracting the area of said at least one negative cutout shape.

14. The module as claimed in claim 10, wherein said system includes a transformation matrix, said transformation matrix being responsive to said commands, and wherein said code means for testing includes code means for testing said transformation matrix.

15. The module as claimed in claim 10, wherein said graphic element includes a nutrition facts table.

16. The module as claimed in claim 10, wherein said graphic element includes a barcode.

17. The method as claimed in claim 10, wherein said code means for writing includes code means for incorporating said results into a checklist image, said checklist image being included in said packaging image.

18. A packaging design system for evaluating compliance of a graphic element within a packaging image, said system comprising:

(b) a raster image processor;

(c) a digital file including commands geometrically defining the graphic element; and

(b) a self-checking module for execution by said raster image processor, the self-checking module including:

code means defining at least one geometric condition;

code means for testing said commands to determine the compliance of said graphic element with said at least one geometric condition, thereby producing test results; and

code means for writing said test results to said digital file.

19. The system as claimed in claim 18, wherein said code means for testing includes code means for calculating a copy safe area, code means for calculating the area of said graphic element, code means for determining a proportion of said copy safe area occupied by said graphic element, and code means for comparing said proportion with a value, said value being said geometric condition.

20. The system as claimed in claim 18, wherein said raster image processor includes a transformation matrix, said transformation matrix being responsive to said commands, and wherein said code means for testing includes code means for testing said transformation matrix.