[Printers] Minolta MagiColor 2210

[Michael Sleator]

>Very cool.  I would suggest moving the window up or down one row, as that
>puts the "lonely" red dot on the top row next to the "lonely" blue dot in
>the lower left.  This makes all the dots at most sqrt(5) away from each
>other, which seems to tie in nicely to the fact that both patterns have
>30 dots.
>
>Perhaps the data is encoded as the offset of each dot from a given "home
>position"?
>
>Whatever this encoding is, it does seem to provide for nicely scattered
>dots.


See the attached image for a possible interpretation of the code
structure.  The basic idea is that the space is divided up into
2-dimensional blocks, and each block represents some number of bits
in a 1-of-N code.  This achieves the required dispersal of the dots.

There are some interesting properties.  In the scheme I've shown,
there are in fact 30 blocks, which matches the code samples we have.
As you'll see, there are a couple of anomalies in the arrangement
shown, so there might be some subtleties or tweaks that I haven't
accounted for.  One anomaly is the dot at (23, 0), which is in a
forbidden region.  The other is the (1, 1) (center cell) block,
which is empty.  It is tempting to think of the (23, 0) dot as a
transcription error, but it is common to both data sets, so it's
probably not.  I haven't gone back and explicitly verified it in
the scanned images yet, though.  If the (23, 0) dot were displaced
one cell to the right it would wrap back into the (1, 1) block,
which would be very tidy.  The next most tempting rationalization
is that these two anomalies (or single anomaly, depending on how
you choose to think about it) are an explicit violation of the rule,
serving as a synchronization marker.  It is gratifying that the
anomalous dot appears in a corner of the pattern, which does seem
like a nice place to put a marker.

Another interesting property of the alignment I've shown is that,
except for the dot at (21, 3), the leftmost column of each block
is never used.  It would be interesting to see if this holds
true across a larger sample population.  If that's the case,
then the blocks should probably really be 2x3 rather than 3x3.
It is also gratifying that this justifies the pair of orthogonally
adjacent dots at (15, 5) and (15, 6), which had been bothering me.
They could be split by selecting one particular vertical phase,
but that phase puts a blank row in the middle of the pattern, not
at the edge (15), as it so neatly falls out here, and it has other
problems that I was not able to accommodate easily.

I haven't looked very hard at actually interpreting the bit values
in this context, so that might be a productive area to consider.
As always, working from a very small sample set is problematic,
so more samples would be very welcome.

BTW, the attached image is a screen snapshot from a tool I hacked
together to play with this stuff.  Investigating the  printer
tagging has mostly been an excuse to get some more experience in
Python and Tkinter programming.  (My apologies to the list at large
if attaching a 12kB image is an annoyance.  It didn't seem quite
worth the bother of putting it on a web server at this point.)

Michael Sleator
sleat at sleator.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11785 bytes
Desc: not available
Url : http://frotz.zork.net/pipermail/printers/attachments/20051120/49ddda76/attachment.png