Remote Imaging Protocol
Scripting language
The Remote Imaging Protocol and its associated Remote Imaging Protocol Script language, RIPscrip, is a graphics language that provides a system for sending vector graphics over low-bandwidth links, notably modems. It was originally created by Jeff Reeder, Jim Bergman, and Mark Hayton of TeleGrafix Communications in Huntington Beach, California to enhance bulletin board systems and other applications.
RIPscrip was introduced in 1992 and consisted of ASCII-text descriptions of vector-drawn graphics and images, along with facilities to create menus and clickable buttons. These were sent from the BBS instead of the more common ANSI color-coded text-mode screens, and were interpreted on the user's end by a RIP-enabled terminal program such as TeleGrafix's own RIPTerm. Lines of text appeared in one display, graphics in another. RIPscrip could not be used as the basis for a complete GUI, as it included no text editing system.
RIPscript 1.5x was a text-based wrapper around the Borland Graphics Interface (BGI). Drawing primitives all relied on the BGI, fonts were limited to those provided by the BGI (*.CHR). RIPscrip icon (.ICN) file format was that of the BGI getImage() and putImage() functions. The choice to include the BGI flood fill function was considered by many to be a mistake, as third-party implementations of the RIPscrip protocol often failed to implement Bezier curves the same way Telegrafix had, thus leading to the flood fill leaking out of the intended object and filling the entire screen.
This brief starts where responsible research should: with the source description of “Remote Imaging Protocol” as scripting language. Everything that follows is an evidence route, not borrowed authority.
Why this record matters
The subject matters to the general reference register because the source frames it as scripting language. Its deeper value depends on whether names, dates, institutions and citations support that framing.
Named sources, stable identifiers and responsible institutions provide the strongest route from overview to verifiable evidence. The source revision retrieved here is dated Sep 11, 2026. The linked authority identifier is Q7312156. None of the 0 selected statements returned an explicit reference. The first chronological checks are 1992.
Overview language is designed for orientation and should not be treated as a substitute for the evidence cited beneath it. The lead is largely declarative, so disagreement and counter-evidence require a deliberate search beyond the opening account. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.
How to read it
Use the entry as an orientation point, then follow its citations and revision history. Names, dates and institutional relationships should be checked against the original record.
- Subject orientation
- Search vocabulary
- Locating named sources
The closest primary source, responsible institution and strongest cited specialist reference.
Three-step research path
- Establish the record: confirm the title “Remote Imaging Protocol”, its source revision and the description used here.
- Expand the search: follow Remote Imaging Protocol primary sources, Remote Imaging Protocol archive and Remote research across catalogues and specialist indexes.
- Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.
Questions for further research
- Which source most directly establishes the central claim about “Remote Imaging Protocol”?
- What terminology or title could unlock a more precise catalogue search?
- Which cited source is closest to the event, object or claim?
Search terms from this dossier
This entry incorporates text from “Remote Imaging Protocol” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.