gimp-print-devel

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

On Mon, Feb 07, 2000 at 07:42:54PM -0500, Robert L Krawitz wrote:
> OK, I checked in the fix.  I also checked in something else that might

No difference. OK, one little difference: Your init code prints something
one the page: I get two lines
284.4
@EJL=20
at the top of the page. But other than that neither the number of
separations nor the nozzles did change anything. My information is
also that the 740 has 48 nozzles, so I tried the 32, but changed
it back after I saw that it did also not work.

Regarding the init string: I would remove it again. As I said before,
I tried it with an image generated with the Windows driver after I
removed the "junk" at the beginning of the file and the image printed
identical to the one with the init sequence.

The 760 seems to require such a string, the 740 does not.

Karl Heinz

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

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

OK, I checked in the fix.  I also checked in something else that might
help -- I had the inter-jet separation set to 6 lines, which is
unusual; usually it's 8 with these printers.  It's possible that it
really is 6, in which case a separation of 8 will cause somewhat
strange effects.  However, my weaving code may not be correct for a
separation of 6; it needs more testing, and if that was the case,
things simply wouldn't work.

If you still have problems, try this.  Find the line in print-escp2.c
(in the latest version 1.63, it's lines 495-499) that looks like this:

  /* Stylus Color 740 */
  (MODEL_PAPER_LARGE | MODEL_IMAGEABLE_600 | MODEL_INIT_440
   | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
   | MODEL_VARIABLE_4
   | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(48) | MODEL_MAKE_SEPARATION(8)),

Change the 48 to 32.  This will reduce the number of nozzles it uses,
but if my information (about 48 nozzles) is incorrect, this has a
chance of working.

Also, if this works (due to the weird init sequence, presumably),
could you try printing as a 640?  If that fails to print, then we know
the 640 needs the init sequence also.

-- 
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] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

   Date: Sat, 5 Feb 2000 20:40:16 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   This came just in from the linux-usb mailing list. Does anybody
   know about these initialization strings that are sent by the
   Windows drivers? I've seen something similar with the 740 driver,
   however the job prints even when I remove this special init string.
   The stuation with the 760 seems to be different.

In light of all this weirdness we're seeing, I'm beginning to wonder
if this is our problem after all.  The printout someone sent me from a
750 contained exactly this string, also.  I'm going to stick it in;
perhaps you could try it after I commit this?

   From: Pam R <pam...@vi...>
   To: lin...@su...
   Date: Sun, 6 Feb 2000 00:49:57 +0000
   X-Mailer: KMail [version 1.0.28]
   Subject: [linux-usb] Epson Stylus Color 760

   FWIW I've just managed to get the EPC760 working via USB (2.2.14 kernel
   with 2.3.39 backpatch) using a uniprint - stcany.upp - ghostscript
   combination, by adding an extra initialisation string in stcany.upp.
   The string is
      00 00 00 1b01 40 45 4a 4c 20 31 32 38 34 2e 34 0a 40 45 4a 4c 20 20
   20 20 20 0a =20
   Doing it this way the string is sent at the start of each print job,
   but I believe that the printer really only needs it once - on the
   initial connection..

-- 
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] dithering for variable drop size, color adjustments

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

   Date: Mon, 07 Feb 2000 18:16:53 +0100
   From: Andy Thaller <th...@ph...>

   In case I'll ever find out how to utilize my bjc-6000's ink drop
   modulation functionality: how will I tell the dithering algorithm
   to produce suitable output? I'll propably need 2-3 levels of
   dropsizes (can their size-ratios be accounted for?) in a yet to be
   ascertained bit order. I'm just curious -- don't start hacking away
   immediately if the code isn't there already ;-)

I actually checked this stuff in last night.  There's a real API for
this, and it should be fully supported.  Look in print.h for the
various dither_set_* functions.  In particular, you want the functions

dither_set_c_levels(void *, int, double *)

and their equivalents for the other inks.  These functions take the
following arguments:

	void *vd is the handle you're given by init_dither().

	int levels is the number of levels (it will be interesting to
	see if anything not a power of 2 works).

	double *levels is a vector of levels (levels[0] should equal
	0.0).  Each value should be between 0 and 1 inclusive.  They
	should increase monotonically.

The output bit array is treated as a vector of bit arrays numbering
ceil(log2 levels).  So if there are two levels (the normal situation,
in which case you should use the dither_cmyk function), there is one
bit array; if there are four levels there are two arrays, and so
forth.  Bytes 0..length-1 are the lowest order bits, bytes 
length..2 * length - 1 are the next bits, and so forth.  There's a
function escp2_fold in print_escp2.c that folds these bits into a more
normal packing order.  You should be fully set here.

The reason for this seemingly baroque ordering is that PCL printers
actually take these vectors of bits, rather than folding them.  But it
actually makes sense, since different printers will handle this stuff
differently, and it's a fairly easy ordering to deal with (unpacking
bits is a lot messier, particularly with an arbitrary number of bit
planes).

   Something else I'd like to know is how I can set gamma and
   intensity levels for each of the color components seperately. Of
   course, color correction is something a color management system
   should do but until that is available I'd like to have a
   quick'n'dirty way...

About the best thing you could do is recompute the lookup table when
your print function is called.  In fact, calling compute_lut() from
inside print.c is really silly; it should be called from inside the
print function, and I may just change this.  There are already
intensity controls for each of the colors; adding gamma controls isn't
hard, but it is tedious.

It would really make sense to put the LUT in the variables block,
actually, and save it in the printrc.  The LUT (unlike the color map)
is really part of the printer definition, not of the image.  In fact,
it would arguably make sense to put the color mapping stuff in the
image code, rather than the print functions, so that the image code
does the translation to RGB or RGBA.

If you want to expose them, you'll have to hack the UI code in
print.c, which is ugly.  You should probably discuss this with Steve
Miller <sm...@rn...>, who's working on the GUI.

I'm beginning to think that we should consider redoing the printrc
file format some time during this development cycle.  We've already
added stuff to it, and it's rather ugly.  The "obvious" thing to do is
to come up with an XML definition here; we can then easily add stuff
later, and people can edit printer definitions with their favorite
browser (hint: transfer functions!).

I think GTK actually has a pretty nice gamma curve widget.  It's not
really documented anywhere, but I think SANE uses this (hint hint,
somebody :-) ).  This would be a real win for us.

-- 
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] dithering for variable drop size, color adjustments

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

In case I'll ever find out how to utilize my bjc-6000's  ink drop modulation
functionality: how will I tell the dithering algorithm to produce suitable
output? I'll propably need 2-3 levels of dropsizes (can their size-ratios be
accounted for?) in a yet to be ascertained bit order. I'm just curious --
don't start hacking away immediately if the code isn't there already ;-)

Something else I'd like to know is how I can set gamma and intensity levels
for each of the color components seperately. Of course, color correction is
something a color management system should do but until that is available I'd
like to have a quick'n'dirty way...

Andy.

Re: [Gimp-print-devel] 740/750 stuff

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

sh...@al... said: 

> > I won't have much time this week to work on the 740 and 750
problems
> > (and I'll probably have to cut back in general).  The fact that I
> > don't have one of these printers also makes it hard for me to do
very
> > much.  So can someone else look into this?

As I said before, I'd rather spend my time on the Sane/Epson project
(Code freeze a week from yesterday). I will however continue to
test new code.

> 
> I also shouldn't be spending too much time on this, although I'd
like
> to.
> 
> My plan is to keep working on the printer simulator.  If the
problems
> with the 740/750 are that they aren't working properly due to bugs
in

I am pretty sure that as far as the 740 is concerned we are dealing
with real bugs and not some undocumented features. The printer
simulator will probably help to find these things. Will it be
able to select a specific feature set, so that I can run it as
a 740 or a 400? 

Karl Heinz

Re: [Gimp-print-devel] 740/750 stuff

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

> I am pretty sure that as far as the 740 is concerned we are dealing
> with real bugs and not some undocumented features. The printer
> simulator will probably help to find these things. Will it be
> able to select a specific feature set, so that I can run it as
> a 740 or a 400?

In theory it would not be too difficult to code support for that.  I
want to get it fully working as a 750 first, though, and then I'll add
some switches that cause it to forget what the newer commands mean.

Right now, there's all sorts of stuff in the files that the simulator
does not understand.  I've yet to determine how much of that is due to
bugs in the simulator and how much in the driver.  The simulator has some
obvious memory management problems that I need to address before it can
be a truly useful tool.

Eric

Re: [Gimp-print-devel] 740/750 stuff

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

sh...@al... said: 

> > I won't have much time this week to work on the 740 and 750
problems
> > (and I'll probably have to cut back in general).  The fact that I
> > don't have one of these printers also makes it hard for me to do
very
> > much.  So can someone else look into this?

As I said before, I'd rather spend my time on the Sane/Epson project
(Code freeze a week from yesterday). I will however continue to
test new code.

> 
> I also shouldn't be spending too much time on this, although I'd
like
> to.
> 
> My plan is to keep working on the printer simulator.  If the
problems
> with the 740/750 are that they aren't working properly due to bugs
in

I am pretty sure that as far as the 740 is concerned we are dealing
with real bugs and not some undocumented features. The printer
simulator will probably help to find these things. Will it be
able to select a specific feature set, so that I can run it as
a 740 or a 400? 

Karl Heinz

Re: [Gimp-print-devel] 740/750 stuff

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

> I won't have much time this week to work on the 740 and 750 problems
> (and I'll probably have to cut back in general).  The fact that I
> don't have one of these printers also makes it hard for me to do very
> much.  So can someone else look into this?

I also shouldn't be spending too much time on this, although I'd like
to.

My plan is to keep working on the printer simulator.  If the problems
with the 740/750 are that they aren't working properly due to bugs in
the driver, then a lot of these issues should be resolvable this way.
If there are necessary undocumented features, well, then, we'll just
need to increase our vocabulary of swear words.

Shall we have a contest to come up with an acronym for "Epson"? :)

Eric

[Gimp-print-devel] 740/750 stuff

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

I won't have much time this week to work on the 740 and 750 problems
(and I'll probably have to cut back in general).  The fact that I
don't have one of these printers also makes it hard for me to do very
much.  So can someone else look into this?

-- 
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: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

The variable dot size stuff is definitely broken.  I'm committing
something that should make it do something closer to the right thing,
but it's probably still wrong...

Re: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

On Sun, Feb 06, 2000 at 07:26:36PM -0500, Robert L Krawitz wrote:
> Try it in single dot size mode.  I have a suspicion that the variable
> dot size stuff is broken right now.

That's not it. I just tried the softweave/High Quality/Highest
Quality modes with singe dot size, and the result was the same.

Karl Heinz

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

Re: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

   Date: Sun, 6 Feb 2000 19:06:42 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   The High and Highest Quality settings seem to position the=20
   print heads vertically and then do a number of small vertical
   steps which could in total be about he height of the image and
   the eject the page without any print head movement. This consumes
   the complete print job, no data is left after the page is ejected.

Try it in single dot size mode.  I have a suspicion that the variable
dot size stuff is broken right now.

   The 1440 modes just eject the paper.

Re: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

   Date: Sun, 6 Feb 2000 19:06:42 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   On Sun, Feb 06, 2000 at 05:42:02PM -0500, Robert L Krawitz wrote:
   > OK.  I'm trying one more thing with microweave: using straight 720
   > dpi, no new commands at all.  If THIS doesn't work on any Epson ink
   > jet from the Stylus Color on, I'll be very surprised indeed.
   >=20
   > See if this works, then give softweave a try again.

   Bingo! Microweave is working, 360dpi also works, but Softweave
   gave me "barcode" once, but now only produces blank pages. I=20
   don't understand why it put out the "barcode" the first time
   I tried it. The privious page was finished, so I would assume
   that it was some weird interaction between the softweave data
   stream and the printer settings prior to the job. Unfortunately
   I am not able to recreate this.

   The High and Highest Quality settings seem to position the=20
   print heads vertically and then do a number of small vertical
   steps which could in total be about he height of the image and
   the eject the page without any print head movement. This consumes
   the complete print job, no data is left after the page is ejected.

So there's something wrong with the data itself.  I guess we need to
find someone running one of these printers under Windows to generate a
print file for us and figure out what we're doing wrong.

   The 1440 modes just eject the paper.

Probably something wrong with how we're setting units or something.

Re: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

On Sun, Feb 06, 2000 at 05:42:02PM -0500, Robert L Krawitz wrote:
> OK.  I'm trying one more thing with microweave: using straight 720
> dpi, no new commands at all.  If THIS doesn't work on any Epson ink
> jet from the Stylus Color on, I'll be very surprised indeed.
>=20
> See if this works, then give softweave a try again.

Bingo! Microweave is working, 360dpi also works, but Softweave
gave me "barcode" once, but now only produces blank pages. I=20
don't understand why it put out the "barcode" the first time
I tried it. The privious page was finished, so I would assume
that it was some weird interaction between the softweave data
stream and the printer settings prior to the job. Unfortunately
I am not able to recreate this.

The High and Highest Quality settings seem to position the=20
print heads vertically and then do a number of small vertical
steps which could in total be about he height of the image and
the eject the page without any print head movement. This consumes
the complete print job, no data is left after the page is ejected.

The 1440 modes just eject the paper.

Karl Heinz

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

Re: [Gimp-print-devel] Epson Test Results

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

Well, that's interesting...in microweave mode on the 740, there's some
extra garbage that shouldn't be there.

Re: [Gimp-print-devel] Epson Test Results

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

   Date: Sun, 6 Feb 2000 14:35:12 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I've done some testing this afternoon and was able to get some
   images from my printer (STC740), unfurtunately all the "interesting"
   modes are not working. Here's a table of my findings:

Not work means that it simply ejects the page and does nothing, or
does it print garbage, or something else?

   -----------------------------------------------------------------------
   Test results - printing to a stc740
   -----------------------------------------------------------------------

   Selected Printer	Mode			Result

   Epson Stylus		360 dpi			+
			   720 dpi			+

   Stylus Color 740	360 dpi			-
			   720 dpi Microweave	-

So it works as an Epson Stylus, but not as a Stylus Color 740.  Very
interesting...

-- 
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: [khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

OK.  I'm trying one more thing with microweave: using straight 720
dpi, no new commands at all.  If THIS doesn't work on any Epson ink
jet from the Stylus Color on, I'll be very surprised indeed.

See if this works, then give softweave a try again.

[khk@khk.net: Re: [Gimp-print-devel] Epson Test Results]

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

=2E.. this should have gone to the list as well ...

----- Forwarded message from Karl Heinz Kremer <kh...@kh...> -----

Date: Sun, 6 Feb 2000 17:19:28 -0500
From: Karl Heinz Kremer <kh...@kh...>
To: Robert L Krawitz <rl...@al...>
Subject: Re: [Gimp-print-devel] Epson Test Results
X-Mailer: Mutt 1.0i

On Sun, Feb 06, 2000 at 04:27:40PM -0500, Robert L Krawitz wrote:
> OK, I put in some fixes that *should* (in theory, at any rate) allow
> microweave to work correctly.  If you get this message, could you give
> it a try (in 740 mode)?

I tried the microweave mode with the CVS version from just minutes
ago and it is still not working: The printer does some vertical
movement, probably to the correct place, then stops for a split
second, does some movements and then spits out the page without
ever putting ink on the paper.

At the end the printer goes to the next page, which I do not
allow by only feeding one page and resetting the printer afterwards.

=2E.. just received your mail regarding the variable dot size...
recompiling, installing, retesting ...

=2E.. the result is just a different sound when it stops after the=20
first vertical postitioning. No ink on the paper.

With 360dpi the printer spits out just one page, no additional=20
data in the buffer that requests a new sheet of paper.=20

So it seems that different resolutions result in different problems

Karl Heinz


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



----- End forwarded message -----

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

Re: [Gimp-print-devel] Epson Test Results

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

BTW, just in case the variable dot size gets us into trouble, I've
added an option (under Ink Types) for single dot size.  That's
probably worth a try.

-- 
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] Epson Test Results

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

I notice that in softweave command there were some things out of
sequence that might reasonably matter -- ESC(S followed ESC(V.  So
it's just barely possible that softweave will work now.

-- 
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] Epson Test Results

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

OK, I put in some fixes that *should* (in theory, at any rate) allow
microweave to work correctly.  If you get this message, could you give
it a try (in 740 mode)?

[Gimp-print-devel] Epson Test Results

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

I've done some testing this afternoon and was able to get some
images from my printer (STC740), unfurtunately all the "interesting"
modes are not working. Here's a table of my findings:

-----------------------------------------------------------------------
Test results - printing to a stc740
-----------------------------------------------------------------------

Selected Printer	Mode			Result

Epson Stylus		360 dpi			+
			720 dpi			+

Epson Stylus Pro	360 dpi			-
			720 dpi Microweave	+
			720 dpi Softweave	-
			720 dpi High Quality	-
			720 dpi Highest Quality	-

Epson Stylus Pro XL	360 dpi			+ (low contrast)
			720 dpi Microweave	+
			720 dpi Softweave	-
			720 dpi High Quality	-
			720 dpi Highest Qualtiy	-

Stylus Color 400	360 dpi			+ (low contrast)
			720 dpi Microweave	+
			720 dpi Softweave	-
			720 dpi High Quality	-
			720 dpi Highest Quality	-

Stylus Color 440	360 dpi			+
			720 dpi Microweave	+
			720 dpi Softweave	-
			720 dpi High Quality	-

Stylus Color 500	360 dpi			+ (low contrast)
			720 dpi Microweave	+
			720 dpi Softweave	-

Stylus Color 640	360 dpi			+
			720 dpi Microweave	+
			720 dpi Softweave	-
			720 dpi High Quality	-
			720 dpi Highest Quality	-
			1440x720 Softweave	-
			1440x720 HQ		-
			1440x720 Two Pass	-

Stylus Color 700	360 dpi			-
			720 dpi Microweave	-

Stylus Color 740	360 dpi			-
			720 dpi Microweave	-

Epson Stylus Color 1500	360 dpi			+ (low contrast)
			720 dpi Microweave	+
-----------------------------------------------------------------------

So it looks like all the softweaving modes are not working, with some
printer versions the microweaving is also not working. There are
however some that will work in 360 and 720 Microweave mode.=20

Can somebody make some sense out of this?

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

[Gimp-print-devel] more reorg

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

I created a new file print-dither.c that contains all the dithering
stuff that used to be in print-util.c.  This was simply because
print-util.c was getting a bit too large and unwieldly for my taste.

-- 
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 unknown...

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

> 8, or 6?

I've seen the occasional 6, but it's mostly 8's that I get.

> My tool doesn't show any ESC 0x8, but I do see ESC 0x6 when
> I use the 750 driver (or anything else).  To tell the truth, I don't
> remember why that's in there.

Oh, goody.  Time to read the source more...

Eric