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.