[Drawkit] Grid span issues

[Graham Cox]

On 24 Jul 2008, at 2:21 am, Brad Larson wrote:

> I think so, yes.  Most of the other vector and CAD drawing programs  
> I've worked with in the past have just used major and minor grid  
> lines, so maybe eliminating the "span" term and going with the  
> unitToPointsConversionFactor that is set in the DKDrawing would be  
> the way to go.  Then you could set up and draw only the major and  
> minor grid lines, and snap to the minor grid lines (if grid snap is  
> on).

If you look at almost any real piece of printed graph paper (e.g. that  
produced for professional use such as Chartwell's) it has three levels  
of line weight. It does make it easier to grasp the scale of data in  
many cases, so I wanted to make something that emulated that in DK.  
The fact that other CAD programs don't bother is probably because in  
the past drawing really fine lines was hard to do and it wasn't  
feasible to emulate printed graph paper. Really early attempts at  
grids (as in MacDraw for example) don't look anything like real-world  
graph paper, as the smallest thing that could be drawn on the screen  
was one solid pixel. While that was a very common approach for grids  
on a computer display that everyone got used to, don't lose sight of  
the fact that it was a compromise and that now it's no longer really  
necessary.

So I do wish to keep the three levels in other words, which means that  
terms need to be used to describe them - hence "span" which is both  
the middle line weight drawn and establishes the grid spacing relative  
to the underlying coordinate system. Maybe there's already a term for  
this other than "span" but if so I don't know it!

My initial scheme was always to have span as 1 x whatever the  
conversion factor was, but I realised that this isn't quite flexible  
enough. If you want a scale where 1km = 1cm for example, but only draw  
the middle line weight at 2km (2cm) intervals, the original scheme  
doesn't allow it. The modified scheme should allow it by passing the  
1cm conversion factor as the unit distance, and 2 as the span. That  
also explains why I changed the method name to specify "unit distance"  
since it's meant to convey the idea of the distance of one unit of  
your measurement system, as distinct from span which is the number of  
these units between the span grid lines.

> In any case, attached are the files for a DKGridLayer that stores  
> the span locally, as it did in Beta 3.  Also, I added a workaround  
> in the createGridCacheInRect: method for the case where mSpanCycle  
> is 0, which leads to an infinite loop and complete consumption of  
> system resources.  This happened to me a couple of times when  
> setting a span of 10.0 using my small units.

OK, I added that fix to my code too. The cycle shouldn't be permitted  
to drop below 1 - I'll look into making sure of that.

> It's a little confusing as to what units (Quartz or drawing) to use  
> where, but the following works right now for setting up a grid with  
> 100 micron spacing for minor lines, 1000 microns for major lines,  
> groupings of major units that are 2-wide, and a nice power of 10  
> step up / down on the rulers:
>
> [grid setDistanceForUnitSpan:kSPMicronToPointsConversion  
> drawingUnits:@"Microns" span:1000.0 divisions:10 majors:2 rulerSteps: 
> 10];

To be honest, it is quite confusing, even to me! But I think we are  
getting there. I assume your kSPMicronToPointsConversion value is  
quite small, though possibly not an actual micron (which would equate  
to 2.834645669291e-03). If that were the case the above would yield a  
span of 1mm which would be pretty dense.

Anyway, I have revised the code - see if it does the job for you. I've  
removed the setSpan:divisons:majors: method so that everything is now  
done using the more complex method but it should reduce the confusion.  
Note that the demo code will not compile with this modified code  
because it currently calls the old method directly, but it's easy  
enough to revise if you need to, as I have done myself.

cheers, Graham


-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKGridLayer.m
Type: application/octet-stream
Size: 48598 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080724/cc530bb3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKGridLayer.h
Type: application/octet-stream
Size: 6891 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080724/cc530bb3/attachment-0003.obj>