Data format conversion

Abstract

A style of document format known as compound document architecture is known, in which a document is broken up into a tree of objects or segments (e.g. document: chapter: subtitle: para: para: etc.), possible with a second layout tree. Two styles of such architecture are ODA and CDA. Conversion from CDA to ODA presents difficulties, as in CDA, a segment can contain e.g. text and graphic elements, while ODA has stricter formatting rules. One of a plurality of DAPs (Document Application Profiles) 12 is selected, depending on which subset of full ODA is being used. The DAP contains a structure converter component which starts to construct the objects of the ODA document. When an information element is reached (text, graphics, etc.), it is sent to the appropriate one of a set of content handlers 13. These call back to callback units (text, graphics, footnote, etc.) in the DAP when an ODA logical object is to be completed, and on each other (possible recursively, as for footnotes in text) when a change of information element type is reached.

Claims

We claim:

1. A data structure format conversion system comprising:

a plurality of profile conversion components for converting the logical and/or layout structures of the source document to those of the target format;

a plurality of content architecture conversion components selected by the profile conversion components for converting the contents of the source document to the target format and being invoked by the required content architecture conversion component; and

a main converter component for identifying the profile to which the compound document conforms and invoking the required profile conversion component.

2. A system according to claim 1 wherein the content architecture conversion components include a text conversion component, a geometrical graphics conversion component, and a raster graphics (bit image) conversion component.

3. A system according to claim wherein the profile conversion components include components implementing ODA Q111, Q112, and Q121 standards.

4. A system according to claim 1 wherein each profile conversion component comprises means for generating logical objects of the target document architecture, comprising a structure converter unit for generating compound logical objects of the target document and a plurality of callback units, each for generating a different type of basic logical object or set of logical objects including at least one basic logical object; and each content architecture conversion component converts a different one of the possible data types of the content of the source document to the target format, each being callable from the others and from the units of the structure architecture conversion component, and each capable of calling back to any one of a corresponding set of the callback units.

5. A system according to claim 2 wherein each profile conversion component comprises means for generating logical objects of the target document architecture, comprising a structure converter unit for generating compound logical objects of the target document and a plurality of callback units, each for generating a different type of basic logical object or set of logical objects including at least one basic logical object; and each content architecture conversion component converts a different one of the possible data types of the content of the source document to the target format, each being callable from the others and from the units of the structure architecture conversion component, and each capable of calling back to any one of a corresponding set of the callback units.

6. A system according to claim 3 wherein the callback units include a text callback unit, a graphics callback unit, and a footnote callback unit.

7. A data structure format conversion system comprising;

a structure architecture conversion component for generating logical objects of the target document architecture, comprising a structure converter unit for generating compound logical objects of the target document and a plurality of callback units, each for generating a different type of basic logical object or set of logical objects including at least one basic logical object;

a plurality of content architecture conversion components each for converting a different one of the possible data types of the content of the source document to the target format, each being callable from the others and from the units of the structure architecture conversion component, and each capable of calling back to any one of a corresponding set of the callback units.

8. A system according to claim 7 wherein the content architecture conversion components include a text conversion component, a geometrical graphics conversion component, and a raster graphics (bit image) conversion component.

9. A system according to claim 7 wherein the callback units include a text callback unit, a graphics callback unit, and a footnote callback unit.

10. A system according to claim 8 wherein the callback units include a text callback unit, a graphics callback unit, and a footnote callback unit.

11. A system according to claim 7 wherein there is a plurality of structure architecture conversion components, any one of which is selectable.

12. A system according to claim 8 wherein there is a plurality of structure architecture conversion components, any one of which is selectable.

13. A system according to claim 10 wherein there is a plurality of structure architecture conversion components, any one of which is selectable.

14. A system according to claim 7 wherein the structure architecture conversion components include components implementing ODA Q111, Q112, and Q121 standards.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the conversion of data between different formats, and more particularly to such conversion between different forms of compound document architecture.

2. Data Architectures--General

In word processing, desk-top publishing, and the like, a variety of data formats have been developed. The simplest formats are designed to deal only with textual matter. Even with such an apparently simple situation, there are many aspects which may or may not be dealt with, and which, if they are dealt with, may be dealt with in a variety of ways. These include, for example, word wrapping, right justification, headers and footers, and margin control. More advanced formats include provision for things like footnotes and paragraph and section numbering, tabular information, geometric graphics, and bit image graphics.

As the nature of such formats becomes increasingly complex, it becomes convenient to distinguish between the general principles or rules of a format and the details of the implementation of such a set of principles. The set of principles is commonly termed an architecture, and an implementation is often termed an interchange format of that architecture.

With a simple architecture, such as that provided by a basic word processing system, the structural features of a document formatted under that architecture are very simple. With such an architecture, the document will normally be formatted as a stream of alphanumeric characters--the text--with whatever structural features it has being embedded within that stream. That is, features such as line returns will be represented by control codes occurring at the appropriate points within the character stream. Similarly, such matters as the starting and stopping of italics and bold-face can be represented by the inclusion of control characters in the character stream. This style of architecture can obviously be extended to more complicated situations. For example, if the architecture includes pagination, the codes for page endings can obviously be included in the character stream.

The appropriate information regarding such matters as line and page length must obviously be specified. In very simple cases, this can sometimes be dealt with by the operation of whatever printer the document is sent to. However, it is more usual for such information to be included within the document. If the line and page lengths are unchanged throughout the document, then this information will normally be included at the beginning of the document, preceding the text, and forming a header block.

This technique naturally extends to the provision of similar control blocks at appropriate points within the information stream where the format (in the sense of such matters as margins and page length) of the document changes. A simple example is the inclusion of a quotation in the form of a distinct paragraph using a smaller typeface than and with its margins inset from the main text. This will be preceded by a control block setting the typeface and margins, and will naturally be followed by another control block setting the original typeface and margins.

The discussion so far has largely assumed that the document is fully formatted. However, it is often convenient to separate the informational contents of the document from its final formatting. The document in its initial state is in what is termed processable form. (The term "informational contents" is to be taken in the broad sense of including the general parameters of the document such as page headers and footers, typeface, paragraph insets, narrowed margins, etc. are defined.)

With a processable document, the details of the actual page layout (primarily page width or line length and page length) are left undefined. When the document is finally printed as a hard copy, the printing system has to have such formatting information supplied to it, and the system has to calculate the positions of line and page endings and make appropriate adjustments (e.g. in page numbering and footnote positioning).

A major advantage of using documents in processable form is that editing of the document is simplified, for two reasons. One is that the editing of the document (usually on a word processor) does not have to take account of the details of the layout of the document on the page. This means that the operation of the word processor is faster, particularly in situations where the operator jumps between widely separated locations in the document. (If the document is maintained in fully formatted form, the system would have to reformat the whole of the text between the relevant locations in moving forward from one to the other).

The other reason is that the document can be transferred between different systems much more easily. Such different systems may involve different hardware, or something apparently as minor as a slight change of printer character style (which will require recalculation of line lengths), or perhaps simply a change in the size of paper. Again, if the document were fully formatted, such a change would involve reformatting the whole document, whereas with the document in processable form, no change is required to the document.

It will be assumed from here on that documents are in processable form.

Compound Document Architecture--General

The formatting technique discussed above consists essentially of incorporating the formatting information in the character stream of the document. With a very simple word processing system, such information may consist for example of little more than paragraphing, and this technique is generally satisfactory. However, in more complicated situations, this technique can become unwieldy.

A simple example can arise in the situation mentioned above, where there are quotations in the text. If there are several such quotations, there will be a corresponding number of repetitions of the control blocks. Another situation is where the document is large, consisting of a number of chapters each subdivided into sections.

Further, there is often a need for systems which are more elaborate that simple word processing systems. The possibilities of such things as typeface changes have already been mentioned, and such systems can be developed further to permit the inclusion of, for example, geometric and/or raster graphics and various kinds of lists and tables.

For these and other reasons, an alternative approach has been developed as the architecture becomes more complicated, giving a second style of architecture, generically termed compound document architecture. This second style involves the separation of the structure of a document from its contents.

With this approach, the logical structure of a document is defined in the form of a tree, which can most easily be explained by means of an example. Suppose the document is a textbook. Then the first level of structure of the document may be defined as consisting of a title, a list of contents, an introduction, a number of chapters, a list of references, and an index, with the number of chapters being variable and, say, the presence of an introduction being optional. In turn, each of these elements has its own structure; for example, the structure of a chapter may consist of a title and a number of sections each with a section heading. An element with such a structure of its own is termed a compound element; an element with no such subordinate structure is termed a basic element.

With this second, more formalized and structured, architectural style, the format or layout of the document is a separate and to some extent subsidiary matter which has to be superimposed on the logical structure. This is done by defining a layout structure for each logical element. In principle, this could be achieved by defining a set of independent layout structures, but since the desired layouts of the various logical elements will usually have many features in common, this is achieved in practice by defining a tree of layout elements.

The logical structure will thus consist of a tree of elements, with the final or "leaf" elements containing the actual data (text or other information). The "leaf" elements of the layout structure or tree will be associated with the "leaf" elements of the logical structure. Minor local features of the layout, such as boldface and italics, are embedded in the character string of the logical element by the layout process.

As with the first architectural style, the compound document style can be tailored to produce either a processable or a fully formatted document. There is a further complication with the fully formatted form, since the logical elements as so far described are independent of page breaks. What is usually done is that logical element crossing a page break is redefined as two separate logical elements, one on each page. (These two logical elements naturally share a common logical parent.) We shall here, however, assume as before that we are concerned primarily with documents in processable form.

A different issue has to be addressed if complicated information is to be dealt with. Information may, as assumed so far, be in the form of text; however, it may also be desirable to deal with information in other forms, such as geometric graphics, raster (bit image) graphics, tables, spreadsheets, and so on. (Geometrical graphics are diagrams defined in terms of lines whose end-point coordinates are given, circles whose center coordinates and radii are given, fill patterns, etc; bit image graphics are diagrams defined by the states of their individual pixels.) These will in general need their own formats to be defined largely independently of the formats of other types of information, and these formats will be included as control blocks or layout elements depending on the architectural style.

In general, blocks of information of different types may follow each other and/or be embedded in each other fairly freely in the first architectural style. In the second style, a basic logical element must be of a single information type, but a compound logical element can include basic logical elements of different information types.

A special situation arises with footnotes, which have to be treated to some extent as if they are of a different information type although they are usually text occurring in text. With the second architectural style, a footnote is dealt with by means of a separate logical element. (With the first style, a footnote is embedded in the character stream by means of a suitable control clock.)

There is of course a vast variety of specific data formats, and there is often a need to convert data from one format to another. Such conversion can rarely be performed perfectly even if the two formats use the same architectural style. The present invention is concerned with the conversion between certain different implementations or architectures of the second style.

CDA and ODA Compound Document Architectures

Several compound document architectures currently exist, e.g. CDA and ODA (note that the word "compound" is used in two different senses, one generic and the other specific (CDA)). Each of these defines how compound documents can be represented and stored. More specifically, CDA is Compound Document Architecture and ODA is Open Document Architecture. These have associated with them two respective specific formats, DDIF (Digital Document Interchange Format) and ODIF (Office Document Interchange Format) respectively. The ODA/ODIF architecture and format are defined by ISO document ISO 8613, and the DDIF architecture and format are defined by document DEC STD 078 of Digital Equipment Corporation. CDA and ODA are architectures, and DDIF and ODIF are particular formats which conform with those respective architectures.

Both these architectures and their associated formats are widely used, and there is an obvious need to be able to convert data in either format into the other. However, these two architectures and formats differ significantly. The conversion between them is therefore not trivial.

The present invention will be described with reference to CDA/DDIF and ODA/ODIF. It should however be understood that it is not limited to any particular features of those particular architectures, and also that many of the characteristics of those architectures are described in modified and/or simplified form for present purposes.

The details of the structures of documents in ODA/ODIF and CDA/DDIF are defined by the documents noted above. However, to understand the present invention, a brief informal description of these structures is desirable.

Both structures utilize a hierarchy of elements (generally termed "objects" in ODA/ODIF and "segments" in CDA/DDIF) arranged in tree form, the tree starting with a root element. For example, if the document is a book, the root element will be the entire document (the book); the elements in the first level down will be the chapters; the elements in each chapter may be a title and a number of sections; the elements in a section may be a section heading a number of paragraphs; and so on. Each element will in general have a number of attributes, each of which can have one of a range of possible values.

In ODA/ODIF, the elements just mentioned form the logical structure. The root element is termed a root logical object. At the "leaf" ends of the branches, the lowermost elements are termed "contents portions"; these contain the content or material of the document. The elements between the root element and the content portion elements are termed "basic logical objects" (BLOs) if they contain only contents portions, or "compound logical objects" (CLOs) otherwise (i.e. if they contain further logical objects).

In ODA/ODIF, the layout of a document is described by a layout structure which is also in the form of a tree. The layout structure has a root element, the document. The elements one level down are page sets; the elements the next level down are pages; these may be followed by frames (optionally several levels thereof); and these by blocks (forming the lowest level). This layout tree is independent of the logical structure, though it will usually have some general similarities with that logical structure. For example, if the document is a book, then the logical structure of a chapter element being composed of a heading element and section elements will usually be reflected in a layout structure of a heading layout element and a section layout element, but most or all of the logical section elements will share a single common section layout element.

In ODA/ODIF, these two trees for a document must be constructed in such a way that each content portion of the logical structure is paired with a corresponding block in the layout structure. As noted above, this will often involve splitting a paragraph between two columns or pages.

It will be realized that when a document is being worked on (created or edited), the full constraints are not normally observed. This is because, as is well recognized, the editing of a document is slowed and complicated considerably if the document is reformatted very time a small change is made to its contents. Instead, the full constraints are imposed on the document when editing ends. (This principle applies equally to ODA/ODIF and CDA/DDIF.)

In CDA/DDIF, there are logical and layout tree structures somewhat similar to those of ODA/ODIF. However, the structure of CDA/DDIF is less rigidly constrained and defined than that of ODA/ODIF, which is more rigidly formalized and structured.

To some extent, CDA/DDIF uses an implicit galley-based layout (though the attributes of the various elements will generally define many of the characteristics or features of the layout--for example, fonts, font sizes, line widths, &c). CDA/DDIF is thus simpler than ODA/ODIF in some ways; however, it is more elaborate in others (for example, it allows the use of live links and external references).

To a considerable extent, individual elements in ODA/ODIF and CDA/DDIF correspond directly to each other on a one-to-one basis. Among these elements may be, for example, elements, attribute names, attribute values, text strings, and so on.

However, the differences between these two architectures means that this correspondence is not exact. Thus CDA/DDIF allows what is in effect a nesting of segments, which results in the segmentation being somewhat less clear-cut than in ODA/ODIF. Further, in this nesting in CDA/DDIF, a contents portion of one type (e.g. textual) can be followed by a contents portion of another type (e.g. graphical), whereas in ODA/ODIF, contents portions of different types must be in distinct (logical) objects. (The different types of contents--e.g. text, raster graphics, and geometric graphics--may also be termed metaclasses.)

In addition to the obviously different types of contents (text, geometric graphics, raster graphics, list structures, and so on), there is another situation in which different pieces of contents need to be treated to some extent as different types, even though they are both textual. This situation is that of footnotes. In CDA/DDIF, a footnote can be included (embedded) in the middle of a textual segment. In ODA/ODIF, a footnote has to have its own object (or, in fact, its own object tree, as will be described later). Somewhat similar situations arise with things such as the insertion of page numbers in the form of cross references in the body of the document (as distinct from page numbers in headers or footers, which are not involved in documents in processable form).

For the operation of the system to be explained, it is desirable to outline the nature of ODA/ODIF and CDA/DDIF in rather more detail.

ODA Document Structure

Considering first ODA/ODIF, an ODIF document is structured as a pair of trees, a logical tree for the contents and a layout tree. The logical tree ends in blocks which correspond one-to-one with "contents" objects (basic logical objects, BLOs) and which are the actual contents of the BLOs. The two trees meet at the "leaf" level, with each BLO (or block) of the logical tree being also a final or "leaf" element of the layout tree. A single "contents" object can contain contents of only one type--text, geometric graphics, bit image graphics, etc. (Hence a diagram will typically be defined by a "diagram" object as consisting of a geometric graphics object, a title, and optionally one or more labels to go in the diagram.)

The objects of the logical tree, as discussed above, define the logical structure of the document, and each object constrains the number, type, and arrangement of the objects connected directly below it. The layout objects define the layout of the document, and each may contain attributes. Attributes are inherited by default; thus if a object does not declare values for some attributes, those attributes have the values declared in the object above it in the tree. Logical objects may also contain attributes, which over-ride the attributes of the layout objects which would otherwise apply. Each final layout object defines the layout and presentation of the contents of the logical objects coupled to it.

The general structure of an ODIF can thus be shown as a double tree, FIG. 1 being a simplified example. The same document can alternatively be represented in tabular form, as shown in Table I. This is broadly the form in which the document is stored in memory. The tabular structure of the document in this form is present in a relatively explicit manner.

                  TABLE I
    ______________________________________
            Logical object 1
            "Chapter"
            Listing of permitted sub-objects
            Logical object 1.1
            "Table"
            Listing of permitted sub-objects
            Logical object 1.2
            "Section"
            Listing of permitted sub-objects
            ***
            Logical object 1.1.1
            "Content"
            Logical object 1.2.1
            "Subtitle"
            Listing of permitted sub-objects
            Logical object 1.2.2
            "Section"
            Listing of permitted sub-objects
            Logical object 1.2.3
            "Section"
            Listing of permitted sub-objects
            ***
            Logical object 1.2.1
            "Content"
            Block 1.2.1
            Layout - layout object 1.1.1
            Logical object 1.2.1.1
            "Content"
            Block 1.2.1.1
            Layout - layout object 1.1.2
            Logical object 1.2.1.2
            "Content"
            Block 1.2.1.2
            Layout - layout object 1.1.2
            ***
            Layout object 1
            "Document"
            Attributes
            Listing of permitted sub-objects
            Layout object 1.1
            "Title page"
            Attributes
            Listing of permitted sub-objects
            Layout object 1.2
            "Page"
            Attributes
            Listing of permitted sub-objects
            ***
            Layout object 1.1.1
            "Title page frame"
            Attributes
            Layout object 1.1.2
            "Frame"
            Attributes
            ***
    ______________________________________

                  TABLE II
    ______________________________________
        Segment A
        attributes
        [
                  Segment B
                  attributes
                  [
                            primitive contents element .times. 1
                  ]
                  [
                            primitive contents element .times. 2
                  ]
                  [
                            primitive contents element .times. 3
                  ]
        ]
        [
                  Segment C
                  attributes
                  [
                            primitive contents element .times. 4
                  ]
                  [
                            Segment E
                            computed contents
                  ]
                  [
                            primitive contents element .times. 5
                            ]
                  ]
                  [
                  Segment D
                  attributes
                  [
                          primitive contents
                          element .times. 6
                  ]
                  [
                          primitive contents
                          element .times. 7
                  ]
                  [
               ]
    ]
    ______________________________________

• Inventors
  Kelly, Jean; McNelis, Paul; Smith, J. Mark;
• Assignee
  Digital Equipment International Ltd. (CH)
• Published
  Dec-22-1992
• Current US Classes:
  715/530
• Application #
  669173
• International Classes
  G06F 015/38
• Field of Search
  364/419 395/144 395/145 395/146 395/147 395/148
• Examiner
  Envall, Jr.; Roy N.
• Agent
  Myrick; Ronald E., Young; Barry N.
• US Patent References:
  4723209
  4723211