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

[Bill K. <nb...@so...>]

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...


> 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.

If, however, you're on a tablet PC in portrait orientation (e.g., 768x1024)
and print on that same paper, the image will NOT be rotated.

I tested a few combinations (asking for different papersizes and Tux Paint
canvases) and viewed the resulting PS in KPDF, and it worked reasonably
well.

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.


> 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.


> 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.

Well, the point here, was to work as intelligently as possible with the
least feedback from the user.  In the end, it may come down to a documentation
problem (e.g., "maybe your system is set up for A4, but you're in the US
so your printer is Letter?  check your system printing config").

At the moment, it's a "Known Issues" documentation problem.  (The whole lot of
printing problems, in fact... e.g., "try running through 'ps2ps' on Linux" and
"try running Tux Paint through the PPC simulator ('Rosetta') on Intel Macs")


> 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)

Not a bad idea, actually.


> 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.


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.
Could you please include C comments that explain what the PS is trying to
do? :^)

Thx,

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/