Diagrab Guide

     by techkn@ck    
Installation Files Enter code to create installation files:
downloads Download Diagrab
General download help

Diagrab creates diagrams in HTML code. The diagrams are built from a small number of line and arrow images.
Each diagram is an HTML table. The diagrams download quickly, and the HTML code is easy to edit and can be scanned by text search programs.
Diagrams are created using a graphical editor, which operates on a grid of either 20x20 or 50x50 pixel cells.

Image File naming conventions

The file names beginning with 20 or 50 indicate that the shape occupies a 20*20 or 50*50 pixel square,
except for
  1. Horizontal (EW) lines where the stem ends with a lower case n (e.g. 50EWn), in which case the shape is 50 pixels in the direction of the line, but only as wide as the shape is in the other direction. This is to allow for text to be placed in the same cell as a line, above and/or below it.
    There are also versions of these lines which extend across 2,3,4, and 5 normal cell widths (50EWn2, 50EWn3 etc.), for use in extended cells to avoid having e.g. multiple 50EWn image elements.
  2. Horizontal (EW) lines and arrows, where the stem ends with a lower case m (e.g. 50EWm), which is similar to above, except that the shape include blank pixels to the width of an arrow head, so that text on lines ending with an arrow will line up.
    For the lines (but not the arrows) there are versions which extend across 2,3,4, and 5 normal cell widths, as above.
  3. Shapes where the stem ends in lower case z, which have smaller widths.
    There is currently only one such shape: 20NSvWz , which is to allow text to be packed closer to the left apex of a decision diamond.
  4. Shapes where the stem ends with H or V, which are thin blank lines which surround and define a grid.
    For the diagram editing grid, the lines are black instead of blank so that cell overflows will show up as breaks in the grid border. For these the stem ends with Hb or Vb.
Files beginning with 20 are similar to the 50*.gif files, except for their smaller size.
Following the size digits, upper case letters of the four points of the compass (N E S W), starting with N and going round clockwise, indicate the end points of the image (e.g. a horizontal line is 20EW.gif ).
If an endpoint ends in a corner, a lower case compass point letter follows the upper case one, using normal conpass conventions (Ne, not En).
Also, a lower case c follows the size digits (to avoid confusion between e.g. NESW and cNeSw .
[- there is a problem with image end points in corners - if the line width is greater than one pixel, the line will appear pinched at the corner. Could Have additional images in neighbouring squares which fill in the missing pixels, but this is very clumsy. Corner end points are best avoided.]

Ther are two exceptions to the 'clockwise' rule:
1) If there is an arrowhead in the image. The destination compass point then comes last, and is preceded by the digit 2. e.g. 20W2E.gif .
2) If two lines cross but do not intersect, the line identities are retained, and a lower case x is placed between them.
e.g. NESW , but NSxEW .

If lines do not pass through the centre, and form a 'v' at one point, or are just a slanting line across one corner, then a lower case v is inserted before the apex of the 'v', or between the letters if there are only two.
e.g. NSvW , NvW , NvWxEvS .
Rounded lines across corners have a lower case r between the compass points. e.g. NrW .

Diagrams are usually drawn on a standard grid, consisting of an array of squares, each 50*50 pixels, or 20*20 for thumbnail diagrams.
See Diagram Template.

Lines have transparent backgrounds, and will overlay boxes etc if declared after them. e.g.
<tr><td><img src="50N2E.gif"></td>
<td rowspan=2 colspan=2 class="boxy">box 2x2</td></tr>
<tr><td colspan=3><img src="50SE.gif"><img src="50W2E.gif"><img src="Printer.gif"></td>
box 2x2

e.g.
<tr><td></td><td><img src="50EvS.gif"></td>
<td>Yes<br /><img src="50EWm.gif"><br /><br /></td></tr>
<tr><td><img src="50EW.gif"></td>
<td colspan=2><table border=0 cellspacing=0 cellpadding=0 rules=""><tr>
<td><img src="50NSvWz.gif"></td><td>Decision</td>
</tr></table></td></tr>
<tr><td></td><td><img src="50NvE.gif"></td><td> <br /><img src="50EWm.gif"><br />No</td>
Yes
Decision


No

Line Positions and Diagonal Lines

Horzontal and Vertical line width is 2 pixels. Diagonal lines are 3 pixels horizontally or vertically, so for a line at 45° the width of the line alternates between 1.414 and 2.818, vor an average of 2.12.

There is a general problem with extending diagonal lines (except those with a corner endpoint, which have a different problem - see above). Two adjoining diagonal lines will both have 3 pixels mirroring each other where they join, and the line will have a kink at that point.

With 3 pixel wide lines in a 20x20 pixel cell, horizontal and vertical lines can be central, but the diagonal problem remains.
The solution adopted in both cases is for diagonal lines nearest the NW corner to be one pixel nearer the corner than diagonal lines nearest the SE corner.
Since forward sloping diagonals can only be sequences of NW SE NW SE ..., there will be no kinks.
e.g. 20SvE.gif followed by 20NvW .
Similarly diagonal lines nearest the SW corner are nearer that corner than lines nearest the NE corner are to their corner.

Positioning Text

Class boxy is:
{background-color:#FFFFC0;text-align:center;vertical-align:middle;border-style:solid;border-width:1px;border-color:black;}
For some other text alignment (e.g. to line up with external arrows), it is usually easiest to start from the top by putting
style="vertical-align:top;"
in the td element [or use class boty], and using <br /> to space down.
- Text lines are normally about 20 pixels high, so arrows will normally point to lines 2, 4.5, 7, 9.5 etc.
If a text line is required at e.g. line '4.5', then try to split it into 2 parts at lines 4 and 5.

To draw a dashed line across a 3 col box, use 15 dashes: - - - - - - - - - - - - - - -

Text outside boxes, e.g. headings, is usually preceded by a 1x20.gif at the start of the line.
- This does cause any box such a line impinges to have a non-standard size.

Examples

Flat File Reports (N.B. Clicking on links will not work).
Internet Cache Avoidance.
Downloading Files Used in Download.

To Be Done

  1. Nudge an Area instead of one cell.
  2. Nudge by a Number of Cells instead of just one position at a time.
  3. Set Cell Size from list of sizes.
  4. Libraries of Diagram Parts in external files.
  5. Undo more than one level.
  6. Line drawing to be more intelligent.

Colour Tester

+10
+1
Colour test: #                
-1
-10
        - this is just a colour tester/adjuster.


Mozilla vs IE

  1. With IE, if put a newline before </td>, then will get 4 vertical padding pixels which will break up any graphics lines.
    If newline is desirable for source layout, can comment it out with <!-- -->.
    Moz/FF is OK.
  2. If set border=0 in the css definition, then Moz/FF displays all OK (with no border). [But see strict.dtd below.]
  3. With Moz/FF, the border in class boxy displays as 3 pixels for any non-zero value of border=.
  4. IE sets the border to the specified size, and does it by overlaying the graphic, so the size including the border does not change, whatever the value of border= (even zero).
  5. One and a half of these 3 pixels is outside the graphic, so the box is 3 pixels too big.
  6. If add
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    before the <html> element (see W3C Recommended list of DTDs)
    then IE also displays 3 pixel borders for any non-zero value of border=.
    However, these are displayed inside the cell graphic area, so the overall picture is OK.
    Adding this to Moz/FF causes more small scale padding which breaks up the adjoining lines, and this effect persists even if set border=0.
  7. With Moz/FF, some border parts are missing, mostly bottom and lower right edge.
    - If change border-style-solid to border-style=inset, lose more left and right edges.
  8. On occasion (i.e. once) with Moz/FF, the right border extended down past the box till it hit something.
  9. With Moz/FF, there appear to be 2 pixels of padding above and below text outside the boxes, but this effect vanishes if set border=0.
  10. Several websites say that for IMG elements IE incorrectly puts the border outside, while FF correctly puts it inside.
N.B. Layers round content are: Content | Padding | Border | Margin. The Margin is always transparent.

Also see: Mozilla Quirks Mode Behavior.

Things that made no difference:

<tr style="max-height:50px;">
<tr style="pixel-height:50px;"> (Not standard, and does not apply to HTML anyway.)
<col span=16 height=50px>
<col span=16 style="border-width:0;">
<col span=16 style="border-style:none;">
<style>td {border-style:none;}</style>
<style>td {margin:0;}</style>
<style>td {padding:0;}</style>