U.S. patent application number 11/973290 was filed with the patent office on 2008-05-01 for method and system for dynamic flowing data to an arbitrary path defined by a page description language.
This patent application is currently assigned to Tesseron Ltd.. Invention is credited to James R. Walker.
Application Number | 20080104509 11/973290 |
Document ID | / |
Family ID | 38870572 |
Filed Date | 2008-05-01 |
United States Patent
Application |
20080104509 |
Kind Code |
A1 |
Walker; James R. |
May 1, 2008 |
Method and system for dynamic flowing data to an arbitrary path
defined by a page description language
Abstract
Improvements to a method for flowing variable data, such as text
data, image data, bar code data, and the like, into a path of a
template defined by a PDL specification in a high-speed printing
operation.
Inventors: |
Walker; James R.;
(Maineville, OH) |
Correspondence
Address: |
MACMILLAN SOBANSKI & TODD, LLC
ONE MARITIME PLAZA FIFTH FLOOR
720 WATER STREET
TOLEDO
OH
43604-1619
US
|
Assignee: |
Tesseron Ltd.
|
Family ID: |
38870572 |
Appl. No.: |
11/973290 |
Filed: |
October 5, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09436749 |
Nov 9, 1999 |
7315979 |
|
|
11973290 |
Oct 5, 2007 |
|
|
|
60107583 |
Nov 9, 1998 |
|
|
|
Current U.S.
Class: |
715/276 |
Current CPC
Class: |
G06F 3/0483 20130101;
G06T 11/60 20130101; G06F 40/106 20200101 |
Class at
Publication: |
715/276 |
International
Class: |
G06F 17/00 20060101
G06F017/00 |
Claims
1. A method for generating a multi-page document, such as a book,
comprising the steps of: (a) accessing a page description language
file, the page description language file defining at least a
boundary; (b) accessing a text file external to page description
language file; (c) associating the boundary with the text file; (d)
accessing an attribute defining an aspect of the appearance of text
data in a bitmap image; (e) generating bitmap representations of
text data in the text file and, during the generating step,
applying the attribute to the text data; (f) creating a page of the
book by flowing the bitmap representations of the text data into
the boundary until the bitmap representations fill the boundary;
and (g) creating a next page of the book by flowing the remainder
of the bitmap representations of the text data into the boundary
until the remainder of bitmap representations fill the
boundary.
2. The method of claim 1, wherein the creating step (g) is repeated
for all of the remainder of bitmap representations.
3. The method of claim 1, wherein the page description language
file and the text file are defined in a job file external to the
page description language file and the text file, and the method
further includes the step of, prior to step (a), processing the job
file to identify the external page description language file and
the external text file.
4. The method of claim 1, further comprising the step of (h)
dispatching the page and the next page to a printer.
5. The method of claim 1, wherein the attribute is defined in the
page description language file.
6. The method of claim 5, wherein the attribute defined in the page
description language file is associated with the boundary.
7. The method of claim 6, wherein the boundary is defined by a path
command and attribute is associated with a string command linked to
the path command.
8. The method of claim 7, wherein the attribute is part of a
graphic state associated with the string command.
9. The method of claim 1, wherein the attribute is defined in a
file external to the page description language file.
10. The method of claim 9, wherein the attribute is defined in a
job file.
11. The method of claim 1, wherein the text file includes a
plurality of text blocks separated by delimiters.
12. The method of claim 11, wherein the generating step (e) applies
different attributes to at least two of the plurality of text
blocks.
13. The method of claim 11, wherein at least one of the creating
steps (f) and (g) include a step of flowing a bitmap of an artistic
image between at least two of the plurality of text blocks.
14. The method of claim 13, wherein the method further includes the
step of redefining the boundary for the page into which the bitmap
of the artistic image has been flowed to include a perimeter of the
artistic image.
15. The method of claim 1, wherein the text data is modified prior
to the generating step (g) to insert personal information
associated with an intended recipient of the multi-page document
into the text data.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a divisional of U.S. patent application
Ser. No. 09/436,749, filed Nov. 9, 1999, which claimed the benefit
of U.S. Provisional Application No. 60/107,583, filed Nov. 9, 1998.
The disclosures of both applications are incorporated herein by
reference.
BACKGROUND OF THE INVENTION
[0002] This invention relates in general to the high speed printing
industry, and more particularly a system and method for flowing
variable data into a page description language file in a high speed
printing environment.
[0003] Application programs, such as word processors, illustrators,
and computer-aided design systems are software packages used to
create a document (text and graphics) on a computer screen and to
simultaneously generate a page description language ("PDL")
specification, which is to be transferred to the printer or to any
other type of raster or output device for creating a hard copy or
copies of the document. Alternatively, a PDL specification can be
generated by a programmer without the assistance of an application
program.
[0004] The printer executes the PDL specification to generate a
bitmap of the document, or a raster-data representation of a
document, and eventually transfers the bitmap or raster-data to the
physical medium. A typical PDL language, such as PostScript (a
registered trademark of Adobe Corporation) defines a page of the
document as containing a number of data areas, where each data area
contains either graphic or alpha-numeric data. Each data area is
defined by a "graphic state," which is a collection of parameters
for controlling the representation and appearance of text and
graphics. For example, the graphic state can include a set of text
attributes such as scale-factor, type-font, etc. In PostScript, an
example of a PDL command used to build a graphic state can be:
twenty rotate\Times-Roman findfont 14 scalefont and setfont.
Examples of PDL commands used to define the graphic or
alpha-numeric data that is displayed in the data area include: 0 0
moveto and (ABC) show. The entire group of PDL commands used to
define a document is hereinafter referred to as the "PDL
specification."
[0005] In variable data printing each printed document shares a
common template and there is at least one area in the template that
changes for each printing of the template. Typical PDL languages
are not designed for high-speed variable data printing because,
with PDL languages and PDL interpreters, even if a single item of
data in the document changes, an entirely new PDL specification
must be created and interpreted. For example, if one-hundred
thousand copies of a mass-mailing advertisement were to be printed
(i.e., each copy of which is identical except for the mailing
address), it is typically necessary to generate a new PDL
specification for each copy to be printed. Hence, to generate
one-hundred thousand advertisements, it would be necessary to
generate one-hundred thousand PDL specifications, even though each
advertisement is virtually the same except for the variable data
area. The processing time required to interpret and render
one-hundred thousand PDL specifications is enormous, significantly
slowing the entire printing system.
[0006] Furthermore, typical PDL languages do not include any text
or data flowing capabilities. These features are usually
implemented by the application program, and when such an
application program flows data (such as text) into a PDL document,
the calculations to determine where to place the data are completed
prior to the generation of the PDL specification. Accordingly,
variable data cannot be flowed into a template document without
creating a new PDL specification for each document. Accordingly,
there is a need for a high-speed printing operation having the
ability to merge variable data into a template defined by a PDL
specification; in particular, having the ability to flow variable
data into a template path defined by PDL specification in a
high-speed printing operation.
SUMMARY OF THE INVENTION
[0007] It is an object of this invention to provide a system and
method for flowing variable data (such as text data, image data,
bar code data and the like) into a path of a template defined by a
PDL specification in a high-speed printing operation. It is a
further object of this invention to provide the ability to generate
a plurality of merged bitmaps, which are each essentially a copy of
a template, except for at least one portion of the template that
contains an arbitrary path. In that path, each merged bitmap can
contain a different set of variable data merged into it. The
template is defined by a page description language, and the page
description language only needs to be processed or interpreted once
before creating all of the merged bitmaps, thus providing an
extremely high-speed variable data printing operation.
[0008] The computer implemented method for flowing data into an
arbitrary path defined by a page description language specification
("PDL specification") generally comprises the steps of: processing
(interpreting) the PDL specification to produce a template;
designating a path defined in the PDL specification as a wrapping
path; associating a block of variable data with the wrapping path;
and merging variable data, according to the path boundary and
according to a predefined flow rule, into a copy of the
template.
[0009] The method of this invention is accomplished by executing a
control task in conjunction with a PDL interpreter program. The
control task generates a template display list based upon the PDL
commands in the PDL specification. The display list includes a
plurality of rendering commands, where each rendering command
designates a particular data area or object to be rendered, the
graphics state to be applied to the data area and the offset
address at which the rendered object, if any, in the data area is
to be overwritten onto the final bit map. The graphic states for
each data area are set forth in the PDL specification, and pertain
to the print attributes that describe how particular graphic or
alpha-numeric data is to appear on the printed page. These
attributes can include the size, font, position, orientation,
location, and the like.
[0010] The control task, during the PDL interpretation procedure,
monitors the data areas defined by the PDL specification to watch
for variable data paths defined by the PDL code. If the control
task identifies a path as being a variable data path, it reserves
the graphic states associated with that variable data path in a
cache or memory, and then moves on to the next data area defined in
the PDL specification, preferably without allowing the path data to
be added to the template display list.
[0011] Once the interpreter program completes its interpretation of
the PDL specification, the control task saves the template display
list in memory without dispatching a bitmap of the template to the
printer. Subsequently, a merge task is initiated which accesses a
variable data record from a merge file; associates the variable
data record to a particular variable data path; creates
representations of the variable data, such as rendering commands
according to the reserved graphic states pertaining to that
particular variable data path, according to the boundary of the
particular variable data path and according to a predefined flow
rule; and then generates a merged bitmap by processing the template
display list and the variable data rendering commands. The final
merged bitmap may then be dispatched to the printer. This merge
task is repeated for each variable data record in the merge file
associated with that particular variable data path to create a
plurality of the merged bitmaps.
[0012] Thus, the PDL specification of the template need only be
interpreted once, saving significant processing time for the
variable printing operation, because the reserved graphic states
may be utilized over and over again to create the flowed data
bitmap for each variable data record contained in the merge
file.
[0013] How the control task identifies a particular PDL path
defined in the PDL specification as being unique, i.e., as being
identified as a wrapping path, is an important step in the above
process. This is accomplished by providing a text command in the
PDL specification that defines one or more characters that are
recognized by the control task as being special characters, as
opposed to merely being characters that are to be included on the
printed page. The control task monitors all text strings defined by
the PDL specification for such special characters, and responsive
to a detection of the special character in the text string defined
by the text command, the control task identifies the path command
that has a predetermined relationship with the text command in the
PDL specification. This predetermined relationship can be satisfied
by the first path command to follow the text command in the PDL
specification or by the path command that is "grouped" with the
text command in the PDL specification.
[0014] In one embodiment of this invention, the characters
"<<" and ">>" are used as part of a special text string
to define an area as a variable data area. And if that special text
string also includes the string wrap then the control task will
recognize that the very next path command appearing in the PDL
specification will be a unique path, in this case a path for
flowing variable text bitmaps into.
[0015] Various aspects of this invention will become apparent to
those skilled in the art from the following detailed description of
the preferred embodiment, when read in light of the accompanying
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 is a is a schematic, block-diagram representation of
a high-speed printing system according to this invention;
[0017] FIG. 2 is a first example of a job ticket file for use with
this invention;
[0018] FIG. 3 is a second example of a merge file for use with this
invention;
[0019] FIG. 4 is a graphical representation of data contained in a
first example PDL specification for use with this invention;
[0020] FIG. 5 is a graphical representation of a process step of
this invention operating on data contained in the PDL specification
of FIG. 4;
[0021] FIG. 6 is a graphical representation of a process step of
this invention following the process step of FIG. 5;
[0022] FIG. 7 is a graphical representation of a process step of
this invention following the process steps of FIGS. 5 and 6;
[0023] FIG. 8 is a graphical representation of a process step of
this invention following the process steps of FIGS. 5 and 6;
[0024] FIG. 9 is an example of a merged document created by the
process and system of this invention;
[0025] FIG. 10 is an example of a merged document created by the
process and system of this invention;
[0026] FIG. 11 is a flow chart representation of a process of this
invention;
[0027] FIG. 12 is an example of a merged document created by the
process and system of this invention;
[0028] FIG. 13 is an example of a merged document created by the
process and system of this invention;
[0029] FIG. 14 is a second example of a job ticket file for use
with this invention;
[0030] FIGS. 15A and 15B are a second example of a merge file for
use with this invention;
[0031] FIG. 16 is a graphical representation of data contained in a
second example PDL specification for use with this invention;
[0032] FIGS. 17A-17C are graphical representations of process steps
of this invention operating on data contained in the PDL
specification of FIG. 16, the job ticket of FIG. 14 and the merge
files of FIGS. 15A-15B; and
[0033] FIGS. 18A-18C are examples of merged pages created by the
process of this invention using the PDL specification of FIG. 16,
the job ticket of FIG. 14 and the merge files of FIGS. 15A-15B.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0034] As shown in FIG. 1, a system for performing the method of
this invention includes a printer controller 10 having access to a
job ticket file 12, a page description language ("PDL") file 14, a
source of variable data such as a merge file 16, and an optional
printer configuration file 18. The system also contains an operator
control terminal 20 for providing operator controls such as
indicating the name and path of the job ticket file 12 for the
specific print job.
[0035] The job ticket file 12 contains the guidelines for the print
job which can include the names and locations of the PDL file(s)
14, the merge file(s) 16, the configuration file(s) 18, etc.; and
may also include special instructions pertaining to features such
as data wrapping, described below. The PDL file 14 is preferably a
PostScript.RTM. (registered TM of Adobe Systems, Inc.)
specification created by an application program, such as a word
processor, illustrator, or computer-aided design system. The merge
file 16 contains platform independent data, such as text data,
image data, bar-code data and the like, which is to be merged into
a template bitmap defined by the PDL file during the merging task,
as will be described in detail below. The configuration file 18
defines the print engines and post processing equipment and other
options to be executed.
[0036] Initially, the path and name of the job ticket file 12 are
specified by the operator using the operator control terminal 20.
The printer controller 10 retrieves the job ticket file 12 and then
retrieves the PDL files 14 and merge files 16 that are specified in
the job ticket file. Next the controller 10 initiates a control
task 22 in conjunction with a page description code interpreter
program.
[0037] The control task interprets the PDL specification from the
PDL file 14 and monitors data areas defined in the PDL
specification to watch for areas defined by the specification to
become variable. If the control task identifies a data area as
being a variable data area, it reserves the graphic states 23 of
that variable data area in memory 24 and then moves on to the next
data area defined by the PDL specification, usually without
allowing any data defined by the variable data area to be added to
the template bitmap. Preferably, the control task 22 will also
create a font cache (an entire set of character bitmaps generated
according to the reserved graphic states) for the reserved graphic
states, which will be linked to the reserved graphic states in
memory 24. Once the control task completes its processing of the
PDL specification, the control task saves the template bitmap 25 in
memory 26.
[0038] The control task 22 may also create a template display list
25 of static data defined by the PDL file 14. The display list 25
will include a plurality of rendering commands, where each
rendering command designates a particular static data area or
object to be rendered, the graphics state to be applied to the
static data area and the offset address at which the rendered
object, if any, in the static data area is to be overwritten onto
the final bit map. As mentioned above, the graphic states for each
data area are set forth in the PDL specification, and pertain to
the print attributes that describe how particular graphic- or
alpha-numeric data is to appear on the printed page. Once the
control task completes its processing of the PDL specification, the
control task may save the template display list 25 in memory 26. If
the PDL file 14 does not include code for any static data, the
control task may generate an empty template display list 25 or may
decide not to create a template display list at all.
[0039] Next, a merge task 28, having access to the variable data
records 17 from the merge file 16, is executed to apply the
reserved graphics states 23 and associated font cache to the
variable data records 17, creating rendering commands for that
variable data record as defined by the graphic states. The merge
task 28 retrieves a copy 25' of the template display list 25 from
the memory 26 and merges the variable data rendering commands with
the template display list to create a merged display list 30.
Finally, the controller 10 performs a rendering task 32 to render
the merged display list 30 into a plurality of bitmap bands 34 for
dispatching to at least one print engine 36.
[0040] A method for performing the above control task and merge
task is described in U.S. Pat. No. 5,729,665 entitled "Method of
Utilizing Variable Data Fields with a Page Description Language,"
the disclosure of which is incorporated herein by reference. A
method and system architecture for performing the above merging,
banding and dispatching operations are respectively described in
U.S. Pat. Nos. 5,594,860 and 5,796,930, the disclosures of which
are also incorporated herein by reference.
[0041] A first embodiment of this invention is illustrated by way
of example in FIGS. 2-10. As illustrated in FIG. 2, the job ticket
file 12 can contain a file path 38 for determining the location and
name of the PDL file, and can contain a file path 40 for
determining the location and name of the merge file. The job ticket
file 12 can also contain a descriptive name of a path 42, in this
case, named "Shape," for identifying a name of a path in the PDL
file that is to have variable data flowed into it during the merge
task. The variable data to be flowed into the path, text data in
this case, will be taken from the file designated by the file path
40 of the merge file. In this case the merge file is named
"info.text." The group header 44 "[Wrap]" indicates that the group
is defining a wrapping path. After the wrapping path "Shape" has
been defined in the job ticket file, a second group header 46
"[Shape]" can be thereafter defined in the job ticket file to
provide information about the wrap path; such as defining the fill
rule 48 to be used in the wrapping operation, and such as defining
a path drawing rule 50, i.e., whether the path is to be drawn in
the final rendered image. Other definable wrapping commands for the
particular path "Shape" can include defining the top, bottom or
side margins, defining the justification, setting the number of
paths to flow the data into, defining an overflow path, etc. A
complete description of the different elements that can be defined
for the wrapping path in the job ticket file is described in detail
in the Appendix, below.
[0042] As illustrated in FIG. 3, the merge file 16 is a
platform-independent data file that contains the "variable" data to
be merged into the path defined in the PDL specification. The merge
file can contain a field name 52, corresponding to a field name
that will be defined in the PDL specification, which is associated
with a particular variable data path. The merge file will also
contain a number of variable data blocks 54, text blocks in this
case, corresponding to the field name 52. One variable data block
54 will be merged into the variable data path, defined in the PDL
specification, at a time.
[0043] As illustrated in FIG. 4, the designer will utilize an
application program to create a document containing a path 56 and
attribute data, such as an attribute string 58, to be associated
with the path 56. The application program will then be directed to
create a PDL specification of the document by the designer. The
attribute string 58 contains a field name 60 surrounded by special
characters, "<<" and ">>", a wrap attribute command
string 62, and a path identifier 64. The PDL specification
generated by the application program will include the graphic
states of the attribute string 58. These graphic states can include
the font size (i.e., 10 point), the type-font (i.e., Script) the
orientation (i.e., angled upwardly at 50.degree.) and the like.
[0044] As discussed above, and referring again to FIGS. 1-4, the
control task 22 will execute a PDL interpreter program to interpret
the PDL specification created by the application program to
generate a template bitmap 25 of the document, and to also monitor
for any variable data paths defined in the PDL specification.
[0045] In the preferred embodiment, the control task 22 monitors
for variable data areas defined by the PDL specification by
monitoring for special characters in the text strings defined by
text commands in the PDL specification. As shown in FIG. 4, the
special characters "<<" and ">>" surround the field
name 60. The control task, upon identifying the special characters
in the text command for the attribute string will thus know that
the attribute string 58 is defining a variable data area, and is
not merely defining a text string to appear on the printed page
(the attribute string will not appear on the final printed page
unless the control task is directed to by the job ticket file). The
field name 60 surrounded by the special characters identifies the
associated field name 52 present in the merge file 16. During the
processing of the text command for the attribute string 58, the
control task will also monitor for the wrap string 62 within the
attribute string, which also includes the path identifier string 64
associated therewith. If found, the control task will know that a
path defined in the PDL specification that has a predetermined
relationship with the text command for the attribute string will be
a wrapping path, where the wrapping path has the wrapping
attributes defined in the job ticket file 12 for the particular
group header 44 and descriptive name of a path 42 matching the path
identifier string 64 set forth in the attribute string 58.
[0046] Preferably, the predetermined relationship is satisfied by
the first path command to follow the text command for the attribute
string in the PDL specification. This can be accomplished by using
the application program to sequentially type the attribute string
58 and then draw the path 56, such that the path command will be
the first path command to follow the text command in the PDL
specification created by the application program. Alternatively the
predetermined relationship can be satisfied by the path command
that is "grouped" with the text command for the attribute string in
the PDL specification. This can be accomplished by using a "GROUP"
tool as provided by many application programs to group the
attribute string 58 and path 56 together. It will be apparent to
one of ordinary skill in the art that there are many similar
predetermined relationships available between the text command for
the attribute string and the path command for the wrapping path
that can be established in the PDL specification, all of which fall
within the scope of this invention.
[0047] Thus, during the execution of the PDL interpreter program,
the control task 22 will match the wrap attribute command string 62
and path identifier 64 with the group header 44 and descriptive
name of the path 42 defined in the job ticket file 12. Once the
attribute string 58 is identified as defining a variable data path
by the control task 22, the control task will save the graphic
states 23 of the attribute string 58 in memory. The control task
may also create a font cache according to the graphic states 23,
and store the font cache along with the graphic states in memory
24. The control task will also save the field name 60 along with
the graphic states 23 in memory so that the particular graphic
states can be matched to the blocks of text data in the merge file
16 under the matching field name 52, as will be described below.
The merge task 28 will apply these graphic states 23 and associated
font cache to the variable data 54 prior to merging and flowing the
variable data into the path 56.
[0048] Once the control task 22 has identified the path as being a
variable data path, and has reserved the graphic states 23 of the
attribute string 58 associated with the path in memory 24, the
control task 22 advances to the next data area in the PDL
specification, preferably without allowing the attribute string
data or the path to be added to the template display list 25 stored
in memory 26. And once the PDL interpreter program has completed
interpreting the PDL specification, the control task 22 then passes
authority to the merge task 28.
[0049] The merge task 28 first accesses a set of the saved graphic
states 23 and identifies the field name 60 associated with these
graphic states. The merge task 28 then accesses the merge file 16
and searches the merge file for a field name 52 matching the field
name 60 associated with the graphic states. The merge task then
accesses a variable data block 54 associated with the field name 52
and then generates rendering commands for the variable data block
according to the graphic states 23, the predefined flow rule 48 and
the boundary of the path 56. The predefined flow rule 48 may or may
not be defined by the job ticket file 12. Accordingly, when the
rendering command is executed the bit map data defined by the
rendering command will flow within the path 56 according to a
predefined flow rule.
[0050] As shown in FIG. 11, and as illustrated in FIGS. 5-10, a
method for merging and flowing the variable text data into the path
56 is as follows: as indicated in step 100 and illustrated in FIG.
5, preferably the control task will first "flatten" the path, which
involves breaking the complex path 56 (which may contain ellipses
and curves) into a series of simple straight lines 64 (i.e.,
converting the path into a series of "move to" and "line to"
commands). Each straight line 64 will comprise a particular portion
of a boundary 65, into which the variable data is to be positioned.
Alternatively, it is within the scope of the present invention to
have the path 56 itself define the boundary into which the variable
data is to be positioned. As will be described below, the extent of
the boundary may also be defined, in part, by the designation of
margins, or the creation of additional paths, etc. As indicated in
step 102 and as also illustrated in FIG. 5, a horizontal axis 67 of
a coordinate system 69 will be aligned with the attribute string
58. As indicated in step 104 and as illustrated in FIG. 6, a new
equivalent boundary 65' is created, whose coordinates are those of
the original boundary 65, but rotated into the same coordinate
system 69 as the attribute string 58 (for example, as shown in FIG.
5, the attribute string 58 is rotated a negative 50.degree. in the
document, and therefore, in FIG. 6 the boundary 65' is rotated by a
positive 50.degree.).
[0051] As indicated in step 106, the stored graphic states 23
(e.g., font-type and point size) are applied to a variable data
block 54 to be merged into the boundary 65' and to calculate the
dimensions of a plurality of word bitmaps, the word bitmaps being
defined by a collection of characters separated from the rest of
the data by white space characters (e.g., a space, tab, new line,
etc.). The dimensions of paragraphs can be calculated by defining a
paragraph as a collection of word bitmaps separated from other
paragraphs by "new line" characters. Assuming that the text flow
direction will be from top to bottom and left to right, as
indicated in step 108 and as illustrated in FIGS. 7 and 8, the
"top" or highest point 66 of the path 65' is determined and a top
margin 68 is applied to the boundary 65' by measuring a distance
downward from the highest point 66 of the boundary. The top margin
68 can be pre-defined, defined in the job ticket file 12, or by any
other sufficient means.
[0052] As indicated in step 110 and illustrated in FIGS. 7 and 8, a
rectangular insertion area 70 is defined, having a vertical height
corresponding to the calculated vertical height of the bitmap
representation of the first word (the point size of the text) to be
flowed into the boundary 65', and having a top horizontal border 72
abutting the top margin 68. As indicated in step 112, this
insertion area 70 will be overlayed onto the entire boundary 65' at
that present vertical level to establish at least one intersection
point 74. As indicated in step 114, only those areas between
adjacent intersection points 74 will be considered valid candidates
for receiving the bitmap representations of the text data. If there
are more than two intersection points present within the insertion
area, then the particular flow rule being utilized will determine
between which of the intersection points that the bitmap
representations of the text data will be inserted. As illustrated
in FIGS. 7 and 8, when only two intersection points are
established, the bitmap representations of the text data will
typically be inserted therebetween.
[0053] Once two adjacent intersection points 74 are determined to
be candidates for receiving bitmap representations of the text
data, as indicated in step 116 and illustrated in FIG. 8, left and
right margins will then be measured inwardly from each of the
intersection points 74 to define left and right borders 77 within
the rectangular insertion area 70. Between the left and right
borders 77, therefore, is defined a text placement area 78 for
merging the bitmap representations of the text data therein. The
left and right margins 76 can be pre-defined, defined in the job
ticket file 12, or determined by any other sufficient means.
[0054] As indicated in step 118, the rendering commands to create
the bitmap representations of a word of the text data as merged
into the text placement area are created and added to the display
list 25, depending upon whether the calculated width of the bitmap
is equal to or less than the available width calculated to remain
in the text placement area. The rendering commands will define the
proper orientation of the bitmap representation of the word rotated
back into the original orientation of the attribute string.
[0055] As illustrated in FIG. 8, in the first text placement area
78, bitmap representations of the words "in" and "a" were able to
fit therewithin, however, the bitmap representation of the word
"world" was too wide for the remaining width. Accordingly, in the
final merged bitmap only the bitmaps representing the words "in"
and "a" will be rendered into the first text placement area 78. If
no word bitmaps are capable of fitting within the text placement
area, then the area is left blank.
[0056] As indicated in step 120 and illustrated in FIG. 8, a
line-spacing 79 is measured below the present insertion area and
then the next rectangular insertion area 80 is created and
overlayed onto the boundary 65' below the line-spacing 79 in the
same manner as defined above for the first rectangular insertion
area 70. As indicated in step 122, if the new insertion area
extends below the lowest point of the boundary 65' (or below the
bottom margin) or if there are no more words to insert, then the
merging process for this particular boundary and text block is
finished as shown in step 124. If the insertion area does not
extend below the lowest point of the boundary and there are more
bitmaps representing words to insert, then the process returns to
step 114, described above. Essentially, steps 114-122 will be
repeated thereafter until step 124 is reached. As illustrated in
FIG. 8, bitmaps representing the words "world" and "of` were able
to be rendered into the second rectangular insertion area 80 and
bitmaps representing the words "interactive," "media" and "and"
were able to rendered into third rectangular insertion area 82.
[0057] Subsequent to step 122, the merge task will then search for
additional variable data areas or variable data paths in which to
merge variable data blocks. If no more of such variable data areas
or variable data paths exist for the particular document, then the
merged display list 30 is transferred to the rendering task 32, as
described above, to generate the bitmap bands 34 for printing. FIG.
9 illustrates the entire block of text 54 from the merge file 16
formatted according to the above process and merged into the path
56 to create a first finished document 84. FIG. 10 illustrates the
appearance of the next block of text 54' from the merge file 16
formatted according to the above process and merged into the path
56 to create a second finished document 86.
[0058] Preferably, in the above step 118, the height of the
rectangular insertion area is determined by the dimensions
calculated for the first word bitmap. And if, for whatever reason,
a next word bitmap is calculated to be higher than the first or
previous word bitmap, and higher than all other word bitmaps
inserted thus far into a particular text placement area, then the
entire rectangular insertion area is thrown out, and steps 116 and
118 are repeated again for the higher rectangular insertion area
generated according to this higher word bitmap.
[0059] As discussed above, a number fill rules are available for
flowing the word bitmaps into the boundary. Accordingly, the merge
task can mark the path intersections 74 as "positive," "negative"
or "neutral" based upon whether the path enters and leaves from the
top or the bottom of the insertion area, or whether it enters and
exits the insertion area from the same direction. All of the
available fill rules will be apparent to one of ordinary skill in
the art, and are thus within the scope of this invention.
[0060] As discussed above, text flowing into the boundary 65' will
continue until it is determined that there are no more word bitmaps
to flow into the boundary or until it is determined that there is
no more text areas available to flow the word bitmaps into. In the
case of the latter, it is within the scope of the invention to
define a path as an "overflow" path for continuing the flowing of
the text therein, until this overflow path runs out of room. This
overflowing process can continue until once again it is determined
that there are no more text areas to flow text into. Text can also
flowed into more than one path at a time.
[0061] For illustration, as shown in FIG. 12, if the job ticket
file defines the number of flow paths as two, and the two flow
paths are the circle and square paths, designated as numerals 88
and 90, respectively; then the two paths essentially comprise one
boundary, and text will flow directly from the circle path 88 into
the square path 90. Note that the 2nd through 8th lines of text
flow from the circle path 88 directly into the square path 90. But
when the text reaches the end of the square path 90, the flowing
operation stops because the area within the two flow paths has been
used up. Accordingly, as illustrated in FIG. 13, if an "overflow
path" is designated in the job ticket file to be the triangle path
92, the text flowing will continue into the triangle path 92 until
there is no more text to be merged or until the path runs out of
additional room.
[0062] The operation of this invention is illustrated by way of a
second example as shown in FIGS. 14-18. This second example
illustrates the use of this invention in constructing a book having
variable text and picture placement, where a character name
presented in the book may also be customized. Once customized, the
text and pictures will flow into the pages of the book regardless
of the size differences between the substituted character names.
For example, if a substituted character name is substantially
longer or shorter than the original character name in the text, the
text and pictures will flow throughout the book such that no
noticeable gaps or overflows are detectable. In order to perform
such a task, this invention allows a plurality of different merge
files or data items to be flowed into a single path; this invention
allows text to flow around pictures that are inserted into the
path; and by utilizing special delimiters within the merge file,
the merged task is able to recognize points in the merge data where
the graphic states to be applied to such merge data are to be
changed in accordance with a next attribute string in the PDL
Specification. This is all explained in detail as follows:
[0063] As illustrated in FIG. 14, the job ticket file 12 contains a
group header, "[PageDescriptionLanguageFile]" 126 specifying the
file path(s) defined thereunder as determining the locations of the
`template` PDL files. In the present example, the template PDL file
path 128 defines the location of the template (PostScript) file
"jungle.ps" as shown graphically in FIG. 16. Next, the job ticket
file 12 lists a group header, "[MergeFiles]" 144 specifying the
labels ("names" and "rikkitxt") of the merge files to be accessed
by the merge task. The group header "[names]" 146 is thereafter
defined in the job ticket file to provide information about the
merge file "names.txt" located in the file path 130. As indicated
by the definitions following the group header "[names]" 146, this
merge file is a delimited merge file where the record delimiters
are `/n` and the field delimiters are `|`. In this merge file, the
definition DoGlobalSubstitution is set to FALSE, which indicates
that substitutions of the text within the merge file are not to be
performed by the merge task during the merging operation. The group
header "[rikkitxt]" 148 provides information about the merge file
"rikki.txt" located in the file path 132. The MergeType definition
is set to "field", which indicates that the merge file only
contains a single record, and therefore requires no record
delineations. The MergeHeader definition is set as NO, which
indicates that the merge file will not include a merge header
(because there is only one record in the merge file). As also
defined under the "[rikkitxt]" group header is that the field
delimiter will be `#` character, the page break delimiter will be
the `.about.` character and the paragraph delimiter will be the `@`
character. Finally, the definition DoGlobalSubstitution is set to
TRUE which means the merge task is to look for text phrases within
the rikki.txt merge file and replace them with variable data as
defined in the job ticket file as follows.
[0064] The group header 150 "[mergefile:substitution]" establishes
the global substitutions for the "rikki.txt" merge file as
described above. Accordingly, within the body of the "rikki.txt"
merge file, every instance of the name Mowgli is to be changed to
the variable data name listed under the "name1" heading (which is
present in the "names" merge file--not shown). Furthermore, any
occurrence of the name Teddy within the "rikki.txt" merge file will
be replaced with the same variable data name as listed under the
"name1" heading in the "names" merge file. This substitution is
preferably performed by the merge text when creating bitmaps for
the merge data in the "rikki.txt" merge file that are to be merged
into the template defined in the "jungle.ps" file (FIG. 16).
[0065] The next group header 136 "[Wrap]" in the job ticket file 12
contains a descriptive name of a path 134 (in this case, named
"path") for identifying a name of a path in the PDL file that is to
have variable data flowed into it during the merge task. The group
header 136 "[Wrap]" indicates that the group is defining a wrapping
path. After the wrapping path "path" has been defined in the job
ticket file, a next group header 138 "[path]" is thereafter defined
to provide information about the wrap path, such as defining the
FillRule 140 as using the even/odd rule, defining the DrawPath
definition as FALSE 142 to indicate that the path is not to be
drawn. The other definable wrapping commands for the particular
path "path" are described in detail in the appendix below.
[0066] Although not shown in FIG. 14, the job ticket file 12
includes attribute definitions defining the print job as a `book`
job, which directs the merge task to repeatedly access templates
and flow bitmaps into the path(s) in the templates until the merge
task reaches the end of the merge file.
[0067] As illustrated in FIGS. 15A and 15B, the merge file
"rikki.txt" 16 is a platform independent data file that contains
the `variable` data to be merged into the path defined in the PDL
specification (FIG. 16). In the present example, this merge file
does not contain a field name because the MergeHeader definition in
the job ticket file 12 was set to NO. In the present example, the
mergefile is a single data record consisting of the text of the
Rikki-Tikki-Tavi story of the Jungle Book. Paragraph delimiters 154
(`@`) are placed at selected points within the text to inform the
merge task where to start a new paragraph during the merging
operation. Field delimiters 156 (`#`) are also placed in selected
areas of the text to indicate to the merge task when a particular
field of the merge file has ended and a next field of the merge
file is to begin. The use of the field delimiters 156 will be
described in greater detail below.
[0068] As illustrated in FIG. 16, the designer will utilize an
application program to create a template document 157 containing a
path 158 and several attribute data strings 160. As discussed
above, the designer will associate the attribute data strings 160
with the path 158 by assuring that the path 158 is the first path
drawn after the insertion of the attribute data strings 160 or by
using a "GROUP" feature of the application program to group the
attribute data strings 160 with the path 158. As also shown in FIG.
16, the template document 157 also contains static data 162 which
will remain constant during every printing of the merged document.
Once the template document 157 has been created, the application
program will then be directed to create at PDL specification 14 of
the document. Each attribute string 160 contains a field name 164
surrounded by special characters, a wrap attribute command string
166, and a path identifier 168 if the attribute data is to be
associated with a path. The PDL specification generated by the
application program will include the graphic states of the
attribute strings. For example, the graphic states for first
attribute string 170 include a bold/italics font attribute and a
larger point size attribute; the graphic states for second
attribute string 172 include an italics font attribute and a
smaller point size attribute than the first attribute string; the
graphic states for third attribute string 178 include a standard
font attribute, etc.
[0069] As discussed above, referring to FIG. 1 and FIGS. 14-17, the
control task 22 will execute a PDL interpreter program to interpret
the PDL specification created by the application program to
generate a template bit map 25 of the template document 157, and to
also monitor for any variable data paths defined in the PDL
specification 14. During the execution of the PDL interpreter
program, the control task 22 will match the path identifier 168 in
each wrap attribute command string 166 with the group header 136
and descriptive name of the path 134 defined in the job ticket file
12. Once the attribute string 166 is identified as defining a
variable data path by the control task 22, the control task will
save the graphic states 23 of the attribute string 166 in memory
(which is preferably a stack). The control task may also create a
font cache according to the graphic states 23, and store the font
cache along with the graphic states to memory 24. The control task
will also link the graphic states 23 with the merge file defined by
the job ticket file having a name matching the field name 164
("rikitxt" for the first, second, third and fifth attributes
strings 170, 172, 178, 182 and 190). The merge task 28 will apply
these saved graphic states 23 and the associated font cache to the
variable data prior to merging and flowing the variable data into
the path 158.
[0070] Once the control task 22 has identified the path as being a
variable data path; and it has reserved the graphic states 23 of
the attribute strings 166 associated with the path in memory 24,
the control task 22 advances to the next data area in the PDL
specification, preferably without allowing the attribute strings or
the path to be added to the template display list 25 stored in
memory 26. Once the PDL interpreter program has completed
interpreting the PDL specification, the control task 22 then passes
authority to the merge task 28.
[0071] The merge task 28 first accesses a first set of graphic
states 23 from memory 24 and identifies the particular field name
164 associated with these graphic states. The merge task 28 then
accesses the merge file 16 associated with this field name and
graphic states. The merge task then accesses a variable data block
associated with a first variable data block in the merge file and
then generates rendering commands for the variable data block
according to the graphic states 23, the predefined flow rule 140
and the boundary of the path 158.
[0072] As illustrated in FIGS. 17A-17C, a method for merging and
flowing the text data in the merge file into the path 158 of the
document 157 to create the variable length book is as follows. Upon
initiation, the merge task will first access the saved graphic
states and attributes associated with the first attribute string
170 defined in the PDL specification. As shown in FIG. 16, the
field name is "rikkitxt" and the path associated with the attribute
string 170 is the path 158 (because the path 158 is the first path
created after the attribute string 170). Referring to FIG. 14, the
merge task matches the field name "rikkitxt" 164 in the first
attribute string 170 with the group header 148, and accesses the
merge file identified by the path 132. As shown in FIG. 15A, a
first text-block 171 is taken from the beginning of the mergefile
until a first field delimiter 156a is encountered. The saved
graphic states 23 associated with the first attribute string 170
are applied to this text block to create a bit map for the text
block which is then flowed into the path 158 as shown by numeral
172 in FIG. 17A. Note that the attribute string 170 included an
attribute command "textc," which caused the control task to add an
additional text centering attribute to the saved graphic states 23.
Accordingly, the bit map 172 associated with the text string and
applied graphic states is centered in the path 158. The paragraph
delimiter 154 in the mergefile causes the merge task to add a line
space after the insertion of the bit map 172.
[0073] Because the merge task reaches the first field delimiter
156a in the mergefile, the merge task refers back to memory to
retrieve the reserved graphic states 23 attributed to the second
attribute string 172. The field name 164 identified by the second
attribute string 172 is "rikkitxt" as in the first attribute string
170; and therefore, the merge task will again refer to the
mergefile 152 when retrieving variable data to insert into the
path. It is should be apparent to those of ordinary skill in the
art that the field name 164 may also refer to a different merge
file and the merge task would thus access data from the different
merge file. As with the first attribute string 170, the second
attribute string 172 includes the additional attribute commands
such as "textc" and "padjust=0." Referring again to FIG. 15A, the
merge task will access the next block of data 173 between the first
field delimiter 156a and the second field delimiter 156b. The merge
task will then apply the graphic states 23 corresponding to the
second attribute string 172 to this text data to form the bit map
data block 174 to be merged into the path 158. Once this bit map
block has been merged into the document, the merge task accesses
the graphic states associated with the next attribute string 178
from memory.
[0074] Because the field name 164 in the third attribute string 178
is "rikkitxt" as with the first two attribute strings, the merge
task will refer back to the mergefile 152 and will extract the
block of data 179 after the second field delimiter 156b and before
the third field delimiter 156c. The graphic states 23 associated
with the third attribute string 178 will be applied to this text
data to create bit map data which is merged and flowed into the
path 158 according to the steps described herein. Once the merge
text reaches the end of the path 158, the merge task will know to
access another copy of the template from memory because a "book"
attributes have been predefined in the job ticket file. The second
template bit map is indicated in FIG. 17B. Note that the block of
text flows beyond the path 158 of the second template bitmap shown
in FIG. 17B and into the path 158 of the third template bitmap
shown in FIG. 17C. Once this block 180 has been mapped and the
merge task reaches the third field delimiter 156c, the merged task
refers back to the graphics states 23 in memory to obtain the
graphic states associated with the fourth attribute string 182.
[0075] The field name 164 in this attribute string 182 refers to
"rpic1", which is defined in the job ticket file as a bit map of a
picture to be inserted at this point. Note that this attribute
string also includes additional attribute commands: "text1" and
"dropcap". This indicates that the picture bit map is to have left
justification and is to be treated as a drop-cap character. As
shown in FIG. 17C, the picture bitmap is inserted into the path 158
with left justification after the block of bit map data 180. If the
drop-cap command had not been specified in the attribute string,
the next block of data would be inserted at point 185 after the
picture bit map. However, it is often desirable to include pictures
within the text of a book and then have text appear to flow around
the picture. Accordingly, the drop-cap attribute definition
indicates to the merged text to treat the bit map defined in the
attribute string as a drop-cap character. When the merged task sees
this command, after inserting the picture 183 into the path 158 the
merged task adds the boundary 184 of the picture to the path 158
and then moves the insertion point of the next bit map data to the
beginning 186 of the picture bit map 183. However, because the
boundary 184 of the picture bit map 183 has been combined with the
boundary 158 of the path, the next insertion point will be at point
188 to the right of the picture bit map.
[0076] Once this step is completed, the merge task will access the
graphic states 23 associated with the next attribute string 190
from memory. The field name "rikkitxt" 164 in this next attribute
string 190 indicates to the merge task to access data again from
the merge file 152. Referring to FIG. 15C, the next point to access
data for the merge file is the block of data indicated by numeral
192, between the third and fourth field delimiters 156c, 156d. The
graphic states 23 of this next attribute string 190 will be applied
to this block of data 192 and the bit maps will thus be flowed into
the path 158 as discussed above. This block of data 192 is the
first block including a character name `Teddy` which the job ticket
directs as needing to be replaced by a variable data name from the
`names.txt` merge file as discussed above. In the present example,
the first variable name listed in the `names.txt` merge file is
"Ranen." Accordingly, merge file will replace all instances 193
within the block of data 192 where the name `Teddy` appears with
the `Ranen` bitmaps 195 in the printed document. This process will
continue until the merge task reaches the end of the mergefile 152,
indicating to the merge task that the book has been created. FIGS.
18A-18C illustrate the appearance of the pages of the book as
prepared in the example described above.
[0077] Accordingly, this invention provides capability of
identifying particular paths defined in a page description language
as data flowing paths, and provides the capability for flowing data
within such paths. In addition, the present invention allows the
user to specify margin, paragraph formatting, fill rules, and
justification parameters on a path by path basis.
[0078] Having described the invention in detail and by reference to
the drawings, it will be apparent to one of ordinary skill in the
art that variations and modifications are possible without
departing from the scope of the invention as defined on the
following claims.
[0079] The following appendix provides a compilation of text
wrapping commands and parameter definitions that can be specified
in the job ticket file 12. Each entry provides the particular
command header, the syntax for the command, any relevant remarks
for the use of the command, examples, etc. As will be apparent to
one of ordinary skill in the art, it is within the scope of this
invention to include the means to provide for any of the
attributes, or similar attributes, as defined in the Appendix.
APPENDIX
[0080] COMMAND HEADER=[Wrap] [0081] A group that provides a list of
tags which you create to describe the text flowing (wrap) path(s)
to be used in the print job. Each tag will become a user-defined
group of additional information about the wrap path. [0082] Syntax
[wrap] [0083] <Path Tag X.> [0084] <Path Tag Y> [0085]
<Path Tag Z> [0086] Remarks Optional. Each tag that appears
under this [Wrap] group will optionally become a new group name in
a succeeding section of the Job Ticket. [0087] Explanation <Path
Tax X> [0088] Create a descriptive name for a wrap path used in
the print job. [0089] Note: Fields on a template that you wish to
be flowed into a particular path will use a field attribute of the
format: [0090] <<fieldname>> wrap=<name> [0091]
The <name> argument of the wrap attribute must match a path
tag listed in the [Wrap] group. [0092] Example [Wrap] [0093] Circle
[0094] Square [0095] Triangle
[0096] COMMAND HEADER=[<Path Tag>] [0097] A user-defined tag
name for a group that provides information about the wrap path and
corresponds to the descriptive tag that you create under the
initial [Wrap] group. [0098] Syntax [<Path Tag>] [0099]
Baseline Adjust= [0100] Bottom Margin= [0101] Clobber Path= [0102]
Draw Path= [0103] Enforce paragraph Spacing= [0104] Fill Rule=
[0105] Fit Last Name= [0106] Justify= [0107] Left Margin= [0108]
Margins= [0109] Min Paragraph Lines= [0110] Number Of Paths= [0111]
Overflow= [0112] Paragraph Adjust= [0113] Reverse Flow= [0114]
Reverse Path= [0115] Right Margin= [0116] Top Margin= [0117]
Remarks A separate [<Path>] group defines path information
for each descriptive tag listed under the initial [Wrap] group.
[0118] If a [<Path Tag>] group is not defined for a path
listed under the [Wrap] group, that path will receive the default
values for all of the [<Path Tag>] elements. [0119]
Explanation [<Path Tag>] [0120] Take the descriptive tag
under the initial [Wrap] group and write it here as a group name
within the brackets [ ]. [0121] Baseline Adjust= [0122] (See the
Baseline Adjust Element Description) [0123] Bottom Margin= [0124]
(See the Bottom Margin Element Description) [0125] Clobber Path=
[0126] (See the Clobber Path Element Description) [0127] Draw Path=
[0128] (See the Draw Path Element Description) [0129] Enforce
Paragraph Spacing= [0130] (See the Enforce Paragraph Spacing
element description) [0131] Fill Rule= [0132] (See the Fill Rule
Element Description) [0133] Fit Last Line= [0134] (See the Fit Last
Line Element Description) [0135] Justify= [0136] (See the Justify
Element Description) [0137] Left Margin= [0138] (See the Left
Margin Element Description) [0139] Margins= [0140] (See the Margins
Element Description) [0141] MinParagraph Lines= [0142] (See the
Minparagraph Lines Element Description) [0143] Number Of Paths=
[0144] (See the Number of Paths Element Description) [0145]
Overflow= [0146] (See the Overflow Element Description) [0147]
Paragraph Adjust= [0148] (See the Paragraph Adjust Element
Description) [0149] Paragraph Indent= [0150] (See the Paragraph
Indent Element Description) [0151] Reverse Flow= [0152] (See the
Reverse Flow Element Description) [0153] Reverse Path= [0154] (See
the Reverse Path Element Description) [0155] Right Margin= [0156]
(See the Right Margin Element Description) [0157] Top Margin=
[0158] (See the Top Margin Element Description) [0159] Examples
[Circle] [0160] Fill Rule=EvenOddRule [0161] DrawPath=False [0162]
Overflow=Square [0163] [Square] [0164] FillRule=WindingRule [0165]
DrawPath=True [0166] Overflow=Triangle [0167] [Triangle] [0168]
FillRule=EvenOddRule [0169] DrawPath=False [0170] Overflow=Square
[0171] [Square] [0172] FillRule=WindingRule [0173] DrawPath=True
[0174] Overflow=Triangle [0175] [Triangle] [0176]
FillRule=EvenOddRule [0177] DrawPath False
[0178] PARAMETER=Baseline Adjust [0179] An element that determines
the adjustments made to each baseline of text drawn within the
path. [0180] Syntax Baseline Adjust=<BaseAdjustNum><Unit
Type> [0181] See Also Paragraph Adjust, Enforce Paragraph
Spacing. [0182] Remarks Optional. [0183] By default, the process
will space successive text lines at 120% of the font size. For
example, a 12-point font will have the next baseline set at 14.4
points (120%.times.12) from the previous baseline. The Baseline
Adjust element defines an offset from this default value. [0184] A
positive Baseline Adjust value increases the space between each
baseline of text (essentially, moving the next line of text down).
A negative value decreases the space between each baseline of text
(essentially, moving the next line of text up). [0185] The default
value for Baseline Adjust is 0. [0186] Explanation
<BaseAdjustNum> [0187] Enter the number of units. [0188]
<Unit Type> [0189] Optional. Enter the abbreviation to
identify the unit type if the unit type for Baseline Adjust is
different from the default unit type defined in the Units element.
Possible values are: [0190] cm for centimeters [0191] dots for dots
[0192] ft for feet [0193] in for inch (default value) [0194] mm for
millimeter [0195] pts for points [0196] Example BaselineAdjust=1
pt
[0197] PARAMETER=Bottom Margin [0198] An element that specifies the
distance from the bottom of the path at which to stop flowing text.
[0199] Syntax BottomMargin=<BottomMarginNum><Unit Type>
[0200] See Also Margins, Overflow. [0201] Remarks Options. [0202]
NOTE: A non-zero value for the BottomMargin element overrides (for
the bottom margin only) the value set in the Margins elements.
[0203] For example, if Margins=1 in and BottomMargin=2 in, the path
will have 1-inch margins on the top, left, and right sides but will
have a 2-inch margin on the bottom side. [0204] The default value
for Bottom Margin is 0. [0205] Explanation <BottomMarginNum>
[0206] Enter the number of units. [0207] <UnitType> [0208]
Optional. Enter the abbreviation to identify the unit type if the
unit type for Bottom Margin is different from the default unit type
defined in the Units element. Possible values are: [0209] cm for
centimeters [0210] dots for dots [0211] ft for feet [0212] in for
inch (default value) [0213] mm for millimeter [0214] pts for points
[0215] Example BottomMargin=3 mm
[0216] PARAMETER=Clobber Path [0217] An element that specifies if
two adjacent ON areas separated by a path segment are treated as
one area when determining text flow. [0218] Syntax
ClobberPath=[True/False] [0219] See Also FillRule [0220] Remarks
Optional [0221] This element affects the way in which text is
flowed in adjacent ON areas. It applies only to paths defined with
FillRule=WindingRule. [0222] If ClobberPath is set to True, text is
flowed across the two adjacent ON areas as if they were one area.
In this case, only the "outer" margins of the combined areas would
be recognized. Text flow would be continuous across the "inner"
margins where the path segment intersects the adjacent areas.
[0223] If ClobberPath is set to False, text is flowed separately
into each area. [0224] The default value of ClobberPath is True.
[0225] Explanation {True/False} [0226] If two adjacent ON areas are
to be treated as one area, type True. [0227] If two adjacent ON
areas are to be maintained separately, type False. [0228] Example
ClobberPath=False
[0229] PARAMETER=DrawPath [0230] An element that determines if the
wrap path is actually drawn on the template. [0231] Syntax
DrawPath={True/False} [0232] Remarks Optional. [0233] The default
value for DrawPath is True. [0234] Explanation {True/False} [0235]
If the wrap path is to be drawn on the template, type True. [0236]
If the wrap path is NOT to be drawn on the template, type False.
Example DrawPath=False
[0237] PARAMETER=EnforceParagraphSpacing [0238] An element that
determines if the next paragraph will always start at a distance of
the ParagraphAdjust value from any previous paragraphs that were
set. [0239] Syntax EnforceParagraphSpacing={True/False} [0240] See
Also BaselineAdjust, ParagraphAdjust. [0241] Remarks Optional.
[0242] If the text flowed into your path contains blank paragraphs,
this element determines how the blank paragraphs are to be handled.
[0243] If you want your next paragraph to start at a distance of
the ParagraphAdjust value from your previous text paragraph
(thereby, "skipping" any blank paragraphs and permitting text to
continue to flow), set the EnforceParagraphSpacing value to True.
[0244] If you want the blank paragraphs to be allotted the
appropriate space defined in ParagraphAdjust, set the
EnforceParagraphSpacing value to False. [0245] The default value
for EnforceParagraphSpacing is False. [0246] Explanation
{True/False} [0247] If the next non-blank paragraph should start at
a distance of the ParagraphAdjust value from any previous
paragraphs that were set, type True. [0248] If blank paragraphs are
to be allocated their appropriate paragraph space, type False.
[0249] Example EnforceParagraphSpacing=True
[0250] PARAMETER=FillRule [0251] An element that provides the rules
used to determine which areas of the path should have text flowed
into them and which areas should be blank. [0252] Syntax
FillRule={WindingRulelEvenOddRule} [0253] See Also ClobberPath,
ReversePath. [0254] Remarks Optional. [0255] Text is flowed into an
area enclosed by ("inside") the current path. If a path is simple,
it is clear which areas are inside the path. However, if a path is
complex (for example, intersecting itself or having one subpath
that encloses another), it is not as apparent which areas are
inside. One of two fill rules will be used to determine which areas
lie inside a path. [0256] The FillRule element defines if the
non-zero winding rule (WindingRule) or the even-odd rule
(EvenOddRule) will be used for the current path. [0257] The
non-zero winding rule determines whether a given area along the
proposed flow line is inside the path (and thus receives text) by
examining the places where a path segment crosses the flow line.
Path segments that cross (intersect) the flow line from top to
bottom are given a direction of 1. Path segments that cross
(intersect) the flow line from bottom to top are given a direction
of -1. Path segments that do not fully cross the flow line (for
example, entering and exiting the top of the flow line) are given a
direction of zero. [0258] An on-going sum of all crossings is
calculated from left to right, If the sum of all crossings to that
point is zero, the area (immediately to the right) is outside the
path. If the sum is non-zero, the area is inside the path and will
receive text. [0259] The even-odd rule determines whether a given
area long the proposed flow line is inside the path (and thus
receives text) by counting the number of times a path segment
crosses the flow line. Path segments that fully cross (intersect)
the flow line are given a score of 1. Path segments that do not
fully cross the flow line are given a score of zero. [0260] An
on-going sum of all crossings is calculated from left to right. If
the sum of all crossings to that point is even, the area
(immediately to the right) is outside the path. If the sum is odd,
the area is inside the path and will receive text. [0261] The
default value for FillRule is WindingRule. [0262] Explanation
{Winding Rule/EvenOddRule} [0263] If the winding rule will
determine which areas lie inside a path, type WindingRule. [0264]
If the even-odd rule will determine which areas lie inside a path,
type EvenOddRule. [0265] Example FillRule=EvenOddRule
[0266] PARAMETER=FitLastLine [0267] An element that determines if
the Fit justification rule is applied to the last line of every
paragraph. [0268] Syntax FitLastLine={True/False} [0269] See Also
Justify [0270] Remarks Optional. [0271] The FitLastLine element
applies only to paths defined with Justify=Fit. [0272] If
FitLastLine is set to True, the text on the last line will be
forced to fit flush on the left and the right. Since the last line
of a paragraph may often contain less text than the other lines in
a paragraph, this justification will often result in more white
space between text on the last line. [0273] The default value for
FitLastLine is False. [0274] Explanation {True/False} [0275] If the
last line of every paragraph should be aligned at both the left
side and the right side of the path, type True. [0276] If the last
line of every paragraph should not be forced to fit flush left and
flush right, type False. [0277] Example FitLastLine=False
[0278] PARAMETER=Justify [0279] An element that specifies the type
of justification (horizontal alignment) to be applied to each line
of text drawn in the path. [0280] Syntax
Justify=<JustifyRule> [0281] See Also FitLastLine [0282]
Remarks Optional. [0283] The default value for Justify is Left.
[0284] Explanation <JustifyRule> [0285] Enter the type of
justification (horizontal alignment) to be applied to each line of
text drawn in the path. Possible values are: [0286] Left (Default
value) Text is aligned from the left side of the path. [0287] Right
Text is aligned from the right side of the path. [0288] Center Text
is centered between the left side and right side of the path.
[0289] Fit Text is aligned at both the left side and right side of
the path. [0290] Example Justify=Center
[0291] PARAMETER=LeftMargin [0292] An element that specifies the
distance from the left side of the path at which to start flowing
text. [0293] Syntax
LeftMargin=<LeftMarginNum><UnitType> [0294] See Also
Margins [0295] Remarks Optional. [0296] NOTE: A non-zero value for
the LeftMargin element overrides (for the left margin only) the
value set in the Margins elements. [0297] For example, if Margins=1
in and LeftMargin=2 in, the path will have 1-inch margins on the
bottom, top, and right sides but will have a 2-inch margin on the
left side. [0298] A default value for LeftMargin is 0. [0299]
Explanation <LeftMarginNum> [0300] Enter the number of units.
[0301] <UnitType> [0302] Optional. Enter the abbreviation to
identify the unit type if the unit type for LeftMargin is different
from the default unit type defined in the Units element. Possible
values are: [0303] cm for centimeters [0304] dots for dots [0305]
ft for feet [0306] in for inch (default value) [0307] mm for
millimeter [0308] pts for points [0309] Example LeftMargin=5 mm
[0310] PARAMETER=Margins [0311] An element that specifies the same
text margins for all four sides of the path (top, bottom, left, and
right). [0312] Syntax Margins=<MarginsNum><Unit Type>
[0313] See Also BottomMargin, LeftMargin, Right Margin, TopMargin
[0314] Remarks Optional. [0315] Note: The value for the Margins
element will be overridden on an individual margin basis by any
non-zero value defined for the other specific margin attributes
(BottomMargin, LeftMargin, RightMargin, and TopMargin). [0316] For
example, if Margins=1 in and TopMargin=2 in, the path will have
1-inch margins on the bottom, left, and right sides but will have a
2-inch margin on the top. [0317] The default value for Margins is
0. [0318] Explanation <MarginsNum> [0319] Enter the number of
units. [0320] <UnitType> [0321] Optional. Enter the
abbreviation to identify the unit type if the unit type for Margins
is different from the default unit type defined in the Units
element. Possible values are: [0322] cm for centimeters [0323] dots
for dots [0324] ft for feet [0325] in for inch (default value)
[0326] mm for millimeter [0327] pts for points [0328] Example
Margins=6 mm
[0329] PARAMETER=MinParagraphLines [0330] An element that specifies
the minimum number of lines of a paragraph to be set before the
paragraph is allowed to be split between path areas. [0331] Syntax
MinParagraphLines=<MinLinesNum> [0332] See Also
NumberOfPaths, Overflow. [0333] Remarks Optional. [0334] If the
minimum number of lines of a paragraph defined here cannot be set
consecutively in a path area, the entire paragraph will be moved
down to the next scanline that allows the specified number of lines
to be set consecutively. [0335] The default value for
MinParagraphLines is 1. [0336] Explanation <MinLinesNum>
[0337] Enter the integer representing the minimum number of lines
of a paragraph to be set before splitting between path areas is
permitted. [0338] Example MinParagraphLines=2
[0339] PARAMETER=NumberOfPaths [0340] An element that determines
how many postscript paths on the template are concatenated and
treated as one path. [0341] Syntax NumberOfPaths=<PathsNum>
[0342] See Also MinParagraphLines, Overflow. [0343] Remarks
Optional. [0344] This element is used to combine multiple paths
drawn on the template and to treat them as a single path. The path
to be combined will be determined by the order in which they were
drawn. [0345] The default value for NumberOfPaths is 1. [0346]
Explanation <PathsNum> [0347] Enter the integer representing
the number of paths to be combined. [0348] Example NumberOfPaths=2
[0349] Illustration See FIG. 12 and corresponding description
above
[0350] PARAMETER=Overflow [0351] An element that specifies the name
(tag) of the wrap path that will receive overflow text from the
current wrap path being described. [0352] Syntax
Overflow=<PathTag> [0353] See Also MinParagraph Lines,
NumberOfPaths. [0354] Remarks Optional. [0355] This element defines
the use of an overflow feature. When overflow is available, if the
current path has no more space into which text can flow, the text
will continue to flow into the path named in this element. [0356]
NOTE: If the Overflow element references a wrap path that is not
named under the [Wrap] group, the print job will be aborted. [0357]
If the Overflow element is not defined, the system will assume that
no overflow will occur for the current path being described.
Therefore, text will flow into the current path until it is filled.
No overflow text will be printed. [0358] Explanation
<PathTag> [0359] Enter the descriptive tag of the path into
which overflow text from the current path will flow. This value
should correspond to a descriptive tag that you created under the
initial [Wrap] group. [0360] Example Overflow=Square [0361]
Illustration See FIG. 13 and the corresponding description
above.
[0362] PARAMETER=ParagraphAdjust [0363] An element that determines
the distance to adjust the baseline for the start of the next
paragraph within the path. [0364] Syntax
ParagraphAdjust=<ParagraphadjustNum><Unit Types> [0365]
See Also BaselineAdjust, Enforce Paragraph Spacing. [0366] Remarks
Optional. [0367] The ParagraphAdjust value overrides the Baseline
Adjust value only for the first baseline of text in each paragraph.
[0368] A position ParagraphAdjust value increases the vertical
space between the last baseline of text in each paragraph and the
start of the next paragraph (essentially, moving the start of the
next paragraph down). A negative value decreases the vertical space
between the last baseline of text in each paragraph and the start
of the next paragraph (essentially, moving the start of the next
paragraph up). [0369] The default value for ParagraphAdjust is 0.
[0370] Explanation <ParagraphadjustNum> Enter the number of
units. [0371] <UnitType> [0372] Optional. Enter the
abbreviation to identify the unit type if the unit type for
ParagraphAdjust is different from the default unit type defined in
the Units element. Possible values are: [0373] cm for centimeters
[0374] dots for dots [0375] ft for feet [0376] in for inch (default
value) [0377] mm for millimeter [0378] pts for points [0379]
Example ParagraphAdjust=6 pts
[0380] PARAMETER=Paragraphlndent [0381] An element that specifies
the indentation from the left margin for the first line of every
paragraph in the path. [0382] Syntax
Paragraphlndent=<ParagraphlndentNum><UnitType> [0383]
See Also ParagraphAdjust [0384] Remarks Optional. [0385] The
default value for Paragraphlndent is 0. [0386] Explanation
<ParagraphlndentNum> [0387] Enter the number of units. [0388]
<UnitType> [0389] Optional. Enter the abbreviation to
identify the unit type if the unit type for Paragraphlndent is
different from the default unit type defined in the Units element.
Possible values are: [0390] cm for centimeters [0391] dots for dots
[0392] ft for feet [0393] in for inch (default value) [0394] mm for
millimeter [0395] pts for points [0396] Example Paragraphlndent=0.5
in
[0397] PARAMETER=ReverseFlow [0398] An element that determines if
the text will be flowed from bottom to top in the current path.
[0399] Syntax ReverseFlow={True/False} [0400] See Also FillRule
[0401] Remarks Optional. [0402] The default value for ReverseFlow
is False. [0403] Explanation {True/False} [0404] If the text will
be flowed from bottom to top, type True. [0405] If the text will be
flowed from top to bottom, type False. [0406] Example
ReverseFlow=True
[0407] PARAMETER=ReversePath [0408] An element that determines if
the ON/OFF designations for areas in the path will be reversed.
[0409] Syntax ReversePath=[True/False] [0410] See Also FillRule
[0411] Remarks Optional. [0412] The ReversePath element applies
only to paths defined with FillRule=EvenOddRule. [0413] If
ReversePath is set for True, the areas originally marked as ON
based on the EvenOddRule calculation will be set to OFF and the
areas originally marked as OFF based on the EvenOddRule calculation
will be set to ON. [0414] If ReversePath is set to False, the
EvenOddRule calculations will be retained. [0415] The default value
for ReversePath is False. [0416] Explanation {True/False) [0417] If
the ON/OFF designations for areas in the path will be reversed,
type True. [0418] If the ON/OFF designations for areas in the path
will be retained, type False. [0419] Example ReversePath=True
[0420] PARAMETER=RightMargin [0421] An element that specifies the
distance from the side of the path at which to stop flowing text.
[0422] Syntax RightMargin=<RightMarginNum><UnitType>
[0423] See Also Margins [0424] Remarks Optional. [0425] NOTE: A
non-zero value for the RightMargin element overrides (for the right
margin only) the value set in the Margins element. For example, if
Margins=1 in and RightMargin=2 in, the path will have 1-inch
margins on the bottom, top, and left sides but will have a 2-inch
margin on the right side. [0426] The default value for RightMargin
is 0. [0427] Explanation <RightMarginNum> [0428] Enter the
number of units. [0429] <UnitType> [0430] Optional. Enter the
abbreviation to identify the unit type if the unit type for
RightMargin is different from the default unit type defined in the
Units element. Possible values are: [0431] cm for centimeters
[0432] dots for dots [0433] ft for feet [0434] in for inch (default
value) [0435] mm for millimeter [0436] pts for points [0437]
Example RightMargin=5 mm
[0438] PARAMETER=TopMargin [0439] An element that specifies the
distance from the top of the path at which to start flowing text.
[0440] Syntax TopMargin=<TopMarginNum><UnitType> [0441]
See Also Margins [0442] Remarks Optional. [0443] NOTE: A non-zero
value for the TopMargin element overrides (for the top margin only)
the value set in the Margins element. [0444] For example, if
Margins=1 in and TopMargin=2 in, the path will have 1-inch margins
on the bottom, left, and right sides but will have a 2-inch margin
on the top side. [0445] The default value for TopMargin is 0.
[0446] Explanation <TopMarginNum> [0447] Enter the number of
units. [0448] <UnitType> [0449] Optional. Enter the
abbreviation to identify the unit type if the unit type for
TopMargin is different from the default unit type defined in the
Units element. Possible values are: [0450] cm for centimeters
[0451] dots for dots [0452] ft for feet [0453] in for inch (default
value) [0454] mm for millimeter [0455] pts for points [0456]
Example TopMargin=0.25 in
[0457] The principle and mode of operation of this invention have
been explained and illustrated in its preferred embodiment.
However, it must be understood that this invention may be practiced
otherwise than as specifically explained and illustrated without
departing from its spirit or scope.
* * * * *