 |
Description  |
|
|
CROSS REFERENCE TO RELATED APPLICATIONS
The present patent application is related to the following U.S. patent
applications, also assigned to the assignee of the present patent
application: U.S. patent application Ser. No. 655,280 filed Sept. 27, 1984
and U.S. patent application Ser. Nos. 658,952, 658,953, 659,192 and
659,203, all filed on Oct. 9, 1984.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a data processing system and, in
particular, a system particularly designed for the processing of data in
document form.
2. Prior Art
Data processing systems of the prior art have generally fallen into one of
two classes, the first being general purpose systems designed to perform a
wide variety of tasks and the second being specialized systems optimized
for a limited range of related tasks.
A recurring problem with the first class of data processing systems is that
many such systems, while having a wide range of applications, may not be
as efficient for certain tasks as more specialized system. The second
class of systems, however, are generally not easily expandable for tasks
other than those for which they were originally designed, even when the
additional tasks may be related to the original tasks.
SUMMARY OF THE INVENTION
The present invention provides a solution to the above described problems
of the prior art, and other problems, by providing a data processing
system with features which allows the system to efficiently perform
relatively specialized, related tasks, such as document processing, while
being readily expandable for other tasks.
In the present embodiment, the system incorporates a task control means
including a task loader for transferring tasks from a storage means to a
system memory means and a task manager responsive to operation of the
system for controlling execution of tasks, and a document manager for
loading document information in the form of document data structures from
the storage means to the system memory and managing access to the document
data structures by the tasks. The task manager incorporates task control
blocks, which are used to manage the execution of tasks, while the
document manager incorporates document control blocks which are used to
manage access to the document data structures by the tasks.
There is a task control block for each active task in the system, and each
task control block includes an identification field for storing
information identifying the corresponding task, a status field for storing
information identifying the status of execution of the corresponding task,
a priority field for storing information identifying the relative priority
of execution of the corresponding task, and a stack pointer field for
storing information identifying the location of a stack mechanism usable
by the corresponding task. The task control blocks reside in a task
manager queue mechanism, with the task control blocks being linked by
pointers in the preferred sequence of their execution.
There is a document control block for each document data file in the system
and the document files and document control blocks are designed to
represent and relate to the structure of documents. Each document file
includes at least one page, and each page including at least one area,
wherein each area contains at least one type of information. Each area
including, in an area containing text information, at least one column for
containing text information. Each column including at least one line, and
each line including a string of at least one text character, a reference
to attributes applying to the characters of the string, and references to
external data items associated with the line.
The document file structure includes, for each document file, at least one
page block, each page block comprising fields describing the logical
dimensions of the page, fields describing the position of a cursor on the
page, the cursor position indicating the logical position within the data
contained in the page of an operation being performed on the data, a field
indicating cursor type, a field describing page layout, and field
containing a pointer to an area block. Each file structure includes at
least one area block, each area block comprising a field for containing a
pointer to a next area, fields containing information defining the type of
area, fields defining the logical position of the area with the page,
fields defining the margins of the area, fields defining the position of
text appearing in the area, fields defining the relationship of the area
to other areas of the page, and a field for a pointer to a column block.
The structure further includes at least one column block, comprising a
field identifying the format of the text appearing in the area, and at
least one field for a pointer to a link block. The structure includes at
least one line block, each line block comprising at least one field
containing a string of at least one text character, a reference to
attributes applying to the characters of the string, and references to
external data items associated with the line.
The system also includes a screen manager for creating visual display
screens representing data, generally residing in the document structures
described above. The screen manager includes means responsive to active
tasks for creating a screen manager control structure containing
information relating each screen to a corresponding task, and, for each
screen, information describing certain properties of the screen, and
information relating the screen to the data residing in the document
structure to be displayed therein. The screen manager also includes means
responsive to the corresponding tasks and corresponding screen manager
control structures to access and display the corresponding data.
Each screen is described, in the screen manager control structure, by a
virtual screen descriptor block and includes at least one viewport onto a
portion of the data structure being operated upon by an associated task.
Each virtual screen descriptor block includes a field identifying the
associated screen, a field identifying the associated task, fields
describing the associated screen, a field containing a pointer to a first
viewport associated with the screen, a field containing an array of
numbers identifying all viewports associated with the screen, and a field
for containing a pointer to a next virtual screen descriptor block
associated with a screen.
Each viewport is described by a viewport descriptor block including a field
containing a pointer to a page containing the data to be displayed within
the viewport, fields describing the logical location and dimensions of the
viewport relative to the data to be displayed therein, fields describing
the location of a cursor within the viewport, the position of the viewport
being associated with the operation of the associated task upon the data,
and a field for containing a pointer to a next viewport descriptor block
of a viewport associated with the screen.
Other advantages and features of the present invention will be understood
by those of ordinary skill in the art after referring to the following
detailed description of preferred embodiment and drawings, wherein:
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a system incorporating the present invention;
FIG. 2 is a diagrammic representation of the residence of control functions
and data structures in the system of FIG. 1;
FIG. 3 is a diagrammic, functional representation of the operation of the
control and data structures of the system of FIG. 1;
FIG. 4 is a diagrammic representation of the structure and operation of
applications tasks in the system of FIG. 1;
FIG. 5 is a diagrammic representation of the system loader and task manager
of the system of FIG. 1;
FIG. 6 is a diagrammic representation of the data structure of the system
of FIG. 1;
FIG. 7 is a diagrammic representation of the data file structure of the
system of FIG. 1;
FIG. 8 is a diagrammic representation of the document manager of the system
of FIG. 1;
FIG. 9 is a diagrammic representation of a document control block generated
by the document manager of the system of FIG. 1,
FIGS. 10A and 10B are a diagrammic illustration of a display generated by
the screen manager of the system of FIG. 1;
FIG. 11 is a diagrammic representation of the screen manager data
structure; and,
FIG. 12 is a diagrammic representation of the operation of the screen
manager of the system of FIG. 1.
DESCRIPTION OF A PREFERRED EMBODIMENT
The following description presents the structure and operation of a data
processing system incorporating the present invention. The structure and
operation of the system will be first presented on an overall level,
followed by descriptions of certain aspects of the system on a more
detailed level. Finally, further detailed information and descriptions of
certain of the system functions and structures will be presented in the
form of appendices.
Before beginning the descriptions of the system, it should be noted that
the reference numbering system used herein is constructed to clarify the
following descriptions in the manner in which the references appearing in
the text are related to the drawings and the elements shown therein. Each
reference number is comprised of either three or four digits, wherein the
two rightmost digits refer to a specific element appearing in a drawing
and the one or two left digits refer to the figure in which the element
first appears. For example, the reference 303 refers to the 3rd element
first appearing in FIG. 3, while the reference 1033 would refer to the
33rd element first appearing in FIG. 10. Once a reference number has been
assigned to an element, that reference number will be used throughout the
following portions of the descriptions, including the following figures.
For example, element 1033 first appears in FIG. 10 and, if it also appears
in FIG. 11, will be indicated in FIG. 11 by the reference 1033.
1. Overall System Structure and Operation (FIGS. 1 and 2)
Referring to FIG. 1, a block diagram representation of a system
incorporating the present invention is shown. The system, as described
further below, is in the present embodiment a single user, multi-tasking
system primarily dedicated to the performance of office functions, such as
the generation, filing and printing of documents and other related office
functions. As indicated therein, the system includes a Central Processing
Unit (CPU) 102 for performing operations upon and related to Document
Files (DFs) 104 residing in Memory 106. The operations of CPU 102, and
other elements of the system, described below, are controlled by sequences
of instructions, or routines, also residing in Memory 106. These routines
are grouped into two broad classes, the first being Operating System (OS)
routines 108 which direct the overall operations of the system and control
certain commonly used or shared functions. The second group of routines
are comprised of Applications 110, which are routines for controlling
particular user operations upon the document files, for example, word
processing and mailing list printings. As indicated in FIG. 1,
Applications 110 reside in Memory 106 as one or more Tasks 112, wherein a
Task 112 represents a series of operations to be performed by the system
under control or direction of a user of the system.
Other elements of the system may include a Keyboard (KYBD) 114, through
which a user enters instructions, commands and data to the system, and a
Display Memory (DSPM) 116 and Display 118 through which the user is
provided with visual representations of the system operations. Yet other
elements may include a Disc Storage unit (Disc) 120 for storing, for
example, document files and applications routines and an Input/Output
device (I/O) 122 through which the system may communicate with other
systems or devices. The elements of the system described above are
interconnected and communicate through a System Bus 124.
Referring to FIG. 2, a diagrammic representation of the physical residence
of the Operating System (OS) 108 routines, Applications 110/Task 112
routines and Document Files 104 in the present system is shown. As
described above, the controlling routines and data reside in the system
memory space, which is comprised, as indicated in FIGS. 1 and 2, of Disc
120 and Memory 106.
Referring first to the OS 108 class of routines, these routines include
both routines for directing the overall operation of the system and
certain functions which are commonly used or shared by the various Tasks
112. In contrast to Applications 110/Tasks 112, these routines are, after
system initialization, permanently resident in Memory 106. These common or
shared functions, described in greater detail in the following
descriptions, include, for example:
Test Mode/Formatting Functions 202 containing common text/document
manipulation operations,
Document Management Functions 204 which control access to Document Files
104, the communication of Document Files 104 between Disc 120 and Memory
106 and the creating, deleting, indexing, opening, closing, reading,
writing, and updating of documents,
Input Functions 206 which in part provide the interface between the user,
through KYBD 114, and other functions controlling system operations,
Menu Functions 208 which provides a menu type interface, displayed through
Display 118, through which a user may select and control certain system
operations and receive messages and prompts from the system,
System/Loader Function 210 which in part controls the loading of
Applications 110/Tasks 112 into Memory 106 from Disc 120,
Memory Manager Functions 212 which control the allocation and use the the
available space in Memory 106.
Task Manager Functions 214 which control the sequence of execution of Tasks
112 in the system, and
Screen Manager Functions 216 which control and direct the generation of
displays appearing on Display 118.
It should be noted that, at least in certain embodiments or applications,
certain or portions of certain of the above may not reside permanently in
Memory 106, but may reside in Disc 120 and may be called from Disc 120 to
Memory 106 for use by other functions or tasks as required.
Referring to the Applications 110/Task 112 class of routines, as indicated
above Applications 110 are not permanently resident in Memory 106 but
commonly reside in Disc 120 as Applications/Load Units 218.
Applications/Load Units 218 are loaded into Memory 106 as required to
perform user selected operations and, when so loaded, become Tasks 112. As
indicated in FIG. 2, the system is a multi-tasking system and more than
one Task 112 may be resident in Memory 106 and executing at a given time.
Applications/Load Units 218 may include, for example:
Edit and Background Print 220, which are separate Applications 110/Tasks
112, contain the functionality necessary to perform, for example, document
generation and word processing functions, including printing of the final
result,
Mailing List Print 221 which, as the name implies, performs mailing list
operations,
Document Copy Utilities 222 which performs document manipulation operations
associated with the copying and moving of documents or portions thereof,
Software Generation Utilities 224 which provides certain programming or
software generation facilities to a system user, for example, the
generation of fonts in which to print documents, and
Forms Utilities 226, the operation of which is described in U.S. patent
application No. 595,079, titled "Electronic Processing With Forms" and
filed Mar. 3, 1984.
Referring finally to document residing in the present system, as indicated
in FIG. 2 Documents 228 primarily reside in the system in Disc 120 as
Document Files 230 in disc file format. Document files 230 to be operated
upon by the system, or portions thereof, are loaded into Memory 106 and
reside therein in a document structure format, described further below, as
Document Files 104. Again because the system is a multi-tasking system,
more than one Document File 104 may reside in Memory 106 to be operated
upon at any given time.
2. System Functional Structure and Operation (FIG. 3)
Referring to FIG. 3, a diagrammic representation of the functional
structure and operation of the system is presented. Indicated therein is
Disc 120 memory space containing one or more Application/Load Units
(A/LUs) 218 and one or more Document Files (DFs) 230 in disc file format.
Also indicated is that portion of Memory 106 available for storing Tasks
112 and Document Files (DFs) 104 in document structure to be operated
upon.
Considering first the functional elements for loading Tasks 112 into Memory
106 and for managing execution of Tasks 112, the system includes, as
previously described, a System/Loader element (S/L) 302, a Task Manager
element (TM) 304 and a Memory Manager element (MM) 306. S/L 302, which
includes System/Loader Routines (S/LR) 210, is the means by which A/LUs
218 are loaded into Memory 106 to become executable Tasks 112 and operates
in conjunction with TM 304 and MM 306 in performing these operations. TM
304 and MM 306 include, respectively, the previously described Task
Manager Routines (TMR) 214 and Memory Manager Routines (MMR) 212.
S/L 302 is responsive to either user requests, entered through KYBD 114, or
requests resulting from the the operation of an already resident Task 112
to load A/LU 218s into Memory 106. In response to such request, and as
described further below, S/L 302 responds to such requests by providing
corresponding requests to MM 306 (not indicated in FIG. 3) to provide Task
Node Spaces (TNSs) 308 to contain the new Tasks 112 and to TM 304 to
create the control structures necessary to control execution of the newly
loaded Tasks 112.
MM 306 responds to such requests from S/L 302 by providing such TNSs 308
while TM 304 responds by building the appropriate control structures. In
this regard, it should be noted that TM 304, being the central management
structure for a multi-tasking system, includes both a Task Stack Mechanism
(TSM) 310 which contains a Task Stack (TS) 312 for each active Task 112
and a Task Queue (TQ) 314, which is used in determining the sequence of
execution of the active Tasks 112. TM 304 also constructs, for each active
Task 112, a Task Control Block (TCB) 316, described further below, which
identifies and provides information pertinent to the execution of the
associated Task 112.
The loading of DFs 230 or portions thereof into Memory 106 as DFs 104 to be
operated upon, and access to such DFs 104 for such operations, is
performed and controlled through Document Manager element (DM) 318, which
includes Document Manager Routines (DMR) 204. DM 318 interacts with MM 306
to obtain the necessary space in Memory 106 and constructs and maintains,
for each DF 104, a control/data structure referred to as a Document
Control Block (DCB) 320, described further below, which contains
information pertinent to the associated DF 104. It should be noted that,
in addition to controlling the transfer of DFs 104 between Memory 106 and
Disc 120, and the associated transformations in file structure, all access
to DFs 104 by Tasks 112 or other system routines is generally performed
through DM 318 in the manner described further below, the exception,
described below, being the access of DFs 104 by Screen Manager element
(SM) 322.
Referring now to the system elements effectively comprising the interface
between the user and system operations, these elements include, of course,
KYBD 114 and DSP 118. User inputs through KYBD 114 are provided to Input
element (Input) 324, which includes keystroke handling routines. Input 324
in turn provides outputs to Tasks 112, to effect the execution thereof, to
Menu element (Menu) 326, and to SM 322. Considering first Menu 326, as
previously described Menu 326 includes the routines necessary to create
and provide a menu type interface, displayed through Display 118, through
which a user may select and control certain system operations and receive
messages and prompts from the system. As required by these functions, Menu
326 also provides outputs to SM 322 to be displayed through DSP 118.
SM 322, described in further detail below and in U.S. patent application
Ser. No. 655,280, titled "Screen Manager For A Data Processing System and
filed Sept. 27, 1984, generates screen displays representing the
operations of the system and presents such displays to the user through
DSP 118 through Rasterizer/Bit Mapped Display Memory (R/BMDM) 328, which
includes DSPM 116. As required by these functions, SM 322 requires access
to the information contained in the document structures created as DFs 104
by DM 318, but does so through a SM 322 control structure, described in
detail further below, rather than through DM 318 and DCBs 320. As also
described further below. SM 322 is also provided with access to TM 304
maintained information regarding the status of certain currently active
Tasks 112.
Having described the overall functional structure and operation of the
system, certain elements and aspects of operation of the system will be
described in further detail next below, beginning with the construction
and execution of Tasks 112 and OS 108 routines.
3. Structure and Execution of Tasks 112 (FIG. 4)
Referring to FIG. 4, therein is represented the construction and execution
of an A/LU 218. The initial structure of an A/LU 218, represented at the
top of FIG. 4, is comprised of one or more source code Modules 402 created
by a programmer and defining the operations to be performed by the Task
112, for example, word processing. Represented in the lower portion of
FIG. 4 are the routines comprising the OS 108 and common, shared routines,
referred to as "System Primitives" 404, and certain system utility
routines. These System Primitive Routines 404, some of which are described
in further detail in following descriptions, may be called by an A/LU 218,
as a Task 112, as required to perform the operations of the A/LU 218 and
may include, for example:
Document Manager Routines 204,
Memory Management Routines 212,
Semaphore Management Routines (associated with Task Manager Routines 214),
Scheduling Routines (associated with Task Manager Routines 214),
Task Management Routines 214,
Timer Service Routines (associated with Task Manager Routines 214),
Screen Management Routines 216,
File Management Routines,
Direct Interrupt Control Routines,
File Access Routines,
Menu Routines 208, and
Device Control Routines.
In order to be able to create each A/LU 218 separately and to be able to
load each A/LU 218 into the system dynamically, it is necessary to
decouple all System Primitive Routines 404 and certain system functions,
as described above, from the A/LUs 218. It is further preferable if, in
doing so, the speed of execution of system primitive calls by the A/LUs
218 were enhanced. This is done, as shown in FIG. 4, by coding all System
Primitive Routine 404 entry points as interrupt vectors through a Software
Interrupt Vector Table 406 residing in a reserved area of Memory 106.
Essentially, and as described below, all System Primitive Routine 404
calls by A/LUs 218, that is, by Tasks 112, are executed as software
interrupt calls. As an initial step in such calls, the calling Task 112,
operating through the stack handling facility of TM 304, pushes all
necessary arguments onto its' associated stack and, for some calls, puts
its' function code into a designated register.
In addition to the above A/LU 218/Task 112 calls, certain system functions,
such as system start and application program terminate, are called through
software interrupts to maintain software version independency. The system
also provides, as indicated in FIG. 4, an Entry Address Table 408 for
other entry to System Primitive Routines 404.
Considering now the construction of a A/LU 218/Task 112 performing System
Primitive Routine 404 calls through a software interrupt mechanism, the
initial source code applications Modules 402 have associated with them a
Link Module 410 which defines the relationships between system primitive
calls and the entries in Software Interrupt Vector Table 406. Upon
compilation and linking of the original source code Modules and Link
Module 410, through Compiler and Linker 412, the modules are transformed
into a single, linked, relocatable Object File 416 wherein the original
system primitive calls are linked into the appropriate interrupt vectors
taken from Link Module 410.
Object File 416 is an object code A/LU 218 and may be loaded into Memory
106 as a "run" file by S/L 302, as previously described, and all system
primitive calls will, as described above, be executed as software
interrupts by the Interrupt Vectors 418 resulting from such system
primitive calls.
Having described the construction and structure of an A/LU 218 and Task
112, the loading of an A/LU 218 into the system to become a Task 112 will
be described next below.
4. Loading of Tasks 112-Operation of System/Loader 302, Task Manager 304
and Memory Manager 306 (FIG. 5)
Referring to FIG. 5, therein is represented the loading of an A/LU 218 into
the system to become a Task 112, and the associated operations of S/L 302,
TM 304 and MM 306. Shown therein are a plurality of A/LUs 218 resident in
Disc 122, one of which is to be loaded into Memory 106 as a Task 112.
The loading of an A/LU 218 into Memory is initiated by a request for such
an operation. Such requests may be initiated by a user through KYBD 114
and Input 324, or may be initiated by another active Task 112, and will
include a file name identification of the requested A/LU 218. Such a
request is provided to S/L 302, which identifies the corresponding A/LU
218 by means of a Header 502, containing identification information,
associated with the A/LU 218 Task Code (TC) 504, or routines.
S/L 302 first generates a request to MM 306, by means of a MM 306 primitive
(Getnode), for an area of Memory 106 to be assigned as the TNS 308 of the
requested A/LU 218/Task 112. MM 306 will respond by assigning such a space
and will identify the location of the TNS 308 to S/L 302. The TNS 308
associated with a given Task 112 is effectively that Task 112s memory
space to be used as required in executing its' operations.
S/L 302 then provides a request to TM 304 for TM 304 to construct the
appropriate control structures for the requested A/LU 218. TM 304 responds
by constructing a TCB 316, as described previously, and returning the TCB
Identification (TCDI) 506 of the newly constructed TCB 316 associated with
the requested A/LU 218.
S/L 302 then writes the A/LU 218 into the assigned TNS 308 and the assigned
TCDI 506 into a assigned location within the TNS 308. The A/LU 218 thereby
becomes an executable Task 112 by being assigned an active TNS 308 and by
being linked into TM 304 by its' associated TCDI 506, which is effectively
an address, or pointer, to its' associated TCB 316 in TM 304.
Referring now to TM 304 as shown in FIG. 5, as indicated therein each TCB
316 includes a unique Identification 508 identifying that particular TCB
316, Status 510 information describing the state of execution of the
associated Task 112, Priority 512 information identifying the relative
priority of the associated Task 112, and a Task Stack Pointer 514
identifying the location of the associated Task 112s stack in TM 304's TSM
310. Each TCB 316 associated with a Task 112 effectively resides in TM
304's Task Queue 314 wherein the TCBs 316 are linked, or chained, in order
of task execution by a series of head pointers and a tail pointer. The
order of execution is determined by task priority and status and TM 304
maintains a separate Task Queue 314 for each level of priority.
The above description has described the operation of MM 306 with regard to
the initial assignment of a TNS 308 when a new A/LU 218 is loaded into the
system to become a Task 112. It should be noted that, as described in
further detail in following descriptions, MM 306 provides means for a Task
112 to request the assignment of further Memory 106 space to its' TNS 308,
specifically through the Getmynode primitive.
Further description regarding the structure and operation of TM 304 and MM
306 may be found in the attached appendices titled, respectively,
"Appendix A-Task Manager" and "Appendix B-Memory Manager", incorporated
herein by reference.
Having described above the structure of Tasks 112 and the loading of Tasks
112 into the system, the structure of DFs 104 upon which those tasks
operate will be described next below, followed by a description of DM 318.
5. Document Files 104 Structure (FIGS. 6 and 7)
The structure of Document Files (DFs) 104 may be considered as comprised of
two parts, the first being the actual document structure and the second
being the file structure through which DM 318 accesses the document
structure. These structures will thereby be described below, in that order
and with reference to, respectively, FIGS. 6 and 7.
Before describing the document structure, the concept upon which the
document structure is based must first be described. Essentially, the
concept of the document structure is based upon that of an actual,
physical document, which is comprised of one or more pages and wherein
each such page may be regarded as comprised of one or more definable
areas, each area containing a particular type of information. The
information which may appear in such areas may include, for example,
single column text, multiple column text, graphics, images, headers or
footers, and footnotes.
A document file is comprised of a group of one or more Pages, wherein each
Page is a rectangular, displayable object of general content comprised,
for example, of text, graphic and image data. A Page may be a Menu, a
Status line, a Prompt, or a Document Page. In this regard, a Page should
not be confused with a Document Page, which is one form of a Page.
Each Page contains one or more Areas, an Area being a rectangular portion
of a Page which is not sub-divided and which may contain one or more
Layers. A Layer, in turn, is a portion of the contents of an Area and
contains a particular type of information, for example, text, graphics or
images, and Layers may be superimposed to comprise the contents of an
Area.
To aid in understanding the following descriptions of the operation of the
present system, the following definitions are further provided. First, a
Region is a rectangular portion of a Page which is further sub-divided.
Finally, a Window is a rectangular portion of a Page which can be visible,
for example to a user.
Referring now to FIG. 6, a partial illustration of a DF 104 data structure
is shown; the data structure is further illustrated in "Appendix
C-Document Data Structure". The first element of the structure is a Page
Block 602 containing a pointer to the first Area of the Page, Page size
information, Page Cursor information describing the location of a cursor
in the Page. The cursor position information, among other functions,
defines the location within the Page wherein current operations, for
example, the insertion of text, will be performed. Also included is
information as to cursor type, Save information, information as to whether
the Page displays formatting, and information regarding Page layout. The
Page block also contain Path Pointer information pointing to a Path Block
which in turn defines, for example, whether the Page contains graphic or
free text information and areas to receive overflow text. The second
element or elements of the data structure are one or more Area Blocks 604,
each of which contains information pertaining to an associated Area of the
Page. An Area Block 604 contains a pointer to the next Area Block 504, if
there is more than one, information defining the type of Area, information
identifying the locations of the top left and bottom right corners of the
Area within the Page, and information regarding the right and left margins
of the Area. A Text Contents pointer identifies the location of a Column
Block 606, described below and identifying the location of text appearing
in the Area, and a Layer Descriptor identifies the location of a Layer
Block 608 described further below and identifying the location of graphics
or image data appearing in the Area. Other fields of an Area Block 604
define the relationships between the edges of the Area and other Areas
(ES), the path sequences to previous and next Areas of the Page
(Path/Reference, Prev., Next), style information pertaining to text in the
Area (Area Style), and information pertaining to positional
characteristics of text appearing in the Area (VERTB1, HORTB1).
The next elements, the Column Blocks contain information pertaining to text
appearing in the Area. The first information, Lines & Spacing, defines the
number of lines appearing in a column of text and the vertical spacing of
the lines. The Format Page field contains a pointer to a block of format
information defining the format of the associated column. The following
fields, Line 1, Line 2, and so on, contain pointers to Line Blocks 610,
each containing text appearing in the associated column and information
pertaining to that text.
Referring to the example of a Line Block 610, the text appearing in a
column is comprised of a series of text strings, each such string having
common characteristics, or attributes, such as whether the characters are
bold or italic or overscored or underscored. A Line Block 610 is comprised
of a Line Prefix String containing information pertaining to the following
text and one or more Text Strings containing the characters of the text.
Each Text String is comprised of a String Header containing information
regarding the characteristics or attributes of the associated string of
text characters, and a string of text characters to which those attributes
apply. A line may also contain a reference to an external information item
which applies or is related to the Line, for example, headers, footers and
footnotes, but may include other such items.
Referrin | | |
