[GRASS-SVN] r38328 - grass/trunk/lib/display

[svn_grass at osgeo.org]

Author: martinl
Date: 2009-07-09 05:59:33 -0400 (Thu, 09 Jul 2009)
New Revision: 38328

Removed:
   grass/trunk/lib/display/rastergraphicslib.dox
Log:
remove outdated doxygen file


Deleted: grass/trunk/lib/display/rastergraphicslib.dox
===================================================================
--- grass/trunk/lib/display/rastergraphicslib.dox	2009-07-09 09:12:01 UTC (rev 38327)
+++ grass/trunk/lib/display/rastergraphicslib.dox	2009-07-09 09:59:33 UTC (rev 38328)
@@ -1,139 +0,0 @@
-/*! \page rastergraphicslib GRASS Raster Graphics Library
-
-\section intro Introduction
-
-The <i>Raster Graphics Library</i> provides the programmer with access to 
-the GRASS graphics devices. <b>All video graphics calls are made 
-through this library (directly or indirectly)</b>. No 
-standard/portable GRASS video graphics module drives any video display 
-directly. This library provides a powerful, but limited number of graphics 
-capabilities to the programmer. The tremendous benefit of this approach is 
-seen in the ease with which GRASS graphics applications modules port to new 
-machines or devices. Because no device-dependent code exists in application 
-programs, virtually all GRASS graphics modules port without modification. 
-Each graphics device must be provided a driver (or translator program). At 
-run-time, GRASS graphics modules rendezvous with a user-selected driver 
-module. Two significant prices are paid in this approach to graphics: 1) 
-graphics displays run significantly slower, and 2) the programmer does not 
-have access to fancy (and sometimes more efficient) resident library 
-routines that have been specially created for the device.
-
-This library uses a couple of simple concepts. First, there is the idea of a 
-current screen location. There is nothing which appears on the graphics 
-monitor to indicate the current location, but many graphic commands begin 
-their graphics at this location. It can, of course, be set explicitly. 
-Second, there is always a current color. Many graphic commands will do their 
-work in the currently chosen color. The programmer always works in the 
-screen coordinate system. Unlike many graphics libraries developed to 
-support CAD, there is no concept of a world coordinate system. The 
-programmer must address graphics requests to explicit screen locations. This 
-is necessary, especially in the interest of fast raster graphics.
-
-The upper left hand corner of the screen is the origin. The actual pixel 
-rows and columns which define the edge of the video surface are returned 
-with calls to <i>R_screen_left()</i>, <i>R_screen_rite(), 
-R_screen_bot(), and R_screen_top().</i>
-
-<b>Note.</b> All routines and global variables in this library, documented 
-or undocumented, start with the prefix <b>R_.</b> To avoid name 
-conflicts, programmers should not create variables or routines in their own 
-modules which use this prefix.
-
-
-\section conn Connecting to the Driver
-
-Before any other graphics calls can be made, a successful connection to a 
-running and selected graphics driver must be made.
-
-- R_open_driver()
-
-- R_close_driver()
-
-\section col Colors
-
-Colors are set using integer values in the range of 0-255 to set the
-<b>red, green</b>, and <b>blue</b> intensities.
-
-- R_standard_color()
-
-- R_RGB_color()
-
-\section basic Basic Graphics
-
-- R_box_abs()
-
-- R_erase()
-
-\section poly Poly Calls
-
-In many cases strings of points are used to describe a complex line, a series of
-dots, or a solid polygon.
-
-- R_polydots_abs()
-
-- R_polygon_abs()
-
-- R_polyline_abs()
-
-\section text Text
-
-These calls provide access to built-in vector fonts which may be sized and
-clipped to the programmer's specifications.
-
-- R_set_window()
-
-- R_font()
-
-- R_text_size()
-
-- R_text()
-
-- R_get_text_box()
-
-\section font GRASS font support
-
-The current mechanism of GRASS font support is this (all files are in the
-directory display/drivers/lib unless stated otherwise):
-
-<ul>
-<li> A client calls R_font(), which sends the filename
-  ($GISBASE/fonts/font_name) to the display driver using the FONT command. See
-  lib/raster/Font.c.
-  
-<li> The display driver receives the FONT command and the filename. See
-  command.c.
-  
-<li> It passes the filename to Font_get() (Font_get.c), which passes it to
-  init_font() (font.c), which reads the file into memory.
-  
-<li> A client draws text by calling R_text (lib/raster/Text.c), which
-  sends the string to the display driver using the TEXT command.
-  
-<li> The display driver receives the TEXT command and the string. See command.c
-  (again).
-  
-<li> It passes the string to Text() (Text.c) which calls soft_text() with the
-  string and several stored parameters.
-  
-<li> soft_text() (Text2.c) calls drawchar() (same file), to draw each
-  character.
-  
-<li> drawchar() calls get_char_vects() (font.c) to retrieve the actual vector
-  definitions. It then draws the character using text_move() and text_draw()
-  (same file), which use the Move_abs() and Cont_abs() functions (these are
-  implemented separately by each display driver, e.g. XDRIVER).
-</ul>
-
-\section load Loading the Raster Graphics Library
-
-The library is loaded by specifying $ (RASTERLIB) in the Makefile.
-
-<b>Note.</b> This library must be loaded with $(GISLIB) since it uses 
-routines from that library. See \ref GIS_Library for details on that 
-library. This library is usually loaded with the $(DISPLAYLIB). See 
-\ref Display_Graphics_Library for details on that library.
-
-See \ref Compiling_and_Installing_GRASS_Modules for a complete 
-discussion of Makefiles.
-
-*/