Re: Inkjet Driver for Chemcal Synthesis: msg#00095 linux.printing.gimp-print.devel

From: "Wayne Brooke-Devlin" <wbd@xxxxxxxxxx>
Date: Fri, 23 Jul 2004 16:09:40 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C470CF.7669C180
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0004_01C470CF.766B4820"

------=_NextPart_001_0004_01C470CF.766B4820
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,
Like Brooke, I'm interested in developing an Epson
inkjet driver for experimental chemical synthesis. Is anyone else
currently working on this, or is anyone interested in working on it with
me? If this doesn't interest, you then please feel free to stop
reading now. I have no desire to be responsible for anyone's
death due to this boringly long-winded and tediously detailed post.

I've been attempting to get a separated drop output using Gimp,
gimp-print, and an Epson Photo 960 as follows:

In gimp I created a 12 pixel by 12 pixel block at a resolution of
1440X1440dpi. In this block I then colored pixels 00, 60, 06, and 66
black (00 is the 0 x-coordinate, 0 y-coordinate pixel in the top left
corner of the block). I then saved this as a "fill"
pattern in gimp (0060.pat). This separation may seem excessive; however
I've calculated that a "spherical" 2 picolitre
drop of water should have a diameter of about 15.6 microns while at 1440
dpi an individual pixel should be about 17.6 microns across. If I assume
that the 2pL drop becomes hemispherical when it sits on a non-wetable
surface (I've been using transparencies), then that
hemispherical drop would be about 19.7 microns in diameter. In practice
the smallest droplets I've observed under a microscope have been
30 microns in diameter and the majority I've seen have been about
40 microns in diameter, so each drop occupies about 2 pixels and my fill
pattern should print a separation of 3 blank pixels between filled ones.

As Mr. Krawitz pointed out in his first comment, what I created was a
pre-dithered input. I used my pattern to fill a 1 inch wide by =C2=BD
inch tall rectangle in Gimp and printed it many times using different
combinations of gimp-print parameters. I got closest to the separation
I'd hoped for using 1440x1440 highest quality, 1440dpi
magnification, colored output, and very fast dithering (I know there
were some other parameters too but I can't think of them right
now). Near the center of the 1 by =C2=BD inch block thus produced I got
a nice grid of 40 microns drops separated both vertically and
horizontally by about 40 microns. However, for about the first 40 rows
from the top I got the following pattern. First, three rows of 40 microns
drops separated both vertically and horizontally by about 40 microns as
above. Then a row consisting of pairs of small 30 pl drops 5 pl
from larger 40 pl drops with about 40 microns of horizontal spacing
between each set of pairs. Further, the last third of the rows in the
printed figure consisted almost entirely rows of this paired dot
pattern.

At this point I became curious as to what the gimp-print driver was
actually telling the printer to do. So I saved a hex dump of the driver
output to file, and began parsing it by hand using Epson's ESCP2
manual, the programming manual for the photo 960, your ESCP2 info, and
anything else I could find on the subject. I now understand some of the
remote mode commands (more than a few still appear undocumented), most
of the ESCP2 commands (a few confuse me, perhaps we can discuss this
later), but I'm rather lost when it comes to the actual data
encoding. For instance, I would have expected my pattern of one dot
every 6 spaces to be encoded as 82 08 20
(1000/0010/0000/1000/0010/0000), but what I get is 92 49 24
(1001/0010/0100/1001/0010/0100). Is this due to dithering? Or is it that
I don't yet understand weaving? (I'm working on
understanding both) Also, the count byte for each row calls for (hex) 57
or (dec) 87+1=88, 16 bit bytes, but a one inch row at 1440dpi would
require 90*16 =1440 bytes. I do note that after the 88th byte the
final 2 bytes do appear, although they are separated by 00's (ie
92 00 49 00 24). I hope someone can give me a better grasp of the data
encoding. It may seem odd to you that I looked at the hex output rather
than your source code as a starting point here. In my defense, I can
only say that I'm a chemical engineer who's done a good
bit of work in instrumentation and control. So I'm a lot more
comfortable with the assembly language of ESCP2 than I am with the
higher level (C code?) of your drivers. It was only at the point where I
saw how different the output data was from what I had expected that I
began to recognize how much the drivers were massaging the input. I
entered this project imagining that I might control the printer like an
old 9-pin dot matrix printer. You know: move the head x move, the platen
y, fire pins 1,5,7, etc. Oh boy! Was I wrong.

At any rate, the pre-dithered input problem appears to be of concern to
me and several others here:

By: David Barkin - ulzana <http://sourceforge.net/users/ulzana/>
<http://sourceforge.net/forum/message.php?msg_id=2233095> [EXT]
Stochastic Screening
2003-10-11 19:31

From: Andrew A. Gill <superluser@xxxxx>

<http://sourceforge.net/mailarchive/message.php?msg_id=9021842> Darn
you, stochastic dithering! I shall be avenged!

2004-07-20 21:38

Jernot Judman (support requests)

Linux printing 16 bit pictures

2003-05-11

I suspect that the replies to these posts hold some of the information
needed to enable pre-dithered input. As must be fatiguing obvious by
now, I'm pretty highly motivated to work on this project. I see
a lot of potential for many types of micron-scale manufacturing here.
Sort of like rapid prototyping that produces by deign not a model of
something, but the useable thing itself.

Concerning Mr. Krawitz's second and fourth points, to me they
appear somewhat related. I've tried taking one of my 1 by 2 inch
printed blocks and re-feeding it through the printer for a second (over)
print. I found very little displacement in drops between the first and
second prints. For the most part, at least in the area where I had the
desired separation, the second coat of drops appeared to be right on top
of the first. I think this is referred to as very good registration.
However, I haven't examined if the printer is capable of placing
one colored drop directly on top of another during a single file
printing cycle. This might be useful, but I don't think
it's essential for what I have in mind. What I've been
thinking of is a print file consisting of the initial remote and ESCP2
commands followed by the data for my pattern. Then, rather than ejecting
the page, the file would instruct the printer to reverse feed to the
position at which it had started printing the pattern. Following the
reverse feed the file would contain the data to reprint the pattern (or
print another pattern) which would be followed by another reverse feed,
and so on. I understand that Epson has eliminated the ESC j code for
reverse feeding, however I found a reference (I think in one of the
Epson manuals) to a set of paper feed values that allow for up to =C2=BD
inch of reverse feed. (I guess I'm going to have to find that
reference and make sure it works. I seem to remember it had to do with a
number exceeding a certain value being interpreted as negative. It made
sense when I read it anyway). You can see now why I've been
working with a block =C2=BD inch high.

Another possibility for reverse feeding may dovetail with the work
people here have been doing on CD printing. I've been hoping to
use something like the CD holder (or even the holder itself) as a
carrier for whatever material I use as a print substrate. I've
noticed that, once the tray has been properly positioned, the first
action of the printing cycle is to reverse feed (suck) the tray in by
=C2=BD an inch. If a figure =C2=BD inch high were then printed, then the
tray would return to its initial hand fed position. This would allow
another file of a =C2=BD inch high figure to be printed, and so on. I
think the printer indexes this initial movement using the paper-out
switch, which is a lever arm interrupting an optical sensor arrangement.
There's a slot cut in the CD tray, and when the tray is hand
positioned the lever arm above the paper path drops into this slot
(normally an out-of-paper or no-paper-loaded signal). I believe that the
printer reverse feeds the tray until the arm hits the top end of the
slot lifting it above the carrier (a paper-loaded signal) where it then
stops. The distance of the reverse feed is the =C2=BD inch needed to
position the topmost point on a CD to be printed above the highest jet
on the print head, and using the switch to do the positioning is likely
much more accurate than any human operator. The feed CD tray behavior is
quite different from the normal paper feed. Perhaps the instructions for
this feed are part of the undocumented remote commands. Conceivably, the
remote command might also point to a hard "EEPROM" coded
feed sequence.

I sincerely apologize for the great length of this post. I'll
try to keep it short in the future. I didn't intend to write a
novel here. I did however want you to have some idea of what
I've done so far, what I think a driver for this purpose might
need to do, and how I think such a driver might accomplish these ends.
Please let me know of your ideas. Many, if not all, of you understand
what must be done here much better than I do. I would sincerely
appreciate your advice and assistance. Also, if there's anything
I can clarify please let me know. Perhaps as a starting point, we might
outline the work needed to produce a non-dithering driver. I look
forward to hearing from anyone interested in this project.
Here's a final thought: Given that almost every computer in the
world has some sort of hard copy output device, isn't it
surprising how little information is available concerning their
operation. Thank God for Linux and the Linux community.

Your friend and I hope colleague,

Wayne Brooke-Devlin

By: brookepb ( Brooke )
Getting started writing customized drivers
2004-02-17 08:00
Hello,

I apologize for this being off-topic but tried to hit the open
discussion forum as the least offensive and I don"t know where else I
might find information to get started.

I am hoping that someone can point me toward more appropriate resources
for learning what I need to know to write custom minimal printer
drivers. My intention is to use an inkjet as an experimental chemical
synthesis platform for my research but find that while many people have
done so, they all seem to have jumped into making a company to exploit
their work and thus aren"t terribly forthcoming about methods and
techniques or they simply haven"t responded to my requests for "how"d
you do it?".

Unlike regular printing applications, I prefer my dots to be separated.
:o) I was hoping to be able to buy a five or six color printer with
variable drop size control and reverse line feed control. My custom
driver would just be able to let me say which cartridge (w/ the ink
replaced by my chemical of choice) would contribute to which location
and ideally the relative volume of the chemical deposited there. I
would
need to be able to revisit the same spot location multiple times so I
can react the different desired chemical combinations at that location.
This is just basic combinatorial chemistry but using an affordable (the
big driver here :o) and reliable chemical dispenser for my own
research.
This would of course critically depend on being able to return to the
precise location of a previous dot with close to no spread(spray) of
droplet fragments while in flight.

Any pointers to information about the appropriat forum for questions
like this, writing custom printer drivers and/or what off-the-shelf
common printers might fit the bill would be welcome.

Thanks,

Brooke

-=-=-=
By: rlk ( Robert Krawitz )
RE: Getting started writing customized driver
2004-02-17 17:33
This is actually reasonably on-topic, although it"s easier to
discuss on the gimp-print-devel mailing list, which you"re welcome to
subscribe to.

We don"t try to keep our stuff secret, obviously :-) This is a
rather interesting application. Gimp-Print as is won"t quite do what
you
want, although a couple of weeks of work could probably make it fit the
bill. There are a few issues I can see:

1) Gimp-Print doesn"t support pre-dithered input; you can give it
8 or 16 bits, but it dithers it down to the 1 or 2 bits that the
printers actually support. Adding this facility would be useful, but
it"s not at the top of my agenda. If you want to do it, though, it
likely wouldn"t be too hard to do. There"s also a way to work around
this with the 16-bit input; if you decide to proceed with this project,
we can discuss that.

2) Gimp-Print also doesn"t support overprinting in this way.
Again, this is a simple matter of software. It"s less interesting to
me,
since it doesn"t have a lot of application for general purpose
printing,
but it could be done if you wanted to without too much difficulty.

3) All of the printers that support variable drop size support
only 2 or 3 drop sizes at a given resolution, with fixed ratios. At
least, I"m not aware of any Epson printers that allow programming the
drop sizes in arbitrary ratios, and if there are, I don"t know how to
program them.

4) I"m not aware of any cheap inkjets that allow reversing the
feed (I"m not aware of any expensive ones that do, either, but that"s
neither here nor there). If there are, that"s also something that would
need to be reprogrammed in Gimp-Print, but that"s also a simple matter
of programming. The hard thing is finding the printer meeting your
specs.

5) Inkjets print in bands, and the printing pattern isn"t very
simple. They don"t simply print one row of dots and move to the next.
You could easily hack Gimp-Print to do that, though, but it would make
for very slow printing.

Gimp-Print 5.0 alpha supports a mode whereby you can control each
color independently (the "raw" mode). That would be ideal for your
purposes.

------=_NextPart_001_0004_01C470CF.766B4820
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=utf-8">

<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>

</style>

</head>

<body lang=EN-US link=black vlink=black>

<div class=Section1><pre>Hi,</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Like Brooke, I'm interested in developing an Epson inkjet driver
for experimental chemical synthesis. Is anyone else currently working on
this, or is anyone interested in working on it with me? If this
doesn't interest, you then please feel free to stop reading now.
I have no desire to be responsible for anyone's death due to
this boringly long-winded and tediously detailed
post.</pre><pre> </pre><pre>I've been attempting to get a
separated drop output using Gimp, gimp-print, and an Epson Photo 960 as
follows:</pre><pre> </pre><pre>In gimp I created a 12 pixel by 12 pixel
block at a resolution of 1440X1440dpi. In this block I then colored
pixels 00, 60, 06, and 66 black (00 is the 0 x-coordinate, 0
y-coordinate pixel in the top left corner of the block). I then saved
this as a "fill" pattern in gimp (0060.pat). This
separation may seem excessive; however I've calculated that a
"spherical" 2 picolitre drop of water should have a
diameter of about 15.6 microns while at 1440 dpi an individual pixel
should be about 17.6 microns across. If I assume that the 2pL drop
becomes hemispherical when it sits on a non-wetable surface
(I've been using transparencies), then that hemispherical drop
would be about 19.7=CE=BCm in diameter. In practice the smallest
droplets I've observed under a microscope have been 30=CE=BCm in diameter and the majority I've
seen have been about 40=CE=BCm in diameter, so each drop occupies about 2
pixels and my fill pattern should print a separation of 3 blank pixels
between filled ones.</pre><pre> </pre><pre>As Mr. Krawitz pointed out in his first
comment, what I created was a pre-dithered input. I used my pattern to
fill a 1 inch wide by =C2=BD
inch tall rectangle in Gimp and printed it many times using different
combinations of gimp-print parameters. I got closest to the separation
I'd hoped for using 1440x1440 highest quality, 1440dpi
magnification, colored output, and very fast dithering (I know there
were some other parameters too but I can't think of them right
now). Near the center of the 1 by =C2=BD inch block thus produced I got
a nice grid of 40=CE=BCm drops
separated both vertically and horizontally by about
40=CE=BCm. However, for about the first 40 rows from the
top I got the following pattern. First, three rows of 40=CE=BCm drops
separated both vertically and horizontally by about
40=CE=BCm as above. Then a row consisting of pairs of
small 30=C2=B5m drops 5=C2=B5m from larger 40=C2=B5m drops with about 40=CE=BCm of horizontal spacing between each set of
pairs. Further, the last third of the rows in the printed figure
consisted almost entirely rows of this paired dot
pattern.</pre><pre> </pre><pre>At this point I became curious as to what the
gimp-print driver was actually telling the printer to do. So I saved a
hex dump of the driver output to file, and began parsing it by hand
using Epson's ESCP2 manual, the programming manual for the photo
960, your ESCP2 info, and anything else I could find on the subject. I
now understand some of the remote mode commands (more than a few still
appear undocumented), most of the ESCP2 commands (a few confuse me,
perhaps we can discuss this later), but I'm rather lost when it
comes to the actual data encoding. For instance, I would have expected
my pattern of one dot every 6 spaces to be encoded as 82 08 20
(1000/0010/0000/1000/0010/0000), but what I get is 92 49 24
(1001/0010/0100/1001/0010/0100). Is this due to dithering? Or is it that
I don't yet understand weaving? (I'm working on
understanding both) Also, the count byte for each row calls for (hex) 57
or (dec) 87+1=88, 16 bit bytes, but a one inch row at 1440dpi would
require 90*16 =1440 bytes. I do note that after the 88th
byte the final 2 bytes do appear, although they are separated by
00's (ie 92 00 49 00 24). I hope someone can give me a better
grasp of the data encoding. It may seem odd to you that I looked at the
hex output rather than your source code as a starting point here. In my
defense, I can only say that I'm a chemical engineer
who's done a good bit of work in instrumentation and control. So
I'm a lot more comfortable with the assembly language of ESCP2
than I am with the higher level (C code?) of your drivers. It was only
at the point where I saw how different the output data was from what I
had expected that I began to recognize how much the drivers were
massaging the input. I entered this project imagining that I might
control the printer like an old 9-pin dot matrix printer. You know: move
the head x move, the platen y, fire pins 1,5,7, etc. Oh boy! Was I
wrong.</pre><pre> </pre><pre>At any rate, the pre-dithered input problem
appears to be of concern to me and several others
here:</pre>

<table class=MsoNormalTable border=0 cellpadding=0>
<tr>
<td nowrap bgcolor="#DDDDDD"
style='background:#DDDDDD;padding:.75pt .75pt .75pt .75pt'>
By: David Barkin - <a
href="http://sourceforge.net/users/ulzana/";>ulzana</a> 
<a
href="http://sourceforge.net/forum/message.php?msg_id=2233095";>[EXT]<AD-
height="12" width="10" border="0" alt="" images forge.net
msg.gif?>
Stochastic Screening</a>   
2003-10-11 19:31 
</td>
</tr>
<tr>
<td style='padding:.75pt .75pt .75pt .75pt'>
 <=
/font>
</td>
</tr>
</table>

<pre>From: Andrew A. Gill <superluser@xxxxx> 
<a
href="http://sourceforge.net/mailarchive/message.php?msg_id=9021842";>=
<img border=0 width=10 height=12
src="cid:image001.gif@01C470CF.5CD5E780">Darn you,
stochastic dithering! I shall be avenged!</a>   
2004-07-20 21:38</pre><pre> </pre>

<table class=MsoNormalTable border=0 cellpadding=0>
<tr>
<td style='padding:.75pt .75pt .75pt .75pt'>
Jernot
Judman
(support requests)
Linux
printing 16
bit pictures
2003-05-11</sp=
an>
 <=
/font>
</td>
</tr>
</table>

<pre>I suspect that the replies to these posts
hold some of the information needed to enable pre-dithered input. As
must be fatiguing obvious by now, I'm pretty highly motivated to
work on this project. I see a lot of potential for many types of
micron-scale manufacturing here. Sort of like rapid prototyping that
produces by deign not a model of something, but the useable thing
itself.</pre><pre> </pre><pre>Concerning Mr. Krawitz's second and
fourth points, to me they appear somewhat related. I've tried
taking one of my 1 by 2 inch printed blocks and re-feeding it through
the printer for a second (over) print. I found very little displacement
in drops between the first and second prints. For the most part, at
least in the area where I had the desired separation, the second coat of
drops appeared to be right on top of the first. I think this is referred
to as very good registration. However, I haven't examined if the
printer is capable of placing one colored drop directly on top of
another during a single file printing cycle. This might be useful, but I
don't think it's essential for what I have in mind. What
I've been thinking of is a print file consisting of the initial
remote and ESCP2 commands followed by the data for my pattern. Then,
rather than ejecting the page, the file would instruct the printer to
reverse feed to the position at which it had started printing the
pattern. Following the reverse feed the file would contain the data to
reprint the pattern (or print another pattern) which would be followed
by another reverse feed, and so on. I understand that Epson has
eliminated the ESC j code for reverse feeding, however I found a
reference (I think in one of the Epson manuals) to a set of paper feed
values that allow for up to =C2=BD inch of reverse feed. (I guess
I'm going to have to find that reference and make sure it works.
I seem to remember it had to do with a number exceeding a certain value
being interpreted as negative. It made sense when I read it anyway). You
can see now why I've been working with a block =C2=BD inch
high.</pre><pre> </pre><pre>Another possibility for reverse feeding may
dovetail with the work people here have been doing on CD printing.
I've been hoping to use something like the CD holder (or even
the holder itself) as a carrier for whatever material I use as a print
substrate. I've noticed that, once the tray has been properly
positioned, the first action of the printing cycle is to reverse feed
(suck) the tray in by =C2=BD an inch. If a figure =C2=BD inch high were
then printed, then the tray would return to its initial hand fed
position. This would allow another file of a =C2=BD inch high figure to
be printed, and so on. I think the printer indexes this initial movement
using the paper-out switch, which is a lever arm interrupting an optical
sensor arrangement. There's a slot cut in the CD tray, and when
the tray is hand positioned the lever arm above the paper path drops
into this slot (normally an out-of-paper or no-paper-loaded signal). I
believe that the printer reverse feeds the tray until the arm hits the
top end of the slot lifting it above the carrier (a paper-loaded signal)
where it then stops. The distance of the reverse feed is the =C2=BD inch
needed to position the topmost point on a CD to be printed above the
highest jet on the print head, and using the switch to do the
positioning is likely much more accurate than any human operator. The
feed CD tray behavior is quite different from the normal paper feed.
Perhaps the instructions for this feed are part of the undocumented
remote commands. Conceivably, the remote command might also point to a
hard "EEPROM" coded feed
sequence.</pre><pre> </pre><pre>I
sincerely apologize for the great length of this post. I'll try
to keep it short in the future. I didn't intend to write a novel
here. I did however want you to have some idea of what I've done
so far, what I think a driver for this purpose might need to do, and how
I think such a driver might accomplish these ends. Please let me know of
your ideas. Many, if not all, of you understand what must be done here
much better than I do. I would sincerely appreciate your advice and
assistance. Also, if there's anything I can clarify please let
me know. Perhaps as a starting point, we might outline the work needed
to produce a non-dithering driver. I look forward to hearing from anyone
interested in this project. Here's a final thought: Given that
almost every computer in the world has some sort of hard copy output
device, isn't it surprising how little information is available
concerning their operation. Thank God for Linux and the Linux
community.</pre><pre> </pre><pre>Your friend and I hope
colleague,</pre><pre> </pre><pre>Wayne
Brooke-Devlin</pre><pre> </pre><pre> </pre><pre> </pre><pre> </pre><pre> </pre><pre> </pre><pre>By: brookepb ( Brooke
)</pre><pre>
Getting started writing customized drivers=C2=A0
</pre><pre>=C2=A02004-02-17
08:00</pre><pre>
Hello,</pre><pre>
</pre><pre>=C2=A0I apologize for this being off-topic
but tried to hit the open</pre><pre>
discussion forum as the least offensive and I don"t know where else
I</pre><pre>
might find information to get started.</pre><pre>
</pre><pre>=C2=A0I am hoping that someone can point me
toward more appropriate resources</pre><pre>
for learning what I need to know to write custom minimal
printer</pre><pre>
drivers. My intention is to use an inkjet as an experimental
chemical</pre><pre>
synthesis platform for my research but find that while many people
have</pre><pre>
done so, they all seem to have jumped into making a company to
exploit</pre><pre>
their work and thus aren"t terribly forthcoming about methods
and</pre><pre>
techniques or they simply haven"t responded to my requests for
"how"d</pre><pre>
you do it?".</pre><pre>
</pre><pre>=C2=A0Unlike regular printing applications, I
prefer my dots to be separated.</pre><pre>
:o) I was hoping to be able to buy a five or six color printer
with</pre><pre>
variable drop size control and reverse line feed control. My
custom</pre><pre>
driver would just be able to let me say which cartridge (w/ the
ink</pre><pre>
replaced by my chemical of choice) would contribute to which
location</pre><pre>
and ideally the relative volume of the chemical deposited there. I
would</pre><pre>
need to be able to revisit the same spot location multiple times so
I</pre><pre>
can react the different desired chemical combinations at that
location.</pre><pre>
This is just basic combinatorial chemistry but using an affordable
(the</pre><pre>
big driver here :o) and reliable chemical dispenser for my own
research.</pre><pre>=C2=A0 This would of course critically depend
on being able to return to the</pre><pre>
precise location of a previous dot with close to no spread(spray)
of</pre><pre>
droplet fragments while in flight.</pre><pre>
</pre><pre>=C2=A0Any pointers to information about the
appropriat forum for questions</pre><pre>
like this, writing custom printer drivers and/or what
off-the-shelf</pre><pre>
common printers might fit the bill would be
welcome.</pre><pre>
</pre><pre>=C2=A0Thanks,</pre><pre>
</pre><pre>=C2=A0Brooke</pre><pre>
</pre><pre>=C2=A0-=-=-=</pre><pre><fo=
nt
size=2 color=black face=Courier>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 By: rlk
( Robert Krawitz )</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RE:
Getting started writing customized driver=C2=A0
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02004=
-02-17 17:33</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0This is actually reasonably on-topic, although it"s
easier to</pre><pre>
discuss on the gimp-print-devel mailing list, which you"re welcome
to</pre><pre>
subscribe to.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0We
don"t try to keep our stuff secret, obviously :-) This is
a</pre><pre>
rather interesting application. Gimp-Print as is won"t quite do
what you</pre><pre>
want, although a couple of weeks of work could probably make it fit
the</pre><pre>
bill. There are a few issues I can see:</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01)
Gimp-Print doesn"t support pre-dithered input; you can give
it</pre><pre>
8 or 16 bits, but it dithers it down to the 1 or 2 bits that
the</pre><pre>
printers actually support. Adding this facility would be useful,
but</pre><pre>
it"s not at the top of my agenda. If you want to do it, though,
it</pre><pre>
likely wouldn"t be too hard to do. There"s also a way to work
around</pre><pre>
this with the 16-bit input; if you decide to proceed with this
project,</pre><pre>
we can discuss that.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02)
Gimp-Print also doesn"t support overprinting in this
way.</pre><pre>
Again, this is a simple matter of software. It"s less interesting
to me,</pre><pre>
since it doesn"t have a lot of application for general purpose
printing,</pre><pre>
but it could be done if you wanted to without too much
difficulty.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03)
All of the printers that support variable drop size
support</pre><pre>
only 2 or 3 drop sizes at a given resolution, with fixed ratios.
At</pre><pre>
least, I"m not aware of any Epson printers that allow programming
the</pre><pre>
drop sizes in arbitrary ratios, and if there are, I don"t know how
to</pre><pre>
program them.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04)
I"m not aware of any cheap inkjets that allow reversing
the</pre><pre>
feed (I"m not aware of any expensive ones that do, either, but
that"s</pre><pre>
neither here nor there). If there are, that"s also something that
would</pre><pre>
need to be reprogrammed in Gimp-Print, but that"s also a simple
matter</pre><pre>
of programming. The hard thing is finding the printer meeting
your</pre><pre>
specs.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05)
Inkjets print in bands, and the printing pattern isn"t
very</pre><pre>
simple. They don"t simply print one row of dots and move to the
next.</pre><pre>
You could easily hack Gimp-Print to do that, though, but it would
make</pre><pre>
for very slow printing.</pre><pre>
</pre><pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Gimp=
-Print 5.0 alpha supports a mode whereby you can control
each</pre><pre>
color independently (the "raw" mode). That would be ideal for
your</pre><pre>
purposes.</pre><pre>
</pre>

 

</div>

</body>

</html>

------=_NextPart_001_0004_01C470CF.766B4820--

------=_NextPart_000_0003_01C470CF.7669C180
Content-Type: image/gif;
name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@xxxxxxxxxxxxxxxxx>

R0lGODlhCgAMAOMAAP////j4+OPj493d3czMzMDAwIaGhnd3d19fX1VVVUJCQjk5OQD/VAAAAP//
/////yH+Dk1hZGUgd2l0aCBHSU1QACH5BAEAAA8ALAAAAAAKAAwAAAQt0MhpnjUgZ9Ou3kCHFWTY
nJgWBATRYJTkpsC6zkCi77ht44ugcNYqFk/I5CkCADs=

------=_NextPart_000_0003_01C470CF.7669C180--

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Previous by Date:	Re: What I'm up to: 00095, Robert L Krawitz
Next by Date:	Re: Inkjet Driver for Chemcal Synthesis: 00095, Robert L Krawitz
Previous by Thread:	Inkjet Driver for Chemcal Synthesisi: 00095, Wayne Brooke-Devlin
Next by Thread:	Re: Inkjet Driver for Chemcal Synthesis: 00095, Robert L Krawitz
Indexes:	[Date] [Thread] [Top] [All Lists]