Preface
Why This Document?
This document 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 and OpenGL.
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.
This document provides a more elegant solution. 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: Locations of important files.
• 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.
Graphics Administration Guide for HP-UX 10.20
Page 8