[Printers] Minolta MagiColor 2210

[Eduardo Luís]

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