Inquiry Regarding Custom Inkset Control and ESC/P2 vs. ESC/P-R Clarification

--===============2534932380601884857==
Content-Type: multipart/alternative; boundary="000000000000a8d3cf06373eba2d"

--000000000000a8d3cf06373eba2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello!
I am Kevin, a student researcher at UC Berkeley working on creating prints
to test people's color vision. A critical component of our research
involves using a custom inkset and achieving colorimetric accuracy, which
requires precise, individual control of each ink channel, bypassing the
standard CMYK color processing used by commercial software like Printfab.
Currently, our setup inadvertently activates the K (black) channel to
produce grayscale when we attempt to independently control multiple ink
channels, causing significant issues.

Presently, we resort to using two printers, each managing two inks. This
approach introduces alignment and accuracy challenges. Thus, we seek a
solution by potentially customizing our own printer driver, integrating all
links within a single printer and possibly expanding the number of inks
used.

After reviewing the extensive documentation and code provided by
Gutenprint=E2=80=94which has been invaluable=E2=80=94we concluded that dire=
ctly
communicating with Epson printers via the ESC/P2 language seems most
viable. However, several questions arose during our exploration:
Upon consulting Epson=E2=80=99s specifications, we've observed that several=
 current
models (e.g., ET-8550, XP-15000) seem to utilize ESC/P-R rather than ESC/P2
according to Epson. Information about ESC/P-R appears scarce, especially
regarding how it differs from ESC/P2. Given that Gutenprint lists support
for some ESC/P-R printers (like the XP-15000), is it appropriate to assume
that ESC/P-R largely overlaps with ESC/P2 but includes additional
high-level commands, or is it fundamentally distinct?

Despite thorough review of the documentation on rasterization and color
handling, I remain slightly concerned whether printers perform any
additional internal processing of the rasterized data we send=E2=80=94parti=
cularly,
could commanding specific CMY channels inadvertently activate the K channel
in the printer's internal processing?

In the driver file section of your documentation, it states: "Some printers
require that all of the nozzles be used. Those printers will set
min_nozzles and/or min_black_nozzles to the same value as nozzles and/or
black_nozzles." Does this mean that for printers with min_nozzles equal to
the total nozzle count, all nozzles must actively be used at some point
during each print cycle? Does this mean that for full control of individual
channels, we need to select printers that do not require all of the nozzles
used?

Thank you very much for developing such comprehensive documentation and a
versatile driver, both of which have significantly aided our research
efforts. We look forward to your insights and guidance.
Warm regards, Kevin

--000000000000a8d3cf06373eba2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello!</div>I am Kevin, a student researcher at UC Be=
rkeley working on creating prints to test people&#39;s color vision. A crit=
ical component of our research involves using a custom inkset and achieving=
 colorimetric accuracy, which requires precise, individual control of each =
ink channel, bypassing the standard CMYK color processing used by commercia=
l software like Printfab. Currently, our setup inadvertently activates the =
K (black) channel to produce grayscale when we attempt to independently con=
trol multiple ink channels, causing significant issues.<div><br>Presently, =
we resort to using two printers, each managing two inks. This approach intr=
oduces alignment and accuracy challenges. Thus, we seek a solution by poten=
tially customizing our own printer driver, integrating all links within a s=
ingle printer and possibly expanding the number of inks used.<div><br>After=
 reviewing the extensive documentation and code provided by Gutenprint=E2=
=80=94which has been invaluable=E2=80=94we concluded that directly communic=
ating with Epson printers via the ESC/P2 language seems most viable. Howeve=
r, several questions arose during our exploration:<br>Upon consulting Epson=
=E2=80=99s specifications, we&#39;ve observed that several current models (=
e.g., ET-8550, XP-15000) seem to utilize ESC/P-R rather than ESC/P2 accordi=
ng to Epson. Information about ESC/P-R appears scarce, especially regarding=
 how it differs from ESC/P2. Given that Gutenprint lists support for some E=
SC/P-R printers (like the XP-15000), is it appropriate to assume that ESC/P=
-R largely overlaps with ESC/P2 but includes additional high-level commands=
, or is it fundamentally distinct?</div><div><br>Despite thorough review of=
 the documentation on rasterization and color handling, I remain slightly c=
oncerned whether printers perform any additional internal processing of the=
 rasterized data we send=E2=80=94particularly, could commanding specific CM=
Y channels inadvertently activate the K channel in the printer&#39;s intern=
al processing?</div><div><br>In the driver file section of your documentati=
on, it states: &quot;Some printers require that all of the nozzles be used.=
 Those printers will set min_nozzles and/or min_black_nozzles to the same v=
alue as nozzles and/or black_nozzles.&quot; Does this mean that for printer=
s with min_nozzles equal to the total nozzle count, all nozzles must active=
ly be used at some point during each print cycle? Does this mean that for f=
ull control of individual channels, we need to select printers that do not =
require all of the nozzles used?</div><div><br>Thank you very much for deve=
loping such comprehensive documentation and a versatile driver, both of whi=
ch have significantly aided our research efforts. We look forward to your i=
nsights and guidance.<br>Warm regards, Kevin</div></div></div>

--000000000000a8d3cf06373eba2d--


--===============2534932380601884857==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2534932380601884857==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

--===============2534932380601884857==--