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

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

On 6/25/07, Bill Kendrick <nb...@so...> wrote:
>
> The PostScript generating code in Tux Paint has been moved to an external
> set of source files (postscript_print.c and .h) and the PS content itself
> has been rewritten from the ground up (based on NetPBM's "pnmtops" source
> code, and examining its output).
>
> It's not perfect, but it should be a lot better.
>
> Bonus: Tux Paint targets that use this PostScript generating code
> (that is, _not_ Windows, Mac OS X or BeOS, which have their own
> platform-specific print code) now uses "libprint" to determine the
> user's or system's current default paper size (e.g., "letter" or "a4").
>
> That size (in PS points) is included in the generated PostScript, and
> Tux Paint asks the PS device to scale the user's picture up to fit
> on the page.  It rotates it appropriately, based on paper size and
> image aspect ratio.
>
> Finally, Tux Paint lets the user specify a different paper size than
> what "libprint" discovers (via $PAPER or /etc/papersize).  A pulldown
> that shows all paper sizes known by "libprint" has been added to
> Tux Paint Config.
>
> PLEASE TEST! :^)  Recommendations to make it perfect would be appreciated.
> (Look for "FIXME" comments in the postscript_print.c :^) )
>
> Thanks!  (Special thanks to my friend Henry House for looking over the
> current PS output for me, and giving recommendations.  And thanks to
> Jef Poskanzer, who wrote "pnmtops" back in the day.)

Well, I can't complain too much because I never found the time
to look into things, but... I think this is a step backwards.

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.

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.

Now we can't handle sideways printers. There might not
be any of course, but that is lost functionality.

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.

Pushing regular stuff into Tux Paint Config is not good.
It's likely that few people run this. It is also bad to expect
that the Alt printing stuff is usable. Things ought to work
right, every time, without the add-on hacks.

Note that there are 6 reasonable printing locations on the
paper. (landscape or not, centered in the too-small dimension
or to one side in that dimension) It'd be nice to make all 6
of these available in the normal print dialog. (thumbnails)

Anyway, I really wish the simple fix had been tried.