When you set the model up, "fore" is farthest from the user etc.

But the model rotates in 3D. The programmer using the library may choose to initially display the chart with any orientation; and the user may rotate it to any orientation.

I find dealing with humans simplest for humans to understand.

The point is, anterior means in-front for a human being; but means below, towards the ground for a horse; so the obscure terminology would be ambiguous even to those few who are familiar with the medical/biological/anatomical terms; depending on whether the come from medical/veterinarian/piscean fields; and more so for programmers.

Anticlockwise as seen by someone looking forward.

I did say it was rhetorical; but ... the lookout on watch on one ship calls down to the helmsman: "The ship coming towards us on the bow is yawing to port. Take evasive action!".

Does the lookout mean the other ship is yawing to its port; or the port of the ship he is on?

And if the same message is being sent to the helmsman from an observer on shore, does that observer mean "your port" or "his port"?

And if teh observer is in a helicopter overhead; does he mean the helmsman's port, the other ship's port, or the helicopter's port?

And is the rule: pass the port to the right? Or left? :)

facing the 'back' -- Whatever fits your brain, but I think you're making problems for yourself here, as this is the opposite of how the user will see (and therefore think about) it.

Hm. Didn't you just say: "fore" is farthest from the user. And isn't fore the same as front the same as your nose. Ie. Facing the same direction as the viewer.

This is where I need to know the purpose of the naming. If it's for the programmer

As I mentioned in the OP, this is purely for (re)naming the variables within the program. (I think the original author must have had a stutter; because almost without exception, every variable in the code is called xx, yy, uu, vv, gg, pp, mm, nn, dd, ii, jj etc. which makes the function _BoundingBoxDraw() pretty much unreadable.

I've refactored that huge, repetitious function into:

function _BoundingBoxDraw( ) {
    var frontOrBack = ( ( this.Parent.Fi < 90 ) || ( this.Parent.Fi >=
+ 270 ) ); 
    var leftOrRight = ( this.Parent.Fi >= 180 );                      
+          
    var topOrBottom = ( this.Parent.Th <= 0 );                        
+          

    drawFace( this, 'z', 'x', 'y', 0, 0, 1, topOrBottom, frontOrBack, 
+leftOrRight );
    drawFace( this, 'y', 'x', 'z', 1, 2, 3, leftOrRight, frontOrBack, 
+topOrBottom );
    drawFace( this, 'x', 'y', 'z', 2, 4, 5, frontOrBack, leftOrRight, 
+topOrBottom );
}
[download]

Where drawFace() is:

And drawGrid() is:

Which I believe is a vast improvement, but there is still work to do. In particular, the variables/parameters named cond1, cond2 & cond3 need urgent attention. And that is the crux of the problem. Those conditions determine which 3 of 6 faces (along with the associated gridlines, axis ticks and labels) of the bounding box are drawn, and that is determined by which of each pair of opposite faces are furthest from the viewer. Thus, any form of model-relative naming scheme is meaningless because which faces are drawn is determined entirely with respect of the viewpoint.

Whilst the names for those conditions work (sort of) for the top level code where the entire bounding box is being considered, once you get down to drawGrid(), the naming convention falls apart because the same routine is called to draw the grid lines on all six faces, so anything X/Y/Z, left/right/up/down/front/back, or any other model-relative terminology doesn't make sense at that level.

Ie. The horizontal and vertical gridlines on the 'back face' flow x-x and y-y respectively; but on the 'bottom face' they flow x-x and z-z; and the 'left face' z-z & y-y respectively. And that's before you rotate the thing and up is down, left is right, front is back; or somewhere in between.