JPH032058A - Processing method for font pattern - Google Patents

Abstract

PURPOSE:To generate a natural pattern by tracing a profile with an intrinsic code array corresponding to the type of a stroke as a starting point on a byte map, and extracting stroke component of a font pattern. CONSTITUTION:A CPU 3 forms a byte map allocated with a byte code for a value calculated by a vicinity bit for each black point of a font pattern on a bit map of a memory 1, and stores it in a memory 2. A profile is traced with an intrinsic code array corresponding to the type of a stroke as a starting point on the byte map, the stroke component of the font pattern is extracted, divided into to contour lines at both end points as a boundary, only one of the contour lines is extracted as the stroke component, and the contour line for forming a stroke is generated together. In this case, a different line diameter enlarging rate responsive to the type of the stroke is applied. Thus, the font pattern of natural character shape can be generated.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to font pattern processing, and particularly to processing such as stroke extraction, thinning, and bolding of font patterns.

[Prior Art and Problems to be Solved by the Invention] In document creation systems using personal computers, laser printers, etc., there is an increasing demand for greater diversity in fonts.

Regarding font processing to meet this demand, affine transformations such as linear size conversion, italicization, and rotation are relatively easy regardless of whether the font is a bitmap or a vector font. However, the more important and effective font processing, character line diameter conversion, i.e., thinning and bolding, has been difficult to achieve with nonlinear conversion, so conventionally, characters with different line diameters were prepared as separate fonts. This is common, and there is a problem that the font memory increases.

Furthermore, a font pattern basically consists of a closed loop of two contour lines along the stroke (movement of the brush). In various types of font processing, it is often necessary to extract these stroke components. Conventionally, such stroke extraction is often performed by contour tracing on a bitmap in which one pixel of a font pattern is represented by one bit. However, the efficiency of software processing is low, and the detection of stroke intersections and contacts is difficult.
There has been a problem in that it is geometrically extremely difficult to match two contour lines along a stroke.

SUMMARY OF THE INVENTION Therefore, an object of the present invention is to provide an improved font pattern processing method for stroke extraction, thinning, nonlinear variable diameter format conversion, etc. of font patterns.

[Means and operations for solving the problem] According to the present invention, processing is performed not on a bitmap of a font pattern but on a bytemap.

This byte map is a map in which a predetermined byte code is assigned to a value calculated using neighboring bits for each black point of a font pattern on the bit map.

On such a byte map, by finding a unique code sequence corresponding to the type of stroke, tracing the contour using the position of this code sequence as a starting point, and detecting the end points (start and end points) of the stroke, the stroke of the font pattern can be determined. Extract the ingredients.

Each code on the bitemap symbolically expresses the geometric and topological characteristics of the pattern, so the code can be used to classify the types of strokes, match the two contour lines that make up a stroke, and distinguish the contours. Directionality can be easily confirmed, strokes can be extracted efficiently, and strokes can be easily and reliably decomposed even if there is interference between strokes such as stroke intersection or contact.

Now, a stroke is a closed loop of two contour lines, and it can be considered that the stroke center line exists between the two contour lines, but it is meaningless to determine this geometrically. This is because, for example, serifs in Mincho fonts are unrelated to the stroke center line.

Even if such a virtual stroke center line is extracted, it is impossible to reproduce a stroke pattern including serifs.

Therefore, in the present invention, the stroke component extracted by contour tracing as described above is divided into two contour lines using both end points as boundaries, and only the second contour is extracted as a stroke component.

According to this, the memory space is halved compared to the method of extracting and saving data of two outlines of a stroke. moreover,
The contour lines to which serifs are added are determined depending on the stroke type, so depending on the stroke type, you can select one contour line without serifs as the stroke component to be extracted, and use it as a stroke vector to extract the other contour line. It is possible to derive the contour line including serifs.

Pattern size and line diameter are important design elements of fonts, and fonts that differ in these elements are designed as separate fonts.

However, in general, the basic design (stroke) of characters is considered to be almost the same (similar) regardless of size or wire diameter.

On the other hand, when making a font bold, a natural pattern cannot be obtained by making the line diameter uniform for all strokes. For example, in the case of a Mincho font, a natural pattern can be obtained by making the vertical strokes thicker and making the horizontal strokes have a smaller diameter.

Therefore, in the present invention, contour lines constituting a stroke are derived from the contour lines extracted as stroke components, and at that time, different wire diameter enlargement ratios are applied depending on the type of stroke, so that a common To make it possible to generate font patterns of various sizes and line diameters and natural character shapes from fonts.

〔Example〕

Hereinafter, one embodiment of the present invention will be described in detail using the drawings.

FIG. 1 shows an example of an apparatus configuration for executing font pattern processing according to the present invention. 2 is a bitmap memory for storing a bitmap of a font pattern. On this bitmap, one pixel of the font pattern is represented by one bit, and the value of each bit is 1 for a black point and 0 for a white point.

2 is a byte map memory for storing a font pattern byte map. On this bytemap,
One pixel of the font pattern is expressed by a one-byte code. Note that it is also possible to use a common memory as the bitmap memory 1 and the bytemap memory 2.

3 is a CPU that executes processing. A program memory 4 stores programs for processing by the CPU 3. Reference numeral 5 denotes a data memory for temporarily storing intermediate data, result data, etc. of processing by the CPU 3.

FIG. 2 shows the overall processing flow in one embodiment of the present invention. The processing contents of each processing block in FIG. 2 will be explained below.

Processing Block ■ This processing block converts a bitmap to a bytemap.

This conversion is performed by assigning a predetermined byte code to each point of the font pattern on the bitmap in accordance with the result of a specific operation using the values (white/black) of neighboring bits. The range of neighborhoods referenced during this conversion is 8 neighborhoods (vertical, horizontal).

(diagonal) or 4 neighborhoods (vertical, horizontal); however, in the case of font pattern processing, it is sufficient to refer to 4 neighborhoods.

In this embodiment as well, four neighborhoods are selected, and for each point of interest (x, y) in the font pattern, each bit Cx in the four neighborhoods is selected.
ty-i)+ (x+ y+i), (x-1ty
)t (x+1.y) with binary weights (8, 4
, 2, 1) to form a coat.

That is, the following equation is calculated for each point (x, y).

V (x, y) = 8 X B (x + y 1)
+ 4 X B (x * y + 1) + 2XB (
x-1)+B(x+1.y)-(1)However,
B (a, b) is 1 if the neighboring bits (a, b) are black, and 0 if they are white. Furthermore, the above formula is applied when the point of interest (x, y) is black, and when the point of interest is white, V (x F
y) is set to -i (=OXFF). Therefore, V
(x+y) is an integer from -1 to +15.

Then, a byte code as shown in Table 1 is assigned to such arithmetic value V (X*y). However, in this embodiment, since the code "F" corresponds to an isolated point and can be regarded as thermally meaningful noise in processing, it is replaced with "blank".

Margin below Table 1 FIGS. 3 to 5 show examples of byte maps for kanji.

Processing Block ■ This processing block decomposes the font pattern into strokes (brush movements) or extracts the strokes on the bite map. Here, four types of strokes as shown in Table 2 are defined.

Table 2 In this embodiment, these four types of strokes are extracted in order, as shown in FIG.

To extract each type of stroke, raster scan the byte map from the upper left corner to search for a code sequence (Figure 7) specific to the stroke type of interest. When this unique code sequence is found, the outline is drawn in both directions from that position. This is done by tracking and searching for endpoints. Therefore, the bytemap will be scanned a total of four times. Generally, there are multiple strokes in one font pattern. For example, the third
On the bytemap of "Ko" shown in the figure, the vertical line is the VTL
~VT7 (7) 7 pieces, horizontal line is HR1 ~ HRLI (1) 1
There is one. The same applies to the bite maps shown in FIGS. 4 and 5. Here, the number added to the abbreviation of each stroke is a counter of the number of strokes for each type.

Although it seems that there are an infinite number of stroke unique code sequences, in reality, the contour is traced starting from the first unique code sequence encountered by scanning the byte map, and the code that has passed once is deleted. In principle, there is a correspondence between each stroke and one unique code sequence.

FIG. 8 is a flowchart of such stroke extraction processing. In processing block 111, variables x, y
, c is initialized (cleared). X.

y is a pointer for scanning the byte map, and C is the stroke counter, which is an index of stroke data. Processing block 12 is.

Detects the unique code and extracts the end point of the stroke from that position (
The contour is traced until the starting point and ending point are found, and each time a stroke is extracted, 1 is added to the value of the counter C.

Note that details of this processing will be described later. Processing block 13 checks the end of bytemap scanning by checking the position 41 (Xmax, Ymax) at the lower right corner of the bytemap.
Compare and judge pointers X and y. Processing step 14
increments the pointer y.

FIG. 9 shows an image of the extracted strokes. The outline of the stroke is divided into two outlines at the end points P1tP2. What is saved as stroke data is
Only one outline is represented by a solid line. In other words, the solid line is a single stroke. The dashed contour is derived as a function of the solid contour;
Serifs are also uniquely included. The diagonal stroke p3 is
Since a specific pattern is called as "U diagonal line" by the attribute parameter, it is not necessarily necessary.In short, in this embodiment, the stroke type and the end points P1+P2
Only the coordinates of are saved as stroke data in the format shown in FIG. Therefore, the memory capacity required to store the data of one stroke is extremely small, 5 bytes.

In general, strokes are caused by interference with other strokes (continuous,
However, here we will explain contour addition and end point detection assuming that there is no stroke interference.9 Since the unique code array of a stroke is always in the middle of the stroke, it can be used in both directions from that position (for vertical lines, by tracing contour points vertically upward and vertically downward.

A code or code sequence is found that indicates the endpoint of the stroke (pi, p2). FIG. 11 shows how such contour tracking is performed for each stroke type.

Further, the code or code arrangement of the end points is shown in FIG. An example of such an end point code or code arrangement is then saved as the stroke end point PlyP2.

Now, in actual font patterns, interference between strokes frequently appears. Here, each interference is defined as follows.

``One continuous (C)'': Different types of strokes consecutively form one stroke like a key.

"Contact (T)": The end of a stroke is included in another stroke, such as a T-junction or a T-junction.

``Intersection (X)'': A stroke passes through another stroke midway, as in a crossroads or an X-junction.

An example of such stroke interference is shown in FIG.

Next, stroke extraction processing when there is stroke interference (
Processing block 12) in FIG. 8 will be explained. If there is stroke interference, the code or code arrangement at the end shown in FIG. 12 cannot simply be used as the end point of the stroke, and it is necessary to change the method of detecting the end point depending on the type of interference.

For example, in the case of contour tracing of a vertical line that intersects a horizontal line as shown in FIG. 8 II. The code below this code 1181) that spreads left and right is "4", which is a code arrangement specific to the horizontal line shown in Part 7. Therefore, the vertical line and horizontal line of interest Now that we know the interference of
The code arrangement in the line immediately below 1 is +++, and this code II + It means a point inside the contour line, so
Proceed with contour tracing of vertical line strokes. The same applies to the 9th line. If we continue tracing up to line 10, here we see the code sequence “
2 + 1'' appears again. This means that the vertical line has passed through the horizontal line, and the interference can be determined to be an intersection. In the case of such an intersection, the code or code arrangement at the end is different from the intersection. The found position is taken as the end point.

FIG. 15 is an example of "contact". In tracing down the vertical line, the code arrangement of the horizontal line in the 8th line appears, but the code arrangement "444" in the 9th line is encountered.

Since this chord arrangement is a contour line, the downward progression of the vertical line is prevented. That is, the ninth row is determined to be the lower end of the vertical line.

FIG. 16 is an example of "continuous". The upward progression of the vertical line stroke is the 10th consecutive chord sequence "2 + 1".
Proceed to line. The code sequence "2+5" appears in the next 9th line, but since this code sequence does not correspond to any of the unique code sequences of the four types of strokes shown in Figure 7, even if it is an "intersection" with other strokes, Since it is not "contact", it can be seen that it is "continuous". In this case, since a horizontal line code arrangement is encountered on the left contour line side in the 8th line, it is determined that this vertical line is continuous with the horizontal line, and the end point is searched for by proceeding with contour tracing.

In addition, in the case of the Mincho typeface, there is a serif unique to the key at the corner of the key. In this example, the path of the right-hand side line (a series of "1"s) (a series of codes 1, 5, D, 9, 9 degrees B, A) is a serif code arrangement unique to the key, and this is It can be patterned in advance.

FIG. 17 shows a flowchart of stroke extraction in consideration of such stroke interference. Processing block 21
is a block that detects a code sequence unique to a stroke type, and contour tracking starts in both directions from the position of this unique code sequence as a starting point. The processing block 22 is a block that detects interference with other strokes, detects end points, and determines the type of interference during tracking.

If no interference is detected, the stroke is simply advanced (processing block 23). When an endpoint, i.e., a code or code arrangement of said endpoint, is detected, the position of the endpoint is saved and tracking in its direction is terminated (processing block 24
).

When "contact" is detected, processing is performed in processing block 25. 'Contact' means the end point of the stroke of interest itself or the end point of the stroke of the contact partner.In the case of the end point of the stroke of the contact partner, only one contour line of the stroke of interest (consisting of two contour lines) is interfered with. , in the case of the endpoint of the stroke of interest itself, the progression of both contours is blocked, so
The distinction is possible. Therefore, if the position of the "interference" is the stroke of interest itself, the position of the opponent's contour line is saved as an end point, and tracking in that direction is ended.

When a ``cross'' is detected, a 1'+'' code appears in the direction of stroke progression. If a chord sequence specific to the stroke of interest appears again after skipping this 11+'' chord, the stroke is allowed to proceed as is (processing block 26).

If "interference" is neither "contact" nor "intersection", it is "continuous", and specifically, it is a case where two strokes (horizontal line and diagonal line in the case of a key) are continuous, as in the case of a key ()). . In this case, as described above, the curved portion is detected and continued with the opponent's stroke, and tracking is advanced (processing block 27).

FIGS. 18 to 20 are images of single-line strokes extracted from the bite maps shown in FIGS. 3 to 5, respectively, or thinned images of font patterns.

Processing block ■1 This is a processing block that generates font patterns of various sizes and line diameters from the strokes of the font pattern extracted in processing block ■.

The extracted stroke is one of the reference outlines as shown by the solid line in FIG. Therefore, the length and position of the stroke are adjusted according to the font size, and the remaining contour line (broken line in FIG. 9) that forms the necessary linear shape is derived from this stroke. At this time, the wire diameter expansion rate is changed depending on the type of stroke so that a natural pattern can be obtained. Then, fill in the inside of the stroke as necessary.

〔Effect of the invention〕

The parameter of the character pattern structure is the stroke,
The contour, that is, the thickness of the line, can be said to be a secondary projection derived from the stroke. However, the actual characters to be processed are drawn with lines of a certain thickness, and their outlines include line intersections, contacts, etc., so one stroke on a bitmap can be geometrically drawn from the outline. It is extremely difficult to extract.

In contrast, according to the present invention as defined in claim (1).

By utilizing the fact that specific code sequences appear along strokes on a bytemap representing the geometrical or topological features of a pattern, even strokes with interference can be extracted accurately and efficiently.

A stroke is a closed loop connecting two end points with two contour lines. These two contour lines represent the thickness of the line, and are highly correlated and functional with each other, and it is possible to functionally derive one contour line from the other contour line.

According to the present invention as set forth in claim (2), since only one contour of a stroke is extracted, the capacity of the memory for storing stroke data can be reduced compared to the case where both contours are extracted and stored. Furthermore, since the end points of the stroke are the extreme values in the horizontal and vertical directions, by giving the attributes of the start and end of filling to the two contour lines, it is possible to fill the inside of the stroke at high speed.

In addition, in order to perform linear transformation according to the type of stroke, divide the stroke outline into two, and divide one outline into 1Q of the other.
It is necessary to express it as a function bounded by a contour line. Claim (3)
According to the present invention described in , it is possible to easily perform such non-linear conversion of the wire diameter, so it is possible to convert various font patterns with different sizes and wire diameters by non-linear variable wire diameter font conversion for a common font. It becomes possible to generate.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing an example of a device configuration for carrying out the present invention, FIG. 2 is a flowchart showing the overall processing of an embodiment of the present invention, and FIGS. 3 to 5 are examples of byte maps, respectively. FIG. 6 is a flowchart showing the processing flow of the stroke extraction processing block in FIG. 2, FIG. 7 is a diagram showing the code arrangement specific to each stroke, and FIG. Flowchart showing the contents of the processing block, FIG. 9 is a diagram showing an image of the stroke to be extracted, FIG. 10 is a diagram showing the data format of the stroke, and FIG. 11 is an explanatory diagram of contour tracking for stroke extraction. , FIG. 12 is a diagram showing the code or code arrangement at the end, FIG. 13 is a diagram showing an example of interference between strokes, and FIG. 14 is a diagram showing an example of interference between strokes.
The figure is a diagram for explaining stroke extraction in the case of "crossing", Figure 15 is a diagram for explaining stroke extraction in the case of "contact", and Figure 16 is a diagram for explaining stroke extraction in the case of "continuous". A diagram for explaining extraction, FIG. 17 is a flowchart of stroke extraction processing considering interference between strokes.
8 to 20 are diagrams showing strokes extracted from the bite maps shown in FIGS. 3 to 5, respectively. 1... Bit map memory, 2... Byte map memory, 3... CPU, 4... Program memory, 5...
...Data memory. Figure 3 h! I Fig. 2 Fig. 6 m, LL44 Salary 44> Fig. 9 Convex de Todorowora Fig. 7 Fig. 8 Fig. 11 Figure 12, figure 17, overflow, etc. Figure 20

Claims (1)

[Claims] (1) A byte map is created in which a byte code is assigned to a value calculated using neighboring bits for each black point of a font pattern on the bit map, and on the byte map, a unique A font pattern processing method characterized by extracting stroke components of a font pattern by tracing contours using a code sequence as a starting point. (2) Font pattern processing characterized in that the stroke component extracted in claim (1) is divided into two contour lines using both end points as boundaries, and only one of the contour lines is extracted as a stroke component. Method. (3) In claim (2), a contour line constituting a stroke is derived from the contour line extracted as a stroke component, and at that time, a different wire diameter enlargement rate is applied depending on the type of stroke. Characteristic font pattern processing method.