Menu
▾
▴
gimp-print-devel
|
From: Jean-Marc V. <ver...@if...> - 2000-05-03 02:08:37
|
On May 2, 7:58pm, Robert L Krawitz wrote:
> Welcome!
Thanks
>
> { 0.152, 0x1, 0 },
> { 0.255, 0x2, 0 },
> { 0.38, 0x3, 0 },
> { 0.5, 0x1, 1 },
> { 0.67, 0x2, 1 },
> { 1.0, 0x3, 1 }
>
> The last 3 values also go for K and Y (simple case).
>
> Well, this is easy to fix. Thank you for doing this. Would you like
> to commit the fix?
Sure if it's also applicable to other printers.
> The balance between light and dark inks is very different from what I've
> come up with; I came up with .25. It might be that I'm using
> different inks, or they might simply be reformulated.
I just went back to what I had found for 3.1.2 and it was also between 0.35
and 0.4. 0.25 is definitely too low for me; 0.33 already is (too low).
>
> Could someone test these on a 740 and a 900 (standard_dither_ranges
> and dot_sizes also needs to be fixed the same way)?
>
> On my STP870, my values yield absolutely identical densities for each of
the
> inks/levels. The color balance still needs to be improved.
>
> What's wrong? Maybe I can make some suggestions.
>
Primarily, red looks too yellow and blue too magenta to me. Gray is not quite
gray either. This can probably be fixed by adjusting the respective densities
but I haven't tried yet.
> If I understand well, this should therefore apply as well to
print-escp2.c:
>
> 1217,1218c1217,1218
> < dither_set_c_ranges(dither, 5, variable_dither_ranges,
v->density);
> < dither_set_m_ranges(dither, 5, variable_dither_ranges,
v->density);
> ---
> > dither_set_c_ranges(dither, 6, variable_dither_ranges,
v->density);
> > dither_set_m_ranges(dither, 6, variable_dither_ranges,
v->density);
>
> Indeed it should.
>
> Finally as of the version before today's black was too dark.
>
> Let us know how the version as of this morning works, since that was
> one of the key improvements. Maybe we can also try lower black
> thresholds (particularly k_lower) with the variable dot sizes.
>
Wow, much better ! I can see color again :) The thresholds look excellent.
Looks a bit grainy (Dither=2), but that's photo quality again.
By the way, I'm not using the gimp here, but ghostscript.
--
--
Jean-Marc Verbavatz <ver...@if...>
5, rue La Fontaine "http://perso.cybercable.fr/verbavat"
F-75016 Paris
|
|
From: Jean-Marc V. <ver...@if...> - 2000-05-03 23:18:11
|
> OK, probably the inks are different. I should put an Epson cartridge > in my printer and see what happens. Aha, that would explain. I'm using Epson inks. > > Primarily, red looks too yellow and blue too magenta to me. Gray is > not quite gray either. This can probably be fixed by adjusting the > respective densities but I haven't tried yet. > > I've noticed that too. Does your gray turn out slightly greenish? Yup. > > Wow, much better ! I can see color again :) The thresholds look excellent. > Looks a bit grainy (Dither=2), but that's photo quality again. > > Try adaptive random (dither=4). I need to take a closer look at this > grain issue, since the stuff as of this morning seems to have > regressed a bit. > Same thing with dither=4. The rendenring is slightly different but about as grainy. I just printed the exact same photograph (a rather difficult one from previous experience) with my version of gimp-print-3.1.2 (a), with stock 3.1.3 (b), yesterday's 3.1.3 with dither=2 (c) and with dither=4 (d). b, compared to others is lousy. That's history. c and d don't differ significantly. They're good. A bit grainy, slightly oversaturated, greenish grays (see above). At this point (a) is best in my opinion. A little less saturated than c,d (but whether this is worse or better is rather subjective and can be adjusted). Better grays. Less grainy. Why (a) is better, I don't know yet, but I might find out by examining the ouput. I'll report later. I have some thoughts though: The greenish thing should not be difficult to fix. That's color balance again and probably involves no specific flow in the algorithms. One issue in the grain, I've seen it while working on 3.1.2, is what I would call "undersampling of smallest drops". Because I'm new here I don't know whether this has been discussed before, sorry. Anyway, I think that smallest drops in variable size (or smallest ink levels) are so tiny that they don't fill in. Take 50% gray. If printed with only smallest dot size black will shoot everytime at 720 dpi and yet will be grainy because the diameter of the drop is less than 35 microns. This particularly shows for dark inks (K,C,M). The fix is to mix in larger volumes of lighter inks (Y, LC, LM) instead and to use some CMY instead of K (larger volumes again) for midtone grays. The risk then is to damp the paper. So we need to keep track of the volume of ink laid down. I can tell for sure that this problem occurs and I can tell where exactly from the printout, particularly for grays, because it shows despite randomization. Of course there might be other issues as well. Let me know if I am too verbose. I realize that the above is rather descriptive and does not actually fix the problem. I'm still a bit overwhelmed by changes in dithering in 3.1.3. But I realize they're for the better; dithering plays a huge role in a good rendering. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Jean-Marc V. <ver...@if...> - 2000-05-05 23:48:06
|
> I just printed the exact same photograph (a rather difficult one > from previous experience) with my version of gimp-print-3.1.2 (a), > with stock 3.1.3 (b), yesterday's 3.1.3 with dither=2 (c) and with > dither=4 (d). b, compared to others is lousy. That's history. c > and d don't differ significantly. They're good. A bit grainy, > slightly oversaturated, greenish grays (see above). At this point > (a) is best in my opinion. A little less saturated than c,d (but > whether this is worse or better is rather subjective and can be > adjusted). Better grays. Less grainy. > > Huh. That's very interesting, and doesn't accord with my experience. > I would expect stock 3.1.3 to be the least grainy, followed by the > current repository and then 3.1.2. 3.1.2 might be denser, which would > reduce the perceived grain. > Right, this is not what I meant. Saying that the current repository was lousy was an overstatement. I meant it's too dark to tell. For 3.1.2 I meant a version that I had modified. I would otherwise agree with you. > The greenish thing should not be difficult to fix. That's color > balance again and probably involves no specific flow in the > algorithms. > > I hope not, but it's been exceedingly difficult to get right thus far. I think the density ratio between colors is simply not one. I'll send you a patch over the week end, that mostly fixes grays. To get it absolutely right, we need to address the grain issue first though. To fix red and blue, the only thing I came up with were hue adjustements. > > Actually, gray IS printed as CMY (and LC and LM as appropriate) until > it gets quite dark. And currently, there's some CMY mixed in all the > way to almost 100% black. > I know and I can't argue with that until I understand the new dithering a little better. This was just a general thought. > > I think that the black threshold is a bit too low right now. Yes indeed. The new k_lower in print-escp2 .138, looks better already. That does not totally fix the problem, but helps very much. > It's > also possible that the density value that's being used to compute the > size of the black dot is wrong. Try changing this: > > tk = print_color(d, &(d->k_dither), bk, bk, k, x, row, kptr, > NULL, bit, length, 0, 0, 0, 0); > > to > > tk = print_color(d, &(d->k_dither), bk, bk - d->k_lower, k, x, row, kptr, > NULL, bit, length, 0, 0, 0, 0); > > What this will do is decide what kind of black dot to print based on > the difference between the black value and the lowest value at which > black is printed, rather than the absolute black value. So that would > use smaller dots. Let me know how it works. > Well this does not improve things in my opinion. It is lighter as you would expect, but grain remains. The change in k_lower is much more useful. Have you tried to print a black and white picture in color mode ? I've noticed that, beyond the greenish tone, it shows diffuse magenta grains, particularly around transitions and I could not figure out why. Interestingly, I've noticed that (now that black is better), grain in color pictures was mostly magenta as well and in fact localized in exactly the same regions. Is it just me ? -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Jean-Marc V. <ver...@if...> - 2000-05-07 02:32:26
|
1) The standard Epson density (.6`ish) is all wrong for this printer.
I had to scale it to 1.3 (which really means 1.3 * .6, or about .8)
to get anything that looked even remotely reasonable. Even that`s
a bit too low (I`m using photo glossy paper). I also had to
knock
down both gamma and brightness a bit (.9 gamma and 80 brightness;
that gamma might be just a bit too low). Ron van Ostayen suggested
a value of 1.6 for his ESC 900; that creates solid blacks, but it
definitely drops too much ink (see below).
This might explain why people with 900`s are complaining that
output is too light. Maybe all the variable dot size printers need
adjustment.
I had mentionned that in my first mail to you (not to this list).
2) The ink dries very slowly.
True on most papers. I have found that ink dried very quickly on TDK pro
quality paper. I find it's a very good paper too. Unfortunately a bit
expensive.
3) Pale tones are very good indeed. Gray is very neutral. However,
under a loupe there`s some weirdness going on. I think that the
error spread setting (controlling how widely the error is diffused)
is too high. That`s not surprising; the spread settings are set up
for single dot size.
Could that have something to do with my magenta problem ?
4) Mid and dark tones are grainy. It`s less obvious when I push the
density up. It might be a sign that the dither algorithm has
problems here; it might also simply be a sign that the density is
too low. The grain looks a little bit like "shadowing" from large
dots, but not entirely.
I would agree, wouldn't I ?
5) Using the smallest dot size from the dark inks makes the grain
worse. That doesn`t particularly surprise me; it`s not laying down
a lot of ink, but it`s printing quite dark. We may be better off
not using this. Or maybe we need to find a way to use it only in
heavy gray situations.
That was my point a few days ago. I would not recommend not using small dots at
all. The problem really occurs with dark cyan, dark magenta and black only
(dark inks). Even with these inks not using small dots will sometimes result in
using too much of the light inks and laying down too much ink.
6) The printer is nearly silent -- a nice change after the noisy EX.
That is a pleasure, isn't it ? I'm no longer afraid of wakening my son at 3 am.
7) I think the high density results in too much ink being dropped
(which is bad because of the slow drying ink and its expense).
Jean-Marc Verbavatz had an idea about an ink budget. I think
that`s a great idea and needs some more study. We also need to
look at other ink reduction techniques.
Yes, increasing density until you get solid colors is not the answer. I'll
try to implement that again with the current version of gimp-print.
For a full description of this printer's features one should add that the
bottom margin is quite small ~6-7 mm as far as I can tell and it does not keep
printing on the next page if you go over the margin.
--
--
Jean-Marc Verbavatz <ver...@if...>
5, rue La Fontaine "http://perso.cybercable.fr/verbavat"
F-75016 Paris
|
|
From: Jean-Marc V. <ver...@if...> - 2000-05-15 22:27:18
|
On May 14, 10:41pm, Robert L Krawitz wrote: > Subject: Re: Epson 870 > First off: the gray scale is much better than mine. > > 720 dpi looks pretty good. 1440 looks a bit distorted, and 1440 > enhanced (pseudo-1440x1440) looks positively strange. I think that > thaere's some kind of arithmetic overflow going on in darker regions; > light tones are OK. It might be the ink budget stuff triggering it, though. > > However, in general 1440 and 720 look noticeably different. OK, this is kind of what I have found too, although I didn't find that 1440-enhanced whas _that_ bad. It could be a matter of density or paper quality as well in that particular case. > > Try downloading http://www.tiac.net/users/rlk/colors.tif. This is a > color sweep pattern. > Got it. > > 2 - I made one major change to dithering. That's how we think about > density. In my understanding, current gimp-print scales everything > by density/oversampling. That includes values to print and > thresholds. My approach is to take advantage of oversampling to > use (more) lighter inks. For that purpose, I'm scaling thresholds > only by density (not oversampling). This results in an increase in > the usage of light inks as quality (oversampling) increases. > > I adopted the approach of scaling everything by density, and ignoring > the oversampling issue per se (except for scaling density) between > 3.1.2 and 3.1.3 because the behavior of the 3.1.2 code when the user > changed density (or resolution) was too unpredictable. I wanted the > code to behave identically (as far as ink choice) for any choice of > density and resolution. > > I'm not sure that using more light ink is the way to go. If anything, > I think that at high resolution you're often better off using more > small dots, which means dark ink at some intermediate points, to avoid > laying down too much ink. > I think you're right, but a little more light ink would help reduce grain. In the version you've tried, I had basically pushed the light-ink button all the way down and this is obviously not good. This is how I see the issue: 1 - there's no issue as long as there's no oversampling. 2 - With oversampling, any ink value between density/oversampling and density should work in theory. The former will need to be printed several times, the latter only once in a while. The former will give better smoothness, the latter better color values. The former will be more sensitive to artifacts, like additive errors or soaking the paper. Current gimp-print is on the latter side; the safe side, whereas my test shot is the former. The issue as I see it, is to find a good and stable compromise. > That's all (or almost), but was not easy with the current > dithering. I came across major (and unexpected) color problems. The > reason I believe is that for any given density, dithering will use > mostly one of 2 inks only (one darker one lighter). Without going > into the details, that means that if the settings for only one ink > level is not perfect, everything having a color density between the > immediately lighter ink and the immediately darker ink will > accumulate (and therefore amplify) this error, particularly in flat > tones. I think there is a problem with that. > > I think you're right. I think that it should be possible for segments > to overlap, so that if a particular point lies within multiple > segments, they're each tried in turn. I don't know if that would drop > too much ink, though. > As of today, I've been trying to work something from our (mostly common) conclusions. I'll keep you posted in a few days. Thanks again for giving it a try and for your helpful comments. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Jean-Marc V. <ver...@if...> - 2000-05-30 22:58:56
|
> > 1) There's a weak horizontal patterning that looks superficially like > banding. Under a loupe, though, that's clearly not the case. It's > some kind of dither patterning. This is only noticeable in the > light areas. Could you look at Thomas' 257x257 matrix, and see if > that can be used? > I'll try that. > 2) The light regions of the dark half of the shot (in particular, as > red fades to black) show dark cyan dots. I presume that the idea > is to reduce the amount of ink by using fewer dark dots. However, > it does create noticeable speckling. True. I think I need to increase the c_darkness value further. > > 3) There's too much ink being used in the very dark regions. I think > that this is a matter of merging up with Thomas' black stuff. > Yes, black is not totally under control. I've not worked on it very much. I think recent changes in the repository will help. > Could you try to do a merge-up to the latest stuff in the main > repository, and get those last few little things fixed up? I'll be working on it. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Ralph C. <ra...@in...> - 2000-05-31 10:40:36
|
Hi,
> > 7. As (6) except -dQuality=1 instead of 0. Corrupt output. Print
> > head stayed at LHS of paper and paper moved through printer very
> > slowly. No ink written to paper.
>
> What you really want is -r1440 -dQuality=6 (with 3.1.4).
OK, tried this, still with 3.1.4.
-r1440x1440 -dModel=15 -dQuality=6 -dDither=4
Interesting results. The PostScript draws, amongst other things, two
lines from opposite corners of the A4 page crossing in the middle. The
bottom half of the page (printed last) has some good looking,
continuous lines. The top half has regular gaps in the lines and some
horizontal lines haven't been printed. The difference is exactly at
the point where the diagonal lines cross, i.e. the half-way point.
> With the current repository you can use -dQuality=7, which should
> give you really good output.
>
> What I suggest:
>
> 1) Grab the latest version from the CVS repository.
>
> 2) Use -r1440 -dQuality=7 -dDither=4
OK, thanks, will try this. Thought the above result might be
interesting anyway. I'll get 3.1.5 first and move onto CVS later.
Ralph.
|
|
From: Ralph C. <ra...@in...> - 2000-05-31 10:40:39
|
Hi, > I think for now we should create a single Ghostscript driver, because > most of the files are shared. This probably means reworking it so > that rather than using numbers for everything (particularly model > names), we use strings (e. g. -dModel=esp870). I hate this selection > at compile time nonsense. In the longer term, Mike Sweet has other > ideas about how to proceed. Alongside more documentation about the `good choice' combinations of GhostScript options for different printers it might be an idea to emit a warning if an obviously bad set are choosen, and an error for invalid combinations (this already happens?). Perhaps this could all be driven from a single table with model on one axis and the -dDither, etc., on the other. A rating of 0-5 for -dDither=2 with -dModel=11 would allow the user to examine the table and see what he's got to play with, and it could be used at runtime (or source built from it) to warn the user if say the score was <= 2. A score of zero means not possible and gives an error. I'm all for letting the user do the unlikely even if it doesn't seem wise -- give them enough rope to hang themselves -- but a bit more guidance might help them a lot. Ralph. |
|
From: Ralph C. <ra...@in...> - 2000-06-08 12:49:16
|
Hi Robert, > > The printout is positioned correctly on the page, as near as damit. > > Horizontal and veritical lines, when they appear, are continuous. > > Diagonal lines are still `broken'; lots of gaps occur. > > I'm curious to know exactly what that means... Did you see the PostScript that reproduces the problem at the end of my message? I'll try and explain the result. I print crosses at certain points on the page; two lines, one horizontal, one vertical. At some locations the horizontal line fails to appear *completely*. This suggests some horizontal rows are being missed. Similarly, the diagonal line has many small gaps. It's as if drawn with a very long, erratic, dash pattern, again suggesting some horizontal rows are being missed. I'd guess that this is because the PostScript is drawing lines with a line width of zero; defined to be the thinnest line width the output device supports. Perhaps the stp driver is over estimating how thin this line can be? Feeding the escp2 output into unprint shows the problem there too. Let me know if there's anything more I can do to demonstrate the problem. > > One last question, I'm printing B&W text letters at the moment. > > With these settings it takes a while :-) What setting should I > > experiment with first to see if I can trade speed for quality? > > If you're printing PURE black and white (no colors, and no > grayscale), you can use -dImageType=3. This will be radically faster > than anything else. If that's not suitable, use -dDither=2 > (ordered). On a 1270 the results won't be as good as dither 4, but > for many purposes they'll be good enough. Marvellous, as it is pure B&W I'll try -dImageType=3 first. This is a Red Hat installation. Is the right way to have several different GhostScript backend configurations, one for photo's, one for B&W, etc., available to create one logical queue for each, all on the same /dev/lp1 device? That seems the obvious way to me, but I'd be interested to hear if anyone has a better idea. Thanks, Ralph. |
|
From: Robert L K. <rl...@al...> - 2000-06-09 00:18:50
|
Date: Thu, 08 Jun 2000 11:40:23 +0100 From: Ralph Corderoy <ra...@in...> Did you see the PostScript that reproduces the problem at the end of my message? I'll try and explain the result. I print crosses at certain points on the page; two lines, one horizontal, one vertical. At some locations the horizontal line fails to appear *completely*. This suggests some horizontal rows are being missed. Similarly, the diagonal line has many small gaps. It's as if drawn with a very long, erratic, dash pattern, again suggesting some horizontal rows are being missed. I think I understand. I suggested using -r1440. This means that Ghostscript uses both a horizontal and vertical resolution of 1440 dpi. However, quality=7 is only 720 dpi vertically, so every other horizontal row will be missed. Two things to try: 1) Use -r720. This will do 720 dpi in Ghostscript. 2) Use -dQuality=8. This mode, called "1440x720 enhanced", actually samples at 1440x1440. I'd guess that this is because the PostScript is drawing lines with a line width of zero; defined to be the thinnest line width the output device supports. Perhaps the stp driver is over estimating how thin this line can be? It isn't the stp driver; it doesn't know anything about Postscript or line widths. -- 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 |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-12 22:53:03
|
As promised a while ago I have worked more on merging my work with the current repository. Unfortunately I ran out of ink for several days, hence the delay. Another reason it took that long is that I had overlooked recent dithering progress, which is far too complex for me to understand easily. This whole thing helped me improve my code a little. However, what was bothering me most was fluffy rendering in some areas or other artefacts depending on dither used. I found where this came from. If I understand well, this is from the (now not so) new matrices unfortunately. i.e., either (in print_color()): default: vmatrix = DITHERPOINT(d, x, y, 6); (vs DITHERPOINT(d, x, y, 0)) or else if (rangepoint >= DITHERPOINT(d, x, y, 5)) (vs DITHERPOINT(d, x, y, 3)) or both produce this result. I don't know what to think about this and I would like some advice. To me it looks like these matrices semi-randomly spread out ink on a relatively large surface area. To me again, that makes perfect sense for printers with few ink levels. I'm not that convinced that it should be the case to the same extent for 6 ink level printers such as the Epson 870. In my opinion these printers have the ability to stick to colors more efficiently. That's my little understanding and I may be completely wrong. The bottom line is that these matrices yield strange light dot clusters on the Epson 870 in my hands. I've not posted a new version because I feel that I need to understand the above for any successful merging of ideas. What are your comments ? -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Ralph C. <ra...@in...> - 2000-06-13 22:07:25
|
Hi, > > I print crosses at certain points on the page; two lines, one > > horizontal, one vertical. At some locations the horizontal line > > fails to appear *completely*. This suggests some horizontal rows > > are being missed. Similarly, the diagonal line has many small > > gaps. It's as if drawn with a very long, erratic, dash pattern, > > again suggesting some horizontal rows are being missed. > > I think I understand. I suggested using -r1440. This means that > Ghostscript uses both a horizontal and vertical resolution of 1440 > dpi. However, quality=7 is only 720 dpi vertically, so every other > horizontal row will be missed. > > Two things to try: > > 1) Use -r720. This will do 720 dpi in Ghostscript. That works well. All lines are solid. The lines that are solid on both the 1440 and 720 print outs appear to be the same thickness. The diagonal line appears to have the slightest of gaps occasionally. I tried -r1440x720, since that's the printer's resolution. I the same image as before, still with some horizontal lines missing, but squashed vertically so it only filled the top half of the A4 page. Was I stupid to try this? :-) > 2) Use -dQuality=8. This mode, called "1440x720 enhanced", actually > samples at 1440x1440. That was an improvement in some ways. With -r1440 all the missing horizontal lines have now appeared. But, all lines, horizontal, vertical, and diagonal are still `dashy' where as the vertical lines appeared solid with -dQuality=7. > > I'd guess that this is because the PostScript is drawing lines with > > a line width of zero; defined to be the thinnest line width the > > output device supports. Perhaps the stp driver is over estimating > > how thin this line can be? > > It isn't the stp driver; it doesn't know anything about Postscript or > line widths. OK. Perhaps the various dithering methods don't work well on very thin lines? Ralph. |
|
From: Robert L K. <rl...@al...> - 2000-06-13 23:09:58
|
Date: Tue, 13 Jun 2000 22:55:22 +0100 From: Ralph Corderoy <ra...@in...> I tried -r1440x720, since that's the printer's resolution. I the same image as before, still with some horizontal lines missing, but squashed vertically so it only filled the top half of the A4 page. Was I stupid to try this? :-) No; it sure would be interesting to know where the bug is there. My guess is that it's our bug. > > I'd guess that this is because the PostScript is drawing lines with > > a line width of zero; defined to be the thinnest line width the > > output device supports. Perhaps the stp driver is over estimating > > how thin this line can be? > > It isn't the stp driver; it doesn't know anything about Postscript or > line widths. OK. Perhaps the various dithering methods don't work well on very thin lines? I suspect that the problem is that the ink density is so low at high resolutions that there are simply a lot of dots that just don't get printed. At 720x720, the full-dark density is about .6, so most of the dots do get printed. At 1440x1440, the density is about .15, so if you print lines that are one dot wide, you'll lose most of the dots. -- 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 |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-17 13:49:37
|
I've just cleaned up jmv-branch. It should compile cleanly. Oddly enough my only problem compiling gimp-print for the first time was with mktemp that seg faulted. Fixed. I acknowledge Robert's comments and will work on them, but it was time to release a full version. I'll include recent changes in gimp-print probably tonight. I hope this does not badly interfere with printers other than mine (epson 870). In fact I would like to know. Could anyone with an epson 740 or similar (variable size without light ink ?), an epson photo 700 or similar (fixed size with light ink) or an epson 800 or similar (single size, single ink) try it and let me know if anything is wrong ? I don't promise that my changes will improve things on all printers but I would like to make sure that they don't cause problems. I noticed that the main gimp-print page (http://gimp-print.sourceforge.net) hasn't been updated since the release of version 3.1.4. From there I went to the list of supported printers and noticed that the epson 850 and others still needed testing. I actually have easy access to an epson 850 at work. Do you want me to test gimp-print on it or is this list also outdated ? Finally I tried to use my freshly gimp-print module but my printer didn't show on the list (below screen bottom) as recently reported by someone else. If this is not difficult to fix I should think this must be done quickly ! As an ordinary user I would otherwise think that gimp-print sucks... -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Robert L K. <rl...@al...> - 2000-06-17 14:17:59
|
Date: Sat, 17 Jun 2000 13:50:38 +0000 From: Jean-Marc Verbavatz <ver...@if...> I've just cleaned up jmv-branch. It should compile cleanly. Oddly enough my only problem compiling gimp-print for the first time was with mktemp that seg faulted. Fixed. There was one other problem, in print-canon.c and print-pcl.c (dither_set_density needed the third argument). I fixed it and committed it. I hope this does not badly interfere with printers other than mine (epson 870). In fact I would like to know. Could anyone with an epson 740 or similar (variable size without light ink ?), an epson photo 700 or similar (fixed size with light ink) or an epson 800 or similar (single size, single ink) try it and let me know if anything is wrong ? I don't promise that my changes will improve things on all printers but I would like to make sure that they don't cause problems. Could people also test with Canon and HP printers, and with different resolutions? If people want to fix stuff in print-canon.c, print-ps.c, and print-pcl.c go ahead, but please let Jean-Marc approve changes in any of the other files. I noticed that the main gimp-print page (http://gimp-print.sourceforge.net) hasn't been updated since the release of version 3.1.4. From there I went to the list of supported printers and noticed that the epson 850 and others still needed testing. I actually have easy access to an epson 850 at work. Do you want me to test gimp-print on it or is this list also outdated ? The list is a bit out of date, but the 850 is one I remember somebody reported a problem with and we never did verify it. Finally I tried to use my freshly gimp-print module but my printer didn't show on the list (below screen bottom) as recently reported by someone else. If this is not difficult to fix I should think this must be done quickly ! As an ordinary user I would otherwise think that gimp-print sucks... This really is becoming a problem. We're falling victims of our own success here. I lose a bunch of printers on my 1280x1024 display. We cannot do a major release until this is fixed. -- 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 |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-18 03:05:40
|
I've just merged my work with the latest repository. This is in jmv-branch again. It shouldn't look very different from yesterday's release, only in sync with the main repository (as of 2000-06-17), including recent speed improvements. As before, I am very interested in comments from users of all sorts of printers. As I was updating, I noticed the new x_size and y_size. In a couple of places things didn't look completely consistent. Shouldn't some of the x_size * x_size be x_size * y_size instead (print-dither.c lines 317 or 342 for instance) ? Also I noticed a switch between pick_matrix and dither_matrix that I implemented without thinking, assuming that was right. Finally, I wanted to give gimp-print a try. Therefore I changed the Setup Driver selection so that all printers would show. This is now a list instead of a menu. This is a rather quick fix and my first attempt at doing anythink with gtk, but at least I could use my printer ! The change is in gtk_main_window.c. It works fine but I would have a couple of question/suggestions for the gimp-print module: - I haven't found a way to display centimeters (or millimeters) instead of inches. - The layout window is apparently scaled by paper size. Is this a useful feature ? For small media sizes it becomes really tiny. Actually I haven't found a medium size that would even come close to filling the window with the epson 870. - The resolution settings would not be totally clear to me if I didn't know what they mean from the README. How does 1440x720 enhanced compare to 1440x720 highest quality for instance ? I don't mean to be critical, these were only some of my thoughts. It looks good and is certainly more user friendly that ghostscript ! Again I'm waiting for comments, good bad or neutral, from users of all sorts of printers. Thanks, -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Robert L K. <rl...@al...> - 2000-06-18 13:30:00
|
Date: Sun, 18 Jun 2000 03:07:02 +0000 From: Jean-Marc Verbavatz <ver...@if...> As I was updating, I noticed the new x_size and y_size. In a couple of places things didn't look completely consistent. Shouldn't some of the x_size * x_size be x_size * y_size instead (print-dither.c lines 317 or 342 for instance) ? Good catch. I fixed it on the mainline. It doesn't matter yet, but it will as soon as we have non-square matrices. Also I noticed a switch between pick_matrix and dither_matrix that I implemented without thinking, assuming that was right. That switch is correct. Finally, I wanted to give gimp-print a try. Therefore I changed the Setup Driver selection so that all printers would show. This is now a list instead of a menu. I ported it to the mainline and did gimp_main_window as well. Shall I commit it there or would you like to? - I haven't found a way to display centimeters (or millimeters) instead of inches. We really should do that... - The layout window is apparently scaled by paper size. Is this a useful feature ? For small media sizes it becomes really tiny. Actually I haven't found a medium size that would even come close to filling the window with the epson 870. How do people feel about this? Actually, many Epson printers can print 44" (over 1 meter) long, and the current preview window restricts us from implementing that. - The resolution settings would not be totally clear to me if I didn't know what they mean from the README. How does 1440x720 enhanced compare to 1440x720 highest quality for instance ? Maybe we need some online help? Again I'm waiting for comments, good bad or neutral, from users of all sorts of printers. I want to get this onto the mainline as soon as possible after we do some basic testing to make sure that there's something that hasn't been totally missed. Even if there's a temporary regression in quality, we should do 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 |
|
From: Michael S. <mi...@ea...> - 2000-06-18 13:50:07
|
Robert L Krawitz wrote: > ... > How do people feel about this? Actually, many Epson printers can > print 44" (over 1 meter) long, and the current preview window > restricts us from implementing that. Actually, you should also worry about printers like the SP 9000, which do 44" *wide*, and pretty much as long as you like (I think the current maximum roll length is something like 300 feet :) One of the things I wanted to do with my original print plug-in was to do away with sizing the preview based on the actual media size; instead, it should just represent the aspect ratio and orientation of the page... That will remove the current tiny pages and make life a bit easier down the road for really big prints. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
|
From: Robert L K. <rl...@al...> - 2000-06-18 15:42:52
|
Date: Sun, 18 Jun 2000 09:46:16 -0400 From: Michael Sweet <mi...@ea...> One of the things I wanted to do with my original print plug-in was to do away with sizing the preview based on the actual media size; instead, it should just represent the aspect ratio and orientation of the page... That will remove the current tiny pages and make life a bit easier down the road for really big prints. I suppose that now that we have the size boxes we can do this. Currently this is about the only thing really standing in the way of supporting huge prints. Last month I went to the National Weather Service open house in Taunton, MA (weather being one of my big interests). I noticed two things down there, and only just now connected them: 1) They had a Linux box tucked away somewhere. 2) They had an ESC 3000 (which is a large format printer). So this really isn't a frivolous idea at all. Not that I think they had any plans to hook the ESC 3000 to the Linux box and do anything with it, but I guess it only just now struck me... -- 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 |
|
From: Robert L K. <rl...@al...> - 2000-06-19 00:03:58
|
Date: Sun, 18 Jun 2000 17:31:33 +0000 From: Jean-Marc Verbavatz <ver...@if...> On Jun 18, 11:43am, Robert L Krawitz wrote: > Subject: Re: [Gimp-print-devel] Re: Yet Another Merge > Date: Sun, 18 Jun 2000 09:46:16 -0400 > From: Michael Sweet <mi...@ea...> > > One of the things I wanted to do with my original print plug-in was > to do away with sizing the preview based on the actual media size; > instead, it should just represent the aspect ratio and orientation > of the page... That will remove the current tiny pages and make > life a bit easier down the road for really big prints. > > I suppose that now that we have the size boxes we can do this. > Currently this is about the only thing really standing in the way of > supporting huge prints. So it sounds that everyone so far agrees. Perhaps we should make that scrollable for Epson rolls (just kidding). A correct aspect ration and orientation are all we need in my opinion too. Roll paper and very long prints are two different issues. Very long, narrow prints are going to be hard to represent on the preview window. Roll paper is something else; we need to understand a little better how Epson handles that. Not frivolous at all. I'm using a wide format printer at work from Linux. It's an hp dnj 455 if I recall well and prints up to A1 or A0, more than a meter wide in any case. I even use Linux to spool Windows boxes for that printer. We use it for scientific posters. OK. I'm going to plug the full table of paper sizes into the driver, even if we can't use them yet. > I ported it to the mainline and did gimp_main_window as well. Shall I > commit it there or would you like to? Go ahead. You've already gone a step further than me; I haven't even looked at gimp_main_window and I don't know what it does ! OK. It's in there now. > - I haven't found a way to display centimeters (or millimeters) > instead of inches. > > We really should do that... I'll give it a try tonight (unless it's already done as well). That'll be my second gtk lesson. Could you do this stuff on the mainline, not just on your branch? I want the UI stuff to get in as quickly as possible; your dithering stuff is what needs more testing before committing to the mainline. -- 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 |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-19 00:32:15
|
> Roll paper and very long prints are two different issues. Very long, > narrow prints are going to be hard to represent on the preview > window. Roll paper is something else; we need to understand a little > better how Epson handles that. I didn't realize that was a major issue. Couldn't one consider roll paper as endless paper ? Do you really need a bottom margin before you start printing ? Of course you do with full page layout programs like ghostscript and probably gimp-print as well. But one could imagine a mode where you would simply feed the printer continuously with separate prints until the user says stop or something. Isn't that what Epson does (I haven't tried it) ? > > I ported it to the mainline and did gimp_main_window as well. Shall I > > commit it there or would you like to? > > Go ahead. You've already gone a step further than me; I haven't even looked > at gimp_main_window and I don't know what it does ! > > OK. It's in there now. > > > - I haven't found a way to display centimeters (or millimeters) > > instead of inches. > > > > We really should do that... > > I'll give it a try tonight (unless it's already done as well). That'll be my > second gtk lesson. > > Could you do this stuff on the mainline, not just on your branch? I > want the UI stuff to get in as quickly as possible; your dithering > stuff is what needs more testing before committing to the mainline. > That's what I've done before reading your message actually. So I've done it and committed it. It works for me at least. However: 1 - I haven't dared do the same with gimp_main_window.c 2 - I've use a global variable "vars_unit" at the top of gtk_main_window.c I don't know where to put it for sure. That's not exactly a printer specific variable. I doubt that someone would use inches on one printer and centimeters on another model. That's rather region specific. 3 - The layout is objectionable. Below scaling. But it's there. > Hmm. I'm using an 870 myself (on a parallel port, not a USB). > Evidently the return on a USB port is slightly different. Is there a way I can help with USB ? Please note that I had problems outside of USB as well (and I'm apparently not the only one). -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Charles Briscoe-S. <cp...@de...> - 2000-06-19 16:06:22
|
On Mon, Jun 19, 2000 at 12:33:38AM +0000, Jean-Marc Verbavatz wrote: > > > Roll paper and very long prints are two different issues. Very long, > > narrow prints are going to be hard to represent on the preview > > window. Roll paper is something else; we need to understand a little > > better how Epson handles that. > > I didn't realize that was a major issue. Couldn't one consider roll paper as > endless paper ? Do you really need a bottom margin before you start > printing ? Of course you do with full page layout programs like ghostscript and > probably gimp-print as well. But one could imagine a mode where you would > simply feed the printer continuously with separate prints until the user says > stop or something. Isn't that what Epson does (I haven't tried it) ? I think the issue is that the printer normally ejects the sheet after printing a page. With roll paper, that would not be a good idea. Look in the 870's reference manual for roll mode (on one of the CDs in HTML, IIRC). That gives some idea what's going on. I have some roll-mode printfiles sitting in a directory somewhere that I want to analyse when I get time (I made them when I had Win95 installed briefly on the laptop a month or two ago). There's also a roll-mode zero-margin one there; that might be interesting too. You've probably noticed the little white pads in the printer just at the left margins and 89 and 100mm to the right... That's the two widths that Epson do their newer roll paper in. Hmm. There's a cutout at around 210mm/8.5in which might allow zero-margin printing on A4/Letter paper too. Something to think about. Cheers, -- Charles Briscoe-Smith <URL:http://www.debian.org/%7Ecpbs/> PGP2: 1024/B35EE811 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 "You think that's air you're breathing now?" -- Morpheus, "The Matrix" |
|
From: Ralph C. <ra...@in...> - 2000-06-22 08:34:22
|
Hi,
> I'm experimenting with a 1440x2880 mode (that's correct -- not
> 2880x1440). The reasoning behind this is that dither artifacts in
> 6-color printers often look like "holes" behind dark dots, and that
> oversampling in the Y direction covers them up. It does seem to look
> very smooth, perhaps smoother than 1440x1440, although currently I
> don't have the matrix working correctly with it.
>
> Anyone have any idea what to name it, if I do decide to put it in?
I've been confused by the naming so far so here's my 2p's worth.
Distinguish between `physical' and `pseudo' resolutions. Am I correct
in thinking that most exactly match a printer resolution and it is used
for all calculations? No super-sampling? I'd call that a physical
one. Ones that are over-sampled before being converted back to a
physical one could be `pseudo' resolutions. The printer isn't really
printing at 1440x2880. Each pseudo resolution should have an
accompanying physical one.
Hmmm. I guess I'm really saying there are two resolutions involved all
the time, logical (better than pseudo) and physical. Sometimes they're
the same, 1440x720-1440x720, and sometimes not, 1440x2880-???x???.
Add onto that a method of error diffusion/dithering naming and have we
a canonical format where all parameters are given?
logXxlogY-phyXxphyY-diffused
Sorry if this is wide of the mark because I don't understand the whole
process.
Ralph.
|
|
From: Robert L K. <rl...@al...> - 2000-06-22 11:45:08
|
Date: Thu, 22 Jun 2000 08:52:41 +0100
From: Ralph Corderoy <ra...@in...>
> I'm experimenting with a 1440x2880 mode (that's correct -- not
> 2880x1440). The reasoning behind this is that dither artifacts in
> 6-color printers often look like "holes" behind dark dots, and that
> oversampling in the Y direction covers them up. It does seem to look
> very smooth, perhaps smoother than 1440x1440, although currently I
> don't have the matrix working correctly with it.
>
> Anyone have any idea what to name it, if I do decide to put it in?
I've been confused by the naming so far so here's my 2p's worth.
Distinguish between `physical' and `pseudo' resolutions. Am I correct
in thinking that most exactly match a printer resolution and it is used
for all calculations? No super-sampling? I'd call that a physical
one. Ones that are over-sampled before being converted back to a
physical one could be `pseudo' resolutions. The printer isn't really
printing at 1440x2880. Each pseudo resolution should have an
accompanying physical one.
All resolutions up to 1440x720 use the same resolution for sampling
(dithering) and printing. The only two resolutions where there is an
issue are 1440x1440 (which is currently called "1440x720 enhanced")
and 1440x2880 (which I don't have a good name for). I'm getting rid
of 2880x720; it doesn't have any real advantages over anything else,
and we don't have a matrix that can handle it.
Hmmm. I guess I'm really saying there are two resolutions involved all
the time, logical (better than pseudo) and physical. Sometimes they're
the same, 1440x720-1440x720, and sometimes not, 1440x2880-???x???.
"Logical" or "virtual" are good words for people who understand what's
going on, but they won't make any sense to someone who just wants to
print and not worry about details.
Add onto that a method of error diffusion/dithering naming and have we
a canonical format where all parameters are given?
logXxlogY-phyXxphyY-diffused
The dithering is completely independent from the choice of
resolution.
--
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
|
|
From: Ralph C. <ra...@in...> - 2000-06-22 22:22:58
|
Hi, > > I'd call it "1440x720 with 4x vertical oversampling". A bit wordy, > > but it's clear what it is. > > That's a bit verbose to fit in the menu, and that's also a name aimed > at people who understand the technical details. I want a name that > makes sense to people who *don't* have the technical background to > understand this, but. That's a tough requirement. They probably need to learn about resolutions. Otherwise, how about `1st Class', `2nd Class'... or Bestest, Best, Better, Good... :-) Ralph. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X