From: Sven Neumann <[EMAIL PROTECTED]>
Date: Sat, 19 Feb 2000 22:50:05 +0100
> Doing it correctly won't be entirely trivial, since the print plugin
> currently assumes xres == yres, but I want to start investigating it.
> Whatever happens, it won't get back ported to 3.0.
I don't want to repeat myself, but the fact that the print plug-in
ignores the resolution info is not only a shame, but IMO a bug. Adding the
necessary GUI elements is more or less trivial.
Adding the GUI elements isn't hard (but not entirely trivial); adding
the stuff in the print plugin to deal with xdpi != ydpi (or formally
deciding to ignore that issue), issues of not exceeding the page
layout, etc. is more work. Also, this is not a regression from 2.0,
and there is a workaround (scale it manually).
Mind, based on my own DTP experience, I'm not entirely convinced that
this is all that useful, anyway. When I did newsletters, I had to fit
photos and other graphics to the page; nominal image size meant very
little beyond being careful not to enlarge things too much. The 3.1
plugin has a much better mechanism already in place for sizing and
placing the image than the 3.0 plugin has, which allows exact
placement (to the nearest point). It isn't perfect, but it's a lot
better than the cut and try in 3.0. I encourage people to grab the
3.1 stuff from the repository at gimp-print.sourceforge.net and try
this for themselves.
If the print plugin is being used to create standalone hardcopy
output, I think it's more useful most of the time to scale the image
to the paper like one does with a photographic print. DPI is of some
use if you want a perfect match between printer resolution and output
(so that each output line spans an equal number of printer
rows/columns to avoid uneven pixelation), but in that case the output
resolution must be chosen to match the printer's capabilities. Web
publishing is different from print; on the web, the pixel is the basic
unit of measurement and images get scaled for a target screen size, so
you do want to know how many pixels there are per inch.
In any event, mine isn't the entire word on this subject; one of our
developers wants this also, and we certainly should do it for
consistency. It's just too big of a change for 3.0. I'm already
resisting simpler changes than that for 3.0, because I really do want
it to be a stable release that only takes bug fixes.
It's ready when it's done. Have a look at
to see how many bugs are still open. Since only few people are actively
working at closing these bugs, it may take some time... Yosh might be
able to tell you if there are any plans for a 1.1.18 release yet.
OK. We don't have a 3.2 release timetable yet (we haven't even done
3.1.0 yet, although I really want to get that out, and I might finally
have an excuse this weekend).
Robert Krawitz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."