Graph Reader V2.0 (C) Ju Li 1999

Purpose:

Instructions:

• The program uses both JavaScript and Java, and they need to be enabled in the browser. There are no other system requirements.

• To map a linear graph, it suffices to set three anchors. I.e., you tell the program what x,y the current pointer corresponds to. Usually an anchor could be the origin or either end of a graph's axes. To set anchors,
  • Click on any point in the graph. You see a dot indicating the pointer.

  • Use Up,Down,Left,Right arrow keys to precisely move the pointer to desired position (Ctrl or Shift accelerates its motion). Ctrl/Shift with mouse clicks will also do.

  • Press Return to highlight the text field at bottom. Type in actual x,y values separated by space.

  • Press Return or click the Set 1st anchor button to submit the data. Same for the 2nd and 3rd anchors. If you further click the button, you mean to reset all three anchors.

  The three anchors should not be degenerate, i.e., they should not be all on a straight line. Also, it is crucial to tell the program their accurate x,y values. If the program considers the three anchors "sick," it will ask the user to restart from scratch by showing Set 1st anchor button immediately.

• After the anchors are set, you can see the pointer x,y values in the status bar. Press s to save this data.

• Press d to delete a saved data that is nearest to the pointer.

• Press c to clear all saved data.

• Check show saved box to see your saved data on graph.

• You can dump your saved data to Java console by clicking buttons MLB (Matlab raw data), LTX (LaTeX table), or HTML (table). That can then be pasted to your text editor. To turn on Java console,
  • Netscape Communicator 4.0-4.05: Communicator->Java Console.

  • Netscape Communicator 4.5: Communicator->Tools->Java Console.

  • Microsoft Internet Explorer 4.x: if you have not enabled Java console in MSIE, you need to do this first: View->Internet Options->Advanced->Java VM->Java Console Enabled, then restart MSIE (you only need to do it once). Then, to toggle Java console: View->Java Console.

• V1.0 (JDK 1.0.2) coded in 1997 for my fiancee. Only Netscape on Sun workstations. Unstable on other platforms. The current version is in JDK 1.1.3, tested on i386 RedHat Linux Netscape 4.61, SGI IRIX Netscape 4.07, Microsoft Internet Explorer 4.x.

• The pathological interaction between keyboard events intercepted by handleEvent(), and applet top management and input TextField in V1.0, is now resolved by adding a KeyEvent receptor (pseudo-TextField or applet this) that gets all command keys, a bit like two modes of vi. The switch is the return key.

• It suffices to define just two anchors if the graph is orthogonal and "sitting up." But the scanned image is often slightly rotated, and I don't want this error to exist in the program. To benchmark V2.0's precision, try test.gif generated by test.m. A conservative estimate is 1% relative error for reasonable images. And the larger the image is, the higher the precision.

• To pick your color for the pointer, refer to rgb.html. My favorite is SteelBlue4. The original width and height of an image can be determined by loading the raw image into the browser, right click on it, and look for Properties or View Page Info. Use magn factor (default=1.0) to enlarge or shrink your graph. If the image is larger than the browser, pressing Up,Down,Left,Right arrow keys when the mouse cursor is outside the applet will force the browser to show scrollbars. You can always regain the focus for KeyEvents by clicking in the graph.

  Background color of the graph is taken to be white but that can be changed. To make sure that the pointer works for transparent gifs like trans.gif, I cover the floor with this color before drawing the real image on it, and the pointer color is what one gets when drawing on that color. In case your image is not transparent and the majority of its dots are red instead of white, then the program should be informed that the background is FF 00 00, in order to gain your desired pointer color when drawing on red.

• It is against security restrictions to let a Java applet sent by an "untrusted" server - running now on the client browser, to read or write the local file system. It is also against security restrictions to have third-party communication other than between the browser and the server. Thus, embedable Java applets are mostly "blind performers" who need little viewer information. The only viable method is to let reader.htm, reader.class be on the same computer as the digitized graphs. There are, of course, two ways to do this.

• The programmer writes paint(g), but the applet may pass graphics contexts other than getGraphics() - the whole context you see on the screen - to paint. When an overlapping window is pushed down, the applet may ask paint to draw on a "different" and smaller g, then transfer (copy or simply "on"?) to getGraphics(). Watch the action of a slow IE after we insert a line g=getGraphics(); at the beginning of paint(g) - in this case the entire graph is redrawn every time, whereas previously it only draws in the overlap region, which is more efficient.

  The priority of applet is speed and memory. It does not care about your discomfort with screen flickering. In first download and repaint() - g  is  getGraphics() - and the applet will directly draw on getGraphics() through update(g) to paint(g), unless you override update(g). Double-buffering decreases frame rate but is visually more appealing. One draws on bak_g, then copies to (instead of draws on) g. Management would never do that voluntarily.

  Once we see that g may not be getGraphics(), confusions about setXORMode are cleared. Basically, if the current context color a=g.getColor() [which can be set by g.setColor(a), or to be the initialized black], after which g.setXORMode(b), then if we draw thereafter on g's dot of color c: c -> a (+) b (+) c. Thus, if a is picked or made to be the "background color" of g, where the majority of g's dots have c=a, then it would turn b after we draw on the background once. On other dots (like a yellow circle in mostly white background), the result is unpredictable, but always reversible before setXORMode is changed. The point is, it is important to be sure that a=g.getColor() is what you think it is before running g.setXORMode(b), otherwise you won't get the planned effects - like getting b when drawing on the background of g.