gimp-print-devel

[Gimp-print-devel] http://opensource.corel.com/printlib.html

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

This is an "Application Printing Services API".  It's a bit sparse
right now, but it's worth a check.

Re: [Gimp-print-devel] Recents commits

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

   Date: Wed, 02 Feb 2000 17:28:40 +0100
   From: Andy Thaller <th...@ph...>

   I'm coming to a point where I'd need the possibility to choose the
   installed ink cartridges in the GUI: my BJC can be equipped either
   with a K/CMY combination or Kcm/CMY heads. Other printers allow
   choosing between K and CMY, etc, so generalizing this would make
   sense for me. I'm not too familiar with GTK so if someone offers to
   change the dialog appropriately I'd concentrate on further
   bjc-support.

I went and did it, but I called it "Ink Type" rather than "Print
Head".  This would be useful for other things, such as Luminos inks
for Epson printers.  Luminos inks are special archival inks that are
available for some printers.  They have different characteristics from
Epson inks.  I'm about to check it in.

-- 
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] Recents commits

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

   Date: Wed, 02 Feb 2000 17:28:40 +0100
   From: Andy Thaller <th...@ph...>

   the BJC6000 much more sanely. Except for the still missing left
   image offset the driver should work - as soon as the latter is done
   we can put up a notice about canon-support in the webpages. BTW:
   the new dithering stuff works fine with the canon driver :-)

Good work!

   Another change fixes the lpc-related bug haunting my box ever since
   I'm using the print-plugin: The plp-lpc tool has some paging
   functionality which prints the message "Press RETURN to continue or
   'b' for back one page or 'q' to quit:" after each page leading to
   some quite funny printer entries and extraordinarily wide dropdown
   boxes ;-)

This sort of nonsense is confusing everyone.  Someone tried to give me
a patch to use "lpc status all" rather than "lpc status" because
that's what his lpc needs.  This needs to be part of the configuration
process.

   I'm coming to a point where I'd need the possibility to choose the
   installed ink cartridges in the GUI: my BJC can be equipped either
   with a K/CMY combination or Kcm/CMY heads. Other printers allow
   choosing between K and CMY, etc, so generalizing this would make
   sense for me. I'm not too familiar with GTK so if someone offers to
   change the dialog appropriately I'd concentrate on further
   bjc-support.

It wouldn't be too hard, but it would break compatibility with the
current printrc format (well, I guess we could simply append it to the
end of the current format, but that would be ugly...).  We really need
to think about this, because it's going to come up with other
printers, too...

   The new parameter could be PrintHead and if '*_parameters()'
   returns a NULL pointer the dropdown box could be omitted. Any
   objections, comments or volunteers?

I'm not opposed, just pointing out an ugliness.

[Gimp-print-devel] Epson stuff

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

I took out the fancy 8-byte ESC(c command and replaced it with the
conventional 4-byte variant.  This might help people with 740's.
Could someone give it a try?

Also, would people on this list like to receive CVS commit messages?
I'm receiving them myself, but it occurred to me that people might
like to know what's going on without actually having to take updates.

[Gimp-print-devel] Re: Gimp-print-devel digest, Vol 1 #14 - 5 msgs

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

Robert L Krawitz <rl...@al...> wrote

>    Date: Wed, 02 Feb 2000 00:29:37 +0800
>    From: Nick Urbanik <ni...@vt...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
> 
>    >   But I have
>    >    already run into a problem compiling 3.05.  I've only briefly scanned
>    >    the list archives, so perhaps this has already been answered, but I get
>    >    an error in print.c regarding libgimp/gimpintl.h missing. I did a find
>    >    from / and it isn't anywhere.  I have 1.04 installed.  Is this a new
>    >    file or is something else going on?
> 
>    I mentioned this problem with RH Linux 6.1 on Intel PIII.
> 
>    > If you put -DGIMP_1_0 on the build command line you supposedly can
>    > build it under 1.0, but 1.1 is better for this.
> 
>    Putting -DGIMP_1_0 did not solve the problem of libgimp/gimpintl.h
>    missing.  P.S.  As I mentioned in my previous email, I used an
>    edited version of Makefile.standalone (patch was in previous
>    email).
> 
> Trust me, it will, one of these days :-)
> 
>    Hoping one day to be able to get printing working properly.
> 
> I haven't played with the 1.0 support myself; it's entirely possible
> it's broken, unfortunately...
> 

The 1.0 support is still working in the CVS I downloaded today! Check
in print.c at line 64 for the line:-

#ifdef GIMP_1_0

The code that follows this ifdef only includes libgimp/gimpintl.h if
GIMP_1_0 is NOT defined on the command line when compiling.

The line in my Makefile.standalone reads:-

OPTLEVEL = -O6 -funroll-all-loops -Wall -DGIMP_1_0

and it compiles fine with GIMP 1.0.4.

Dave Hill

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

[Gimp-print-devel] Recents commits

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

I've just committed some changes to the canon-driver allowing it to initialize

the BJC6000 much more sanely. Except for the still missing left image offset
the driver should work - as soon as the latter is done we can put up a notice
about canon-support in the webpages. BTW: the new dithering stuff works fine
with the canon driver :-)

Another change fixes the lpc-related bug haunting my box ever since I'm using
the print-plugin: The plp-lpc tool has some paging functionality which prints
the message "Press RETURN to continue or 'b' for back one page or 'q' to
quit:" after each page leading to some quite funny printer entries and
extraordinarily wide dropdown boxes ;-)

I'm coming to a point where I'd need the possibility to choose the installed
ink cartridges in the GUI: my BJC can be equipped either with a K/CMY
combination or  Kcm/CMY heads. Other printers allow choosing between K and
CMY, etc, so generalizing this would make sense for me. I'm not too familiar
with GTK so if someone offers to change the dialog appropriately I'd
concentrate on further bjc-support.

The new parameter could be PrintHead and if '*_parameters()' returns a
NULL pointer the dropdown box could be omitted. Any objections, comments or
volunteers?

Andy.

[Gimp-print-devel] Joined the list

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

Hi

Just a note to say that I have joined the gimp-print-devel
list and the gimp-print project on Sourceforge.

My name is Dave Hill and I am a Unix Sysadmin in real life. I
am currently "resting" after a 4 year contract so I get some
time to play with my Linux box.

Although an engineer by education, I was a programmer for
a number of years, but not in C. Therefore I tend to write
code that may not use all the esoteric features of C, but
usually works!

I use a HP Deskjet 600C printer with the Gimp print plugin,
hence my joining the project. I am interested in improving the
HP printer support and making sure that it doesn't get too
badly broken by other changes!!

Are there any other HP printer users on the list?

I have found that a great source of HP information is the
ghostscript driver "hpdj" by Martin Lottermoser, see
ftp://ftp.sbs.de/pub/graphics/ghostscript/pcl3

Regards
Dave Hill

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

[Gimp-print-devel] Important commit on the dithering stuff

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

I've just made an important change to print-util.c (and minor changes
to print-escp2.c and print-pcl.c).  In place of the mishmash of
constants in print-util, I created a struct (dither_t) that contains
all the constants.  It looks like this:

typedef struct dither
{
  int error[ERROR_ROWS][NCOLORS][MAX_CARRIAGE_WIDTH*MAX_BPI+1];
  int cbits;
  int lcbits;
  int mbits;
  int lmbits;
  int ybits;
  int lybits;
  int kbits;
  int k_lower;
  int k_upper;
  int lc_level;
  int lm_level;
  int ly_level;
  int c_randomizer;
  int m_randomizer;
  int y_randomizer;
  int k_randomizer;
  int nc_l;
  int nc_log;
  int *c_transitions;
  int *c_levels;
  int nlc_l;
  int nlc_log;
  int *lc_transitions;
  int *lc_levels;
  int nm_l;
  int nm_log;
  int *m_transitions;
  int *m_levels;
  int nlm_l;
  int nlm_log;
  int *lm_transitions;
  int *lm_levels;
  int ny_l;
  int ny_log;
  int *y_transitions;
  int *y_levels;
  int nly_l;
  int nly_log;
  int *ly_transitions;
  int *ly_levels;
  int nk_l;
  int nk_log;
  int *k_transitions;
  int *k_levels;
} dither_t;

Currently, this is essentially static in nature, but there's no reason
that each printer driver couldn't set it up as appropriate.  This is
necessary to allow different printers to share the same dithering
routine.

It printed something out correctly on my printer, so I know it works
perfectly :-)  Seriously, this change was pervasive enough so that
something's almost surely not right somewhere, so take a look at it if
you suspect anything.  Or, if you're close to having something
working, you might not want to take this update quite yet.

-- 
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 BJC 6000

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

   Date: Tue, 01 Feb 2000 16:15:40 +0100
   From: Andy Thaller <th...@ph...>

   BTW: Can I set the density and gamma value for each color and media
   type seperately or is there only one global for all?

There's currently only one density and gamma value, but there's no
reason they couldn't vary for each color.

-- 
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] introduction

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

   Date: Wed, 02 Feb 2000 00:29:37 +0800
   From: Nick Urbanik <ni...@vt...>
   CC: gim...@li...

   Robert L Krawitz wrote:

   >   But I have
   >    already run into a problem compiling 3.05.  I've only briefly scanned
   >    the list archives, so perhaps this has already been answered, but I get
   >    an error in print.c regarding libgimp/gimpintl.h missing. I did a find
   >    from / and it isn't anywhere.  I have 1.04 installed.  Is this a new
   >    file or is something else going on?

   I mentioned this problem with RH Linux 6.1 on Intel PIII.

   > If you put -DGIMP_1_0 on the build command line you supposedly can
   > build it under 1.0, but 1.1 is better for this.

   Putting -DGIMP_1_0 did not solve the problem of libgimp/gimpintl.h
   missing.  P.S.  As I mentioned in my previous email, I used an
   edited version of Makefile.standalone (patch was in previous
   email).

Trust me, it will, one of these days :-)

   Hoping one day to be able to get printing working properly.

I haven't played with the 1.0 support myself; it's entirely possible
it's broken, unfortunately...

-- 
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] introduction

[Nick U. <ni...@vt...>]

Robert L Krawitz wrote:

>   But I have
>    already run into a problem compiling 3.05.  I've only briefly scanned
>    the list archives, so perhaps this has already been answered, but I get
>    an error in print.c regarding libgimp/gimpintl.h missing. I did a find
>    from / and it isn't anywhere.  I have 1.04 installed.  Is this a new
>    file or is something else going on?

I mentioned this problem with RH Linux 6.1 on Intel PIII.

> If you put -DGIMP_1_0 on the build command line you supposedly can
> build it under 1.0, but 1.1 is better for this.

Putting -DGIMP_1_0 did not solve the problem of libgimp/gimpintl.h missing.  P.S.
As I mentioned in my previous email, I used an edited version of
Makefile.standalone (patch was in previous email).

Hoping one day to be able to get printing working properly.

--
Nick Urbanik, Dept. of Electrical & Communications Engineering
Hong Kong Institute of Vocational Education (Tsing Yi)
email: ni...@vt..., ni...@io...
Tel:   (852) 2436 8660, (825) 2436 8674   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

Re: [Gimp-print-devel] CANON BJC 6000

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

Robert L Krawitz wrote:

>  I'm looking at generalizing the drop size stuff in print-util as part
> of the general cleanup of the dithering routines.  Basically, there
> will be an init routine that all of the print routines call that tells
> the dither routine various things (light/dark conversion for 6 or 7
> color printers, a vector of dot sizes, and so forth).  With the vector
> of dot sizes, you should be able to do drop size modulation (doesn't
> Canon support a lot of different drop sizes, unlike Epson which only
> supports 3 sizes even on the current printers?).

I have absolutely no idea. All I know is that according to Canon's data-sheet
(which doesn't really yield much data) in the BJC6000 each nozzle has 2 heating
elements producing 2 differents sizes of ink drops depending if one or both
heaters are active. I also only have a slight glue about how to use this
feature: There's obviously a mode where 2 bits per pixel are transferred to the
printer. Looking at the output is seems as if three drop sizes are actually used.
Apart from this, I've not yet found a reference as to how big the drops are
relative to each other.

BTW: Can I set the density and gamma value for each color and media type
seperately or is there only one global for all?

Andy.

[Gimp-print-devel] Epson STC 740 Debugging

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

.. I'm still here :-) I just don't have any time to work on
the gimp-print stuff right now. The Sane Epson backend work
is taking up all my free time, so the output stuff just has to
wait a little.

Here is what I tried on the weekend: In the past I was able to
use the generic "Epson Stylus" printer to produce output on my
740, the last time I tried this it did not work anymore. I 
tried to identify the command that caused the problem, but was
not successful. All my modifications of the commands with
the wrong number of parameters also did not print. I always end
up with lots of blank pages. So far the printer did not produce
any drop of ink on the paper. At least I'm not wasting ink :-)

As soon as the USB stuff on the scanner is worked out (and some
documentation is written) I will try to work on the printing 
stuff again. BTW: Anybody on this list with an Epson USB
scanner who would like to use it with Sane or Gimp? I'm 
still looking for testers.

Karl Heinz

Re: [Gimp-print-devel] CANON NJC 6000

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

   Date: Tue, 01 Feb 2000 10:16:10 +0100
   From: Andy Thaller <th...@ph...>

   Resolutions 180x180, 360x360, 720x720 and 1440x720 tested fine on A4 plain
   paper, though the left margin is currently ignored. Ink drop size modulation
   doesn't work either and the gamma values are likely to be quite wrong at the
   moment. However, test-prints are possible and everyone is invited to improve
   printing or add support for additional BJC models.

I'm looking at generalizing the drop size stuff in print-util as part
of the general cleanup of the dithering routines.  Basically, there
will be an init routine that all of the print routines call that tells
the dither routine various things (light/dark conversion for 6 or 7
color printers, a vector of dot sizes, and so forth).  With the vector
of dot sizes, you should be able to do drop size modulation (doesn't
Canon support a lot of different drop sizes, unlike Epson which only
supports 3 sizes even on the current 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

[Gimp-print-devel] CANON NJC 6000

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

I've just checked in print-canon.c along with changes to Makefile.am,
Makefile.standalone, print.h and print-util.c

This adds rudimentary support for the CANON BJC 6000 printer.

Resolutions 180x180, 360x360, 720x720 and 1440x720 tested fine on A4 plain
paper, though the left margin is currently ignored. Ink drop size modulation
doesn't work either and the gamma values are likely to be quite wrong at the
moment. However, test-prints are possible and everyone is invited to improve
printing or add support for additional BJC models.

Andy.

PS: no NDA stuff, just guesswork following tons of testprints.... ;-)

Re: [Gimp-print-devel] [utx@k332.feld.cvut.cz: Re: Colormanagement]

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

> Note: I think that colormanagement library should not include only ICC profiles.
> It should include "simple" way based on phospors chromaticity
> and white point for CRT and on C, M, Y, CM, CY, MY and K
> chromaticity for print.
> Ghostscript and PostScript Language Reference Manual is a good source for such
> coding.
> Much worse is to obtain basic chromaticity data (i. e. data for different
> monitors and inks).

I don't think we need to worry too much about monitor variations.  Even
if we could get a published number for phosphor colors, they'd only be valid
for one particular setting of the brightness/contrast controls, ambient
lighting conditions, and monitor age.  Sometimes there are also positional
dependencies on color.  A pixel on the center of the screen isn't necessarily
the same color as a pixel near the edge, nor would it appear to be even if
it was due to the proximity of a (usually) white plastic bezel around the
screen.  All of these things need to be taken into account for precise
color representation.

I think that's beyond our scope and not a good use of our resources to try
and cope with all of that.

There is a published standard called BT. 709 which is what CRT manufacturers
have been supposed to conform to since 1990.  The text of this standard is
not freely available on line, AFAIK, but you can order a copy.

However, you don't really need the official spec.  The essentials of the
BT. 709 color specification are covered in both of the following:

  The Color FAQ (Charles Poynton) 
  http://www.inforamp.net/~poynton/ColorFAQ.html

  The W3 Consortium Standard for Color (co-authored by Microsoft and HP)
  http://www.w3.org/Graphics/Color/sRGB.html

I think we should simply try to follow these standards, and hope that monitor
manufacturers also do a good job of conforming to this specification.

As far as ink colors, I don't think there's quite such a standard.  Most
printers have proprietary drivers for conversion of RGB to the printer's
native ink set.  Getting this information is the most difficult part.

Eric

[Gimp-print-devel] [regisr@regix.com: Re: Colormanagement]

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

------- Start of forwarded message -------
In-Reply-To: <200...@ti...>
Date: Sun, 30 Jan 2000 23:37:47 +0100 (CET)
From: regis rampnoux <re...@re...>
To: Robert L Krawitz <rl...@al...>
Subject: Re: Colormanagement
Cc: gim...@sc...


On 30-Jan-00 Robert L Krawitz wrote:
> We're looking into this stuff a bit on gimp-print.  If anyone here has
> real expertise in this area, we'd like to have you join the gimp-print
> project if you'd like.  Look on sourceforge.net; the project name is
> gimp-print.

There is another project: scarse, but I can't reache the web server any more...
http://ohm.phys.ualberta/scarse/


- ---
<regisr>       re...@re...     http://www.regix.com/
------- End of forwarded message -------

[khk@khk.net: Re: [Gimp-print-devel] [martweb@gmx.net: Colormanagement]]

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

I just realized that I only sent this to Robert and not to
the list like I inteded to. Here's another link to some
color management project:

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

Date: Sat, 29 Jan 2000 22:41:43 -0500
From: Karl Heinz Kremer <kh...@kh...>
To: Robert L Krawitz <rl...@al...>
Subject: Re: [Gimp-print-devel] [ma...@gm...: Colormanagement]
X-Mailer: Mutt 1.0i

Hmmm... this wants to include a file named windows.h :-)

I have two other links regarding CMS and Linux/Unix:

http://www.levien.com/gimp/gcmm.html
http://web.access.net.au/argyll/color.html

The later one does probably the same as the Windows software
(at least as far as we are concerned - apply a color profile
to an image)

Karl Heinz

On Sat, Jan 29, 2000 at 03:16:30PM -0500, Robert L Krawitz wrote:
> ------- Start of forwarded message -------
> Date: Sat, 29 Jan 2000 11:53:17 -0800
> From: "Martin Weber" <ma...@gm...>
> To: gim...@sc...
> Subject: Colormanagement
> 
> Here is an interesting colormanagement for future GIMP releases:
> 
> http://www.abaforum.es/martim/lcms.htm
> ------- End of forwarded message -------
> Date: Sat, 29 Jan 2000 11:55:32 -0800
> From: "Martin Weber" <ma...@gm...>
> To: gim...@sc...
> Subject: Colormanagement II
> 
> http://www.efg2.com/Lab/Library/Color.htm
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

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



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

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

[Gimp-print-devel] [utx@k332.feld.cvut.cz: Re: Colormanagement]

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

------- Start of forwarded message -------
Date: Sun, 30 Jan 2000 18:35:26 +0100
From: Stanislav Brabec <ut...@k3...>
To: gim...@xc...
Subject: Re: Colormanagement
In-Reply-To: <144...@ga...rgle.HOWL>; from tm...@ik... on Sun, Jan 30, 2000 at 01:35:19PM +0200

Few time ago I have found another colormanagement library.
It's completely written in C and license seems to be
BSD like.
web.access.net.au/argyll/icc_readme.html
web.access.net.au/argyll/icclib.zip

Note: I think that colormanagement library should not include only ICC profiles.
It should include "simple" way based on phospors chromaticity
and white point for CRT and on C, M, Y, CM, CY, MY and K
chromaticity for print.
Ghostscript and PostScript Language Reference Manual is a good source for such
coding.
Much worse is to obtain basic chromaticity data (i. e. data for different
monitors and inks).
- -- 
Stanislav Brabec
------- End of forwarded message -------

Re: [Gimp-print-devel] questions

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

>    > (page 41) Monochrome Mode / Color Mode Selection "ESC ( K nL nH m n"
> 
> It works (or at least it doesn't barf) on the EX.

Reading the 740 doc's, it looks like it's just a speed thing, not strictly
necessary.  The 6 color printers probably just ignore it, which is why
it's not documented.

Eric

Re: [Gimp-print-devel] Release strategy

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

> > 1) The current makefile situation is basically silly.  It's just the
> >    generated makefiles, plus a handcrafted one I threw together.  So
> >    we probably need some kind of configure script (which seems like
> >    overkill in a way, but maybe this project isn't so tiny after all),
> >    or the like.
> 
> I'll see what I can do here.  I'll try to upload a conf script along with
> the escp2 to pnm converter.  Expect something Sunday night JST, at the latest.

Ok, I lied.  Autoconf is a little slipperier than I thought.  I'm a
complete novice when it comes to setting it up.  I'll have to put this off
for a few more days, but, I'll keep working on it.  I've got a long train
ride on Tuesday, and twin batteries in my laptop...

Eric

Re: [Gimp-print-devel] questions

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

   From: sh...@al...
   Date: Sun, 30 Jan 2000 22:18:41 +0900

   > (page 41) Monochrome Mode / Color Mode Selection "ESC ( K nL nH m n"

   I wonder if the 750/1200 don't support that...

   It's not listed in the docs for the 700 or EX, either.

It works (or at least it doesn't barf) on the EX.

Re: [Gimp-print-devel] WWW in CVS

[Nicholas P. <pc...@in...>]

Ok, so far I have

---------
^www			Mail -s %s pc...@in...
^www			ssh shell1 /home/groups/gimp-print/updateWebFromCVS.sh
---------

The mail works fine.  /home/groups/gimp-print/updateWebFromCVS.sh
doesn't get executed. I presume this is because ssh doesn't auth. Any
ideas or should I ask in a SF forum ?

--=20
<pc...@in...>           <http://www.innotts.co.uk/~nicholas/>
2048/BEC44395 1999/08/02 Nicholas C. Piper <nic...@in...>
If you want to change the automatic PGP actions of my mailer, see;
http://www.innotts.co.uk/~nicholas/Personal/personal.php3?page=3Dpgp

Re: [Gimp-print-devel] questions

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

   From: sh...@al...
   Date: Sun, 30 Jan 2000 21:19:59 +0900

   One of the first things I noticed was that it generated an unknown command
   error.  gimp-print included an ESC ( K command.  What does this command
   do?  It's not listed in my documentation.  Is there a better document
   that describes this stuff, or, is this an undocumented feature?  Can we
   make a document for undocumented features?

ESC(K sets color vs. black only.  It's not a big deal.

   The other error it generated was a malformed page format error.  The
   page format command ESC ( c should take a 4 byte format string, but
   the one in the file is an 8 byte string.  What does the 8 byte version
   of this command mean?

I don't know.  I'm assuming that it gives 4 bytes for each setting
rather than 2, but we'll have to figure this out.  I got that from
a print output file somebody gave me and my "disassembler".

   I also have some other, more general questions.  There are two ways to send
   raster data to a 750.  Using "ESC i" or "ESC .".   The "." form include
   a density number which lets you know what horizontal DPI the raster
   data should be printed at, but, the "i" version does not.  What determines
   the horizontal printing density for the "i" form?  I assumed that it
   would be a function of the relative horizontal units being used.  This
   probably relates to the page format specification uncertainty I mentioned
   above.  And what exactly are the "page management units" good for?

Page management units are used for the ESC(c command (page format) and
the like.  The doc for the various commands says which unit is used
for each command.  I presume that the horizontal print density for
ESCi comes from the horizontal units (or at any rate, that makes
sense).

In 720 and 1440 dpi mode, I think the right units are 720 dpi for page
management, 1440 for horizontal, and 720 for vertical.  The printer
can't actually do 1440 dpi, though, so that requires two passes with
the carriage shifted by 1 unit for the intermediate dots.  It's also
possible that with ESCi it's automatically running at 720 dpi.  I'll
ask my friend to print something out at 360 dpi.

For the 750, it's really going to be necessary to use ESCi, because
that's the only way to get variable dot size.

-- 
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] introduction

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

   Date: Sat, 29 Jan 2000 22:51:06 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gim...@li...

   sh...@al... wrote:
   > Welcome!
   > 
   Thanks!

   > I think you'll find that Linux is not highly different from Solaris in many
   > respects.
   So far (other than CDE vs whatever) that's what I've seen.  But I have
   already run into a problem compiling 3.05.  I've only briefly scanned
   the list archives, so perhaps this has already been answered, but I get
   an error in print.c regarding libgimp/gimpintl.h missing. I did a find
   from / and it isn't anywhere.  I have 1.04 installed.  Is this a new
   file or is something else going on?

If you put -DGIMP_1_0 on the build command line you supposedly can
build it under 1.0, but 1.1 is better for 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