This document (whose browsable version is accessible by using
your browser's "File→Open File" on /opt/graphics/common/doc/GAG/Web/index.html)
was created to fill a need that became evident as Hewlett-Packard
began to offer multiple Application Programmer Interfaces (APIs).
The situation was this: As HP created one API — say, Starbase
— particular aspects of graphical operation were noted
and diligently explained in the Starbase documentation. However,
some of these aspects were not unique to Starbase, they pertained
to graphics operation in general: they applied to all
of our APIs. Therefore, those users who had HP-PHIGS would be encountering
some of the same graphical questions that were already well-documented
in the Starbase documentation. But HP-PHIGS users wouldn't necessarily
have the Starbase documentation. Are
they just out of luck? The same situation occurred with HP PEX.
Our dilemma was this: do we copy the general-graphics explanations
that already existed in the Starbase documentation, into the documentation
for the other APIs as well? This would mean two, three, or even
more virtually identical copies of the same explanations in different
places, requiring similar changes in each whenever new capabilities
or devices were introduced. And if all documents containing these
similar explanations were not reprinted simultaneously, "current"
documents for the various APIs might contradict each other.
A more elegant solution is: this document. While the API-specific
documents still contain most of their previous contents, the general
graphical information — common to all APIs — was
moved here. Examples include:
Pathnames:
File locations have changed between HP-UX 9.x
and HP-UX 10.x, with its new, standardized
V.4 file system structure.
Creating device files: Regardless
of whether it is Starbase, HP-PHIGS, or HP PEX that creates an image,
you have to tell the operating system where the display is and how
to talk to it.
Compiling and Linking: The
process of turning your source code into executable code has many
common ideas, regardless of API or file system structure.
X Windows issues: All APIs
interact with X windows, so non-unique X Windows information comes
here.
The above topics, and others as well, are good candidates
for a common area. With this approach, only one copy of the common
information need exist, and revisions can happen in a more timely
manner, and at less risk of contradicting other documents.