gimp-print-devel

Re: [Gimp-print-devel] ESP 870 results

[Dave H. <da...@mi...>]

Robert L Krawitz wrote:
> 
> I printed the PDI target full size just now, using a piece of Epson
> photo paper rather than the cheap third party stuff I've been using.
> It isn't perfect by any means, but overall it blows all of my other
> test prints clear out of the water, including some samples I was sent
> from an ESC 660 (using gimp-print and Windows).

Sorry, I must have missed something here. What is "the PDI target"?

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] image offsetted by one centimeter.

[Robert L K. <rl...@al...>]

   Date: Fri, 12 May 2000 01:02:49 +0200
   From: Frank van Maarseveen <F.v...@in...>

   I've carefully created a postscript picture of 595x842 which is exactly
   A4. "gs -sPAPERSIZE=a4 a4.ps" shows it correctly. However, when printing
   this using

	   print-3.1.3/Ghost + GS 6.01 + Epson 740

   and the command

	   gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=12 -dDensity=0.8
		   -r1440 -sPAPERSIZE=a4 -dImageType=2 -dQuality=6 -dDither=4
		   -sOutputFile=outa4.esc a4.ps

   the image is vertically shifted about 1 centimeter. The printer prints the
   top of the page first. Instead of starting with a 3 mm white margin the
   margin looks 13mm. But only 3 mm of the picture is left out. At the bottom
   of the page (printed last) the last 3mm are unused but about 13mm of
   the picture is left out. Left and right sides are ok (both 3 mm left out).

   I've studied the source a bit, pulled the driver into gdb but haven't yet
   found a clue.

This code isn't right yet.  I'm taking a look at it, but the fix won't
happen right away.  I have to hack the softweave code to deal with it,
and that's never a pleasant task.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] image offsetted by one centimeter.

[Frank v. M. <F.v...@in...>]

I've carefully created a postscript picture of 595x842 which is exactly
A4. "gs -sPAPERSIZE=a4 a4.ps" shows it correctly. However, when printing
this using

	print-3.1.3/Ghost + GS 6.01 + Epson 740

and the command

	gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=12 -dDensity=0.8
		-r1440 -sPAPERSIZE=a4 -dImageType=2 -dQuality=6 -dDither=4
		-sOutputFile=outa4.esc a4.ps

the image is vertically shifted about 1 centimeter. The printer prints the
top of the page first. Instead of starting with a 3 mm white margin the
margin looks 13mm. But only 3 mm of the picture is left out. At the bottom
of the page (printed last) the last 3mm are unused but about 13mm of
the picture is left out. Left and right sides are ok (both 3 mm left out).

I've studied the source a bit, pulled the driver into gdb but haven't yet
found a clue.

any hints?

-- 
Frank

Re: [Gimp-print-devel] Continuous Inking Systems ...

[<sh...@al...>]

> I just came across this site:
> 
> http://www.nomorecarts.com/
> 
> They are selling continuous inking systems: Bottles of ink right next
> to the printer. No more cartridges to buy.
> 
> I don't have such a system, so I can not offer any first hand
> experience.

Interesting.  I can just imagine the fun my cat would have knocking those
ink bottles around...

If one of you decides to try this, please post a review.  I'm not sure that
I print often enough to make this economical.  

Eric

[Gimp-print-devel] Continuous Inking Systems ...

[Karl H. K. <kh...@kh...>]

I just came across this site:

http://www.nomorecarts.com/

They are selling continuous inking systems: Bottles of ink right next
to the printer. No more cartridges to buy.=20

I don't have such a system, so I can not offer any first hand
experience.=20

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] Re: dithering stuff

[Raph L. <ra...@ac...>]

Robert L Krawitz wrote:

> Well, mazel tov!  When everyone's settled down, perhaps your baby
> pictures will make good tests of skin tones :-)

Thanks! So far, all the baby pictures are black and white:
http://www.levien.com/~max/

You'll be pleased to hear I just did a GPL release of rinkj, including
the Even Toned screening algorithms. Go to
http://www.ghostprint.com/download/ .

Please feel free to integrate ETS into Gimp-print. Over the longer term,
as rinkj becomes more developed, it may make sense to use it as the
backend rather than trying to support all the different devices
yourself. I'm trying to design an architecture now that will help it
integrate with Ghostscript as well as other imaging API's. I'll
certainly keep you guys posted.

-- 
Raph Levien <ra...@ar...>  |  artofcode LLC  |  www.artofcode.com

Re: [Gimp-print-devel] Epson 1270?

[Karl H. K. <kh...@kh...>]

The 1270 is the same as the 870 - as far as image quality and
command set are concerned. The 1270 is the wide version so you
can print 11x17" and A3 with it. The 870 comes with the roll 
holder and a roll of paper, the 1270 does not.

Robert's 870 results are therefore also valid for the 1270.

Karl Heinz 

Mike Porter <mi...@UD...> said: 

> Is the Epson 1270 similar to the 870?  Can I expect similar results?
> Epson is getting ready to release 870 docs - how about 1270?
> 
> Mike (who would *like* a 1270)

 

[Gimp-print-devel] Epson 1270?

[Mike P. <mi...@UD...>]

Is the Epson 1270 similar to the 870?  Can I expect similar results?
Epson is getting ready to release 870 docs - how about 1270?

Mike (who would *like* a 1270)

===
Mike Porter <mi...@ud...>
PGP Fingerprint: F4 AE E1 9F 67 F7 DA EA  2F D2 37 F3 99 ED D1 C2

Re: [Gimp-print-devel] HP replies!

[Robert L K. <rl...@al...>]

   Date: Wed, 10 May 2000 23:40:04 -0500
   From: Chema Celorio <ch...@ce...>

   Robert L Krawitz wrote:
   > Is there any kind of compression that's common to more than one family
   > of printers?

   Tiff compression for PCL, EPSON and CANNON is nearly identical.
   ( judging from the gimp-print code )

For Epson, it's actually run length encoding, not TIFF mode.  Maybe
they're the same thing, and there's just an additional funky command
set for TIFF mode (which, mind you, I've never actually seen anything
use).

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Canon driver

[Andy T. <th...@ph...>]

Robert L Krawitz wrote:

>    Date: Mon, 08 May 2000 09:01:03 +0200
>    From: Andy Thaller <th...@ph...>
>
>    I've tested the canon driver's output this weekend, though not with
>    every dither algorithm. 360x360 and 720x720 dpi seem fine, though
>    slighty mistuned in respect to brightnes and contrast. 360x360 with
>    variable dot sizes shows extreme color corruption (what can I do
>    here?) and 1440x720 is way too dark.
>
> 1) For 1440x720, you need to divide v->density by 2.  Apparently the
> Canon printers are like the Epson printers in this regard -- they're
> really 720x720, and 1440 is done in two passes.
>
> 2) You probably want to fiddle with the_levels.
>
>   double        the_levels[] = { 0.5, 0.75, 1.0 };
>
> This indicates that there are three dot sizes, of size .5, .75, and
> 1.0 respectively.  However, I doubt that those being a bit off would
> cause even moderately severe color corruption.  Most likely the format
> of the output is wrong.  The dither routine normally generates the
> output as concatenated rows, with the lowest bit plane first.  It's
> possible (by means of dither_set_c_ranges and such) to change that
> ordering around.  If Canon takes each pixel as a full unit, you need a
> folding routine like that in print-escp2.c

The driver already had the folding routine but somehow the pixel order got
mixed somewhere during the last changes...
Now it's fixed and every mode works fine again - except the color balance,
this I want to leave to someone else.

Andy.

Re: [Gimp-print-devel] HP replies!

[Chema C. <ch...@ce...>]

Robert L Krawitz wrote:
> Is there any kind of compression that's common to more than one family
> of printers?

Tiff compression for PCL, EPSON and CANNON is nearly identical.
( judging from the gimp-print code )

[Gimp-print-devel] ESP 870 results

[Robert L K. <rl...@al...>]

I printed the PDI target full size just now, using a piece of Epson
photo paper rather than the cheap third party stuff I've been using.
It isn't perfect by any means, but overall it blows all of my other
test prints clear out of the water, including some samples I was sent
from an ESC 660 (using gimp-print and Windows).

Settings: adaptive hybrid dithering, 80 brightness, 1.1 saturation,
1.5 density, .9 gamma.  Everything else neutral.

Grain: in pale areas, it's essentially invisible.  That's not the case
in dark midtones; there's still some coarseness there (it appears to
be related to light->dark ink transition).  That seems to be related
to the algorithm somehow; I haven't been able to get rid of it.

There were no problems with pooling of ink or anything.  That must be
a function of paper type.  I guess Epson really does design their
papers and their inks to work well together.  That makes sense.

Overall, it's a bit dark, and there appears to be somewhat of a yellow
or yellow-green cast to it.  The skin tones in particular look very
warm, although not green.  The grays look slightly greenish.  The
paper itself is much warmer than the other papers I've used, but I
don't think that that's the entire story.

The golf balls in the cup look like golf balls, not spheres or
circles.

Epson really has a winner with this printer.  If we can only really
get it tuned...

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] HP replies!

[Karl H. K. <kh...@kh...>]

On Wed, May 10, 2000 at 07:56:36PM -0400, Robert L Krawitz wrote:
>    Date: Wed, 10 May 2000 12:15:40 -0500
>    From: Chema Celorio <ch...@ce...>
> 
>    I don't like Epsons attitude either, with their "secrets" commands
>    and with releasing specs to some Free Software developers and
>    asking them not to share it. HP documentation is far supperior than
>    Epson.
> 
> I'm not pleased with this either.  Karl was told that it was a
> temporary state of affairs.  Karl, could you check with your contact
> about when it will be released for real?  Also, about the 870 doc?

... its probably still "in about two weeks" ... I just sent an email
to EPSON.

Karl Heinz

-- 
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

Re: [Gimp-print-devel] HP replies!

[Robert L K. <rl...@al...>]

   Date: Wed, 10 May 2000 12:20:30 -0500
   From: Chema Celorio <ch...@ce...>

   If you guys are intrested, I can move the optimization
   code to gnome-print-compress, so that you can integrate it
   to your driver in a more cleanly manner.

Is there any kind of compression that's common to more than one family
of printers?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] HP replies!

[Robert L K. <rl...@al...>]

   Date: Wed, 10 May 2000 12:15:40 -0500
   From: Chema Celorio <ch...@ce...>

   I don't like Epsons attitude either, with their "secrets" commands
   and with releasing specs to some Free Software developers and
   asking them not to share it. HP documentation is far supperior than
   Epson.

I'm not pleased with this either.  Karl was told that it was a
temporary state of affairs.  Karl, could you check with your contact
about when it will be released for real?  Also, about the 870 doc?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Another ink question

[Robert L K. <rl...@al...>]

   Date: Wed, 10 May 2000 13:02:52 +0100
   From: Dave Hill <da...@mi...>

   I meant that you couldn't lay down black and coloured ink on
   the same spot with the 500 series, but you can on the 600 series.
   But looking at the code, I see that you never put down coloured
   ink if black has been put down (using the "dontprint" argument to
   print_color()).

That should probably be an option anyway, and you shouldn't rely on
that behavior.  It works fine on Epson printers, but other printers
may gain from overprinting.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] HP replies!

[Chema C. <ch...@ce...>]

Dave Hill wrote:
> 
> Interesting. the PCL driver already uses mode 2 (TIFF). I have
> tried mode 9 (CRDR) and it makes it better. I used
> the compression driver written by Martin Lottermoser (sp?) for
> the "hpdj" driver.

If I remember correctly, you are not using Delta Row compression.
I might be completly mistaken !

Delta row (#3) is the best compression in average :

here is a comparison :
   for the testprint3 page.  B&W 300 dpi's
   (NOTE that testprint3 has a pretty big coverage )
   with no compression          :	     1,076,096
   with compression method 2    :	       336,874
   with compression method 3    :		67,290
   with compression method 2&3  :		56,413
   with method 1&2&3 and fixed delta row bug:	53,814
   with blank rows sent as such :		48,379

and there are other speed otimizations, like if you have
test for delta row and the size is 0, look no more and
stuff like that.

Also for color I do delta row with the last row in the same
plane and then test for the row in the previous plane ( for
plane > 1 ) and test for the best size. This is a HUGE diference
when printing in black ( or grays ) objects in color mode.

> 
> I think the trick is to try all the compression schemes and
> dynamically switch to the one giving the shortest output buffer!

Yep. 



> Dave
> 
> --
> Dave Hill, Kempston, Bedford UK         da...@mi...
>                                 davehill at users.sourceforge.net
> Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] HP replies!

[Dave H. <da...@mi...>]

Chema Celorio wrote:
> 
> 2. PCL COMPRESSION
> 
> I implemented HP's supported compression methods
> ( except #9, and there isn't a big gain doing so) and I
> spent the weekend optimizing the driver to get the best
> compression. The compression ratios achieved where
> amazing. (98% Color 96% B&W ). It is important since
> the speed improvement in printing this stuff in lasers
> is noticeable.
> 

Interesting. the PCL driver already uses mode 2 (TIFF). I have
tried mode 9 (CRDR) and it makes it better. I used
the compression driver written by Martin Lottermoser (sp?) for
the "hpdj" driver.

I think the trick is to try all the compression schemes and
dynamically switch to the one giving the shortest output buffer!

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] HP replies!

[Chema C. <ch...@ce...>]

If you guys are intrested, I can move the optimization
code to gnome-print-compress, so that you can integrate it
to your driver in a more cleanly manner.

( This just sparked some ideas on how to clean gnome-print-pclr. )

Chema

Chema Celorio wrote:
> 
> 1.  REGARDING HP REPLY
> 
> I am intrested in ReverseEngineer this stuff,
> so if anyone is too we can work together. I don't
> have the time right now but I will.
> 
> About the atitude towards UNIX, I would not
> worry a lot. Things will change, in the near future
> by it's own weigth and companies will start sending
> us patches.
> 
> I don't like Epsons attitude either, with their
> "secrets" commands and with releasing specs to
> some Free Software developers and asking them not
> to share it. HP documentation is far supperior
> than Epson.
> 
> 2. PCL COMPRESSION
> 
> I implemented HP's supported compression methods
> ( except #9, and there isn't a big gain doing so) and I
> spent the weekend optimizing the driver to get the best
> compression. The compression ratios achieved where
> amazing. (98% Color 96% B&W ). It is important since
> the speed improvement in printing this stuff in lasers
> is noticeable.
> 
> If you guys want to use the code its in :
> gnome-print/libgnomeprint/gnome-print-compress.[ch]
> 
> and if you want to check the optimization I did :
> gnome-print/libgnomeprint/gnome-print-pclr.[ch]
> 
> I would love if we start sharing code either by
> the use of libraries or by sharing ".c" files.
> For example, migrating the compression code from
> your PCL driver to use "gnome-print-compress.c"
> and you can distribute this file with your code.
> I will start working on integrating EPSON's compression
> to that file this week. (  It might not need changes)
> 
> Chema Celorio
> ch...@ce...
> 
> sh...@al... wrote:
> >
> > > I aksed HP the big question about releasing specs for their
> > > printers and this was the answer:-
> > >
> > >      Thank you for your inquiry.  Regarding the PhotoRet technology it
> > > is
> > >      only currently accessible from the Windows Driver.  If you are
> > >      operating outside the Windows environment and can't take advantage
> > > of
> > >      the driver, the only commands available are in the PCl Developer
> > >      Guide.
> > >
> > > This, of course is exactly the answer I expected.
> > >
> > > Anyone got any suitable ammunition to fire back at them?
> > >
> > > I notice they use the words "only currently accessible".
> >
> > I'm sure it's unlikely to produce anything beneficial, but you could always
> > ask for the the source to the Windows driver and offer to port it.
> >
> > Eric
> >
> > _______________________________________________
> > Gimp-print-devel mailing list
> > Gim...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

Re: [Gimp-print-devel] HP replies!

[Chema C. <ch...@ce...>]

1.  REGARDING HP REPLY

I am intrested in ReverseEngineer this stuff,
so if anyone is too we can work together. I don't
have the time right now but I will. 

About the atitude towards UNIX, I would not
worry a lot. Things will change, in the near future
by it's own weigth and companies will start sending
us patches.

I don't like Epsons attitude either, with their 
"secrets" commands and with releasing specs to 
some Free Software developers and asking them not
to share it. HP documentation is far supperior
than Epson.

2. PCL COMPRESSION

I implemented HP's supported compression methods
( except #9, and there isn't a big gain doing so) and I
spent the weekend optimizing the driver to get the best
compression. The compression ratios achieved where
amazing. (98% Color 96% B&W ). It is important since
the speed improvement in printing this stuff in lasers
is noticeable.

If you guys want to use the code its in :
gnome-print/libgnomeprint/gnome-print-compress.[ch]

and if you want to check the optimization I did :
gnome-print/libgnomeprint/gnome-print-pclr.[ch]

I would love if we start sharing code either by
the use of libraries or by sharing ".c" files.
For example, migrating the compression code from
your PCL driver to use "gnome-print-compress.c"
and you can distribute this file with your code.
I will start working on integrating EPSON's compression
to that file this week. (  It might not need changes)


Chema Celorio
ch...@ce...


sh...@al... wrote:
> 
> > I aksed HP the big question about releasing specs for their
> > printers and this was the answer:-
> >
> >      Thank you for your inquiry.  Regarding the PhotoRet technology it
> > is
> >      only currently accessible from the Windows Driver.  If you are
> >      operating outside the Windows environment and can't take advantage
> > of
> >      the driver, the only commands available are in the PCl Developer
> >      Guide.
> >
> > This, of course is exactly the answer I expected.
> >
> > Anyone got any suitable ammunition to fire back at them?
> >
> > I notice they use the words "only currently accessible".
> 
> I'm sure it's unlikely to produce anything beneficial, but you could always
> ask for the the source to the Windows driver and offer to port it.
> 
> Eric
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Another ink question

[Dave H. <da...@mi...>]

Robert L Krawitz wrote:
> 
>    Date: Tue, 09 May 2000 11:12:23 +0100
>    From: Dave Hill <da...@mi...>
> 
>    Apparently, the black and colour cartridges used simultaneously
>    in the Deskjet 550C and 560C have incompatible chemical makeups,
>    and they should not be mixed at a given print point.
> 
>    On the other hand, the newer ones used in the DJ600 series can
>    be mixed with no ill effects.
> 
>    How would you set the dither knobs to differentiate between
>    these two cases. I think it has to do with "set_black_upper()",
>    and what is the default action.
> 
> The way to handle that is to not pass a black bit vector (pass a NULL)
> if you don't want black ink.  I haven't tested this in a while, but
> that's how it's supposed to work.
> 

Sorry, that's not what I meant. That one works fine for printing in
CMY only.

I meant that you couldn't lay down black and coloured ink on
the same spot with the 500 series, but you can on the 600 series.
But looking at the code, I see that you never put down coloured
ink if black has been put down (using the "dontprint" argument to
print_color()).

Dave


-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Debian packaging and ESP 750 troubles

[<sh...@al...>]

Well, last night I was able to compile and build the Ghostscript driver into
a Debian package based on the Debian gs-5.10 package.  Unfortunately, I
haven't yet been able to get the driver to work. :(  I need more time to
figure out what's going on, though.

I also had some strange problems with the regular gimp-print plugin.
I printed a photo at 720 DPI Softweave and most of the image looked ok, but
in the sections of the image that were really dark it printed a kind of
horizontal pin-stripe pattern, with most of the section of the page getting
no ink at all and just thin regularly spaced stripes of ink appearing to be
a single pixel tall and about a mm apart.

I'll try to scan it tonight.

It was weird though, because when I tried to unprint what gimp-print produced,
those sections of the image looked fine.

Eric 

Re: [Gimp-print-devel] HP replies!

[<sh...@al...>]

> I aksed HP the big question about releasing specs for their
> printers and this was the answer:-
> 
>      Thank you for your inquiry.  Regarding the PhotoRet technology it
> is 
>      only currently accessible from the Windows Driver.  If you are 
>      operating outside the Windows environment and can't take advantage
> of 
>      the driver, the only commands available are in the PCl Developer 
>      Guide.
> 
> This, of course is exactly the answer I expected.
> 
> Anyone got any suitable ammunition to fire back at them?
> 
> I notice they use the words "only currently accessible".

I'm sure it's unlikely to produce anything beneficial, but you could always
ask for the the source to the Windows driver and offer to port it.

Eric

Re: [Gimp-print-devel] HP replies!

[Robert L K. <rl...@al...>]

   Date: Wed, 10 May 2000 10:07:56 +0100
   From: Dave Hill <da...@mi...>

   I aksed HP the big question about releasing specs for their
   printers and this was the answer:-

	Thank you for your inquiry.  Regarding the PhotoRet technology
	it is only currently accessible from the Windows Driver.  If
	you are operating outside the Windows environment and can't
	take advantage of the driver, the only commands available are
	in the PCl Developer Guide.

   This, of course is exactly the answer I expected.

   Anyone got any suitable ammunition to fire back at them?

Other than the fact that Epson (as an example of a company taking a
more enlightened approach) will have a much easier time selling
printers into the UNIX community?  I would think that they'd care
about that, but maybe not...

   I notice they use the words "only currently accessible".

Is it unidirectional (the driver generates commands and feeds them to
the printer) or bidirectional (the driver iteracts with the printer)?
If it's unidirectional, it shouldn't be all that hard to generate an
output file from Windows and parse it.  If it's bidirectional, it's a
bit harder; it would need something like a parallel port with a tap
that allows you to record what's sent both ways.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] HP replies!

[Dave H. <da...@mi...>]

I aksed HP the big question about releasing specs for their
printers and this was the answer:-

     Thank you for your inquiry.  Regarding the PhotoRet technology it
is 
     only currently accessible from the Windows Driver.  If you are 
     operating outside the Windows environment and can't take advantage
of 
     the driver, the only commands available are in the PCl Developer 
     Guide.

This, of course is exactly the answer I expected.

Anyone got any suitable ammunition to fire back at them?

I notice they use the words "only currently accessible".

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!