gimp-print-devel

[Gimp-print-devel] 3.1.0

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

I've put 3.1.0 up on sourceforge.  I know that the 740 issue isn't
settled, and there's still the 800 issue outstanding, but it's a
development release.

I haven't sent out the announcement yet; I'll probably do that in the
morning.

-- 
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] File printer not saving correctly

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

Never mind -- I found the problem.

-- 
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] AAAARRRRRGGGGGHHHHHH.... stc740 Problems not over!

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

   Date: Mon, 21 Feb 2000 18:25:34 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   - I'm either losing my mind, or there is something seriously wrong
   with what I'm doing: I can not get the softweave printing to work
   again with my STC740. I tried every version from the CVS repository
   from 1.87 to 1.92 and with none of these can I reproduce the=20
   results I reported this weekend.=20

I just checked in a new version, it's worth a try...

   Is it possible that some modification elsewhere triggers the problems?
   I am seeing the blank pages again.

Grr....

   - The "magic" init string causes more harm on my printer: Once I've=20
   sent a file with this string it makes noises that really scare my:
   Every vertical movement sounds like the printer is broken. And this
   does not go away until I powercycle the printer (a new print job
   with these lines removed sounds the same). I have now ifdef'ed these
   lines in my personal version, just to be able to test again.

   And: No, the softweave does not work when the file uses the init
   string.

It sounded like it was doing weird things on the 640, also.  I've set
it so that it only gets used on the 900.

-- 
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] File printer not saving correctly

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

Whatever I set the File pseudo-printer to, the next time I run the
plugin it comes out in postcard size, with the Postscript driver set.

-- 
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] AAAARRRRRGGGGGHHHHHH.... stc740 Problems not over!

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

Two things:

- I'm either losing my mind, or there is something seriously wrong
with what I'm doing: I can not get the softweave printing to work
again with my STC740. I tried every version from the CVS repository
from 1.87 to 1.92 and with none of these can I reproduce the=20
results I reported this weekend.=20

Is it possible that some modification elsewhere triggers the problems?
I am seeing the blank pages again.

- The "magic" init string causes more harm on my printer: Once I've=20
sent a file with this string it makes noises that really scare my:
Every vertical movement sounds like the printer is broken. And this
does not go away until I powercycle the printer (a new print job
with these lines removed sounds the same). I have now ifdef'ed these
lines in my personal version, just to be able to test again.

And: No, the softweave does not work when the file uses the init
string.

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

Re: [Gimp-print-devel] Re: Unprint

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

   Date: Sun, 20 Feb 2000 20:56:36 +0000
   From: Dave Hill <da...@mi...>

   Robert L Krawitz wrote:
   > 
   >    Date: Sat, 19 Feb 2000 19:12:28 +0000
   >    From: Dave Hill <da...@mi...>
   > 
   >    I tried with the output of print-2.0.2 and the CMY part
   >    contains no black at all, but in all the 3.x versions back to
   >    20000131, the CMY part contains black smears or shadows (the
   >    K part is fine).
   > 
   > What do you mean that the CMY stuff contains "black" smears or
   > shadows?  The 3.x code will use some amount of CMY mixture to generate
   > gray, depending upon the black level, but that's by intent.

   Hi Robert.

   I mean that there is unwanted black "bleeding" into areas outside
   the supposed black.

   I will try and make you some small files to show you.

That was a real bug, all right.  Actually, it was two bugs:

1) Under certain circumstances, the amount of CMY (but probably not K)
   could grow without bound.  That was the cause of the blobs.
   Basically, if the density was high enough, the algorithm would go
   unstable.  I've fixed it by capping the amount of CMY that can be
   tossed into the dither pool.  The fix isn't perfect -- edges aren't
   perfectly sharp -- but it's stable now.

2) Certain image types (indexed RGB, in particular) did not do the
   density calculation (rescaling the LUT, basically).

Both of these are fixed and committed, and will be in 3.1.0 (and 3.0.7!)

-- 
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] Print plugin 3.0.6 bug report

[Stefan K. B. <sf...@co...>]

Robert L Krawitz wrote:
> 
>    Date: Mon, 21 Feb 2000 10:00:11 +0100
>    From: "Stefan K. Berg" <sf...@co...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
> 
>    > Really.  That's very interesting.  Remind me again what you have --
>    > it's an 800, right?  In a way, this is good news; the only issue is
>    > whether some printers need the 5 and some need the 40.
> 
>    Yes, an 800.
> 
> Are you still having trouble printing in microweave?

I just did a test with my previously black test picture, and the answer is no!
It looks fine.

>    > None of those are correct.  Could you also try 64/4, 32/4, and 64/16?
>    > And if none of those look correct, 32/16 (although that strikes me as
>    > unlikely)?
> 
>    The alternatives 64/16 and 32/16 gave me a floating point exception
>    just after selecting the printer type and pressing OK. Stack dump
>    at the end of this message.
> 
> It turns out that the weave code can handle this, but there's other
> code that stores the separation as a 4-bit field.  No matter.
> 
>    None of the 64/4 or 32/4 looked good, but I've put them up at
> 
>    http://home.swipnet.se/consultron/scan3.jpg (56 kB) if they might give you
>    some information.
> 
> Could you also try 24,4, 24,6, 24,8, and 24,12, please?  And compare them (if
> possible) to microweave (720 or 360) for correct sizing?

I did, but found 24/1 to be the best looking so far (very small horizontal
stripes) and it looks just right in size compared to the output in microweave
720. All the other variations has been too large vertically. Talking strictly
proportionally, it would seem that 24/0 would be a great setting...

Pictures as always on http://home.swipnet.se/consultron/test4.jpg (87 kB). The
microweave version is the one at the bottom to the right.

I will use a better (non-indexed) test picture from now.

[Gimp-print-devel] Proposed 3.1.0 release notes

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

This is the Print plugin for the Gimp, version 3.1.0.  This is a
development release, the first on the 3.1 branch.  If this software
causes your print head to zoom off the end of your printer, spilling
ink all over your 1000 year old Persian rug, don't blame us.
Remember, you installed the software.

This software also comes with a GhostScript driver for Epson Stylus
printers.  The support for Epson Stylus printers in the GhostScript
driver is identical to the support for these printers in the Print
plugin -- they use the identical code base.

This plugin can be compiled against either Gimp 1.1 or 1.0.

Print 3.1.0 contains the following user-visible improvements over
Print 3.0.5, the version distributed with the Gimp 1.1.17:

1) Preliminary support for Canon BubbleJet printers (specifically the
   BJC6000).

2) Preliminary support for the Epson Stylus Color 440/640/740/900 and
   Stylus Photo 750/1200 printers.  These printers should in theory
   work in all modes, although that has not been comprehensively
   tested.  1440 dpi mode on the 900 in particular may not work.
   There is also pre-preliminary support for the Stylus Photo 870 and
   1270 based on the published specifications.  This driver is
   completely untuned for these printers at present.

3) Ability to position the image on the page to the point (1/72", or
   about .35 mm), along with a more accurate depiction of the
   positioning on the page.

4) One-click ability to scale to the image resolution (Gimp 1.1 only).

5) Much better handling of the saved state (printrc file), including
   saving of parameters related to file output.

6) Utilities (in various states of completion) to reconstitute an
   image from a print file.

There are additional improvements over Print 2.0.2 (the version
distributed with Gimp 1.1.11 and earlier) too numerous to list here.

-- 
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] Print plugin 3.0.6 bug report

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

   Date: Mon, 21 Feb 2000 10:00:11 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   Robert L Krawitz wrote:

   > Really.  That's very interesting.  Remind me again what you have --
   > it's an 800, right?  In a way, this is good news; the only issue is
   > whether some printers need the 5 and some need the 40.

   Yes, an 800.

Are you still having trouble printing in microweave?

   > None of those are correct.  Could you also try 64/4, 32/4, and 64/16?
   > And if none of those look correct, 32/16 (although that strikes me as
   > unlikely)?

   The alternatives 64/16 and 32/16 gave me a floating point exception
   just after selecting the printer type and pressing OK. Stack dump
   at the end of this message.

It turns out that the weave code can handle this, but there's other
code that stores the separation as a 4-bit field.  No matter.

   None of the 64/4 or 32/4 looked good, but I've put them up at

   http://home.swipnet.se/consultron/scan3.jpg (56 kB) if they might give you
   some information.

Could you also try 24,4, 24,6, 24,8, and 24,12, please?  And compare them (if
possible) to microweave (720 or 360) for correct sizing?

If none of those look right, the next one I'd try is 48,6.

   > I made a change to the softweave code that will affect all of the
   > older Epson printers (no variable dot size) in softweave mode.
   > Specifically, the sequence I was using (which worked on the EX) didn't
   > work on some other printers (the 800, most notably).  The change that
   > I made does work on the EX.  I really need everyone with such a
   > printer to do a quick test of this change!

   Downloaded and tried it and the change works OK - i.e. I do no longer get
   paper feeds (STC800), just striped output. :)

Great.  Thanks for testing it.

-- 
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] Width and Height OK with stc740

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

sh...@al... wrote:

> What I've done in unprint.c is to isolate all of the escp2 specific parts
> into a single subroutine.  This subroutine is given a file pointer to an
> open file, and it reads in the escp2 data.  When it extracts a section
> of raster data from the file, it makes a call to a generic routine to store
> this data in RAM.  When the escp2 routine returns, the stored image is
> organized into a PPM and written out.
>
> I would like to convert pcl-unprint and cannon-unprint to work the same way
> as the parse-escp2 subroutine of unprint.  Any comments/objections?

Just checked in canon-unprint.c
I took escp2-unprint.c and replaced the parse_escp2() with parse_canon() which
currently only checks if the sequence of ESC commands are syntactically correct.
No real data is being parsed yet and thus the output is a 0x0 image... I'll fill
in the rest when I've got more time to spend

Andy.

Re: [Gimp-print-devel] Print plugin 3.0.6 bug report

[Stefan K. B. <sf...@co...>]

Robert L Krawitz wrote:
> 
>    Date: Mon, 21 Feb 2000 00:10:28 +0100
>    From: "Stefan K. Berg" <sf...@co...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
>    >
>    >    Date: Sun, 20 Feb 2000 19:22:36 +0100
>    >    From: "Stefan K. Berg" <sf...@co...>
>    >    CC: gim...@li...
>    >
>    >    Robert L Krawitz wrote:
>    >
>    >    > Could you try a couple of other things?
>    >    >
>    >    > 1) Try changing MODEL_MAKE_NOZZLES(64) to MODEL_MAKE_NOZZLES(24).
>    >    >
>    >    > 2) At line 2447, the following appears:
>    >    >
>    >    >               fprintf(prn, "\033.%c%c%c%c", 1, 8 * 5, 5,
>    >    >
>    >    > Please change the "8 * 5" to "5" (not in quotes, of course).
>    >    >
>    >    > 3) At line 2407, the following appears:
>    >    >
>    >    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
>    >    >
>    >    > Please change it to
>    >    >
>    >    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES) &&
>    >    >           ydpi > 720)
>    >    >
>    >    > Let me know if anything changes in softweave mode.
>    >
>    >    Yes indeed, this time I get output of about the right size but it
>    >    looks very garbled. I've scanned the output of 720 DPI Softweave
>    >    mode, which you will find at
>    >    http://home.swipnet.se/consultron/scan1.gif (96 kB). The black ink
>    >    has bled through my inkjet paper. Also, the printer made some
>    >    strange noises when printing this - a quiet but noticable
>    >    "whooshing" sound from time to time.
>    >
>    > 1) Could you try to identify which of the three changes made it work
>    >    (try them one at a time)?  That would be extremely helpful.
> 
>    The second one, the fprintf. The third one doesn't seem to change anything.
> 
> Really.  That's very interesting.  Remind me again what you have --
> it's an 800, right?  In a way, this is good news; the only issue is
> whether some printers need the 5 and some need the 40.

Yes, an 800.
 
>    > 2) It's apparent that the inter-row spacing (which is set to 8) is
>    >    incorrect.  My suspicion is that the proper value should be 6, and
>    >    that MODEL_MAKE_NOZZLES(48) is correct here.  This can be tested by
>    >    changing MODEL_MAKE_SEPARATION(8) to MODEL_MAKE_SEPARATION(6).
>    >    It's not impossible that the right value is 12 or even 16, though.
> 
>    I tried a number of variations, but so far the best one was 32 nozzles and
>    a separation of one. That gave me white horizontal stripes, but otherwise an
>    OK picture. I have done several tests and scanned them into
> 
>    http://home.swipnet.se/consultron/scan2.jpg (188 kB)
> 
> None of those are correct.  Could you also try 64/4, 32/4, and 64/16?
> And if none of those look correct, 32/16 (although that strikes me as
> unlikely)?

The alternatives 64/16 and 32/16 gave me a floating point exception just after
selecting the printer type and pressing OK. Stack dump at the end of this
message.

None of the 64/4 or 32/4 looked good, but I've put them up at

http://home.swipnet.se/consultron/scan3.jpg (56 kB) if they might give you
some information.

> I made a change to the softweave code that will affect all of the
> older Epson printers (no variable dot size) in softweave mode.
> Specifically, the sequence I was using (which worked on the EX) didn't
> work on some other printers (the 800, most notably).  The change that
> I made does work on the EX.  I really need everyone with such a
> printer to do a quick test of this change!

Downloaded and tried it and the change works OK - i.e. I do no longer get
paper feeds (STC800), just striped output. :)

The stack dump for 64/16 and 32/16 with the latest mainline:

/usr/local/lib/gimp/1.1/plug-ins/print: Floating point exception caught
/usr/local/lib/gimp/1.1/plug-ins/print (pid:2140): [E]xit, [H]alt, show [S]tacktrace or [P]roceed: s
#0  0x401cf780 in g_on_error_stack_trace (
#1  0x401cf67d in g_on_error_query (
#2  0x4004cf14 in gimp_signal (signum=8) at gimp.c:1171
#3  0x402d8b18 in __restore ()
#4  0x80641d9 in plist_callback (widget=0x0, data=0) at print.c:2448
#5  0x8064c1f in setup_ok_callback () at print.c:2678
#6  0x400f165d in gtk_marshal_NONE__NONE (object=0x8107090,
#7  0x40122155 in gtk_handlers_run (handlers=0x810d190, signal=0xbfffe940,
#8  0x401214a0 in gtk_signal_real_emit (object=0x8107090, signal_id=79,
#9  0x4011f3f1 in gtk_signal_emit (object=0x8107090, signal_id=79)
#10 0x4008b5e8 in gtk_button_clicked (button=0x8107090) at gtkbutton.c:338
#11 0x4008cd48 in gtk_real_button_released (button=0x8107090)
#12 0x400f165d in gtk_marshal_NONE__NONE (object=0x8107090,
#13 0x40121343 in gtk_signal_real_emit (object=0x8107090, signal_id=78,
#14 0x4011f3f1 in gtk_signal_emit (object=0x8107090, signal_id=78)
#15 0x4008b528 in gtk_button_released (button=0x8107090) at gtkbutton.c:329
#16 0x4008c6a2 in gtk_button_button_release (widget=0x8107090, event=0x812b8e0)
#17 0x400f1229 in gtk_marshal_BOOL__POINTER (object=0x8107090,
#18 0x401214d9 in gtk_signal_real_emit (object=0x8107090, signal_id=21,
#19 0x4011f3f1 in gtk_signal_emit (object=0x8107090, signal_id=21)
#20 0x40157f58 in gtk_widget_event (widget=0x8107090, event=0x812b8e0)
#21 0x400f1182 in gtk_propagate_event (widget=0x8107090, event=0x812b8e0)
#22 0x400f02fa in gtk_main_do_event (event=0x812b8e0) at gtkmain.c:770
#23 0x401a3e5b in gdk_event_dispatch (source_data=0x0,
#24 0x401d3673 in g_main_dispatch (current_time=0xbffff39c) at gmain.c:656
#25 0x401d3cab in g_main_iterate (block=1, dispatch=1) at gmain.c:874
#26 0x401d3e61 in g_main_run (loop=0x812ad58) at gmain.c:932
#27 0x400efbdb in gtk_main () at gtkmain.c:476
#28 0x80621c7 in do_print_dialog () at print.c:1670
#29 0x805e2e3 in run (name=0x80d2748 "file_print", nparams=3, param=0x80d2758,
#30 0x4004d2d9 in gimp_proc_run (proc_run=0x80d2738) at gimp.c:1375
#31 0x4004d109 in gimp_loop () at gimp.c:1268
#32 0x4004bcaa in gimp_main (argc=6, argv=0xbffff5e4) at gimp.c:257
#33 0x805e160 in main (argc=6, argv=0xbffff5e4) at print.c:342

[Gimp-print-devel] Re: Unprint

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

Eric Wrote:

> Why don't you check in the code you have so far and then we can all
> take a look at it.  Code doesn't need to be "bug-free" to get checked
> in.  If it compiles, runs, and produces output, that's good enough for
> a commission.

Have done so.

pcl-unprint now supports TIFF compressed PCL files (i.e. all
print-pcl printers higher than Deskjet 500), plus it now writes
colour PNM files for all 2-level CMY and CMYK printers. So
the only ones not supported yet are the Deskjet 800 series
(4 level) and, of course, any newer HP printers that aren't
supported by print-pcl!

This version has a quick hack. If you compile normally, it
will output a CMYK image normally. If you compile
with -DOUTPUT_CMYK_ONLY_K it will only output the K, and
similarly for -DOUTPUT_CMYK_ONLY_CMY. They will probably
become debugging options later!

For now, I just or'ed together the black and the CMY images.

Dave

PS If anyone knows anything about newer HP printers (ones that
take the Photo cartridge), I am interested in hearing from
them. I have started taking a passing interest in HP printers
that come up in our local auction house (reading the book
if there is one!).

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

[Gimp-print-devel] Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable

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

   Date: Sun, 20 Feb 2000 22:36:11 +0000 (GMT)
   From: Austin Donnelly <au...@gi...>
   Cc: gim...@sc...

   On Saturday, 19 Feb 2000, Robert L Krawitz wrote:

   > Pending a general way to scale images separately on X and Y axes, what
   > would be your (collective) suggestions about how to handle an image
   > with different X and Y resolutions?

   This happens so rarely that I would (for the moment) ignore it.

   Assume the Y resolution is the same as the X resolution.

OK, the next version (3.0.7) will have a button called "Set Image
Scale" next to the other two scaling buttons (percent and PPI).  It
will immediately set the image to PPI mode and set the resolution to
the Y resolution of the image.  This may not be ideal, but it's quick
and easy to test.  Anything else is likely to be fairly high risk.

This is already checked into the development mainline.  It's strictly
a GUI hack, and has no effect on the rest of the system.

I'm going to hold 3.0.7 until Michael J. Hammel and I can get his
printing issue resolved, and someone else can test a softweave change
I made for the Stylus Color 800 (which is really a fairly general
issue).  Those are important but almost surely very local bugs.

-- 
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] Another IMPORTANT but small Epson change

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

This time it's for the new printers.  There's this strange
initialization sequence that seems to need to be sent once for these
printers to print in softweave.

-- 
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] IMPORTANT but small Epson change

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

I made a change to the softweave code that will affect all of the
older Epson printers (no variable dot size) in softweave mode.
Specifically, the sequence I was using (which worked on the EX) didn't
work on some other printers (the 800, most notably).  The change that
I made does work on the EX.  I really need everyone with such a
printer to do a quick test of this change!

-- 
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] stc740 success

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
>    Date: Sat, 19 Feb 2000 22:38:52 -0700
>    From: "S. Miller" <sm...@rn...>
> 
> I know that it isn't as grain-free as the Windows driver.  We might
> need to adjust the dot size stuff (was this variable dot size or
> single dot size?) some, too.

This was variable dot size.

> 
>    I also found is that it is way too easy to tell the printer to print off
>    the page, which results in a bunch of blank paper being thrown around.
>    Is this something we could try to pick up in the gui and enforce a limit
>    before it gets to the driver?  At the moment its kind of late, and I'm
>    not quite sure how to go about it.
> 
> It does, if you select the right paper size and if we have the borders
> correct.
> 
I selected letter size paper, which is all I have.  I'm guessing the
borders need work.

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] Print plugin 3.0.6 bug report

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

   Date: Mon, 21 Feb 2000 00:10:28 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   Robert L Krawitz wrote:
   > 
   >    Date: Sun, 20 Feb 2000 19:22:36 +0100
   >    From: "Stefan K. Berg" <sf...@co...>
   >    CC: gim...@li...
   > 
   >    Robert L Krawitz wrote:
   > 
   >    > Could you try a couple of other things?
   >    >
   >    > 1) Try changing MODEL_MAKE_NOZZLES(64) to MODEL_MAKE_NOZZLES(24).
   >    >
   >    > 2) At line 2447, the following appears:
   >    >
   >    >               fprintf(prn, "\033.%c%c%c%c", 1, 8 * 5, 5,
   >    >
   >    > Please change the "8 * 5" to "5" (not in quotes, of course).
   >    >
   >    > 3) At line 2407, the following appears:
   >    >
   >    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
   >    >
   >    > Please change it to
   >    >
   >    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES) &&
   >    >           ydpi > 720)
   >    >
   >    > Let me know if anything changes in softweave mode.
   > 
   >    Yes indeed, this time I get output of about the right size but it
   >    looks very garbled. I've scanned the output of 720 DPI Softweave
   >    mode, which you will find at
   >    http://home.swipnet.se/consultron/scan1.gif (96 kB). The black ink
   >    has bled through my inkjet paper. Also, the printer made some
   >    strange noises when printing this - a quiet but noticable
   >    "whooshing" sound from time to time.
   > 
   > 1) Could you try to identify which of the three changes made it work
   >    (try them one at a time)?  That would be extremely helpful.

   The second one, the fprintf. The third one doesn't seem to change anything.

Really.  That's very interesting.  Remind me again what you have --
it's an 800, right?  In a way, this is good news; the only issue is
whether some printers need the 5 and some need the 40.

   > 2) It's apparent that the inter-row spacing (which is set to 8) is
   >    incorrect.  My suspicion is that the proper value should be 6, and
   >    that MODEL_MAKE_NOZZLES(48) is correct here.  This can be tested by
   >    changing MODEL_MAKE_SEPARATION(8) to MODEL_MAKE_SEPARATION(6).
   >    It's not impossible that the right value is 12 or even 16, though.

   I tried a number of variations, but so far the best one was 32 nozzles and
   a separation of one. That gave me white horizontal stripes, but otherwise an
   OK picture. I have done several tests and scanned them into

   http://home.swipnet.se/consultron/scan2.jpg (188 kB)

None of those are correct.  Could you also try 64/4, 32/4, and 64/16?
And if none of those look correct, 32/16 (although that strikes me as
unlikely)?

-- 
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] Print plugin 3.0.6 bug report

[Stefan K. B. <sf...@co...>]

Robert L Krawitz wrote:
> 
>    Date: Sun, 20 Feb 2000 19:22:36 +0100
>    From: "Stefan K. Berg" <sf...@co...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
> 
>    > Could you try a couple of other things?
>    >
>    > 1) Try changing MODEL_MAKE_NOZZLES(64) to MODEL_MAKE_NOZZLES(24).
>    >
>    > 2) At line 2447, the following appears:
>    >
>    >               fprintf(prn, "\033.%c%c%c%c", 1, 8 * 5, 5,
>    >
>    > Please change the "8 * 5" to "5" (not in quotes, of course).
>    >
>    > 3) At line 2407, the following appears:
>    >
>    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
>    >
>    > Please change it to
>    >
>    >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES) &&
>    >           ydpi > 720)
>    >
>    > Let me know if anything changes in softweave mode.
> 
>    Yes indeed, this time I get output of about the right size but it
>    looks very garbled. I've scanned the output of 720 DPI Softweave
>    mode, which you will find at
>    http://home.swipnet.se/consultron/scan1.gif (96 kB). The black ink
>    has bled through my inkjet paper. Also, the printer made some
>    strange noises when printing this - a quiet but noticable
>    "whooshing" sound from time to time.
> 
> 1) Could you try to identify which of the three changes made it work
>    (try them one at a time)?  That would be extremely helpful.

The second one, the fprintf. The third one doesn't seem to change anything.
 
> 2) It's apparent that the inter-row spacing (which is set to 8) is
>    incorrect.  My suspicion is that the proper value should be 6, and
>    that MODEL_MAKE_NOZZLES(48) is correct here.  This can be tested by
>    changing MODEL_MAKE_SEPARATION(8) to MODEL_MAKE_SEPARATION(6).
>    It's not impossible that the right value is 12 or even 16, though.

I tried a number of variations, but so far the best one was 32 nozzles and
a separation of one. That gave me white horizontal stripes, but otherwise an
OK picture. I have done several tests and scanned them into

http://home.swipnet.se/consultron/scan2.jpg (188 kB)

for your reference. The X/Y syntax is of course referring to no of nozzles
and the separation.

Happily waiting for the opportunity to use some more ink! :)

[Gimp-print-devel] 3.1.0

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

Unless anyone voices any serious objections, I plan to release 3.1.0
tomorrow (Monday) -- the Presidents' Day Special.  Please have stuff
checked in by then that you'd like to see in this release.

This is, of course, going to be a development release.  It's not
necessary that everything work perfectly, but we do have significant
new functionality (many of the new Epson printers, the Canon stuff,
the proper positioning) that should see the light of day to get more
testing.

-- 
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] stc740 success

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

   Date: Sat, 19 Feb 2000 22:38:52 -0700
   From: "S. Miller" <sm...@rn...>

   I tried a new round of tests when I got home this evening, and
   positioning seems to be working great.  I then tried a more or less full
   size print of a scanned (at 450 dpi) photo, printed at 1440x720 on
   coated paper.  The results were not as good as I expected.  Dithering in
   a blue sky was grainy, and greens did not fare well at all.  Otherwise,
   it looked OK, although some adjustments in contrast and saturation would
   help.  Some experimentation is probably needed to find good default
   values fro all the sliders across a variety of scene types.

I know that it isn't as grain-free as the Windows driver.  We might
need to adjust the dot size stuff (was this variable dot size or
single dot size?) some, too.

   I also found is that it is way too easy to tell the printer to print off
   the page, which results in a bunch of blank paper being thrown around. 
   Is this something we could try to pick up in the gui and enforce a limit
   before it gets to the driver?  At the moment its kind of late, and I'm
   not quite sure how to go about it.

It does, if you select the right paper size and if we have the borders
correct.

-- 
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] Re: Unprint

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

   Date: Sun, 20 Feb 2000 20:56:36 +0000
   From: Dave Hill <da...@mi...>

   I mean that there is unwanted black "bleeding" into areas outside
   the supposed black.

   I will try and make you some small files to show you.

How far outside the intended black?

-- 
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] Re: Unprint

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 19 Feb 2000 19:12:28 +0000
>    From: Dave Hill <da...@mi...>
> 
>    I tried with the output of print-2.0.2 and the CMY part
>    contains no black at all, but in all the 3.x versions back to
>    20000131, the CMY part contains black smears or shadows (the
>    K part is fine).
> 
> What do you mean that the CMY stuff contains "black" smears or
> shadows?  The 3.x code will use some amount of CMY mixture to generate
> gray, depending upon the black level, but that's by intent.
> 

Hi Robert.

I mean that there is unwanted black "bleeding" into areas outside
the supposed black.

I will try and make you some small files to show you.

Dave


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

Re: [Gimp-print-devel] Re: Unprint

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

   Date: Sat, 19 Feb 2000 19:12:28 +0000
   From: Dave Hill <da...@mi...>

   I tried with the output of print-2.0.2 and the CMY part
   contains no black at all, but in all the 3.x versions back to
   20000131, the CMY part contains black smears or shadows (the
   K part is fine).

What do you mean that the CMY stuff contains "black" smears or
shadows?  The 3.x code will use some amount of CMY mixture to generate
gray, depending upon the black level, but that's by intent.

-- 
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] ESC(D command

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

   From: sh...@al...
   Date: Mon, 21 Feb 2000 01:29:12 +0900

   I got my wife on the 'net, and with a talk session going in on window and
   a shell in another, I sent files to the printer and had her interpret the
   results.

Thanks to you and your wife!

   I used the Graphic2.prn file, and used beav to modify the file before
   sending it to the printer.  First we printed the original file unmodified.
   Then I removed the ESC(D command entirely, then I changed 78 28 to 28 50,
   then I sent the command with all four bytes 0, and finally we printed the
   original again, to guage changes in the printer itself due to warming up.

So the ESC(D command *appears* to be spurious.  Hmm...

-- 
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] Print plugin 3.0.6 bug report

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

   Date: Sun, 20 Feb 2000 19:22:36 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   Robert L Krawitz wrote:

   > Could you try a couple of other things?
   > 
   > 1) Try changing MODEL_MAKE_NOZZLES(64) to MODEL_MAKE_NOZZLES(24).
   > 
   > 2) At line 2447, the following appears:
   > 
   >               fprintf(prn, "\033.%c%c%c%c", 1, 8 * 5, 5,
   > 
   > Please change the "8 * 5" to "5" (not in quotes, of course).
   > 
   > 3) At line 2407, the following appears:
   > 
   >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
   > 
   > Please change it to
   > 
   >       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES) &&
   >           ydpi > 720)
   > 
   > Let me know if anything changes in softweave mode.

   Yes indeed, this time I get output of about the right size but it
   looks very garbled. I've scanned the output of 720 DPI Softweave
   mode, which you will find at
   http://home.swipnet.se/consultron/scan1.gif (96 kB). The black ink
   has bled through my inkjet paper. Also, the printer made some
   strange noises when printing this - a quiet but noticable
   "whooshing" sound from time to time.

1) Could you try to identify which of the three changes made it work
   (try them one at a time)?  That would be extremely helpful.

2) It's apparent that the inter-row spacing (which is set to 8) is
   incorrect.  My suspicion is that the proper value should be 6, and
   that MODEL_MAKE_NOZZLES(48) is correct here.  This can be tested by
   changing MODEL_MAKE_SEPARATION(8) to MODEL_MAKE_SEPARATION(6).
   It's not impossible that the right value is 12 or even 16, though.

   Setting MODEL_HASBLACK_NO without applying your modifications above
   did nothing, I still got paper feeds. Setting MODEL_HASBLACK_NO
   with the above changes gave me rows of color each with different
   distances of each other but never less than 0.5 inch apart.

I didn't expect that this would have much effect.

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