From: Sven Neumann <neumanns@xxxxxxxxxxxxxxxxxx> 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 http://bugs.gnome.org/db/pa/lgimp.html 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 <rlk@xxxxxxxxxxxx> 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 lpf@xxxxxxxxxxxx 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
