JP5080325B2 - Information processing apparatus, information processing method, information processing program, and recording medium - Google Patents

Description

  The present invention relates to an information processing apparatus, an information processing method, an information processing program, and a recording medium that access a document shared on a network.

  Many documents generally have multiple pages. Users who use these documents generally do not read all the pages at once, but typically only read the specific parts of interest. Against this background, there are structured documents that can support multi-pages such as Adobe's PDF (Portable Document Format) in order to support the digitization of documents consisting of multiple pages such as standard books, manuals, and teaching materials. It has been developed (for example, see Non-Patent Document 1).

  The structure of such a structured document generally has several layout objects, and the layout object has at most one mask, and the foreground or background is selectively rendered according to the value of this mask. As a result, the structured document achieves higher image quality and higher compression rate than the unstructured document. As a similar technique, a coding method of a binary image is applied to a mask, and a structured document is formed by coding the foreground and background according to the coding method shown in Non-Patent Document 2. Have been developed (Non-Patent Documents 3 to 8).

  By the way, by sharing an electronic document in a network environment, information included in the electronic document is uniformly provided to a plurality of users. In such an environment, each user can share and read one shared electronic document. When browsing a shared electronic document, it is developed after being downloaded to a local PC (Personal Computer) using FTP (File Transfer Protocol).

  However, in a structured document such as PDF, even if the document required by the user is one page, it is necessary to download the entire electronic document, so the time required for downloading and the load on the network become problems. In addition, when the amount of memory available on the client where the electronic document is browsed is smaller than the data amount of the entire electronic document, the electronic document cannot be expanded, and thus a page required by the user is browsed. There is a problem that can not be.

  Regarding the above problem, conventionally, a technique has been proposed in which a composite file composed of a plurality of files is combined with a file of a page specified by the user to generate a new composite file and send it to the user. (For example, refer to Patent Document 1). As for the generation of a composite file, a technique has been proposed in which files related to a specific keyword are searched from individually stored file groups and the corresponding file groups are combined into one file (for example, Patent Document 2). reference).

PDF Reference fifty edition Adobe Portable Document Format Version 1.6 Adobe System Incorporated WGIN 2750 "Information Technology-JPEG2000 Image Coding System-Part1 FDIS, 18 AUGUST 2000 WG1N2813 "Information Technology-JPEG2000 Image Coding System-Part6: CompoundImage File Format" JPEG2000 Part6 FDIS, 9 DECEMBER2002 “Information Technology-JPEG2000 Image Coding System-Part 9: Interactivity Tools, APIs and protocols 2004-03-30 ITU-T Recommendation T. 4, Standardization of Group 3 facsimile terminals for document transmission ITU-T Recommendation T. 6, Facsimile coding schemes and coding control functions for group 4 facsimile appratus ISO / IEC JTC1 / SC29 N4974 Final Text Of ISO / IEC 15444-2: 2002: Information Technology-JPEG 2000 image coding system: Extensions [SC29 / WG1 N2679 UST ISO / IEC JTC1 / SC29 N2250 Motion JPEG2000 Final Draft International Standard, 17 September 2001 JP 2005-223391 A JP 2003-114814 A

  By the way, in the conventional structured document, one or a plurality of code streams are held as elements constituting one file, and therefore when extracting a specific resolution or a partial area of a specific page from a plurality of pages. Needs to be divided in units of code streams. However, the techniques described in Patent Documents 1 and 2 do not describe anything about the method and cannot be applied. In particular, even if each file described in Patent Document 2 is configured to be stored individually, each document is stored as a file divided into chapters or sections. You cannot divide by page. Further, when the data is stored individually in units of pages, it is necessary to create files for the number of pages. For example, in the case of a document of 1000 pages, it is necessary to create 1000 files in advance, so the burden on file management is large and not realistic.

  The present invention has been made in view of the above, and an information processing apparatus capable of efficiently accessing only a specific code stream among code streams of structured documents shared on a network, An object is to provide an information processing method, an information processing program, and a recording medium.

  In order to solve the above-described problems and achieve the object, the invention according to claim 1 includes at least a code stream and management information indicating a storage position of each code stream. In an information processing apparatus that accesses an external storage device that stores a structured document stored in a predetermined structure via a network, a first acquisition unit that acquires the management information from the structured document; Out of the storage positions indicated by the management information acquired by the acquisition means, receiving means for receiving designation of the storage position of the code stream to be acquired, and second acquisition for acquiring the code stream from the storage position of the specified code stream Means, management information acquired by the first acquisition means, and code stream acquired by the second acquisition means Storage control means for storing the data in the storage means in a structure corresponding to the structured document, and storage of each code stream in the management information in the storage means corresponding to each code stream stored in the storage means Storage position updating means for overwriting the position.

  According to a second aspect of the present invention, in the first aspect of the invention, the storage control means stores the code stream acquired by the second acquisition means in the order in which the code streams stored in the structured document are stored. Are stored in the storage means in the order according to the above.

  According to a third aspect of the present invention, in the first aspect of the invention, the storage control unit stores the code stream acquired by the second acquisition unit in the storage unit in the order in which the code stream is acquired. It is characterized by storing.

  The invention according to claim 4 is the invention according to claim 1, wherein the management information starts from a unique position in the structured document, and an offset from the start point to a position where each code stream is stored. And the length are held as the storage position.

  The invention according to claim 5 is the invention according to claim 4, wherein the second acquisition unit is separated from the starting point of the structured document by an offset and a length corresponding to a storage position of the code stream. The code stream stored at a position is acquired.

The invention according to claim 6 is the invention according to claim 1 or 2 , further comprising a deletion unit that deletes a gap between code streams stored in the storage unit, wherein the storage location update unit is the deletion unit. The storage position of each code stream after the gap is deleted by the means is overwritten on the management information corresponding to each code stream stored in the storage means.

  The invention according to claim 7 is the invention according to claim 1, further comprising decompression means for decompressing each code stream stored in the storage means.

  The invention according to claim 8 is the invention according to claim 1, wherein the accepting unit accepts designation of a storage location of the code stream in units of pages of the structured document.

  The invention according to claim 9 is the invention according to claim 1, wherein the structured document is a file conforming to ISO 15444-1.

  The invention according to claim 10 is the invention according to claim 1, characterized in that the structured document is a file conforming to ISO 15444-2.

  The invention according to claim 11 is the invention according to claim 1, wherein the structured document is a file conforming to ISO 15444-4.

  The invention according to claim 12 is the invention according to claim 1, wherein the structured document is a file conforming to ISO 15444-6.

  The invention according to claim 13 is the invention according to any one of claims 9 to 12, wherein the first acquisition means and the second acquisition means use JPIP defined in ISO 15444-9 as a communication protocol. It is characterized by using.

  The invention according to claim 14 is the invention according to claim 1, wherein the structured document is a file conforming to a specification of a portable document format.

  The invention according to claim 15 is the invention according to claim 1, characterized in that the structured document is a file conforming to the specification of the Multi Page Tagged Image File.

  According to a sixteenth aspect of the present invention, there is provided a structured document including at least a code stream and management information indicating a storage position of each code stream, the code stream and the management information being stored in a predetermined structure. An information processing method executed by an information processing apparatus that accesses an external storage device to be stored via a network, wherein a first acquisition unit acquires the management information from the structured document; An accepting step for accepting designation of a storage location of a code stream to be acquired out of the storage locations indicated by the management information obtained in the first obtaining step, and a second obtaining device comprising the designated code stream A second acquisition step of acquiring the code stream from the storage position of the storage, and a storage control means acquired in the first acquisition step. A storage control step for storing the management information and the code storm acquired in the second acquisition step in a storage unit in a structure corresponding to the structured document, and a storage location update unit stored in the storage unit. And a storage location update step of overwriting the storage location of each code stream in the management information in the storage means corresponding to each code stream.

  According to a seventeenth aspect of the present invention, there is provided a structured document including at least a code stream and management information indicating a storage position of each code stream, wherein the code stream and the management information are stored in a predetermined structure. A computer that accesses a storage external storage device via a network, a first acquisition unit that acquires the management information from the structured document, and a storage location indicated by the management information acquired by the first acquisition unit Receiving means for receiving designation of the storage location of the code stream to be acquired, second acquisition means for acquiring the code stream from the storage location of the designated code stream, and management information acquired by the first acquisition means And a code storm acquired by the second acquisition means in a structure corresponding to the structured document Storage control means for storing, and storage position update means for overwriting the storage position of each code stream in the management information in the storage means corresponding to each code stream stored in the storage means It is characterized by.

  The invention according to claim 18 is characterized in that the information processing program according to claim 17 is recorded.

  According to the present invention, management information indicating the storage position of each code stream that is an element of the structured document is acquired from the structured document existing on the network, and based on the storage position indicated in the management information. Thus, only the code stream stored in the specific storage position is acquired. As a result, the amount of data flowing through the network can be reduced, and the amount of memory required for holding structured documents can also be reduced, so that access can be made efficiently. In addition, since the acquired management information and code stream are stored in the storage unit in a structure corresponding to the structured document, and the reference relationship between the management information and the code stream is updated, compatibility with the original structured document is maintained. And a specific code stream is extracted from the original structured document.

  Exemplary embodiments of an information processing apparatus, an information processing method, and an information processing program according to the present invention are explained in detail below with reference to the accompanying drawings. In the following embodiment, an example in which the information processing apparatus of the present invention is applied to a file conversion apparatus such as a PC (Personal Computer), a browsing apparatus, a copier, a printer, a facsimile, or the like is shown. However, the present invention can be applied to other devices that can access documents shared on the network.

[First Embodiment]
FIG. 1 is a diagram showing a configuration of a document sharing system including a file conversion apparatus 200 according to the present invention. As shown in the figure, the document sharing system includes a document sharing server 100 that provides each device connected to the network N so that a JPM file (to be described later) can be shared, a file conversion apparatus 200 that accesses the JPM file, It has a browsing device 300 and a printing device 400. Hereinafter, the file conversion apparatus 200, the browsing apparatus 300, and the printing apparatus 400 are collectively referred to as a client. Note that the numbers of the document sharing server 100, the file conversion apparatus 200, the browsing apparatus 300, and the printing apparatus 400 connected to the network N are not limited to the mode illustrated in FIG.

  In FIG. 1, a document sharing server 100 and a client are connected via a network N, and transmit and receive various data. As a communication protocol for data communication via the network N, JPIP (JPEG2000 Interactivity Tools, APIs and Protocols) defined by the international standard ISO 15444-9 is used. However, the present invention is not limited to this. Another communication protocol may be used as long as it is a communication protocol capable of individually accessing only pages.

  FIG. 2 is a diagram illustrating a hardware configuration of the document sharing server 100. As shown in the figure, the document sharing server 100 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, and input devices such as a mouse and a keyboard. Control unit 14, a display unit 15 including a display device such as a liquid crystal monitor, a storage unit 16 such as an HDD (Hard Disk Drive), and an external device (such as a file conversion device 200) are controlled. A communication I / F unit 17, a scanner unit 18 that reads a document, and a bus 19 that connects these units are provided, and has a hardware configuration using a normal computer. Various programs and various data are stored in the ROM 12 and the storage unit 16. The CPU 11 loads the various programs stored in the ROM 12 and the storage unit 16 to the RAM 13 and executes them, thereby controlling the entire document sharing server 100 and realizing various functional units described later.

  Further, the document image read by the scanner unit 18 is stored (accumulated) in the storage unit 16 as a structured document encoded by the compression / encoding unit 112 described later in a file format for a structured document. Yes. Here, a structured document is a general document in which constituent elements such as a character part composed of characters and a picture part composed of pictures are mixed, and these constituent elements are regarded as objects, and the foreground, the background, and the foreground and the background. Are composed of a plurality of code streams having a mask for switching between the two.

  In the present embodiment, it is assumed that the JPEG2000 encoding method (see Non-Patent Documents 2 to 8) is used as the encoding method for structured documents. In the JPEG2000 encoding method (hereinafter simply referred to as “JPEG2000”), the conventional JPEG uses a discrete cosine transform, whereas the discrete wavelet transform is used so that the compression is about twice that of JPEG without causing block distortion. The effect is realized.

  Various specifications are defined in JPEG2000. For example, Part2 (ISO15444-2) of JPEG2000 that includes an encoding option of ROI (region of interest), Part3 (ISO15444-3) of JPEG2000, which is a moving image standard, and a picture JPEG2000 Part 6 (ISO 15444-6), which is a standard specialized for composite images including different characteristics such as text and characters, exists.

  Hereinafter, Part 6 of JPEG2000 will be described. Part 6 of JPEG2000 is a standard specialized for composite images including different characteristics such as pictures and characters, and is defined by the international standard ISO15444-615444-6. The file extension of JPEG2000 data defined in Part 6 of JPEG2000 is “JPM”. Hereinafter, a structured document encoded with Part 6 of JPEG 2000 is referred to as a “JPM file”. The JPM file provided by the document sharing server 100 is referred to as “original JPM file”. The JPM file has a plurality of boxes (Boxes) for composing a document, and each page constituting the JPM file is represented by a hierarchical relationship of contents defined by these boxes and an inclusion relationship.

  FIG. 3 is a diagram schematically showing the data structure of the JPM file. As shown in the figure, the JPM file stores a header portion in which various information (management information) for managing the JPM file is stored, and various code streams included in each page of the JPM file. The data section is roughly divided.

In the header part, the following three fields (not shown) are stored in the metadata.
1. Magic number Signature Field
3. Type Field

  Here, “magic number” describes identification information unique to this JPM file. In “Signature Field”, information indicating that this JPM file is a file dependent on JPEG2000 is described. In “Type Field”, information indicating the file type, version, compatibility, and the like is described. These three fields are defined to be stored in the head portion of the JPM file in this order.

  In the header data located after the metadata, compound header data, a page collection box, and a page box are stored. In the compound header data, information indicating that the JPM file is a structured document is described. In the page collection box, information for managing each page included in the JPM file is described, and is associated with a page box for designating each page. In JPM, references are made in the order of “File → Page Collection → Page → Layout Object → Object → Code Stream”, but in the following, for simplification of explanation, “File → Page Collection → Page → Code Stream” The operation will be described assuming that reference is made in order. In the example of FIG. 3, “page box 0” and “page box 1” are shown as page boxes, but this corresponds to two pages corresponding to “page box 0” and “page box 1”. This means that a JPM file is composed of these files. Hereinafter, the pages corresponding to “page box 0” and “page box 1” are represented as “page 0” and “page 1”, respectively.

  In each page box, an object box (Object Box) (not shown) is prepared for each object as an element of the corresponding page. Each object box describes information (offset and length) for indicating the position of the code stream representing the corresponding object, and the code stream is read based on the position indicated by the offset and the length. It is supposed to be. Here, the “offset” is information indicating a distance from a position uniquely determined in the JPM file to the head position of each code stream. The “length” is information indicating the data length from the beginning to the end of each code stream. It is assumed that the offset and length for each code stream are written in the object boxes included in the corresponding page boxes at the time of compression / encoding by JPEG2000.

  In the example of FIG. 3, the object box 0 included in “page box 0” is “offset 0” indicating the storage position of “code stream 0”, and the object box 1 is “offset” indicating the storage position of “code stream 1”. By describing “1”, “code stream 0” and “code stream 1” can be referred to as elements of page 0 (see the broken line in the figure). Similarly, the object box 2 included in “page box 1” can describe “code stream 2” as an element of page 1 by describing “offset 2”. In this way, each page box can access a code stream that is an element of the corresponding page.

  In the JPM file specified by Part 6 of JPEG 2000, it is also possible to refer to the place holder ID given in units of boxes, instead of specifying the storage position by the offset described above. Further, the order in which the code streams are stored may be arbitrary, and it is defined that the code stream functions as a standard compatible JPM file even if the order of appearance varies.

  FIG. 4 is a view showing a display example of the JPM file shown in FIG. In FIG. 4, “page 0” and “page 1” shown on the left side are pages corresponding to “page box 0” and “page box 1”, respectively, and a JPM file is composed of these two pages. . Here, the right side indicates that “page 0” is composed of “code stream 0” and “code stream 1”, and “page 1” is composed of “code stream 2”. Represents that. Note that the size (reduction ratio) and layout position (X, Y) of the image represented by each code stream are determined by layout object header data (Layout Object Header Box) (not shown) prepared for each page box corresponding to each code stream. ).

  FIG. 5 is a diagram showing a functional configuration of the document sharing server 100. The document sharing server 100 includes a document reading unit 111, a compression / encoding unit 112, and an access request receiving unit 113 as functional units realized by the cooperation of the CPU 11 and various programs stored in the ROM 12 or the storage unit 16. A code data reading unit 114.

  The document reading unit 111 controls the scanner unit 18 to sequentially read the document placed on the scanner as image data.

  The compression / encoding unit 112 generates a JPM file having the data structure shown in FIG. 3 by encoding the image data read by the document reading unit 111 with JPEG 2000, and stores the JPM file in the storage unit 16. Remember me. In the present embodiment, the image data to be encoded is the image data read by the document reading unit 111, but is not limited thereto, and is image data input via the communication I / F unit 17. Even if there is, it can be handled in the same way.

  The access request accepting unit 113 accepts various access requests transmitted from an external device (such as the file conversion device 200) via the communication I / F unit 17, and the code data reading unit 114 responds to these various access requests later. The response information copied to the transmission buffer is transmitted to the transmission source external device via the communication I / F unit 17.

  The access request receiving unit 113 registers the transmitted content in a cache area (not shown) secured in the RAM 13 or the storage unit 16. Further, the access request receiving unit 113 determines the degree of overlap between the request content received from the external device and the registered content registered in the cache area, and causes the code data reading unit 114 to read a portion where there is no overlap. On the other hand, if the requested content is within the range registered in the cache area, the instruction information indicating that the request has already been transmitted is transmitted to the external device as the transmission source. In this way, with respect to data that has already been transmitted, redundant traffic on the network can be limited by inhibiting the transmission of the data. The contents registered in the cache area are preferably cleared at a predetermined timing such as after a predetermined time has elapsed or after disconnecting from the external device.

  The code data reading unit 114 reads various information from the JPM file stored in the storage unit 16 in response to the various access requests received by the access request receiving unit 113, and these are secured in the RAM 13 as response information. Copy to send buffer.

  Specifically, when an access request regarding metadata for a specific JPM file is input from the access request receiving unit 113, the code data reading unit 114 reads the metadata from the specified JPM file, and as response information for this request. Copy to send buffer.

  In addition, when an access request regarding header data is input for a specific JPM file from the access request receiving unit 113, the code data reading unit 114 reads the header data from the designated JPM file, and transmits the transmission data as response information to the request. Copy to.

  When the access request regarding the code stream is input from the access request receiving unit 113, the code data reading unit 114 reads response information for the access request from the JPM file for the requested code stream, and sends it to the access request receiving unit 113. Output. Here, it is assumed that the access request related to the code stream includes an offset and length or a place holder ID, and the code stream is read from a specific JPM file based on such information.

  Next, the file conversion apparatus 200 that accesses the document sharing server 100 will be described. The file conversion apparatus 200 is an information processing apparatus that acquires some or all pages of a JPM file provided by the document sharing server 100 and holds the pages locally. The browsing device 300 and the printing device 400 shown in FIG. 1 will be described later.

  FIG. 6 is a diagram illustrating a hardware configuration of the file conversion apparatus 200. As shown in the figure, the file conversion apparatus 200 includes a CPU 21, a ROM 22, a RAM 23, a storage unit 26 such as an HDD, a communication I / F unit 27 that controls communication with an external device (such as the document sharing server 100), and A bus 28 for connecting them, an operation unit 24 constituted by an input device such as a mouse or a keyboard in some cases, a display unit 25 constituted by a display device such as a liquid crystal monitor, and a hardware configuration using a normal computer I have. Various programs and various data are stored in the ROM 22 or the storage unit 26. The CPU 21 loads the various programs stored in the ROM 22 and the storage unit 26 to the RAM 23 and executes them, thereby controlling the entire file conversion apparatus 200 and realizing various functions to be described later.

  Next, with reference to FIGS. 7 and 8, functions unique to the present embodiment that are realized in the file conversion apparatus 200 when the CPU 21 of the file conversion apparatus 200 executes various programs will be described. FIG. 7 is a diagram illustrating a functional configuration of the file conversion apparatus 200. The file conversion apparatus 200 includes a control unit 211, a metadata access unit 212, a header data access unit 213, and a code as functional units realized by cooperation of the CPU 21 and various programs stored in the ROM 22 or the storage unit 26. A stream access unit 214, a code stream storage unit 215, and an offset writing unit 216 are provided.

  FIG. 8 is a diagram showing the relationship between each means described in the claims and each functional unit described above. As shown in the figure, the control unit 211 corresponds to the reception unit, the metadata access unit 212 and the header data access unit 213 correspond to the first acquisition unit, and the code stream access unit 214 corresponds to the second acquisition unit. The code stream storage unit 215 corresponds to the storage control unit, and the offset writing unit 216 corresponds to the storage position update unit. The document sharing server 100 corresponds to an external storage device, and the RAM 13 or the storage unit 16 corresponds to a storage unit. The decompressing unit corresponds to the decompressing unit 311 described later, the deleting unit corresponds to the code stream storage unit 511 described later, and the drawing device corresponds to the display unit 25 or the printing device 400.

  The control unit 211 controls the overall operation of the file conversion apparatus 200. Specifically, the control unit 211 receives various instruction information input from the user via the operation unit 24, and controls each unit according to the content of the instruction. The control unit 211 also displays on the display unit 25 a support screen (GUI: Graphical User Interface) for selecting a JPM file provided by the document sharing server 100, a support screen for specifying a page box in the JPM file, and the like. indicate. Here, the JPM file is specified by a server name, a URI (Uniform Resource Identifier), a directory path, or the like.

  The metadata access unit 212 transmits information requesting reading of metadata included in a specific JPM file to the document sharing server 100 via the communication I / F unit 27, so that the meta data corresponding to the request content is transmitted. Data is acquired from the document sharing server 100. Further, the metadata access unit 212 stores the acquired metadata in a predetermined area prepared in advance in the RAM 23 or the storage unit 26. Hereinafter, this area is referred to as a “memory area”.

  The header data access unit 213 obtains header data from the JPM file by accessing the specific JPM file stored in the storage unit 16 of the document sharing server 100 via the communication I / F unit 27. Here, the box designation method includes the storage location of the JPM file in the document sharing server 100, the method of designating the ID of the box to be accessed (for example, page box 1), and the unique location on the file. This is realized by any one of the methods for specifying the offset and the length. Further, the header data access unit 213 stores the acquired header data in the memory area in a structure corresponding to the JPM file of the sharing source, that is, in a format according to JPEG2000. Specifically, it is stored in the subsequent stage of the metadata already stored in the memory area.

  The code stream access unit 214 obtains individual code streams from the JPM file by accessing the specific JPM file stored in the storage unit 16 of the document sharing server 100 via the communication I / F unit 27. Specifically, when the code stream access unit 214 receives the specification of a specific page box in the page box of the header data acquired by the header data access unit 213, the code stream access unit 214 sets the offset described in the object box included in the page box. Get the codestream separately from the length. Here, the method for accessing the code stream is realized by either a method for specifying the ID of a page box (for example, page box 1 or the like) corresponding to a specific page, or a method for directly specifying an offset and a length. The

  The code stream storage unit 215 stores the code stream acquired by the code stream access unit 214 in a memory area in a structure corresponding to the JPM file of the sharing source, that is, in a format according to JPEG2000. Specifically, a method of sequentially storing the header data or code stream already stored in the memory area in the subsequent stage or the same order as stored in the document sharing server can be used.

  The offset writing unit 216 calculates the offset and length of each code stream stored in the code stream storage unit 215 on the memory area, and the page box has a reference relationship with each code stream stored in the memory area. Overwrites the offset field of the object box included in.

  Specifically, the offset writing unit 216 uses the start address of the JPM file stored in the memory area as a reference, and the offset and length from this start address to the start address of each code stream are included in the corresponding page box. Overwrite an object box (not shown).

  Hereinafter, the operation of the file conversion apparatus 200 according to the present embodiment will be described. FIG. 9 is a flowchart showing a procedure of file sharing processing executed by the document sharing server 100 and the file conversion apparatus 200. Here, steps S11 to S22 indicate processing executed by the file conversion apparatus 200, and steps S31 to S37 indicate processing executed by the document sharing server 100.

  In the file conversion apparatus 200, the control unit 211 stands by until a specific JPM file is designated via the operation unit 24 from the JPM file group provided by the document sharing server 100 (step S11; No). Here, when the control unit 211 receives instruction information for specifying a specific JPM file (step S11; Yes), the metadata access unit 212 requests access to the metadata of the JPM file specified in step S11. Information is transmitted to the document sharing server 100 via the communication I / F unit 27 (step S12).

  On the other hand, in the document sharing server 100, the access request receiving unit 113 waits for access from the client (step S31; No), and when the access is confirmed (step S31; Yes), the request content transmitted from the client is stored in the cache area. It is compared whether or not the registered contents are included (step S32).

  If it is determined in step S32 that the access request content is included in the already cached registration content (step S33; No), information indicating that transmission has already been performed is transmitted to the client (not shown). Return to S31 again. As a result of step S32, when the access request receiving unit 113 determines that the request content includes unregistered content in the cache area (step S33; Yes), the code data reading unit 114 displays the request content from the client. Among them, unsent data is read from the designated JPM file and copied to the transmission buffer as response information (step S34).

  Subsequently, the access request reception unit 113 transmits the response information copied to the transmission buffer in step S34 to the file conversion apparatus 200 via the communication I / F unit 17 (step S35), and then the transmission is successful. Whether or not (step S36). Here, the determination of success or failure is made based on information (ACK (ACKnowledgement) or the like) indicating successful reception transmitted from the file conversion apparatus 200.

  If it is determined in step S36 that transmission has failed (step S36; No), the process returns to step S35, and the response information copied to the transmission buffer is transmitted again. It should be noted that the number of retransmittable times in the case of further failure is not particularly limited. However, when the limit number is reached, the process returns to step S31 again.

  If it is determined in step S36 that the transmission is successful (step S36; Yes), the access request reception unit 113 registers the transmission content transmitted in step S35 in the cache area (step S37), and returns to step S31. Return. Here, the contents registered in the cache area will be used for comparison with the requested contents received in step S31 in the future.

  On the other hand, in the file conversion apparatus 200, when the metadata access unit 212 acquires the metadata requested in step S14 from the document sharing server 100, the metadata is stored in the memory area (step S13).

  Next, the header data access unit 213 transmits information requesting access to the header data of the JPM file designated in step S11 to the document sharing server 100 via the communication I / F unit 27 (step S14). When the header data corresponding to this request is acquired from the document sharing server 100, the header data is stored in the subsequent stage of the metadata stored in the memory area (step S15). Note that the processing in the document sharing server 100 in response to the request for header data is the same as that in steps S31 to S37 described above, and thus description thereof is omitted.

  FIG. 10 is a diagram showing the state of the memory area at the end of the processing in step S15 and the state of the JPM file in the document sharing server 100. Here, the right figure shows the state (data structure) of the JPM file in the document sharing server 100, and the left figure shows the state of the metadata and header data of the JPM file stored in the memory area of the file conversion apparatus 200. .

  As shown in FIG. 10, the file conversion apparatus 200 has acquired information up to the header portion of the JPM file by the processing so far. Since the page configuration of the JPM file can be grasped from the page box included in the header data, the control unit 211 displays the page configuration of the JPM file on the display unit 25, and from this page configuration, the browsing target Support information that can specify the page to be provided is provided to the user.

  Returning to FIG. 9, the control unit 211 displays all pages constituting the JPM file on the display unit 25 based on the page collection box and the page box included in the header data stored in the memory area, and the operation unit It waits until a specific page is designated via 24 (step S16; No). Note that the number of pages specified in step S16 may be one or plural.

  In step S16, when the control unit 211 receives instruction information for designating a specific page (step S16; Yes), the code stream access unit 214 sets one page among the pages designated in step S16 as a processing target. Set (step S17).

  Next, the code stream access unit 214 refers to the page box corresponding to the processing target page from the page data stored in the memory area, and stores the page box at the position indicated by the offset described in the object box included in the page box. Information requesting access to the code stream is transmitted to the document sharing server 100 via the communication I / F unit 27 (step S18).

  Subsequently, when the code stream access unit 214 acquires the code stream requested to be accessed in step S18 from the document sharing server 100, the code stream access unit 214 stores the code stream in the subsequent stage of the code stream stored in the memory area (step S19). Note that the processing in the document sharing server 100 in response to the request for the code stream is the same as that in steps S31 to S37 described above, and thus description thereof is omitted.

  Here, the code storm storage location conforms to the provisions of JPEG2000. However, the code storm may be stored continuously from the end address of the code stream stored immediately before, or a predetermined size from the end address. It is good also as an aspect stored in the separated position. Note that, in the initial stage where the code stream is not stored, it is stored in the subsequent stage of the header data.

  The offset writing unit 216 calculates the offset and length from the top address of the metadata stored in the memory area in step S13 to the top address of the code stream stored in step S19, in the code stored in the memory area. The corresponding position on the object box of the page box that refers to the stream is overwritten (step S20).

  Subsequently, the code stream access unit 214 determines whether or not the processing of steps S18 to S20 has been performed for all the code streams constituting the processing target page, and determines that there is an unprocessed code stream. (Step S21; No), the process returns to Step S18 again, and information requesting an unprocessed code stream is transmitted to the document sharing server 100 via the communication I / F unit 27.

  If it is determined in step S21 that the processing in steps S18 to S20 has been performed for all code streams (step S21; Yes), the code stream access unit 214 further specifies all pages specified in step S16. Is determined as a processing target (step S22).

  If it is determined in step S22 that an unprocessed page exists (step S22; No), the process returns to step S17 to set the unprocessed page as a processing target. If it is determined that all the pages specified in step S16 are to be processed (step S22; Yes), this process ends.

  The operation of the file sharing process will be described below. 11 to 13 are diagrams showing the state of the JPM file stored in the memory area and the state of the JPM file in the document sharing server 100 that is the sharing source. Here, the right figure shows the state (data structure) of the JPM file in the document sharing server 100, and the left figure shows the state of the JPM file stored in the memory area. In the following description, it is assumed that “page box 0” and “page box 1” are designated by the user in step S16.

  First, in the first loop processing of steps S18 to S20, when “code stream 0” whose storage position is indicated in “object box 0 included in page box 0” is acquired by code stream access unit 214, code stream storage is performed. As shown in FIG. 11, the unit 215 stores this “code stream 0” in the subsequent stage of the header data in the memory area. At this time, in step S20, the offset writing unit 216 calculates the length from the top address of the metadata to the top address of “code stream 0” as the offset (offset 0 ′) of “code stream 0” in the memory area. Then, the corresponding position on the object box of the page box that refers to the code stream stored in the memory area is overwritten.

  Next, in the second loop processing of steps S18 to S20, when “code stream 1” whose storage position is indicated in “object box 0 included in page box 0” is acquired by code stream access unit 214, As shown in FIG. 12, the code stream storage unit 215 stores this “code stream 1” in the subsequent stage of “code stream 0” in the memory area. At this time, in step S20, the offset writing unit 216 calculates the length from the top address of the metadata to the top address of “code stream 1” as the offset (offset 1 ′) of “code stream 1” in the memory area. Then, the corresponding position on the object box of the page box that refers to the code stream stored in the memory area is overwritten.

  Next, in the loop processing of steps S17 to S22, when “code stream 2” whose storage position is indicated in “object box 2 included in page box 1” is acquired by code stream access unit 214, code stream storage is performed. As shown in FIG. 13, the unit 215 stores this “code stream 2” in the subsequent stage of “code stream 1” in the memory area. At this time, in step S20, the offset writing unit 216 calculates the length from the top address of the metadata to the top address of “code stream 2” as the offset (offset 2 ′) of “code stream 2” in the memory area. Then, the object box of the page box that references the code stream stored in the memory area is overwritten.

  11 to 12 illustrate the case where the code streams are acquired in the order of “page box 0” and “page box 1”, but the code streams are acquired in the order of “page box 1” and “page box 0”. In such a case, they are acquired from the document sharing server 100 in the order of “code stream 2”, “code stream 0”, and “code stream 1”. Therefore, as shown in FIG. 14, the code streams are stored in the memory area in the order corresponding to the code stream acquisition order.

  As described above, according to the present embodiment, an object box included in a page box indicating the storage position of each codestream that is an element of the JPM file is acquired from the JPM file existing on the network N, and this object box Only the code stream stored in the specific storage location is acquired based on the storage location indicated in (1). As a result, the amount of data flowing through the network N can be reduced, and the amount of memory required to hold the JPM file can also be reduced, so that access can be made efficiently. Further, in order to store various data acquired from the document sharing server 100 in a memory area with a structure corresponding to the JPM file and to update the reference relationship between the object box and the code stream included in the page box, Can be maintained, and only a specific page (code stream) is extracted from the original JPM file.

  In addition, although it demonstrated using the JPM file prescribed | regulated by JPEG2000 Part6 as a typical thing showing the position of each code stream by the offset and length from the unique position on a file, it is a file with the same specification. If it exists, it is good also as an aspect using another file format. For example, JPEG2000 Part1 file, JPEG2000 Part2 file, JPEG2000 Part3 file, PDF (Portable Document Format) file, Multi Page Tagged Image File Format file, etc. are mentioned. Since the position of the code stream is represented by an offset and a length from a unique position on the file, there is no essential difference in operation, so that the code stream can be handled in the same way as a JPM file.

  In the present embodiment, the mode in which the code stream is accessed based on the offset and the length described in the object box in the page box has been described. However, the mode in which the code stream is accessed using another method may be used. . For example, when sending a metadata bin (a collection of top-level boxes of a JPM file) from the document sharing server 100, a Place Holder ID may be assigned, and access may be made from the file conversion apparatus 200 based on the Place Holder ID. . In this case, a plurality of boxes in an inclusive relationship with one box can be sent with one metadata bin ID. As a result, the content corresponding to the place holder indicated by the metadata bin ID is requested to the document sharing server 100, and the obtained data is stored in the location indicated by the same ID as the place holder in the memory area of the file conversion apparatus 200. For details, please refer to A. of JPEG2000Part9. The explanation is omitted because it is in Section 3.6.3.

  In this embodiment, the code stream position is designated by the offset and length from the head position of the file. However, the present invention is not limited to this, and the code stream box name such as a code stream box name is uniquely determined. It is good also as a mode to designate.

  Further, in the present embodiment, the mode in which only specific partial codes are acquired from the same JPM file and a new JPM file is generated has been described. However, the present invention is not limited to this, and specific partial codes are obtained from each of a plurality of JPM files. It is good also as an aspect which acquires only and produces | generates a new JPM file. Here, “partial code” means a part of code in a code stream divided in units of resolution, image quality, color component, and area.

  Specifically, when storage locations of a plurality of JPM files are specified via the operation unit 24, the metadata access unit 212 and the header data access unit 213 receive management information (metadata) from each of the specified JPM files. Data and header data). Here, the JPM file specified via the operation unit 24 may be stored in its own device or stored in an external device connected via the network N. Also good.

  Further, when the partial code for each JPM file is designated from the management information, the code stream access unit 214 acquires the designated partial code from each JPM file. In this case, the storage position of the partial code covers a plurality of JPM files. However, as with the overwriting method in the object box described above, the offset and length up to the start address of each partial code in its own device are set. It is good also as a mode to hold | maintain, and it is good also as a mode which hold | maintains the offset and length to the head address of each partial code in the state which can refer to the original JPM file. Hereinafter, the file structure in the latter case will be described with reference to FIG.

  FIG. 15 is a diagram schematically illustrating an example of a file structure of a new JPM file (hereinafter referred to as a reference source JPM file) that refers to a plurality of JPM files (file X, file Y, etc.). In the figure, the reference source JPM file is composed of media data, a data reference table, and a fragment table. Here, the media data is data composed of a partial code group acquired from each of a plurality of JPM files. As will be described later, the storage position (offset and length) of each partial code is registered in the fragment table.

  In addition, the storage location of the JPM file (file X, file Y) referred to by the reference source JPM file is registered in the data reference table. Specifically, in this data reference table, the server name, URI (Uniform Resource Identifier), directory path, and the like of the server device that stores the JPM file specified via the operation unit 24 are registered. The numerical value “3” stored in the first cell of the data reference table means that there are three entries in the data reference table.

  The fragment table is data referred to by the above-described page box object box, and has a fragment list for storing data. In this fragment list, information (offset and length) of the header table of the header data of each JPM file that is the reference destination acquired by the header data access unit 213 is registered. Note that the fragment table information registered in the fragment list is held in association with the storage location of the JPM file corresponding to the fragment table information registered in the data reference table. Thus, by combining the information registered in the data reference table and the fragment list, it is possible to refer to an arbitrary partial code of the JPM file registered in the data reference table.

  Here, for generation of the reference source JPM file, the partial code acquired from each JPM file of the reference destination by the code stream access unit 214 has the storage position (offset and length) of these partial codes in the memory area. The offset writing unit 216 overwrites the corresponding element in the fragment list. The example of FIG. 15 indicates that the storage positions of the partial codes on the memory area are registered in the first, fourth, fifth, and seventh elements from the left constituting the fragment list. Also, the storage positions of the partial codes in the file X and the file Y are registered in the second and third elements, respectively, and the JPM file provided by the external device (such as the document sharing server 100) existing on the network N It shows that the storage position of the partial code in (not shown) is registered in the sixth element.

  In this way, only a desired partial code is acquired from a plurality of JPM files, and a new JPM file (reference source JPM file) is generated, whereby each JPM file that is a reference destination is acquired individually. Compared to the case, the amount of data flowing through the network N and the amount of memory required to hold a file can be suppressed, so that access can be performed efficiently.

  When a new partial code is acquired from the JPM file referred to by the reference source JPM file based on the data reference table and the fragment table of the reference source JPM file, the offset writing unit 216 calculates the partial code. It is assumed that the storage position in the memory area is overwritten on the fragment table (fragment list). In this example, the data reference table and the fragment table are individually provided. However, the present invention is not limited to this. For example, a single table in which both tables are integrated may be used.

  Next, as a modification of the above-described first embodiment, a browsing device 300 that browses JPM files to which the configuration of the file conversion device 200 is applied and a printing device 400 that prints JPM files will be described. In addition, the same code | symbol is provided about the element similar to the structure of the file converter 200 mentioned above, and description is abbreviate | omitted.

[Modification 1]
FIG. 16 is a diagram illustrating a functional configuration of the browsing apparatus 300 according to the first modification of the present embodiment. As shown in the figure, the browsing apparatus 300 includes a control unit 211, a metadata access unit 212, a header as functional units realized by the cooperation of the CPU 21 and various programs stored in the ROM 22 or the storage unit 26. A data access unit 213, a code stream access unit 214, a code stream storage unit 215, an offset writing unit 216, and an expansion unit 311 corresponding to an expansion unit. Note that the hardware configuration of the browsing device 300 is the same as that of the file conversion device 200, and thus the description thereof is omitted.

  The decompression unit 311 receives the code stream of the JPM file stored in the memory area and generates a bitmap file by performing decompression processing according to JPEG2000.

  Specifically, the decompression unit 311 decompresses the image represented by the code stream to a reduction ratio (Scale) defined by the layout object header data included in the page box corresponding to the code stream, and generates a bitmap image. Further, by expanding the generated bitmap image to the layout position (X, Y) defined by the layout object header data, the image corresponding to the code stream is arranged at a specified position in the page area. Here, the “page area” is an area for expanding each page of the JPM file secured in the RAM 23 or the storage unit 26. Note that a known technique is used for the decompression method in JPEG2000. In the present embodiment, a bitmap image is generated. However, an image according to another format may be generated.

  Hereinafter, the operation of the browsing apparatus 300 according to the first modification of the present embodiment will be described. FIG. 17 is a flowchart illustrating a procedure of file sharing processing executed by the document sharing server 100 and the browsing apparatus 300. Here, steps S41 to S54 indicate processing executed by the browsing apparatus 300, and steps S61 to S67 indicate processing executed by the document sharing server 100. In addition, since the process of step S41-S50 is the same as the process of step S11-S20 mentioned above, description is abbreviate | omitted. In the figure, the processes in steps S61 to S67 are the same as the processes in steps S31 to S37 described above, and thus the description thereof is omitted.

  In step S51, the decompression unit 311 generates a bitmap image from the code stream stored in the memory area in steps S49 and S50, and arranges it at a specified position in the page area (step S51). Next, the control unit 211 displays the bitmap image arranged in the page area on the display unit 25 (step S52).

  Subsequently, the code stream access unit 214 determines whether or not the processing of steps S48 to S52 has been performed for all the code streams constituting the processing target page, and determines that there is an unprocessed code stream. (Step S53; No), the process returns to Step S48 again, and information requesting an unprocessed code stream is transmitted to the document sharing server 100 via the communication I / F unit 27.

  If it is determined in step S53 that the processing in steps S48 to S52 has been performed for all code streams (step S53; Yes), the code stream access unit 214 further selects all pages specified in step S46. Is determined as a processing target (step S54).

  If it is determined in step S54 that an unprocessed page exists (step S54; No), the process returns to step S47 and an unprocessed page is set as a processing target. If it is determined that all the pages specified in step S46 are to be processed (step S54; Yes), this process is terminated.

  In this way, every time a data stream is stored in the memory area, a bitmap image represented by the code stream is sequentially generated and displayed on the display unit 25. This makes it possible to download and browse only the pages desired by the user from among the JPM files shared by the document sharing server 100.

  In the first modification, a bitmap image is generated every time a data stream is stored in a memory area. However, the present invention is not limited to this, and a code stream is stored for each specified page or all pages. Alternatively, the bitmap image may be generated after the image processing. Specifically, this can be realized by adopting a configuration in which the processes in steps S51 and S52 in FIG. 17 are performed in the subsequent stage of step S53 or the subsequent stage of step S54.

[Modification 2]
FIG. 18 is a block diagram illustrating a hardware configuration of a printing apparatus 400 according to the second modification of the present embodiment. As shown in the figure, the printing apparatus 400 includes a printing unit 29 that performs printing in addition to the hardware configuration of the file conversion apparatus 200 described above.

  Here, the printing unit 29 is provided with image forming means (not shown) such as a laser printer method or an ink jet method, and CMYK format image data input from a print control unit 411 described later is recorded on a recording medium such as printing paper. Print on top.

  FIG. 19 is a diagram illustrating a functional configuration of the printing apparatus 400. As shown in the figure, the printing apparatus 400 includes a control unit 211, a metadata access unit 212, and functional units realized by the cooperation of the CPU 21 and various programs stored in the ROM 22 or the storage unit 26. A header data access unit 213, a code stream access unit 214, a code stream storage unit 215, an offset writing unit 216, an expansion unit 311, and a print control unit 411 are provided.

  The print control unit 411 generates image data in CMYK format from the bitmap image arranged in the page area by the decompression unit 311 in units of pages, and outputs the data to the printing unit 29 to print each page constituting the JPM file. I do.

  Hereinafter, the operation of the printing apparatus 400 according to the second modification of the present embodiment will be described. FIG. 20 is a flowchart illustrating a procedure of file sharing processing executed by the document sharing server 100 and the printing apparatus 400. Here, steps S71 to S84 indicate processing executed by the printing apparatus 400, and steps S91 to S97 indicate processing executed by the document sharing server 100. In addition, since the process of step S71-S80 is the same as the process of step S11-S20 mentioned above, description is abbreviate | omitted. Also, in the same figure, the processing of steps S91 to S97 is the same as the processing of steps S31 to S37 described above, and therefore the description thereof is omitted.

  In step S81, the decompression unit 311 generates a bitmap image from the code stream stored in the memory area in steps S79 and S80, and arranges it at a specified position in the page area (step S81).

  Subsequently, the code stream access unit 214 determines whether or not the processing of steps S78 to S81 has been performed on all the code streams that constitute the processing target page, and determines that there is an unprocessed code stream. (Step S82; No), the process returns to Step S78 again, and information requesting an unprocessed code stream is transmitted to the document sharing server 100 via the communication I / F unit 27.

  If it is determined in step S82 that all the code streams have been processed in steps S78 to S81 (step S82; Yes), the print control unit 411 determines that the bits arranged in the page area in step S81. CMYK format image data is generated from the map image and output to the printing unit 29 to print one page constituting the JPM file (step S83).

  Subsequently, the code stream access unit 214 further determines whether or not all pages designated in step S76 have been processed (step S84). If it is determined in step S84 that an unprocessed page exists (step S84; No), the process returns to step S77 to set the unprocessed page as a processing target. If it is determined that all pages specified in step S76 are to be processed (step S84; Yes), the process is terminated.

  In this way, every time an image representing a data stream for one page is arranged in the page area, the printing unit 29 prints one page constituting the JPM file. This makes it possible to download and print only the pages desired by the user from among the JPM files provided by the document sharing server 100.

[Second Embodiment]
In the above-described first embodiment, the mode in which the code stream of the JPM file acquired from the document sharing server 100 is stored in the memory area in the access order has been described. In the second embodiment, a mode will be described in which a code stream is stored in a memory area with a configuration corresponding to the code stream storage order in the shared JPM file. In addition, about the component similar to 1st Embodiment, the same code | symbol is provided and description is abbreviate | omitted.

  FIG. 21 is a diagram showing a functional configuration of the file conversion apparatus 500 according to the present embodiment. As shown in the figure, the file conversion apparatus 500 includes a control unit 211, a metadata access unit 212, and a functional unit realized by cooperation of the CPU 21 and various programs stored in the ROM 22 or the storage unit 26. A header data access unit 213, a code stream access unit 214, a code stream storage unit 511, and an offset writing unit 512 are provided. Note that the hardware configuration of the file conversion apparatus 500 is the same as that of the file conversion apparatus 200, and thus the description thereof is omitted.

  The code stream storage unit 511 stores each code stream acquired by the code stream access unit 214 in the memory area in an order corresponding to the code stream storage order in the JPM file shared by the document sharing server 100.

  Here, as a method of storing the code stream in the original JPM file in the memory area in the order corresponding to the code stream storage order, various methods can be adopted. Specifically, the offset and length of the code stream acquired by the code stream access unit 214 are read from the object box included in the page box corresponding to the code stream stored in the memory area, and the offset and length are read. This can be realized by storing the acquired code stream in the storage position in the memory area according to the above (hereinafter referred to as the first method). The “storage position in the memory area according to the offset and length” means a position that is separated from the start address of the JPM file stored in the memory area by the offset from the start address of the metadata.

  As another method, the code stream storage position in the memory area may be determined based on the magnitude relationship of the offset described in the object box included in each page box. Specifically, since the offsets of the code streams written in the object box included in the page box are arranged in ascending order, it is possible to determine in what order the code stream is located. That is, when the code stream is stored, it is determined what order the code stream is positioned in the entire code stream, and the code stream is stored in the storage position in the memory area corresponding to the rank (hereinafter referred to as the code stream). The second method). In this case, the code stream may be stored at the position indicated by the offset described in the object box included in the page box. Alternatively, the code stream may be stored in the header data direction and stored every time the code stream is stored. In addition, the storage position may be dynamically moved according to the order.

  When the code stream is stored in the memory area based on the offset described in the object box included in the page box in the first method and the second method described above, only a part of the pages constituting the JPM file from the user Is specified, a blank area (gap) in which valid data does not exist may occur between code streams stored in the memory area. For example, in the case of the JPM file shown in FIG. 3, even if only “page box 1” is designated, an area for “page box 0” is secured in the memory area. In such a case, the amount of data transmitted from the document sharing server 100 can be reduced, but the JPM file in the memory area is substantially the same size as the original JPM file.

  Therefore, after storing all the code streams acquired by the code stream access unit 214 in the memory area, the code stream storage unit 511 moves the storage position of each code stream in the header data direction, and there is no valid data. By filling the blank area, it functions as a deletion means for deleting the gap between the code streams. Thereby, the JPM file stored in the memory area can be made compact.

  The offset writing unit 512 has the same function as the offset writing unit 216 described above. When the code stream storage unit 511 moves the storage position of the code stream stored in the memory area, The offset in the memory area of each code stream is calculated, and the offset value of the object box included in the page box corresponding to each code stream stored in the memory area is overwritten.

  Hereinafter, the operation of the file conversion apparatus 500 according to the present embodiment will be described. FIG. 22 is a flowchart showing a procedure of file sharing processing executed by the document sharing server 100 and the file conversion apparatus 500. Here, steps S101 to S114 indicate processing executed by the file conversion apparatus 500, and steps S121 to S127 indicate processing executed by the document sharing server 100. In addition, since the process of step S101-S108 is the same as the process of step S11-S18 mentioned above, description is abbreviate | omitted. In the figure, the processes in steps S121 to S127 are the same as the processes in steps S31 to S37 described above, and thus the description thereof is omitted.

  In this process, in step S109 described above, the code stream storage unit 511 sets the code stream acquired by the code stream access unit 214 to the storage position in the memory area according to the offset and length of the code stream. Store (step S109).

  Subsequently, the offset writing unit 216 stores the offset and length from the top address of the metadata stored in the memory area in step S109 to the top address of the code stream stored in step S19 in the memory area. The object box of the page box that refers to the code stream is overwritten (step S110). Note that this processing may be omitted when the offset and the length are stored in step S109.

  Subsequently, the code stream access unit 214 determines whether or not the processing of steps S108 to S110 has been performed on all the code streams that configure the processing target page, and determines that there is an unprocessed code stream. (Step S111; No), the process returns to Step S108 again, and information requesting an unprocessed code stream is transmitted to the document sharing server 100 via the communication I / F unit 27.

  If it is determined in step S111 that the processing in steps S108 to S110 has been performed for all code streams (step S111; Yes), the code stream access unit 214 further specifies all pages specified in step S106. Is determined as a processing target (step S112).

  If it is determined in step S112 that there is an unprocessed page (step S112; No), the process returns to step S107, and an unprocessed page is set as a processing target. If it is determined that all pages specified in step S106 are to be processed (step S112; Yes), the code stream storage unit 511 moves the code stream stored in the memory area in the header data direction, The gap between code streams is deleted (step S113).

  Subsequently, the offset writing unit 512 calculates the offset and length on the memory area of each code stream moved in step S113, and stores it in the page box corresponding to each code stream stored in the memory area. After overwriting each of the included object boxes (step S114), this process is terminated.

  As described above, according to the present embodiment, the object box included in the page box indicating the storage position of each codestream that is an element of the JPM file is acquired from the JPM file existing on the network N, and this object Based on the storage location indicated in the box, only the code stream stored in the specific storage location is obtained. As a result, the amount of data flowing through the network N can be reduced, and the amount of memory required to hold the JPM file can also be reduced, so that access can be made efficiently. Further, in order to store various data acquired from the document sharing server 100 in a memory area with a structure corresponding to the JPM file and to update the reference relationship between the object box and the code stream included in the page box, Can be maintained, and only a specific page (code stream) is extracted from the original JPM file.

  In addition, since the code streams are stored in the memory area in the order corresponding to the code stream storage order in the original JPM file, compatibility with the original JPM file can be further improved.

  In this embodiment, the gap between the code streams is deleted. However, the present invention is not limited to this, and the gap may be maintained in the memory area. In this embodiment, all code streams acquired by the code stream access unit 214 are stored in the memory area in the order corresponding to the storage order in the original JPM file. However, the present invention is not limited to this. Alternatively, it may be applied to only a part of the code streams. Also, the offset writing unit 512 may be applied to the configuration of the first embodiment described above.

[Example]
Hereinafter, examples using the file conversion apparatus (browsing apparatus) of the first and second embodiments will be described. FIG. 23 is a diagram schematically showing the structure of a JPM file provided by the document sharing server 100 in this embodiment. This JPM file is a compound document composed of four pages corresponding to the four seasons of spring, summer, autumn and winter.

  In FIG. 23, a “header part” corresponds to the header part shown in FIG. 3 and includes metadata, a page box, and the like. “Document thumbnail (four seasons)” is a code stream corresponding to the cover page of the JPM file, and represents a thumbnail image of the display page. “Page thumbnail (spring)” and “text (spring)” are code streams that are elements of one page of the JPM file, and “page thumbnail (spring)” represents a thumbnail image of this page. "Text (Spring)" represents the text of this page. Similarly, “page thumbnail (summer)”, “text (summer)”, “page thumbnail (autumn)”, “text (autumn)”, “page thumbnail (winter)”, “text (winter)” Are code streams representing thumbnail images and headquarters of each page.

  In the above configuration, it is assumed that the page thumbnail of each page can be referred to from “document thumbnail (four seasons)”. Also, it is possible to refer to the page box in the header corresponding to each page from each page thumbnail. That is, it is assumed that the corresponding text can be traced from each page thumbnail.

  24 and 25 are diagrams for explaining operations in the file conversion apparatus. In the file conversion apparatus, after acquiring the “header part” from the JPM file shared by the document sharing server 100 and then acquiring “document thumbnail (four seasons)”, the control unit 211 controls the display unit 25 to display “document thumbnail (four seasons)”. ) "Is displayed (see FIG. 24, left diagram). Next, when “document thumbnail (four seasons)” is designated by the user via the operation unit 24, the file conversion apparatus acquires each page thumbnail having a reference relationship with “document thumbnail (four seasons)” from the shared JPM file. Then, a list is displayed on the display unit 25 under the control of the control unit 211 (see FIG. 24, central view). Here, if “page thumbnail (summer)” is designated by the user via the operation unit 24, the file conversion apparatus refers to the “text (summer)” that has a reference relationship with “page thumbnail (summer)” from the shared JPM file. Is displayed on the display unit 25 under the control of the control unit 211 (see FIG. 24, right figure).

  After the above operation, the JPM file acquired from the document sharing server 100 is stored in the memory area of the file conversion apparatus 200 according to the first embodiment in the state shown in FIG. That is, the code streams are stored in the memory area in the order in which they are acquired. Needless to say, the offset value of the object box included in each page box is updated by the offset writing unit 216 according to the position where each code stream is stored.

  When “page thumbnail (spring)” is selected via the operation unit 24 after the display of “text (summer)” is closed (see FIG. 25, the left diagram and the central diagram), the file conversion apparatus From the shared JPM file, “text (spring)” having a reference relationship with “page thumbnail (spring)” is acquired and displayed on the display unit 25 under the control of the control unit 211 (see the right diagram in FIG. 25).

  After the above operation, the obtained JPM file is stored in the memory area in the state shown in FIG. 27 in the file conversion apparatus 200 according to the first embodiment. That is, the code streams are stored in the memory area in the order in which they are acquired. Needless to say, the offset value of the object box included in each page box is updated by the offset writing unit 216 according to the position where each code stream is stored.

  In the file conversion apparatus 500 according to the second embodiment, the acquired JPM file is stored in the memory area in the state shown in FIG. That is, the data is stored in the memory area in a structure corresponding to the code stream storage order in the original JPM file. In the figure, the state after the gap between the code streams is deleted is shown.

  Further, as shown in FIG. 29, the page thumbnails are stored in the order in which the page thumbnails are acquired in the subsequent stage of the header data, and the body texts are structured in accordance with the code stream storage order in the original JPM file in the subsequent stage. May be stored. That is, the function of the code stream storage unit 215 and the function of the code stream storage unit 511 may be used in combination. In this case, it may be properly used according to the data type represented by the code stream such as the thumbnail image or the text, or may be appropriately used according to the data size of the code stream, the structure of the structured document, or the like.

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Moreover, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined.

  For example, a program related to a document sharing process executed by each client (the file conversion apparatus 200, the browsing apparatus 300, the printing apparatus 400, and the file conversion apparatus 500 of the embodiment) is executed on a computer connected to a network such as the Internet. You may comprise so that it may provide by storing and downloading via a network. Further, the program relating to the document sharing process executed by each client may be provided or distributed via a network such as the Internet.

  Further, the program relating to the document sharing process executed by each client may be provided by being incorporated in advance in a storage medium such as a ROM.

  As described above, the information processing apparatus, the information processing method, the information processing program, and the recording medium according to the present invention are useful for an information processing apparatus that accesses a structured document shared on a network. It is suitable for an information processing apparatus that accesses a structured document consisting of

It is the block diagram which showed the structure of the document sharing system. It is the block diagram which showed the hardware constitutions of the document sharing server. It is the figure which showed the data structure of the JPM file typically. It is a figure for demonstrating the JPM file of FIG. It is the block diagram which showed the functional structure of the document sharing server. It is the block diagram which showed the hardware constitutions of the file conversion apparatus. It is the block diagram which showed the functional structure of the file conversion apparatus concerning 1st Embodiment. It is the figure which showed the relationship between each means and each function part. It is the flowchart which showed the procedure of the document sharing process concerning 1st Embodiment. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed typically an example of the file structure of a JPM file which refers to a some JPM file. It is the block diagram which showed the functional structure of the browsing apparatus concerning the modification 1 of 1st Embodiment. It is the flowchart which showed the procedure of the document sharing process in the modification 1 of 1st Embodiment. It is the block diagram which showed the hardware constitutions of the printing apparatus concerning the modification 2 of 1st Embodiment. It is the block diagram which showed the functional structure of the printing apparatus concerning the modification 2 of 1st Embodiment. 10 is a flowchart illustrating a procedure of document sharing processing according to a second modification of the first embodiment. It is the block diagram which showed the functional structure of the file conversion apparatus concerning 2nd Embodiment. It is the flowchart which showed the procedure of the document sharing process concerning 2nd Embodiment. It is the figure which showed the data structure of the JPM file typically. It is a figure for demonstrating operation with a file converter. It is a figure for demonstrating operation with a file converter. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file. It is the figure which showed the state of the JPM file.

Explanation of symbols

100 document sharing server 11 CPU
12 ROM
13 RAM
DESCRIPTION OF SYMBOLS 14 Operation part 15 Display part 16 Storage part 17 Communication I / F part 18 Scanner part 19 Bus 111 Document reading part 112 Compression / encoding part 113 Access request reception part 114 Code data reading part 200 File conversion apparatus 21 CPU
22 ROM
23 RAM
24 operation unit 25 display unit 26 storage unit 27 communication I / F unit 28 bus 29 printing unit 211 control unit 212 metadata access unit 213 header data access unit 214 code stream access unit 215 code stream storage unit 216 offset writing unit 300 browsing Device 311 Expansion unit 400 Printing device 411 Print control unit 500 File conversion device 511 Code stream storage unit 512 Offset writing unit

Claims (18)

The network includes at least a code stream and management information indicating the storage position of each code stream, and stores the structured document in which the code stream and the management information are stored in a predetermined structure via a network. In an information processing apparatus that performs access,
First acquisition means for acquiring the management information from the structured document;
A receiving unit that receives designation of a storage location of a code stream to be acquired among the storage locations indicated by the management information acquired by the first acquisition unit;
Second acquisition means for acquiring the code stream from the storage location of the specified code stream;
Storage control means for storing the management information acquired by the first acquisition means and the code stream acquired by the second acquisition means in a storage means in a structure corresponding to the structured document;
Storage position update means for overwriting the management information in the storage means corresponding to each code stream stored in the storage means with the storage position of each code stream;
An information processing apparatus comprising:   The storage control unit stores the code stream acquired by the second acquisition unit in the storage unit in an order corresponding to a storage order of the code streams stored in the structured document. The information processing apparatus according to 1.   The information processing apparatus according to claim 1, wherein the storage control unit stores the code stream acquired by the second acquisition unit in the storage unit in an order in which the code stream is acquired.   The management information has a unique position in the structured document as a starting point, and holds an offset and a length from the starting point to a position where each code stream is stored as the storing position. The information processing apparatus according to 1.   The said 2nd acquisition means acquires the said code stream stored in the position according to the offset according to the storage position of the said code stream from the starting point of the said structured document. Information processing device. A deletion unit that deletes a gap between code streams stored in the storage unit;
The storage position updating means overwrites the management information corresponding to each code stream stored in the storage means with the storage position of each code stream after the gap is deleted by the deleting means. The information processing apparatus according to claim 1 or 2 .   2. The information processing apparatus according to claim 1, further comprising decompression means for decompressing each code stream stored in the storage means.   The information processing apparatus according to claim 1, wherein the reception unit receives designation of a storage location of the code stream in units of pages of the structured document.   The information processing apparatus according to claim 1, wherein the structured document is a file conforming to ISO15444-1.   The information processing apparatus according to claim 1, wherein the structured document is a file conforming to ISO 15444-2.   The information processing apparatus according to claim 1, wherein the structured document is a file conforming to ISO15444-4.   The information processing apparatus according to claim 1, wherein the structured document is a file conforming to ISO15444-6.   13. The information processing apparatus according to claim 9, wherein the first acquisition unit and the second acquisition unit use JPIP defined by ISO 15444-9 as a communication protocol.   The information processing apparatus according to claim 1, wherein the structured document is a file that conforms to a specification of a Portable Document Format.   The information processing apparatus according to claim 1, wherein the structured document is a file compliant with a specification of a Multi Page Tagged Image File. The network includes at least a code stream and management information indicating the storage position of each code stream, and stores the structured document in which the code stream and the management information are stored in a predetermined structure via a network. An information processing method executed by an information processing apparatus that performs access,
A first acquisition step in which a first acquisition means acquires the management information from the structured document;
A receiving step for receiving a designation of a storage position of a code stream to be acquired out of the storage positions indicated by the management information acquired in the first acquisition step;
A second obtaining step in which a second obtaining unit obtains the code stream from a storage position of the designated code stream;
A storage control step in which the storage control means stores the management information acquired in the first acquisition step and the code storm acquired in the second acquisition step in the storage means in a structure corresponding to the structured document;
A storage location update step in which the storage location update means overwrites the management information in the storage means corresponding to each code stream stored in the storage means with the storage location of each code stream;
An information processing method comprising: The network includes at least a code stream and management information indicating the storage position of each code stream, and stores the structured document in which the code stream and the management information are stored in a predetermined structure via a network. The computer to access
First acquisition means for acquiring the management information from the structured document;
A receiving unit that receives designation of a storage location of a code stream to be acquired among the storage locations indicated by the management information acquired by the first acquisition unit;
Second acquisition means for acquiring the code stream from the storage location of the specified code stream;
Storage control means for storing the management information acquired by the first acquisition means and the code storm acquired by the second acquisition means in a storage means in a structure corresponding to the structured document;
Storage position update means for overwriting the management information in the storage means corresponding to each code stream stored in the storage means with the storage position of each code stream;
An information processing program characterized in that it is made to function.   A computer-readable recording medium on which the information processing program according to claim 17 is recorded.

Images