JPH03147178A - Control method for document data in application software - Google Patents

Abstract

PURPOSE:To increase a document, which can be registered to an auxiliary storage, by removing an unnecessary part or an over-lapped part in document data by the two steps of data compression processings. CONSTITUTION:A page data input/output processing part 12 executes a processing to write compressed page data for one page (a compression buffer 41) into a document file 16 in an auxiliary storage 15 and a processing to read the compression buffer 41 from the document file. A line data input/output processing part 13 executes a processing to take out the compressed line data from the compression buffer 41 read onto a memory in a main storage and to execute data extension (development) and a processing to compress the extended line data (developed line data) and to store the data in the compression buffer 41. A line data edition processing part 14 executes the edition processing of the developed line data. Thus, the capacity of the auxiliary storage 15 is not lacked.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a method for managing document data in application software, and particularly to a method for managing document data in application software that manages documents on a main storage device.

[Conventional technology]

Conventionally, when managing document data using application software, the document data edited on the main storage device is input/outputted line by line to a file on the auxiliary storage device in the form of character strings as they are.

In other words, a large amount of blank characters that are normally included in a document were also output to the file as data.

Additionally, characters that repeated many times within a single line, such as character lines, were output to the file as continuous data.

[Problem to be solved by the invention]

With conventional management methods, document data output to files has many unnecessary or duplicated parts, resulting in an increase in the amount of data per document, which is one of the causes of insufficient auxiliary storage capacity. was.

Furthermore, due to the increase in the amount of data per document, an area for holding one page of the document cannot be secured in the memory of the main storage device, and only a few lines of data can be held. Therefore, even while editing the page, the updated line data is output to a file on the auxiliary storage device, and the next few lines of data are read from the file.
This caused a decrease in the execution speed of document editing work.

[Means to solve the problem]

The document data management method in the application software of the present invention reduces the size of the document data using a data compression function in processing the document data on the main storage device, and stores one page of document data in the memory on the main storage device. When editing a document, the data of the row to be edited is expanded, and the other rows are kept compressed. It is constructed by performing input/output processing of document data on a page-by-page basis.

〔Example〕

Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of an embodiment of the present invention.

The main processing unit 11 compresses and compresses line data in response to edit line change requests and edit page change requests that occur during document editing.
Instructs expansion processing and page data read/write processing.

The page data input/output processing unit 12 performs the process of writing one page of compressed page data (this is called a compression buffer 41) to the document file 16 in the auxiliary storage device 15, and the process of reading the compressed buffer from the document file. .

The line data input/output processing unit 13 extracts compressed line data from a compression buffer read into the memory in the main storage device, performs data decompression (this is called expansion), and processes the decompressed line data. Data (this is called expanded row data) is compressed and stored in a compression buffer.

The line data editing processing unit 14 performs editing processing of expanded line data.

FIGS. 2 and 3 are diagrams showing the relationship between document data management and apparatus of the present invention. The process of displaying document data on the CRT device 21, the process of editing the document data based on data input from the keyboard device 22, and the process of printing document data on the printer device 23 all refer to the expanded line data 27. Alternatively, since it is updated, there is no need to be aware of the compressed multiple row data 27A.

The data in the compression buffer 26 will now be explained.

FIG. 4 shows the structure of data within the compression buffer 26. The compression buffer 41 is composed of a header 411, line data 412, and a stopper 413. The header 411 contains 0-line data 412, which is a fixed-length area in which management information such as the overall length of the compression buffer is stored.
The compressed data for each row within a page is stored in ascending order of row number. However, a blank line (a line with only blank characters and no attributes or rivers added) has no line data, and the stopper 413 is a fixed value for recognizing the end of the compression buffer.

The row data 42 is the same as the row data 412, and 1
This is compressed document data for lines. Line number 421 is
The total length of the 0-line data 422, which indicates which line the line data is, is the data length of the line data 42, the character data length 423 is the data length of the character data section 425, and the attribute data length 424 is the attribute data. The data length of the (color, ruled line, etc. data) section 426 is stored respectively.

The character data section 43 is the same as the character data section 425, and stores one line of compressed character data. Compressed data is made up of compression units called items. There are two types of items. The first type is a type that sets data for a specified length from a specified digit position,
This item means to cent the character string 433 from the 1-digit position 431 to the data length 432. The second type is a type that repeats data a specified number of times from a specified digit position, and is an item that repeatedly sets characters 437 for a repetition number of 436 from a digit position 434. The type of item is determined by whether a repeating identifier (fixed value 0) 435 is present. The attribute data section 44 is the same as the attribute data section 426, and stores one row of compressed attribute data.

Its internal structure is similar to that of the character data section 43.

FIG. 5 shows the contents of the attribute data section 44. Attribute data is expressed in one byte per digit. If no attribute is set, the value is 80H (green only (this is called a normal attribute)).

FIG. 6 is an example of processing for compressing one line of character data. 61 is expanded character data, blank character (20M)
is expressed as Δ°''. The compression process is divided into the following two stages.

The first step is to remove blank characters before and after the data (in the case of attributes, normal attributes) from the data.

If the first company name section is a blank character and is a normal attribute, it is determined that it is a blank line and the compression process is interrupted. Also, if the character data is either all blank characters or all the attribute data is normal attributes, the character data length 423
Alternatively, 0 is stored in the attribute data' length 424, and the character data section 425 or attribute data section 426 disappears. As a result of this compression step, one line of character data or attribute data becomes one compressed item.

The second step is to select three or more consecutive blank characters (or normal attributes) in the data for this item.
are removed from the data, and characters (or attributes) that repeat five or more times at the same time are further divided into items. Through this two-stage compression process, one line of data is represented by several items, such as a character data section 43 and an attribute data section 44.

Figure 7 shows how to retrieve the specified line in the compressed buffer when extracting the line data of the specified line number from the compressed buffer, or when replacing the line data updated by document editing processing with the line data of the same line in the compressed buffer. This figure shows the process of searching for the start address of row data. A row number 721 and a row data length 722 are stored at the beginning of each row data 72, and the row data is stored in ascending order of row numbers, so if the specified row number and compression bar are
The line numbers 721 in the sofa are compared, and if they are the same, that becomes the start address of the line data, and if the specified line number is smaller, it is known that the specified line is a blank line. If the designated row number is larger, the row data length 722 is added and compared with the next row number at the address. If it is the stopper 73, the designated line will be a blank line.

8 and 9 show input/output processing performed by the line data input/output processing unit 13, that is, line data is extracted from the compression buffer,
FIG. 8 is a flowchart of a process for decompressing data, and FIG. 9 is a flowchart of a process for compressing expanded row data and storing it in a compression buffer.

The procedure for extracting and decompressing row data will be explained with reference to FIG.

The input information for this process is the line number and the expanded data cutting edge address of the character part and attribute part. At step 81, data output of the character section and attribute section is initialized. This initialization means clearing the character part data output destination with a blank character (2On) and clearing the attribute part data output destination with a normal attribute (80H). Next, in step 82, the line data of the specified number is searched within the compression buffer. In step 83, it is determined whether there is line data with the specified line number, and if there is line data, the compressed data of the character part is decompressed and output to the character part data output destination. , the compressed data of the attribute section is expanded and outputted to the attribute section data output destination (step 84). If there is no row data, the process ends immediately.

Next, the processing procedure for compressing and storing expanded row data will be explained with reference to FIG.

The input information for this process is the line number and the address of the expanded form data of the character part/attribute part. Step 9
In step 1, compress the expanded data of the character part and attribute part (Example of compressing the character part in Figure 6), create line data based on this (see line data 42 in Figure 4), and create the new data.
Find the row data length. Here, as a result of the compression process, both the character part data length and the attribute part data length are O
In this case, no row data is created, and the new row data length is set to 0.Next, in step 92, search for the specified row data in the compression buffer, and calculate its length (old row data length). demand. Here, if there is no row data, the old row data length is set to O.

In step 93, the old line data length and new line data length are compared. If the old line data length is longer,
Step 94 moves the line data after the specified line number in the compression buffer forward by the amount by which the line data length has been decreased, and the process moves to step 98.

If the new and old row data lengths are the same, the process directly advances to step 98. If the new row data length is longer, compare whether the free memory area for the compression buffer is greater than the increase in the row data length (step 95), and if it is larger than the specified row number in the compression buffer. The subsequent row data is moved backward by the increase in row data length (step 96), and the process moves to step 98. If there is less memory, an insufficient memory error is displayed (step 97), and the process ends. In this case, no storage processing is performed.

In step 98, the new row data is transferred to the compression buffer (nothing is done if the new row data length is 0), the compression buffer length is updated, and the process ends.

Through the document data management processing described above, the document data is reduced in size, and one part of the document data is stored in the memory of the main storage device.
Since pages are held, input/output processing of document data to and from the document file can be performed on a page-by-page basis.

〔Effect of the invention〕

As explained above, according to the present invention, document data is reduced in size through two-stage data compression processing to remove unnecessary parts and duplicate parts in the document data. This reduction in document data has the effect of increasing the number of documents that can be registered in the auxiliary storage device.

Furthermore, since file input/output processing is performed on a page-by-page basis, there is no need to perform file input/output processing during editing work within a page of a document, which has the effect of simplifying and speeding up document editing processing.

Figure 7 is an explanatory diagram showing the process of searching the start address of line data in the compressed buffer, Figure 8 is a flowchart of the process of extracting line data from the compressed buffer, and Figure 9 is a flowchart of the process of extracting line data from the compressed buffer. FIG.

Main processing unit 11, page data input/output processing unit 12, line data input/output processing unit 13, line data editing processing unit 14, auxiliary storage device 15, document file 16, main storage device 17°

Claims (1)

[Claims] When processing document data on the main storage device, the data compression function is used to reduce the size of the document data, hold one page of document data in the memory on the main storage device, and when editing the document, expand the data of the line to be edited. The other rows manage the document data while keeping the data compressed, and input/output processing of the document data between the document file on the auxiliary storage device and the memory on the main storage device is performed on a page-by-page basis. A method for managing document data in application software, characterized in that: