Gimp won't reduce graphics to Print Size on printing

[Hedley]

My sister-in-law sent me some JPEG photo files that displayed rather
large on the monitor and clearly were not going to fit the photo paper I
had available.  I opened both Image Size and Print Size and changed the
resolution from 90dpi to 300dpi, whereupon the millimetre dimensions
reduced sufficiently to fit the paper.

The RGB --> CMYK printer is an Epson CX6900F multifunction that has a
page preview function. When the photos were printed, the preview showed
only a small area from the upper left corner, i.e. the size/resolution
information saved in the JPEG files had been totally ignored.  
Eventually I had to use  (blush!) Microsoft Photo Editor, a freebie that
comes with Windows XP.

What is going on?

Windows XP SP3, Gimp  2.4.6

Regards,
Hedley

--

Hedley Finger

28 Regent Street   Camberwell VIC 3124   Australia
Tel. [phone]   Fax. (call phone first)
Mob. (cell) [phone]
Email. "Hedley Finger" <hfinger@...>

[Tor Lillqvist]

> changed the resolution from 90dpi to 300dpi, whereupon the millimetre dimensions
> reduced sufficiently to fit the paper.

I doubt that is necessary. The "dpi" (should be ppi) information
inside image files is just for information, no software needs to
actually use it. Any software that is good at printing will have
options to ignore any "dpi" setting in the file anyway, and offer
possibilities to scale the image to fit the paper, etc. (I assume this
is possible in GIMP, too, but then printing in GIMP on Windows is
broken anyway, read on.)

> Eventually I had to use  (blush!) Microsoft Photo Editor, a freebie that
> comes with Windows XP.

Nothing to blush about. If it works, use it. Printing on Windows is
known to be broken in various ways in GTK+ 2.12 (GTK+ is the toolkit
that GIMP uses). It is hopefully better in GTK+ 2.14. Until you have a
GIMP where printing works reliably, by all means, use another
application to print your images. If printing out images is the main
thing you use GIMP for, and you print several times a day, GIMP is
probably the wrong application for you anyway.

--tml

[Cline Frasier]

This printing problem is a bug in Windows version of Gimp 2.4.6 and
2.4.7. The only way I've been able to print from these versions is to
experiment with the dpi setting in the printer dialog that comes up when
printing. I posted the problem with 2.4.6 on the Gimp bug reporting list
and it was verified as a bug. How the bug manifests itself during
printing is a little different in 2.4.7, but it is still there.

Cline

Tor Lillqvist wrote:

>
> > changed the resolution from 90dpi to 300dpi, whereupon the
> millimetre dimensions
> > reduced sufficiently to fit the paper.
>
> I doubt that is necessary. The "dpi" (should be ppi) information
> inside image files is just for information, no software needs to
> actually use it. Any software that is good at printing will have
> options to ignore any "dpi" setting in the file anyway, and offer
> possibilities to scale the image to fit the paper, etc. (I assume this
> is possible in GIMP, too, but then printing in GIMP on Windows is
> broken anyway, read on.)
>
> > Eventually I had to use (blush!) Microsoft Photo Editor, a freebie that
> > comes with Windows XP.
>
> Nothing to blush about. If it works, use it. Printing on Windows is
> known to be broken in various ways in GTK+ 2.12 (GTK+ is the toolkit
> that GIMP uses). It is hopefully better in GTK+ 2.14. Until you have a
> GIMP where printing works reliably, by all means, use another
> application to print your images. If printing out images is the main
> thing you use GIMP for, and you print several times a day, GIMP is
> probably the wrong application for you anyway.
>
> --tml
>
>  

[Non-text portions of this message have been removed]

[Kent Paul Dolan]

From: Cline Frasier <misty34@...>
Date: Mon, 08 Sep 2008 06:32:13 -0400

> This printing problem is a bug in Windows version
> of Gimp 2.4.6 and 2.4.7. The only way I've been
> able to print from these versions is to experiment
> with the dpi setting in the printer dialog that
> comes up when printing. I posted the problem with
> 2.4.6 on the Gimp bug reporting list and it was
> verified as a bug. How the bug manifests itself
> during printing is a little different in 2.4.7,
> but it is still there.

Please notice that printing is essentially a device
dependent operation, and a real nightmare to
implement well even for very large shrink-wrap
software development corporations.

The implementation team has to choose just what
range of printers in what printer families it will
support, and then cater to all their quirks, at the
architecture, design, implementation, and testing
stages.

It's a bit much to expect that software built by
volunteer labor is going to match the stuff built
with big money corporate funding.

I'm guessing that someone somewhere will _always_
find that printing in GIMP doesn't work on their
particular printer, because GTK+ has not yet covered
that particular piece of hardware's quirks.

All that said, GTK+ has the opportunity to become a
"pretty good" printer library, just because it is
being used as a library by several different
application programs, focusing more attention on its
limitations.

It's a bit of a shame that MS-Windows, the world's
majority operating system, is such a pig to program
within, lacking most of what experienced programmers
expect in the way of software development tools,
that most of the open source software is developed
under *nix instead, with MS-Windows compatability
and porting almost always an afterthought.

xanthian, printer driver implementation battles:
been there, done that, Software Publishing
Corporation (makers of "Harvard Graphics"),
1988-1989.

[Tor Lillqvist]

> Please notice that printing is essentially a device
> dependent operation, and a real nightmare to
> implement well even for very large shrink-wrap
> software development corporations.

Sure, if you want to do it extremely well, you probably might want to
take some device-specific quirks into consideration for some known
special cases.

That is not the problem with GIMP (or GTK+ actually) printing on
Windows, though. It is just broken in much more generic ways. No
device-specific knowledge is needed to make it work better.

> The implementation team has to choose just what
> range of printers in what printer families it will support,

Sorry, but this is misinformation. Flashback from Windows 3.x?

 > It's a bit of a shame that MS-Windows, the world's
> majority operating system, is such a pig to program
> within, lacking most of what experienced programmers
> expect in the way of software development tools,

Of course, that is not true at all. Surely the majority of experienced
programmers *today* are experienced with Microsoft's Visual Studio? To
them it is Unix in general and Linux in particular that lack what they
("experienced programmers") expect in the way of software development
tools, i.e., Microsoft Visual Studio. Old school programmers like me
(and you?) who come from a Unix background, and still recall when Make
was a new and interesting invention, are definitely a minority.

--tml

[warjo]

     Try this:
         Open the original file in Gimp, and when it is on the screen. click on image, and then scale image. In the dialog box that opens, choose inches in the pixes/inches box, and change the width to the width of the paper you have to print on. Make sure the height will fit, too. If not, change the height to what will fit, and the width will follow.
Then click on scale.  Then print.   -Joe Ward
  ----- Original Message -----
  From: Hedley Finger
  To: GIMP, Windows
  Cc: GIMP, General
  Sent: Sunday, September 07, 2008 10:58 PM
  Subject: [gimpwin-users] Gimp won't reduce graphics to Print Size on printing



  My sister-in-law sent me some JPEG photo files that displayed rather
  large on the monitor and clearly were not going to fit the photo paper I
  had available. I opened both Image Size and Print Size and changed the
  resolution from 90dpi to 300dpi, whereupon the millimetre dimensions
  reduced sufficiently to fit the paper.

  The RGB --> CMYK printer is an Epson CX6900F multifunction that has a
  page preview function. When the photos were printed, the preview showed
  only a small area from the upper left corner, i.e. the size/resolution
  information saved in the JPEG files had been totally ignored.
  Eventually I had to use (blush!) Microsoft Photo Editor, a freebie that
  comes with Windows XP.

  What is going on?

  Windows XP SP3, Gimp 2.4.6

  Regards,
  Hedley

  --

  Hedley Finger

  28 Regent Street Camberwell VIC 3124 Australia
  Tel. [phone] Fax. (call phone first)
  Mob. (cell) [phone]
  Email. "Hedley Finger" <hfinger@...>



   

[Non-text portions of this message have been removed]

[Hedley]

Kent:

> The implementation team has to choose just what
> range of printers in what printer families it will
> support, and then cater to all their quirks, at the
> architecture, design, implementation, and testing
> stages.

I thought the whole point of the Windows GDI was that the programmer
didn't have to know what the backend printer and its driver was.  The
programmer makes the print output write to the GDI and the printer
manufacturer's driver honours the calls made by the GDI.  Why does this
sound too simple?

Regards,
Hedley

--

Hedley Finger

28 Regent Street   Camberwell VIC 3124   Australia
Tel. [phone]   Fax. (call phone first)
Mob. (cell) [phone]
Email. "Hedley Finger" <hfinger@...>

[Kent Paul Dolan]

To: gimpwin-users@...
From: Hedley Finger <hfinger@...>
Date: Tue, 09 Sep 2008 09:29:55 +1000

Kent:

>> The implementation team has to choose just what
>> range of printers in what printer families it
>> will support, and then cater to all their quirks,
>> at the architecture, design, implementation, and
>> testing stages.

> I thought the whole point of the Windows GDI was
> that the programmer didn't have to know what the
> backend printer and its driver was.  The
> programmer makes the print output write to the GDI
> and the printer manufacturer's driver honours the
> calls made by the GDI.  Why does this sound too
> simple?

Well, first of all because Microsoft came very late
to the game of establishing a standard driver
interface. The AmigaOS, for example, had such a
standard "out of the box"; Microsoft was somewhere
post MS-DOS and well into the MS-Windows family of
OSen before the idea finally penetrated that
standard programming interfaces were useful to
hardware manufacturers as well as (possibly
competitors to Microsoft) software creators. Of
course, that "standard" interface didn't do much
good if the vendor of each OS established a
_different_ programming interface standard, which
then became the situation.  It is only when the
standards become collective ANSI or ISO standards
that they start to be useful.

Second, standards become minimal interfaces,
constraining new product features. Also, obeying or
disobeying standards becomes a tactical marketing
decision.

If a manufacturer wants to differentiate its product
[or if it wants to get a "vendor lock" on its
customers], then it will "extend" its product beyond
the standard, creating new capabilities, that are
in turn only useful if the OS vendor cooperates and
supports the class of devices, device by device
separately.

Alternately, the monopolist may deliberately
misapply the standard, as Microsoft does essentially
100% of the time to make stuff like Internet
Explorer impossible to script in W3C standard HTML.

[You _want that_ as a near monopoly vendor, because
then the products created will have to be tailored
by the vast cloud of software cobblers specifically
to match your interface, will have to use a
non-standard set of features catering only to you.

Those non-standard features to make up for the
ideosyncracies of interfacing with your monopolist
product then won't work on the competing products
that obey the standards precisely, except by
extra effort to include some form of conditional
execution, so expensive to create that the result
quite often succeeds iin driving your competitors
out of business even though their behavior is the
"correct" one. It just happens to be business
suicide.]

For example, you'll see this very often in website
HTML code at commercial sites, that the first thing
that is done is to detect the customer's browser
type, and then serve web pages dynamically catering
to that browser type, or alternately serve static
web pages with a mess of internal conditional
execution scripting (think JavaScript) to cater for
each supported browser type. If browser vendors all
stuck to implementing all of and exactly the well
known and published standards, none of that
conditional execution would be necessary.

The moral lesson there using a well known example is
that just because you have a standard in writing
like HTML 4.01, doesn't mean the problem of dealing
with "stuff", say, printers, case by case depending
on the manufacturer and model, has been overcome.

However, given all that, Tor tells us that GTK+ is
broken for MS-Windows at a much more fundamental
level than that.

[Of course, that kind of failure has long ago been
made unnecessary by Posix and other standards.  If
Microsoft actually supported existing standards,
that kind of failure couldn't be a problem, the
interfaces would behave just like the Linux ones do,
just as Posix and other standards say they should
do. That, however, would make the OS an unimportant
detail of what a buyer wants in a computer, and
Microsoft, who gets rich selling its OS, would go
broke as the customer found it to work just like the
free OSen do.]

Or so I believe.

xanthian.

[Tor Lillqvist]

>> I thought the whole point of the Windows GDI was
>> that the programmer didn't have to know what the
>> backend printer and its driver was.

> Well, first of all because Microsoft came very late
> to the game of establishing a standard driver
> interface. [...]

Xanthian, instead of just talking in general, could you give some
concrete examples of how one needs to take printer model specific
quirks into account when using the Win32 printing related APIs?

> [Of course, that kind of failure has long ago been
> made unnecessary by Posix and other standards.

Please note that despite POSIX and all, the printing interface on
various Unixes is far from standardized. GTK+ has for Unix two
different printing backends: cups and lpr. I am sure that there are
many not that uncommon Unix variants that those haven't actually been
tested on.

--tml

[Kent Paul Dolan]

> From: "Tor Lillqvist" <tml@...>
> Date: Tue, 9 Sep 2008 16:56:22 +0300

>>> I thought the whole point of the Windows GDI was
>>> that the programmer didn't have to know what the
>>> backend printer and its driver was.

>> Well, first of all because Microsoft came very late
>> to the game of establishing a standard driver
>> interface. [...]

> Xanthian, instead of just talking in general, could
> you give some concrete examples of how one needs to
> take printer model specific quirks into account when
> using the Win32 printing related APIs?

Not likely, 20 years later.

>> [Of course, that kind of failure has long ago been
>> made unnecessary by Posix and other standards.

> Please note that despite POSIX and all, the printing
> interface on various Unixes is far from
> standardized. GTK+ has for Unix two different
> printing backends: cups and lpr. I am sure that
> there are many not that uncommon Unix variants that
> those haven't actually been tested on.

That's not the level at which Posix standardizes.

> --tml

xanthian.

[Tor Lillqvist]

>> Xanthian, instead of just talking in general, could
>> you give some concrete examples of how one needs to
>> take printer model specific quirks into account when
>> using the Win32 printing related APIs?

> Not likely, 20 years later.

But Win32 did not exist 20 years ago.

--tml

[Kent Paul Dolan]

> From: "Tor Lillqvist" <tml@...>
> Date: Wed, 10 Sep 2008 10:01:28 +0300

>>> Xanthian, instead of just talking in general,
>>> could you give some concrete examples of how one
>>> needs to take printer model specific quirks into
>>> account when using the Win32 printing related
>>> APIs?

>> Not likely, 20 years later.

> But Win32 did not exist 20 years ago.

So? Once again you are entirely out of line.

Did you even bother to read to the bottom of my
original answer, or did you just return some snippy
comment out of meanness of spirit?

The unethical competition tactics and sloppy
software development and software quality control
habits at Microsoft, have existed since it was
founded. The realities of a marketplace where some
potential software targets (both hardware and other
software, like browsers) have too small a market
share for first party and third party developers to
spend time catering to them, has existed since the
first third party software was created.

The limitations of standards to define now and
forever what such a software target's interface must
be able to convey and how to take correct and full
advantages of that software target's quirks and
features beyond the standard, have all existed since
before Microsoft existed.

The problem addressing a diverse marketplace of
software interface targets with a single interface
component isn't an operating system specific
problem, it isn't even a software-specific problem;
the same issues occur for making bags full of
assorted gaskets cater for all the faucets that
buyers might have in their homes.

The intention of my original answer was just to warn
the original author that users of GIMP, and thus
downstream users of GTK+, should not expect for free
the same coverage of printer types that can be put
into commercial software by the expenditure of very
large effort and very large expense by big
companies, so that some personal printers might well
_never_ be covered by GIMP. The end result is the
usual advice: save the GIMP image in a file, import
it to some program with better printing
capabilities, and print it from there.

All of these are ongoing realities, not stuff that
needs detailed example. In GIMP, the user is
_already_ complaining about GIMP not working as
expected. Nor do the problems with MS-Windows need
separate and detailed documenting by me, they are
the stuff of legends. See my just prior posted
message to the group for just one more example of
the horror of currently sold Microsoft software.

xanthian.

[Tor Lillqvist]

> Did you even bother to read to the bottom of my
> original answer,

Not really, no.

--tml

[Kent Paul Dolan]

From: "Tor Lillqvist" <tml@...>
Date: Wed, 10 Sep 2008 21:57:58 +0300

>> Did you even bother to read to the bottom of my
>> original answer,

>Not really, no.

And yet you chose to pick a quarrel without first
informing yourself on what the email even said?

You do know that this is not even in the first dozen
times you've done this to someone here!!

xanthian.

[Tor Lillqvist]

> And yet you chose to pick a quarrel without first
> informing yourself on what the email even said?

Oh, just fuck off, will you?

--tml