Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

[Albert C. <aca...@gm...>]

On 6/26/07, Bill Kendrick <nb...@so...> wrote:
> On Tue, Jun 26, 2007 at 12:46:44AM -0400, Albert Cahalan wrote:
> > We had a proposed fix that looked good. It got sent to the
> > mailing list. It adjusted "%%%%BeginData: %u Binary Bytes\n"
> > include 6 more bytes for "image\n" if I remember right.
> > It seems that the fix never made it in to CVS. I can't find the
> > change anywhere. That might have done the job.
>
> Hrm, sorry if that one flew past me. :^(
>
>
> > The old code sent the data in the obvious manner, as 24-bit
> > sRGB data. The new code uses a very inefficient and awkward
> > representation. It's planar (!) and hexidecimal.
>
> Well, there's still time to change it.  I liked that "pnmtops" saved
> as Level 2 PostScript, which I _imagine_ is more portable than Level 3,
> being older and such...

PostScript 3 is from 1997.

> > Now we can't handle sideways printers. There might not
> > be any of course, but that is lost functionality.
>
> I'm not sure what this means.  As it stands, if you have Tux Paint
> in a typical landscape orientation (e.g., 1024x768) and you print on
> an 11"x17" printer, the image will be rotated sideways to fit.

The old postscript was not printer-specific; it automatically
adjusted itself. This was great for network print queues that
might choose a somewhat random printer for the output.
(maybe choose the printer based on the IP address of the
client, so that the printout occurs in the same room)

> I have no idea if the previous code was this flexible -- there seemed to be
> some PS code in there for rotating, but the fprintf() was commented out.

That needed support in the GUI. A person might want
rotation or not.

If you're doing the cover page for a school report or some
little book, you probably want the image centered at the top.
For other stuff, you might want to fill the page.

> > I'm really suspicious of the whole paper size thing. This makes
> > the assumption that the user has made a paper size setting
> > and that it is correct. The physical printer hardware might not
> > agree with whatever random value Tux Paint ends up getting.
>
> It should be what the user has defined their papersize to be, either
> system-wide, or specific to Tux Paint.

Yes, I know. I'm doubting that this is a reasonable expectation.

As a matter of fact, my printer config at work is always
chopping things off around the margins. So this is a
real problem. (Fedora 7 with some Xerox office thing)

I think it is really nice to be able to ship the postscript off
to a completely unknown printer and get good results.
Printer configuration is really difficult; commonly one's printer
is not in the list of choices but numerous similar ones are.
(older models, European market models, Japanese market
models, high-end models with features you don't have...)
The user picks a random almost-right choice and hopes
that the output isn't too bad.

> > Anyway, I really wish the simple fix had been tried.
>
> One can simply download Tux Paint 0.9.16 source code, make the change,
> and see if it worked.  Of course, IIRC, _I_ never personally had a printing
> problem on my system, so I never found out exactly what was wrong.

Same here. It always worked fine for me. The people with
the problems never provided feedback on the proposed fix.
The fix did look good though, apparently correcting an error
I made in assuming that the "image\n" text wasn't to be
included in the byte count.

> And a request to those of you who DO decide to work on the PostScript
> stuff (at this point, or in the future) -- PostScript is kind of cryptic.

"kind of"???  :-)