[Printers] Minolta MagiColor 2210

[Michael Sleator]

Thank you.  Yes, the data in this image is a combination of your
Epson C1900 data and Michael Thorpe's MagiColor 2210 data.  The red
dots are exclusive to the C1900, the blue dots are exclusive to the
2210, and the magenta dots are common to both.  I described that briefly
in my previous version
(http://frotz.zork.net/pipermail/printers/2005-November/000085.html),
but I guess I didn't make it clear this time.  Sorry.

I hope a few more samples of this code will turn up (either from the
same models or from different models), as it will be very interesting
to see how they match the present trends.

regards,
Michael Sleator
sleat at sleator.com


>I think you have done a great job.
>Have you seen the Epson C1900 pattern I got?
>It's the same encondig and it even has dots in some positions.
>
>Take a look at:
>http://eluis.no-ip.com/printerdots/
>
>Thanks....
>
>
>-----Mensagem original-----
>De: printers-bounces at frotz.zork.net [mailto:printers-bounces at frotz.zork.net]
>Em nome de Michael Sleator
>Enviada: domingo, 20 de Novembro de 2005 9:48
>Para: Michael Thorpe
>Cc: printers at frotz.zork.net; Michael Sleator
>Assunto: Re: [Printers] Minolta MagiColor 2210 
>
>>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
>