JP4480160B2 - Printing apparatus, printing apparatus control method, printing apparatus control program, storage medium, and Web server - Google Patents

Description

  The present invention relates to a rendering and color matching technique in a printing apparatus, and more particularly to a rendering and color matching technique for each rendering command of a PDL document or the like.

  Conventionally, when a color specified in each rendering command of a page description language (PDL) document is output to a monitor or printer, the device gamut (gamut) is used by using the profile of the output destination device. ) Are compressed and converted before being output. This method is described in Patent Document 1, for example.

  Further, Patent Document 2 describes a method for converting an object having different attributes (such as a color space) into an optimal image data structure and switching color matching processing to be applied in real time.

Japanese Patent Laid-Open No. 7-107312 JP-A-8-235346

  When opacity (alpha value) is included in the color specification of the PDL document, alpha blend processing is required when those colors overlap each other. At this time, the rendering result varies depending on whether the device is compressed into the device color gamut before the alpha blend processing or the device is compressed into the device color gamut and then the alpha blend processing is performed. However, the timing at which compression should be performed cannot be uniquely determined, and is affected by the designated color and alpha value, output device, profile used during color compression, rendering intent, and the like.

The present invention has been made in view of the above circumstances, and it is an object of the present invention to perform color matching more appropriately when alpha blend rendering is required when rendering instructions such as PDL documents are rendered. To do.
It is another object of the present invention to enable the color matching to be performed efficiently.

In order to solve the above-described problems, a printing apparatus according to the present invention includes a rendering unit that renders a description language document, color information specified in the description language document, and a color for a printing device that prints the description language document. A color matching means for converting by compressing into information, and if alpha blend rendering is required in the description language document, it is determined whether the conversion by the color matching means is performed before or after the rendering, Selecting means for selecting one according to the determination result.

  In the printing apparatus, the selection by the selection unit is performed by verifying a result when the conversion by the color matching unit is performed before the rendering and after the rendering, and the selection is performed. And

  In addition, the printing apparatus includes a holding unit that holds conditions used in the selection by the selection unit and a selection result, and a utilization unit that uses the information held by the holding unit in the next and subsequent alpha blend renderings. And further comprising.

The present invention also relates to a method for controlling a printing apparatus, wherein a rendering step for rendering a description language document, color information specified in the description language document, and color information for a printing device for printing the description language document are provided. A color matching step for converting by compressing the image, and when alpha blend rendering is required in the description language document, it is determined whether the conversion by the color matching step is performed before the rendering or after the rendering, and the determination And a selection step of selecting one according to the result.

  In the printing apparatus, the selection in the selection step is performed by verifying a result obtained when the conversion in the color matching step is performed before the rendering and after the rendering. And

  Further, the control method of the printing apparatus uses the holding step for holding the conditions and selection results used for the selection by the selection means, and the information held by the holding means at the next and subsequent alpha blend renderings. And a use step.

Further, the present invention is a control program for a printing apparatus, wherein a rendering step for rendering a description language document, color information specified in the description language document, color information for a printing device for printing the description language document A color matching step for converting by compressing the image, and when alpha blend rendering is required in the description language document, it is determined whether the conversion by the color matching step is performed before the rendering or after the rendering, and the determination And a selection step of selecting one according to the result.

  Further, the control program of the printing apparatus verifies the result when the selection in the selection step is performed by performing the conversion in the color matching step before and after the rendering, and makes the selection. It is characterized by that.

  Further, the control program of the printing apparatus uses the holding step for holding the conditions used in the selection in the selection step and the selection result, and the information held by the holding unit at the next and subsequent alpha blend renderings. And a use step.

  The control program for the printing apparatus can be stored in a computer-readable storage medium or a Web server.

According to the present invention, color matching can be performed more appropriately when alpha blend rendering is required in a description language document.
Furthermore, since the stored information can be used in the second and subsequent selections, it is efficient.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.
[Overview of this embodiment]
In this embodiment, SVG 1.1 is used as PDL. The specification of SVG 1.1 is shown in SVG 1.1 Specification (http://www.w3.org/TR/SVG11/). In the user PC (client), an interpreter converts an SVG (Scalable Vector Graphic) document file into intermediate code data. Subsequently, the renderer converts the intermediate code data into bitmap data. At this time, the accuracy of color matching before rendering and color matching after rendering is measured, and the higher accuracy is selected. This selection result is saved so that it can be used not only in this rendering session but also in subsequent renderings. The printer performs output using the bitmap data and obtains a print result.

[overall structure]
First, the overall configuration of the present embodiment will be described with reference to FIG.

  A client PC 101 is operated by a user, and is connected to the network 103 via a network interface. A printer 102 accepts a print instruction via a network, and is connected to the network 103 via a network interface. The PC 101 can transmit a print instruction to the printer 102 via the network 103.

[Configuration of computer device and printer]
Next, with reference to FIG. 2 and FIG. 3, the configuration of the computer device and the printer used in this embodiment will be described.

  FIG. 2 is a block diagram illustrating an example of the configuration of the client 101. A CPU 201 controls the entire apparatus according to a control program stored in the RAM 202. Reference numeral 202 denotes an internal storage unit such as a RAM that stores control programs of the apparatus executed by the CPU 201 and data such as document images. Reference numeral 203 denotes a network interface that transmits and receives data and the like by connecting to a network under the control of the CPU 201. Reference numeral 204 denotes an external storage device such as a magnetic disk for storing data. Reference numeral 205 denotes a display, 206 denotes a keyboard, and 207 denotes a pointing device such as a mouse. The program stored in the RAM 202 uses the function of an OS (Operating System) also stored in the RAM 202 as necessary, reads / writes the contents of data temporarily stored in the RAM 202, and stores the data on the external storage device 204. A predetermined operation is performed by reading and writing data, transmitting and receiving data through a network interface, receiving input from the keyboard 206 and the pointing device 207, and displaying on the display 205.

  FIG. 3 is a block diagram illustrating an example of the configuration of the printer 102. Reference numerals 208, 209, 210, and 211 denote a CPU, a RAM, a network interface, and an external storage device as shown by 201, 202, 203, and 204 in FIG. A printer engine 212 performs printing. A program stored in the RAM 209 performs printing by controlling the printer engine 212 in accordance with a print instruction received through the network interface 210. At that time, the contents of data temporarily stored in the RAM 209 can be read and written, and data can be read and written on the external storage device 211.

[Overall block diagram]
Next, with reference to FIG. 4, a block configuration in the computer apparatus used in the present embodiment will be described.

  FIG. 4 shows logical blocks mainly related to the operation of this embodiment in the client 101, printer 102, and network 103 that physically have the configuration shown in FIG. 1, that is, program modules, file entities, memory data, and communication paths. It is a block diagram which shows a structure.

  Reference numeral 301 denotes a block boundary of the client 101, and here indicates an environment under the control of the OS. The interpreter 309, the renderer 310, and the CMM (Color Management Module) 311 are normally stored in the external storage device 204. However, when the execution is instructed by the user, the OS, or another program, the RAM 202 is controlled by the OS. It will be read and ready to run. Reference numeral 302 denotes an SVG document file stored in the external storage device 204. A program including the interpreter 309 can read and write the contents of the SVG document file 302 by using the function of the OS.

  Reference numeral 303 denotes intermediate code data stored in the RAM 202, and a program including the interpreter 309 and the renderer 310 can similarly read and write the contents of the intermediate code data 303 using the functions of the OS. Reference numeral 304 denotes bitmap data stored in the RAM 202, and a program including the renderer 310 can read and write the contents of the bitmap data 304 by using the function of the OS.

  The interpreter 309 performs conversion from the SVG document file 302 to the intermediate code data 303. This conversion operation can be mechanically determined from the specifications of both languages. Therefore, in this embodiment, the operation of the interpreter 309 is not described in detail, and only the conversion content is presented. The renderer creates bitmap data 304 from the intermediate code data 303 and transmits it to the controller 314 of the printer 313 via the network 103. At this time, the function of the CMM 311 is used for color matching.

  In order to perform necessary color matching, the CMM 311 performs an input profile 305 representing the input color space of the SVG document file 302 and intermediate code data 303, a rendering profile 306 representing the rendering color space of the renderer 310, and a printer representing the device color space of the printer 313. A profile 307 and a rendering intent 308 that specifies a matching method at the time of color matching are used as inputs.

  Since the CMM is usually provided as a part of the OS or a library that can be used by the OS and only uses its function from the program, the operation of the CMM 311 is not described in detail in this embodiment, and its function and usage example. Only shown. Reference numeral 312 denotes a verification result DB configured by a database program (not shown) on the external storage device 204. The program including the renderer 310 can read and write the contents of the verification result DB 312 using the function of a database driver (not shown).

  Reference numeral 313 denotes a block boundary of the printer 102. The controller 314 is a program that is stored in the RAM 209 and is always executable. When the controller 314 receives the bitmap data 304 from the renderer 310 through the network interface 210, the controller 314 stores the bitmap data 304 in the RAM 209 as bitmap data 315, and controls the printer engine 212 according to the information to perform printing.

[SVG document file]
Next, the SVG document file used in this embodiment will be described with reference to FIGS.
FIG. 5 is a diagram showing the contents of the SVG document file 302 used in this embodiment.

The first line is an XML declaration, which indicates that this SVG document file is described according to the XML 1.0 specification.
The second and third lines are document type declarations (Document Type Definitions), which refer to the SVG 1.1 document type definition (Document Type Definition; DTD) as an external subset.

  The 4th to 5th lines are start tags of <svg> elements as root elements. <Svg> The element width and height are 21.0 cm and 29.7 cm (A4 size), respectively, (0, 0)-(210, 297) is specified as the user coordinate system, the SVG namespace, A compliant SVG version number is specified.

The sixth line is a <desc> element, which describes the description of this SVG document file. The content of the <desc> element is not used to render the SVG document.
The seventh, tenth and thirteenth lines are comment elements. The content of the comment element is also not used for rendering the SVG document.

  The eighth to ninth lines are <circle> elements for rendering the first circle. The value of the center coordinate specifies (80, 80) in the user coordinate system, and the value of the radius specifies 50 in the user coordinate system. The fill color inside the circle is “yellow” (yellow), the opacity (alpha value) is 0.7, the circle outline color is “blue” (blue), and the outline width is 2 in the user coordinate system. It is specified.

  The 11th to 12th lines are <circle> elements for rendering the second circle. The center coordinate value specifies (140, 80) in the user coordinate system, and the radius value specifies 50 in the user coordinate system. The fill color inside the circle is “red” (red), the opacity (alpha value) is 0.5, the circle outline color is “blue” (blue), and the outline width is 2 in the user coordinate system. It is specified.

The 14th to 15th lines are <circle> elements for rendering the third circle. The center coordinate value specifies (110, 130) in the user coordinate system, and the radius value specifies 50 in the user coordinate system. The fill color inside the circle is “green”, the opacity (alpha value) is 0.3, the circle outline color is “blue” (blue), and the outline width is 2 in the user coordinate system. It is specified.
The 16th line is the end tag of the <svg> element as the root element, and corresponds to the start tag of the 4th to 5th lines.

  An example of rendering the SVG document file shown in FIG. 5 is shown in FIG. 501 is the first circle corresponding to the <circle> of the 8th to 9th lines, 502 is the second circle corresponding to the <circle> element of the 11th to 12th lines, and 503 is the 14th to 15th lines. A third circle corresponding to the <circle> element. Reference numeral 504 denotes a circumscribed rectangle of the entire SVG document. The size of the circumscribed rectangle 504 is 21.0 cm in width and 29.7 cm in height. The vertical and horizontal broken lines, the circles at the broken line intersections, and the coordinate value display near the broken line intersections are for illustrating the coordinate values of the coordinates serving as the points, and are not included in the actual rendering.

[Intermediate code]
Next, an intermediate code used in the present embodiment will be described with reference to FIGS.
FIG. 7 is a diagram showing the specifications of the intermediate code used in the present embodiment.

Reference numeral 601 denotes an operation code representing a rendering command, which is designated by a number. In this embodiment, nine types of opcodes are defined. The operation code is stored in the intermediate code data 303 as a 1-byte integer.
Reference numeral 602 denotes a mnemonic for facilitating human identification of the operation code. The mnemonic is used only when the contents of the intermediate code are dumped and shown, and is not included in the intermediate code data 303.
Reference numeral 603 denotes an operand representing an argument for the operation code. The number of operands and their meaning depend on the opcode. The operand is stored in the intermediate code data 303 as a 2-byte floating point number.

  In the intermediate code used in this embodiment, only mm is used as the unit system. When coordinates and length are specified in the operand, all values converted to mm are specified. Coordinate values are expressed as absolute values with the origin at the top left of the page. When a color is specified in the operand, it is expressed in RGB (red / green / blue) or RGBA (red / green / blue / alpha value), and R (red), G (green), B (blue), A (alpha value) ) Is specified in the range of 0.0 to 1.0. In the color designation by RGB, the alpha value is handled as 1.0.

Opcode 0 (mnemonic PageStart) represents the start of the page. The operands are a page width W (mm) and a page height H (mm).
Opcode 1 (mnemonic PageEnd) represents the end of the page. There is no operand.
Opcode 2 (Mnemonic Fill) is a designation of a fill color. The fill specified by Fill is applied to all subsequent rendering instructions. The operand is the fill color RGBA.

The operation code 3 (mnemonic Stroke) is an outline specification. The outline specified by Stroke is applied to all subsequent rendering instructions. The operands are the outline color RGB and the outline width W (mm). In the present embodiment, the color of the outline is implicitly set to an alpha value of 1.0.
Opcode 4 (mnemonic PathStart) represents the start of the pass. There is no operand.

  Opcode 5 (mnemonic PathEnd) represents the end of the pass. The operand is a close flag F. When “1” is designated, it represents that the path is closed by rendering a straight line from the end position to the start position of the path. If “0” is specified, nothing is done.

  Opcode 6 (mnemonic PathMoveTo) represents the movement of the rendering position of the pass. Valid only between the PathStart and PathEnd instructions. PathMoveTo only moves the rendering position and does not perform actual rendering. The operand designates the movement position coordinate with values of X (horizontal direction) (mm) and Y (vertical direction) (mm).

  Opcode 7 (mnemonic PathLineTo) renders a straight line from the current position of the path to the position specified by the operand. Valid only between the PathStart and PathEnd instructions. The operand specifies the end coordinates of the straight line with values of X (horizontal direction) (mm) and Y (vertical direction) (mm).

  Opcode 8 (mnemonic PathArc) renders an arc from the current position of the path. Valid only between the PathStart and PathEnd instructions. PathArc always renders arcs in the clockwise direction. The operands are X (horizontal direction) (mm) and Y (vertical direction) (mm) values of the arc center coordinates, and the length of the arc (specified by angle D (°)).

  FIG. 8 is a diagram showing the contents of the intermediate code data 303 obtained by converting the SVG document file 302 having the contents shown in FIG. 5 by the interpreter 309. The intermediate code data 303 is binary data in which only a 1-byte integer opcode and a 2-byte floating-point number operand are stored. FIG. 8 shows a mnemonic that is dumped for easy identification by humans. Is also added.

  The first line is a page start instruction, and the page width and height are specified as 210.0 mm and 297.0 mm by an operand. This corresponds to the start tag of the <svg> element in FIG. 5, and the length designation is converted from cm to mm.

  The second line is a fill command used for subsequent rendering. The operand fill color is yellow and alpha value 0.7, that is, (R, G, B, A) = (1.0, 1.0, 0. 0, 0.7). This corresponds to the fill and fill-opacity attributes of the first <circle> element in FIG. 5, and is converted into RGBA notation from color designation in character string notation and opacity in numerical notation.

  The third line is an outline command used for the subsequent rendering, and the color of the outline is designated as blue in the operand, that is, (R, G, B) = (0.0, 0.0, 1.0). The line width is specified as 2.0 mm. This corresponds to the stroke attribute and the stroke-width attribute of the three <cycle> elements in FIG. 5, and the color designation in the character string notation is converted into RGB notation, and the length designation is converted into mm from the user coordinate system.

  The fourth to seventh lines are a group of instructions for rendering a circle. An angle of 360.0 degrees, centered on the coordinates (80.0 mm, 80.0 mm) and starting from the coordinates (80.0 mm, 30.0 mm) by the rendering position movement command on the fifth line and the arc rendering command on the sixth line Will be rendered. The inside of the circle is filled with yellow / alpha value 0.7 by the command of the second line, and the outline is rendered in blue and the line width of 2 mm by the command of the third line. This corresponds to the first <circle> element in FIG. 5 and the rendering result 501 in FIG. 6, and the coordinate designation and length designation are converted from the user coordinate system to mm.

  The 8th line is a fill command used for the subsequent fill, and the color of the fill in the operand is set to red / alpha value 0.5, that is, (R, G, B, A) = (1.0, 0.0, 0. 0, 0.5). This corresponds to the fill and fill-opacity attributes of the second <circle> element in FIG. 5, and is converted into RGBA notation from color designation in character string notation and opacity in numerical notation.

  Lines 9 to 12 are a group of instructions for rendering a circle. An angle of 360.0 degrees centered on the coordinates (140.0 mm, 80.0 mm) and starting from the coordinates (140.0 mm, 30.0 mm) by the rendering position movement command on the 10th line and the arc rendering command on the 11th line Will be rendered. The inside of the circle is filled with a red / alpha value of 0.5 by the command of the eighth line, and the outline is rendered in blue and the line width of 2 mm by the command of the third line. This corresponds to the second <circle> element in FIG. 5 and the rendering result 502 in FIG. 6, and the coordinate designation and length designation are converted from the user coordinate system to mm.

  The 13th line is a fill instruction used for the subsequent fill, and the color of the fill in the operand is set to green / alpha value 0.3, that is, (R, G, B, A) = (0.0, 1.0, 0. 0, 0.3). This corresponds to the fill and fill-opacity attributes of the third <circle> element in FIG. 5, and is converted into RGBA notation from color designation in character string notation and opacity in numerical notation.

  Lines 14 to 17 are a group of instructions for rendering a circle. An angle of 360.0 degrees, centered on the coordinates (110.0 mm, 130.0 mm) and starting from the coordinates (110.0 mm, 80.0 mm), by the rendering position movement command on the 15th line and the arc rendering command on the 16th line Will be rendered. The inside of the circle is filled with a green / alpha value of 0.3 by an instruction on the 13th line, and the outline is rendered in blue and a line width of 2 mm by an instruction on the 3rd line. This corresponds to the third <circle> element in FIG. 5 and the rendering result 503 in FIG. 6, and the coordinate designation and length designation are converted from the user coordinate system to mm.

[Renderer operation overview]
Next, an outline of the operation of the renderer 310 will be described with reference to FIGS.

  FIGS. 9 to 10 are flowcharts showing an operation in which the renderer 310 renders the intermediate code data 303 to generate the bitmap data 304 and transmits it to the controller 314 of the printer 313.

Step S801 is the start of operation.
Step S802 is variable initialization processing. The intermediate code data 303 obtained by converting the SVG document file 302 is read into the variable dlc. “fill” is a variable for holding a color used for painting applied to the rendering command, and (r, g, b, a) represents each element of the color in RGBA notation. The initial value is (1.0, 1.0, 1.0, 1.0), that is, white that is completely opaque (alpha value 1.0). Stroke is a variable that holds the color and line width used for the outline applied to the rendering command, and (r, g, b, w) represents each element of RGA color and the line width (pixel). The initial value is (0.0, 0.0, 0.0, 1), that is, black and line width of 1 pixel.

Step S803 is processing for obtaining the next opcode and operand from the intermediate code data dlc. The obtained opcode and operand are stored in variables op and operand, respectively.
In steps S804, S806, S809, S811, S813, S816, S821, S823, and S825, the type of the opcode op is determined, and appropriate processing can be performed according to each opcode.

  If the operation code op is 0 (mnemonic PageStart) in step S804, the process proceeds to step S805. Otherwise, the process proceeds to step S806.

  Step S805 is a process for preparing the variable bmp for storing the bitmap data 304. Here, the element w of bmp represents the width (pixel) of the bitmap data. In order to convert the page width W (mm) of the operand “operand” into the unit system (pixel) of the bitmap, the output resolution “res” is multiplied. The element h of bmp represents the height (pixel) of the bitmap data. In order to convert the page height H (mm) of the operand operand into the unit system (pixel) of the bitmap, the output resolution res is multiplied. An element res of bmp represents the output resolution of the printer 313 in PPM (Pixels Per Millimeter).

  The element data [] of bmp is an array for storing bitmap data, and the size is horizontal w (pixel) and vertical h (pixel). Each element (r, g, b, a) of data [] represents the color of each pixel in RGBA notation. The value of each element of data [] is initialized with the current fill value, i.e. white with full opacity (alpha value 1.0). The element pre_or_post [] of bmp is an array that stores whether pre-rendering color matching or post-rendering color matching has been performed for each pixel of the bitmap, and has the same size as the array data []. When color matching before rendering is performed, pre is held as a value, and when color matching after rendering is performed, post is held as a value. The initial value is post. When the process is finished, the process returns to step S803.

  If the opcode op is 1 (mnemonic PageEnd) in step S806, the printer output defined process is called in step S807, and the process ends in step S808. Otherwise, the process proceeds to step S809. The printer output predefined processing will be described later with reference to FIG.

  If the op code op is 2 (mnemonic Fill) in step S809, the process proceeds to step S810. In cases other than that described here, process flow proceeds to Step S811.

  Step S810 is a variable fill update process. The color (R, G, B, A) designated by the operand operand is stored in each element (r, g, b, a) of the variable fill. When the process is finished, the process returns to step S803.

  If the opcode op is 3 (mnemonic Stroke) in step S811, the process proceeds to step S812. In cases other than that described here, process flow proceeds to Step S813.

  Step S812 is a process for updating the variable stroke. The color (R, G, B) and line width (W) specified by the operand operand are stored in each element (r, g, b, w) of the variable stroke. At this time, in order to convert the unit system (mm) of the operand into the unit system (pixel) of the bitmap, the output resolution bmp. Multiply res. When the process is finished, the process returns to step S803.

  If the operation code op is 4 (mnemonic PathStart) in step S813, the process proceeds to step S814. Otherwise, the process proceeds from step S815 to step S816.

  Step S814 is a process for preparing the path rendering variable path [] and the cursor. path [] is an array for storing the coordinate value of the path. Each element (x, y) of path [] is a coordinate value expressed in units of pixels. The cursor is a variable for storing the current rendering position of the path, and the element (x, y) is also a coordinate value expressed in pixels. When the process is finished, the process returns to step S803.

  If the operation code op is 5 (mnemonic PathEnd) in step S816, the process proceeds to step S817. In cases other than that described here, process flow proceeds to Step S821.

  Step S817 is processing for determining whether or not the operand operand is 1. If it is 1, the process proceeds to step S818. Otherwise, the process proceeds to step S819.

  Step S818 is a closed-pass rendering process. The operation code 7 (mnemonic PathLineTo) is inserted at the current reading position of the variable dlc. The operand is path [0] which is the start position of the current pass, but in order to convert from the bitmap unit system (pixel) to the operand unit system (mm), the output resolution bmp. Divide by res. In addition, an operation code 5 (mnemonic PathEnd) is also inserted in order to perform the pass termination process again. This time, since the closed-pass rendering process is not necessary, the operand is set to 0. When the process is completed, the process returns from step S827 to step S803.

  Step S819 is processing for determining whether or not the path needs to be painted. The value of the variable “cursor” representing the current rendering position of the pass is compared with the value of the variable “path [0]” that is the start position of the pass. If they are equal, it is determined that painting is necessary because it is a closed pass, and the process proceeds to step S820. . Otherwise, the process returns from step S827 to step S803.

  Step S820 is a process of calling a predefined process for filling a path. The predefined processing for filling the path will be described later with reference to FIG.

  If the operation code op is 6 (mnemonic PathMoveTo) in step S821, the process proceeds to step S822. In cases other than that described here, process flow proceeds to Step S823.

  Step S822 is a process for updating a variable representing the current rendering position of the path. The coordinate value (X, Y) designated by the operand operand is stored in each element (x, y) of the variable cursor. At this time, in order to convert the unit system (mm) of the operand into the unit system (pixel) of the bitmap, the output resolution bmp. Multiply res. When the process is completed, the process returns from step S827 to step S803.

  If the operation code op is 7 (mnemonic PathLineTo) in step S823, the process proceeds to step S824. Otherwise, the process proceeds to step S825.

  Step S824 is processing for rendering a straight line in the bitmap data bmp. The starting point is cursor (x, y), which is the current rendering position of the path. The end point is the coordinate value (X, Y) specified by the operand operand. In order to convert the unit system (mm) of the operand to the unit system (pixel) of the bitmap, the output resolution bmp. Multiply res. The outline uses the color (RGB) and line width (pixel) of the variable stroke. Each coordinate value (pixel) of the rendered straight line is added to the variable path [], and the last added coordinate value (straight line end point) is stored in the variable cursor. When the process is completed, the process returns from step S827 to step S803.

  If the operation code op is 8 (mnemonic PathArcTo) in step S825, the process proceeds to step S826. In other cases, the intermediate code specification shown in FIG. 7 does not exist, so the process is skipped and the process returns from step S827 to step S803.

  Step S826 is processing for rendering an arc on the bitmap data bmp. The starting point is cursor (x, y), which is the current rendering position of the path. The center point is the coordinate value (X, Y) specified by the operand operand, but in order to convert the unit system (mm) of the operand into the unit system (pixel) of the bitmap, the output resolution bmp. Multiply res. The angle is an angle D (°) specified by the operand operand. The outline uses the color (RGB) and line width (pixel) of the variable stroke. Each coordinate value (pixel) of the rendered arc is added to the variable path [], and the last added coordinate value is stored in the variable cursor. When the process is completed, the process returns from step S827 to step S803.

  An example of the operation of the renderer 310 will be described later with reference to FIGS. 8, 15, and 16.

[Fill Path]
Next, the path filling operation will be described with reference to FIG.
FIG. 11 is a flowchart showing the operation of a predefined process for filling a path. This defined process is called from step S820 of the flowchart shown in FIG.

  Step S901 is the start of a path painting operation. “bmp”, “path”, and “fill” are arguments at the time of calling this predefined process. The argument bmp has the same value as the variable bmp initialized in step S805 and updated in steps S820, S824, and S826 in FIGS. The argument path has the same value as the variable path initialized in step S814 and updated in steps S824 and S825 in FIGS. The argument fill has the same value as the variable fill initialized in step S802 and updated in step S810 in FIGS.

  Step S902 is variable initialization processing. coord is bitmap data bmp. Variables that hold coordinate values when data [] is scanned from the upper left to the lower right, and (x, y) represents the coordinate values in pixel units. The initial value is (0, 0), and bitmap data bmp. Represents the upper left of data. The flowchart shown in FIG. 11 is a loop process using the variable “coord” as a loop variable.

  Step S903 is processing to determine whether the coordinate value represented by the variable “coord” is within the path represented by the variable “path”. Only when it is determined in step S819 that the variable path is a closed path, this processing is called in step S820. Therefore, the path represented by the variable path is always a closed path, and it is determined whether an arbitrary coordinate value is within the path. it can. If it is determined that it is within the path, the process proceeds to step S904. If it is not in the path, the process proceeds to step S908.

  Step S904 is processing for determining whether or not the alpha value of the color represented by the variable fill is 1.0 (completely opaque). If the alpha value is 1.0 (completely opaque), it is determined that alpha blending is not necessary, and the process proceeds to step S905. If the alpha value is other than 1.0 (transparent), it is determined that alpha blending is necessary, and the process proceeds to step S907.

  Step S905 is a painting process when the alpha value of the variable fill is 1.0 (completely opaque). Since alpha blending is not necessary, bitmap data bmp. The color at the coordinate position coord of data [] is replaced with the color represented by the variable fill.

  Step S906 is a process for calling a defined process for alpha blending when the alpha value of the variable fill is other than 1.0 (transparent). Since the alpha blend predefined processing returns the color after alpha blending (RGBA) and a flag (pre or post) indicating whether pre-rendering color matching or post-rendering color matching has been performed, bitmap data bmp. data [] and flag bmp. The value of the coordinate position coord of pre_or_post [] is replaced with the return value. The predefined processing of alpha blend will be described later with reference to FIGS.

Steps S907 to S910 are loop processing.
In step S907, the value coord. This is a process of adding 1 to x.

In step S908, the horizontal value coord. x is the horizontal size bmp. This is a process for determining whether or not it is equal to w. If they are equal, the process proceeds to step S909, and if they are not equal, the process returns to step S903.
In step S909, the value coord. x is initialized to 0, and the vertical value coord. This is a process of adding 1 to y.

In step S910, the value coord. y is the vertical size bmp. This is a process for determining whether or not it is equal to h. If they are equal, the process proceeds to step S911, and if they are not equal, the process returns to step S903.
Step S911 is the end. Although there is no return value for this predefined process, the bitmap data bmp. data [] is updated.

[Alpha blend]
Next, the operation of alpha blending will be described with reference to FIGS.
FIG. 12 is a diagram illustrating a configuration of the verification result DB 312.

Reference numeral 1001 denotes a column constituting each record of the verification result DB 312.
Reference numeral 1002 denotes data stored in each column.
Each column of 1003 and 1004 stores a color to be alpha blended in RGBA notation.

Each column of 1005, 1006, and 1007 stores an ID for identifying the input profile 305, rendering profile 306, printer profile 307, and rendering intent 308 when the renderer 310 uses the CMM 311.
The column 1008 stores the color of the result of alpha blending in RGBA notation.
A column 1009 stores whether pre-rendering color matching or post-rendering color matching has been performed as a pre or post value.

FIG. 13 is a flowchart showing the operation of a predefined process for performing alpha blending.
This defined process is called from step S906 in the flowchart shown in FIG. In this predefined process, as a color matching function of CMM 311, CMM. gm, CMM. cc, CMM. Use the three functions of lab.

  CMM. gm performs gamut mapping. Arguments (color, prof1, prof2, intent) are color specification color, profile prof1, profile prof2, and rendering intent intent. The function compresses the color of the color gamut represented by prof1 into the color of the color gamut represented by prof2 according to the intent, and returns it as the color of the color gamut represented by prof1.

  CMM. cc performs color conversion. The arguments (color, prof1, prof2) are a color specification color, profile prof1, and profile prof2. The function converts the color of the color gamut represented by prof1 into a color of the color gamut represented by prof2 without being compressed, and returns it as the color of the color gamut represented by prof2. It is assumed that the color specified by color is within the color gamut expressed by prof2.

  CMM. lab converts to an L * a * b * value. The L * a * b * color space is a uniform color space established in 1976 by the CIE (Commission Internationale I'Eelairagel; International Lighting Commission), and is represented by a lightness index L * and a chromaticness index a * and b *. The arguments (color, prof) are a color designation color and a profile prof. The function converts the color color of the color gamut represented by prof into an L * a * b * value and returns it.

  Step S1101 is the start of alpha blending. color1 and color2 are arguments at the time of calling this predefined process. The argument color1 is initialized at step 805 in FIGS. 9 to 10 and is updated in steps S905, S906 in FIG. This is the color value at an arbitrary coordinate of data []. The argument color2 is the color value of the variable fill that is initialized in step S802 of FIGS. 9 to 10 and updated in step S810.

  Step S1102 is variable initialization processing. “return” is a variable for holding a return value, and elements (r, g, b, a) represent each element of color in RGBA notation. The element pre_or_post is a variable that holds whether pre-rendering color matching or post-rendering color matching has been performed, and holds pre or post as a value. inputProf is a variable that holds the contents of the input profile 305. printerProf is a variable that holds the contents of the printer profile 307. intent is a variable that holds the contents of the rendering intent 308.

  Step S1103 is a process for searching whether or not the verification result is registered in the verification result DB 312. With respect to the verification result DB whose configuration is shown in FIG. 12, the registration record is searched with the variables color1, variable2, variable inputProf, variable printerProf, and variable intent as arguments. When a record is found in which color1 is in column 1003, color2 is in column 1004, inputProf is in column 1005, printerProf is in column 1006, and intent is in column 1007, the value of column 1008 and the value in column 1009 of the found record are set to variable return. In (r, g, b, a) and (pre_or_post). In step S1103, it is determined whether or not a record is found. If found, the process proceeds to step S1112 and the process is terminated. If not found, the process proceeds to step S1104.

  Step S1104 is processing for obtaining an L * a * b * value when color matching before rendering is performed. First, the CMM. Using the gm function, the value of the argument color1 and the value of the argument color2 are compressed from the input color gamut (represented by inputProf) to the color gamut of the printer 313 (represented by printerProf) with the rendering intent intent, and the results are each represented by the variable preInput1 And preInput2. Next, blend processing is performed with the value of the variable preInput1 and the value of the variable preInput2, and the result is stored in the variable preRender. The blending process is calculated by the following formula from the value of preInput1 (r, g, b, a) and the value of preInput2 (r, g, b, a).

preRender.r = preInput1.r x preInput1.a + preInput2.r x preInput2.a x (1-preInput1.a)
preRender.g = preInput1.g x preInput1.a + preInput2.g x preInput2.a x (1-preInput1.a)
preRender.b = preInput1.b x preInput1.a + preInput2.b x preInput2.a x (1-preInput1.a)
preRender.a = preInput1.a + preInput2.a x (1-preInput1.a)

  Finally, CMM 311 CMM. Using the cc function, the blend result preRender value is converted from the input color gamut (represented by inputProf) to the color gamut of the printer 313 (represented by printerProf), stored in the variable prePrinter, and the CMM. Using the lab function, the value of prePrinter is converted into an L * a * b * value and stored in the variable preLab.

  Step S105 is processing for obtaining L * a * b * values when color matching after rendering is performed. First, blend processing is performed with the value of argument color1 and the value of argument color2, and the result is stored in variable postRender. The blend process is calculated by the following formula from the value of color1 (r, g, b, a) and the value of color2 (r, g, b, a), as in step S1104.

preRender.r = color1.r x color1.a + color2.r x color2.a x (1-color1.a)
preRender.g = color1.g x color1.a + color2.g x color2.a x (1-color1.a)
preRender.b = color1.b × color1.a + color2.b × color2.a × (1-color1.a)
preRender.a = color1.a + color2.a x (1-color1.a)

  Next, the CMM. Using the gm function, the value of the blend result preRender is compressed from the input color gamut (represented by inputProf) to the color gamut of the printer 313 (represented by printerProf) with the rendering intent int, and the result is stored in the variable postInput. Finally, CMM 311 CMM. Using the cc function, the value of the blend result postInput is converted from the input color gamut (represented by inputProf) to the color gamut of the printer 313 (represented by printerProf), stored in the variable postPrinter, and the CMM. Using the lab function, the value of postPrinter is converted into an L * a * b * value and stored in the variable postLab.

  Step S1106 is processing for obtaining a theoretical L * a * b * value in the input color gamut (expressed by inputProf). First, blend processing is performed with the value of the argument color1 and the value of the argument color2, and the result is stored in the variable tRender. The blending process is the same as step S1105. Next, the CMM. Using the lab function, the blend result tRender value is converted into an L * a * b * value and stored in the variable tLab.

Step S1107 is processing for obtaining CIE L * a * b * color difference (CIE 1976) of L * a * b * values preLab and tLab, and postLab and tLab. The color difference ΔE _pre between preLab and tLab and the color difference ΔE _post between postLab and tLab are preLab values (L *, a *, b *), postLab values (L *, a *, b *), tLab values (L *, A *, b *) is calculated by the following formula.

ΔE _pre ² = (preLab.L * −tLab.L *) ² + (preLab.L * −tLab.L *) ² + (preLab.L * −tLab.L *) ²
ΔE _post ² = (postLab.L * −tLab.L *) ² + (postLab.L * −tLab.L *) ² + (postLab.L * −tLab.L *) ²

The calculation results are stored in variables deltaE_pre and deltaE_post, respectively.
Step S1108 is processing for comparing the color difference deltaE_pre and deltaE_post. If the value of the variable deltaE_pre is smaller, the process proceeds to step S1109. Otherwise, the process proceeds to step S1110.

  Step S1109 is processing when the pre-rendering color matching is closer to the theoretical value (that is, deltaE_pre <deltaE_post by the comparison in step S1108). The value of preRender that holds the rendering result in the input color gamut (expressed by inputProf) is stored in (r, g, b, a) of the variable return, and the value pre is stored in (pre_or_post) of the variable return.

  Step S1110 is processing when color rendering after rendering is closer to the theoretical value (that is, deltaE_pre ≧ deltaE_post by the comparison in step S1108). The value of postRender that holds the rendering result in the input color gamut (expressed by inputProf) is stored in (r, g, b, a) of the variable return, and the value post is stored in (pre_or_post) of the variable return.

  Step S1111 is processing for registering the verification result in the verification result DB 312. A record is registered in the verification result DB whose configuration is shown in FIG. 12 with the variables color1, variable2, variable inputProf, variable printerProf, variable intent, and variable return as arguments. color1 is column 1003, color2 is column 1004, inputProf is column 1005, printerProf is column 1006, intent is column 1007, return (r, g, b, a) is column 1008, and return (pre_or_post) is registered in column 1009. Is done.

  Step S1112 is the end. The value of the variable return is returned as a return value.

[Printer output]
Next, the printer output operation will be described with reference to FIG.
FIG. 14 is a flowchart showing the operation of a predefined process for performing printer output. This defined process is called from step S807 of the flowchart shown in FIG.

  Step S1201 is the start of this predefined process. The argument bmp is initialized in step S805 in FIGS. 9 to 10 and has the same value as the variable bmp rendered in steps S820, S824, and S826.

  Step S1202 is a variable initialization process. coord is bitmap data bmp. Variables that hold coordinate values when data is scanned from upper left to lower right, and (x, y) represents coordinate values in pixel units. The flowchart shown in FIG. 14 is mainly composed of loop processing using the variable “coord” as a loop variable. inputProf is a variable that holds the contents of the input profile 305. printerProf is a variable that holds the contents of the printer profile 307. intent is a variable that holds the contents of the rendering intent 308. outputbmp [] is an array that holds bitmap data for printer output, and has a size of bmp. Same as data [].

  In step S1203, the bitmap data of the coordinate value indicated by the variable “coord” and the value of pre or post are converted into bmp. data [] and bmp. This process is acquired from pre_or_post []. The acquired values are stored in variables “data” and “pre_or_post”, respectively.

  Step S1204 is processing for determining whether or not the variable pre_or_post is the value pre. Variable bmp. pre_or_post [] is initialized to the value “post” in step S805, and if alpha blend rendering is performed on the pixel, the value “pre” or “post” is stored in step S906. Is not stored. Therefore, the determination is true only when alpha blend rendering is performed on the pixel by pre-rendering color matching. In that case, the process proceeds to step S1206. Otherwise, the process proceeds to step S1205.

  In step S1205, the CMM 311 CMM. This is a process of compressing pixel data from the input color gamut (represented by inputProf) to the color gamut of the printer 313 (represented by printerProf) using a rendering intent using the gm function. The result overwrites the variable data.

  In step S1206, since the color value of the variable “data” has already been compressed into the color gamut of the printer 313 (represented by “printerProf”), the CMM. This is a process for converting the input color gamut (expressed by inputProf) into the color gamut of printer 313 (expressed by printerProf) using the cc function. The result is stored in the coordinate position indicated by the variable “coord” of the printer output bitmap data outputbmp [].

Steps S1207 to S1210 are loop processing.
In step S1207, the value coord. This is a process of adding 1 to x.
In step S1208, the value coord. x is the horizontal size bmp. This is a process for determining whether or not it is equal to w. If they are equal, the process proceeds to step S1209, and if they are not equal, the process returns to step S1203.

In step S1209, the vertical value coord. This is a process of adding 1 to y.
In step S1210, the value coord. y is the vertical size bmp. This is a process for determining whether or not it is equal to h. If they are equal, the process proceeds to step S1211, and if they are not equal, the process returns to step S1203.

Step S1211 is processing to transmit to the controller 314 of the printer 313 because the printer output bitmap data outputbmp [] has been created. The printer 313 stores the received bitmap data in the RAM 209 as bitmap data 315, and controls the printer engine 212 according to the bitmap data 315 to perform output.
Step S1212 is completed. There is no return value.

[Renderer operation example]
Finally, an example of the operation of the renderer 310 will be described using the intermediate code data shown in FIG. 8 with reference to FIGS.
15 to 16 are diagrams showing how the renderer 310 renders the intermediate code data shown in FIG. 8 according to the flowcharts shown in FIGS. 9 to 10, 11, and 13.

  The intermediate code data is read into the variable dlc in step S802. The variable fill is initialized with fill (r, g, b, a) = (1.0, 1.0, 1.0, 1.0). The variable stroke is initialized with stroke (r, g, b, w) = (0.0, 0.0, 0.0, 1).

  In the first opcode (PageStart) of dlc, the variable bmp is initialized in steps S804 to S805. Here, assuming that the resolution of the printer is 300 DPI (Dots Per Inch), 1 inch = 25.4 mm and 11.1811 PPM, so bmp. w = 210.0 × 11.811 = 2480.31≈2480 (rounded down), bmp. h = 297.0 × 11.811 = 3507.867≈3507 (rounded down), bmp. res = 11.811 (PPM). Bmp. data [] and bmp. The size of both arrays of pre_or_post [] is 2480 × 3507 = 84444856. bmp. data [] is initialized with fill (r, g, b, a) = (1.0, 1.0, 1.0, 1.0) initialized in step S802. pre_or_post [] is initialized with post.

  In the second operation code (Fill) of dlc, the variable fill is updated in steps S809 to S810. Here, flll (r, g, b, a) = (1.0, 1.0, 0.0, 0.7).

  In the third operation code (Stroke) of dlc, the variable stroke is updated in steps S811 to S812. Here, since the line width is multiplied by 2.0 of the operand and the resolution bmp.res, 2.0 × 11.811 = 23.622≈23 (rounded down to the decimal point), and stroke (r, g, b, w) = (0.0, 0.0, 1.0, 23).

  In the fourth opcode (PathStart) of dlc, variables path [] and cursor are initialized in steps S813 to S814. Here, since the processing depending on the operand is not performed, cursor (x, y) = (0, 0).

  In the fifth opcode (PathMoveTo) of dlc, the variable “cursor” is updated in steps S821 to S822. The coordinate value has a resolution bmp. Since res is multiplied, curror. x = 80.0 × 11.811 = 944.88≈944 (truncated after the decimal point), cursor. y = 30.0 × 11.811 = 354.33≈354 (rounded down to the nearest decimal point).

  In the sixth operation code (PathArc) of dlc, an arc 1301 is rendered. The starting point 1302 is the current value of the variable cursor (944, 354). The center point 1303 is set to a resolution bmp. Since res is multiplied, 80.0 × 11.811 = 944.88≈944 (truncated after the decimal point) is (944, 944), and the angle is 360 ° depending on the operand. The outline is blue, which is the current value of the variable stroke, and has a line width of 23 pixels. Each coordinate of the outline that returns from the start point 1302 along the clockwise direction 1301 to the start point 1302 is added to the variable path [].

  In the seventh opcode (PathEnd) of dlc, since the operand is not 1, the process of step S818 is not performed, but both the start point and end point held in path [] are indicated by 1302 (944, 354), it is determined in step S819 that the path is closed, and in step S820, the path fill defined process (FIG. 11) is called.

  In this path filling process, it is determined whether or not each pixel coordinate of the bitmap data is inside path [], and if it is inside path [], a fill process is performed. That is, the points inside the outline 1301 are filled with (r, g, b, a) = (1.0, 1.0, 0.0, 0.7), which is the current value of the variable fill. Since the alpha value is not 1.0, alpha blend defined processing (FIG. 13) is called in step S906.

  If no record is found in the verification result DB in step S1103, alpha blending processing in steps S1104 to S1111 is performed. Here, bmp. The blend process is performed with the initialization values (1.0, 1.0, 1.0, 1.0) of data [] and fill (1.0, 1.0, 0.0, 0.7). Whether pre-blend color matching or post-blend color matching is selected depends on the contents of the input profile 305, printer profile 307, and rendering intent 308. Here, it is assumed that pre-rendering color matching is selected. As for the blend result, the bitmap data bmp. It is assumed that the value of data [] is (0.9, 0.2, 0.2, 1.0) and the value of pre_or_post [] is pre. A state at this time is shown in FIG.

  In the eighth opcode (Fill) of dlc, the variable fill is updated in steps S809 to S810. Here, flll (r, g, b, a) = (1.0, 0.0, 0.0, 05).

  In the ninth opcode (PathStart) of dlc, the variables path [] and cursor are initialized in steps S813 to S814. Here, since the processing depending on the operand is not performed, cursor (x, y) = (0, 0).

  In the tenth operation code (PathMoveTo) of dlc, the variable cursor is updated in steps S821 to S822. The coordinate value has a resolution bmp. Since res is multiplied, curror. x = 140.0 × 11.811 = 1653.54≈1653 (rounded down), cursor. y = 30.0 × 11.811 = 354.33≈354 (rounded down to the nearest decimal point).

  In the elc 11th opcode (PathArc), arc 1304 is rendered. The starting point 1305 is the current value of the variable cursor (1653, 354). The center point 1306 is set at the resolution (bmp.1) at the operand (14.0, 80.0). Since res is multiplied, 140.0 × 11.811 = 1653.54≈1653 (truncated after the decimal point) and 80.0 × 11.811 = 944.88≈944 (truncated after the decimal point) are (1653, 944). The angle is 360 ° depending on the operand. The outline is blue, which is the current value of the variable stroke, and has a line width of 23 pixels. Each coordinate of the outline that returns from the start point 1305 to the start point 1305 along 1304 in the clockwise direction is added to the variable path [].

  In the 12th opcode (PathEnd) of dlc, since the operand is not 1, the process of step S818 is not performed, but both the start point and end point held in path [] are shown in 1305 (1653, 354), it is determined in step S819 that the path is closed, and in step S820, the path fill defined process (FIG. 11) is called.

  In this path filling process, it is determined whether or not each pixel coordinate of the bitmap data is inside the path [], and if it is inside the path [], a filling process is performed. That is, the points inside the outline 1304 are filled with (r, g, b, a) = (1.0, 0.0, 0.0, 05), which is the current value of the variable fill. Since the alpha value is not 1.0, alpha blend defined processing (FIG. 13) is called in step S906.

  Here again, assuming that no record is found in the verification result DB in step S1103, alpha blending processing in steps S1104 to S1111 is performed. For a region 1308 overlapping the outline of the arc 1301, bmp. Blend processing is performed with the values of data [] (0.0, 0.0, 1.0, 1.0) and fill (1.0, 0.0, 0.0, 0.5). For a region 1307 overlapping the inside of the arc 1301, bmp. Blend processing is performed with the values of data [] (0.9, 0.2, 0.2, 1.0) and fill (1.0, 0.0, 0.0, 0.5).

  For other regions 1306, bmp. The blend process is performed with the initialization values (1.0, 1.0, 1.0, 1.0) of data [] and fill (1.0, 0.0, 0.0, 0.7). Whether pre-blend color matching or post-blend color matching is selected depends on the contents of the input profile 305, printer profile 307, and rendering intent 308. Here, it is assumed that all post-rendering color matching is selected.

Regarding the blending result, bitmap data bmp. For the region 1308 overlapping the outline of the arc 1301 is obtained. For the area 1307 where the value of data [] is (0.5, 0.0, 0.5, 1.0) and overlaps the inside of the arc 1301, the bitmap data bmp. The value of data [] is (0.95, 0.1, 0.1, 1.0), and bmp. The value of data [] is (1.0, 0.5, 0.5, 1.0). The values of pre_or_post [] are all post. A state at this time is shown in FIG.
Thereafter, the same processing is performed for the 13th to 17th operation codes of dlc.

  In the 18th operation code (PageEnd), the printer output defined process (FIG. 14) is called in step S807.

  At this point, bmp. For pixels whose pre_or_post [] value is pre, for example, an area that does not overlap other arcs within the arc 1301, the color gamut of the printer is compressed in step S1205. Next, all the pixels are converted into the printer color gamut in step S1206. The printer output bitmap prepared in this way is transmitted to the controller 314 of the printer 313 in step S1211, and a final output is obtained.

[Other embodiments]
In the above embodiment, the intermediate code data is rendered by the client 101. However, the rendering may be performed by the printer 103 by transmitting the intermediate code data from the client 101 to the printer 103.

  In the above embodiment, rendering is performed in the input color gamut (color space) represented by the input profile 305. However, rendering may be performed in the rendering color gamut (color space) represented by the rendering profile 306, or the printer profile 307 may be rendered. You may make it render by the printer color gamut (color space) to express.

  In the above embodiment, SVG 1.1 is used as the PDL. However, the present invention is not limited to this, and any other version of SVG or any PDL that can be converted into the above intermediate code should be used. Is possible.

  In the above-described embodiment, an example in which one page is displayed and printed has been described. However, if the PDL corresponds to a plurality of pages, an intermediate code, a viewer program, and a controller may be associated therewith.

  In the above embodiment, one input profile and rendering intent are used for each SVG document. However, an input profile and rendering intent are specified for each type of object existing in the SVG document, for example, for each image, graphics, and text object. You may be able to do it. Furthermore, a system that allows an input profile and a rendering intent to be specified for each object is also conceivable.

  In FIG. 1, the PC and the printer are connected to the network. However, other connection forms may be used. For example, even if the PC and the printer are directly connected, or data is transmitted through a medium such as a memory card or CD. Even if it is a form to deliver, implementation of this invention is not prevented.

  In FIG. 2, the program is stored in the RAM 202. However, the present invention is not limited to this. In other embodiments, the program may be read from the external storage device 204 and executed. It may be received and executed via Although not shown in FIG. 2, the program may be read from a read-only internal storage unit such as a ROM and executed. Further, instead of or in addition to the keyboard 206 and the pointing device 207, other input devices such as voice input may be provided. Further, the display 205, the keyboard 206, and the pointing device 207 may be shared with other computer devices.

  In FIG. 4, the intermediate code data 303 and the bitmap data 304 and 315 are stored in the RAM, but may be stored in a file, database, or other permanent storage. Further, it is also possible to consider a form in which intermediate code data for the same PDL document is cached and used for subsequent processing.

  Moreover, although the specification of the intermediate code is shown in FIG. 7, the usable intermediate code is not limited to this specification. For example, the unit system may be any unit system other than mm or a combination thereof. The path may be a Bezier curve, elliptical arc, or any other mathematically expressible path. The Fill may be made not to be a single color but to be able to perform complicated painting such as a brush, an image, and gradation. In addition to RGB and RGBA, the color may be specified by a color profile, specified by a device color, or specified by a special color. The use of a 1-byte integer as an opcode and a 2-byte floating point number as an operand is merely an example, and other encoding methods may be used. Alternatively, in the form in which the intermediate code is transmitted to the printer 103, PDL interpretable by the printer 103 may be used.

  In FIG. 11, the entire bitmap is scanned using a general-purpose algorithm to determine whether or not each coordinate is included in the path represented by the argument path. In addition to this, it is included in the path represented by the argument path. A method of extracting coordinates in advance and rendering the coordinates is also conceivable.

Further, although CIE L * a * b * color difference (CIE 1976) is used as the color difference in FIG. 13, other color differences such as CIE ΔE ₉₄ (CIE 1994) and CIE ΔE ₂₀₀₀ (CIE 2000) may be used. .

  In the present invention, a software program that realizes the functions of the above-described embodiments is directly or remotely supplied to a system or apparatus, and the computer of the system or apparatus reads and executes the supplied program code. Can also be achieved. In that case, as long as it has the function of a program, the form does not need to be a program.

  Therefore, in order to realize the functional processing of the present invention with a computer, the program code itself installed in the computer and the storage medium storing the program also constitute the present invention. In other words, the claims of the present invention include the computer program itself for realizing the functional processing of the present invention and a storage medium storing the program.

In this case, the program may be in any form as long as it has a program function, such as an object code, a program executed by an interpreter, or script data supplied to the OS.
As a storage medium for supplying the program, for example, flexible disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, CD-RW, magnetic tape, nonvolatile memory card, ROM, DVD (DVD-ROM, DVD-R).

  As another program supply method, a client computer browser is used to connect to an Internet homepage, and the computer program of the present invention itself or a compressed file including an automatic installation function is downloaded from the homepage to a storage medium such as a hard disk. Can also be supplied. It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a Web server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the scope of the present invention.

  In addition, the program of the present invention is encrypted, stored in a storage medium such as a CD-ROM, distributed to users, and key information for decryption is downloaded from a homepage via the Internet to users who have cleared predetermined conditions. It is also possible to execute the encrypted program by using the key information and install the program on a computer.

  In addition to the functions of the above-described embodiments being realized by the computer executing the read program, the OS running on the computer based on an instruction of the program is a part of the actual processing. Alternatively, the functions of the above-described embodiment can be realized by performing all of them and performing the processing.

  Further, after the program read from the storage medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion board or The CPU or the like provided in the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are also realized by the processing.

It is a figure showing a schematic structure of one embodiment concerning the present invention. It is a figure which shows the structure of the computer apparatus in the embodiment. 2 is a diagram illustrating a configuration of a printer apparatus according to the embodiment. FIG. It is a block diagram which shows the whole structure of the embodiment. It is a figure which shows the content of the SVG document file used in the embodiment. It is an example of rendering of the SVG document file used in the embodiment. It is a figure which shows the intermediate code specification used in the embodiment. It is a dump display example of an intermediate code obtained by converting an SVG document file used in the embodiment. It is a flowchart (1) which shows the operation | movement of the renderer in the embodiment. It is a flowchart (2) which shows the operation | movement of the renderer in the same embodiment. It is a flowchart which shows the path | pass painting operation | movement (predefined process) in the embodiment. It is a figure which shows the structural example of verification result DB in the same embodiment. It is a flowchart which shows the alpha blend operation | movement (predefined process) in the embodiment. 6 is a flowchart illustrating a printer output preparation operation in the embodiment. It is a bitmap example (1) rendered by the renderer in the same embodiment. It is a bitmap example (2) rendered by the renderer in the same embodiment.

Explanation of symbols

101 ... Client 102 ... Printer 103 ... Network 201 ... CPU
202 ... RAM
203 ... Network interface 204 ... External storage device 205 ... Display 206 ... Keyboard 207 ... Pointing device 208 ... CPU
209 ... RAM
210: Network interface 211 ... External storage device 212 ... Printer engine

Claims (11)

A rendering means for rendering a description language document;
Color matching means for converting the color information specified in the description language document by compressing the color information into color information for a printing device that prints the description language document;
When the description language document requires alpha blend rendering, the color matching unit determines whether to perform the conversion before the rendering or after the rendering, and includes a selection unit that selects one based on the determination result. A printing apparatus characterized by that.   The selection by the selection unit is performed by verifying a result when the conversion by the color matching unit is performed before the rendering and after the rendering and performing the selection. Printing device. Holding means for holding the conditions used for selection in the selection means and the selection results;
Means for using the information held by the holding means at the time of subsequent alpha blend rendering;
The printing apparatus according to claim 1, further comprising: A rendering step for rendering a description language document;
A color matching step of converting the color information specified in the description language document by compressing the color information into color information for a printing device that prints the description language document;
When the description language document requires alpha blend rendering, a determination step of determining whether the conversion by the color matching step is performed before the rendering or after the rendering, and selecting one of them based on the determination result is provided. A control method for a printing apparatus.   5. The selection according to claim 4, wherein the selection by the selection step is performed by verifying a result when the conversion by the color matching step is performed before the rendering and after the rendering. 5. Method for controlling the printing apparatus. A holding step for holding the conditions and selection results used for selection in the selection means;
The printing apparatus control method according to claim 4, further comprising: a use step of using information held by the holding unit at the time of subsequent alpha blend rendering. A rendering step for rendering a description language document;
A color matching step of converting the color information specified in the description language document by compressing the color information into color information for a printing device that prints the description language document;
When the description language document requires alpha blend rendering, a determination step of determining whether the conversion by the color matching step is performed before the rendering or after the rendering, and selecting one of them based on the determination result is provided. A control program for a printing apparatus.   The selection by the selection step is performed by verifying a result when the conversion by the color matching step is performed before the rendering and after the rendering and performing the selection. Printer control program. A holding step for holding the conditions and selection results used for selection in the selection step;
The printing apparatus control program according to claim 7, further comprising: a use step of using information held by the holding unit at the time of subsequent alpha blend rendering.   A computer-readable storage medium storing the program according to any one of claims 7 to 9.   A Web server storing the program according to claim 7.

Images