Notes on using the LBL Whiteboard	 Fri Jul 29 21:10:32 PDT 1994

Getting Started
---------------
 - Read the "lblwb.ps" document supplied with the distribution.

 - Read the CHANGES file to find out what has changed recently.

 - If you are running wb with sd 1.14 or earlier, sd's built-in wb
   script will be set up for an earlier version of wb & won't work
   with this wb.  To fix this, put the following in your ~/.sd.tcl:

proc start_whiteboard {} {
	global sd_sess sd_whiteboard wb
	set orient -l
	set recvonly -r
	foreach a $sd_whiteboard(attributes) {
		case $a {
			orient:portrait { set orient -p }
			orient:landscape { set orient -l }
			orient:seascape { set orient +l }
			recvonly { set recvonly -r }
			sendrecv { set recvonly +r }
		}
	}
	exec $wb -t $sd_sess(ttl) -C wb:$sd_sess(name) $orient \
		$recvonly $sd_sess(address)/$sd_whiteboard(port) &
}
set sd_menu(whiteboard) "orient: portrait landscape seascape\nrecvonly\nsendrecv"

Importing Postscript
--------------------
  Wb will allow you to import arbitrary postscript files.  However,
  it you import a file containing multiple pages, it *MUST* conform
  to the Adobe Document Structuring Conventions.  [The reason for
  this is that remote sites may image the pages in arbitrary order
  and unstructured, multipage postscript can only be rendered
  sequentially.]  If wb is given a non-conforming multipage document
  it will only image the first page.  However, such documents will
  always cause performance problems (the postscript renderer must be
  killed & restarted each time the document is rendered) and may
  cause wb to hang or not image subsequent ps pages.

  You should try to use a tool that produces DSC conformant postscript
  when preparing images for wb (e.g., idraw, Adobe Illustrator, SGI
  Showcase, etc.).  If you're stuck with postscript created by some
  piece of junk, you might try running it through distill (available
  from ftp.adobe.com, file still.ps) to turn it into DSCconformant
  postscript.

  wb keeps a cache of the Postscript pages it has recently rendered
  so that they don't have to be re-rendered as you flip between
  wb pages.  This cache is in the form of pixmaps in the X server.
  These pixmaps can cause your X server to grow quite large:  At
  the default wb page size (612 x 792), each pixmap takes 60KB on a
  monochrome display & 480KB on a color display.  If wb is expanded
  to full screen, each pixmap takes ~1MB on a 1100 x 960 sun screen.
  By default wb caches 16 pixmaps (or ~8MB of server space on a
  color display with a default wb window).  You can change the X
  resource wb.RasterCacheSize to some other number to increase or
  decrease the size of the cache.

Using wb for seminars
---------------------
  The tool 'wbimport' may be useful if you are plan to give
  a seminar over the Internet using wb.  If you don't have it, it's
  available on ftp.ee.lbl.gov, file wbimport.tar.Z.  Note that this
  is a tool for the person giving the seminar, not the people receiving
  it.

  When using wbimport to send your slides, you will find it much
  easier if each of your postscript foils is in a separate file
  (As opposed to one file containing multiple postscript pages).
  Also, since wb's output is rate limited, the seminar will be slowed
  down if you try to ship large postscript files.  Try to keep your
  foils simple.  If the foils are in separate files, it is also a very
  good idea to convert them to LZ-compressed postscript (using the
  lzps filter included in the wbimport distribution).  This will
  reduce the amount of data that has to be sent over the net by
  factors of 3 to 10, depending on the page content.

Color Usage
-----------
  nv, imm & wb (when you render color postscript) all need space in
  the colormap on 8-bit color displays.  They all want a lot of colors
  so they conflict.  The following will let you run all three
  simultaneously with no conflicts:  The X11R4 release added a
  'standard colormap' for use by applications that need to map a
  large color space (like 16-bit video or 24 bit jpeg) into a smaller
  one.  You create this map by doing "xstdcmap -default" shortly
  after starting your X server.  Ron Frederick has set up nv so it
  will use colors from this map (plus a few more).  Display Postscript
  will use only colors from this map.  We have modified Ghostscript so
  that it will use only colors from this map.  Xv (used by imm) should 
  use colors from this map but doesn't (we're fixing that) but since
  it uses whatever colors it can get, imm will work as long as you
  run xstdcmap & start nv *before* starting imm.  So the receipe is:
   - set wb to use DPS or get the modfied gs from ftp.ee.lbl.gov.
   - start an nv (say on Mbone video) to create the additional
     colormap cells nv needs.
   - run as many wb's, nv's & imm's as you want.

Postscript rendering and X server memory usage
----------------------------------------------
  If you use gs for postscript rendering, you'll probably find
  its fonts look awful.  Gs can use real Adobe PostScript fonts
  and they look *much* better than the fonts supplied with gs.
  Unfortunately, you have to purchase Adobe fonts.  However you
  might already own them:  If you're on a DECstation or SGI,
  the Adobe fonts came as part of the Display Postscript built
  into the window system they're in /usr/lib/DPS/outline/base on
  the SGI and /usr/lib/DPS/outline/decwin on the DECstation).
  You can simply set up the ghostscript fontmap file (usually
  /usr/local/lib/ghostscript/Fontmap) to reference these fonts
  instead the public domain ones.  If you don't have DPS but
  have purchased ATM (Adobe Type Manager) for a Mac or PC, you
  have the Adobe fonts on your Mac or PC.  If you can find some
  way to get the font files from your PC to a workstation, they
  can either be used as-is by gs or there are programs in the gs
  distribution to convert them to a usable form.
