tuxpaint-devel

[Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

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

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

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.

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/

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"???  :-)

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

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

On Wed, Jun 27, 2007 at 12:21:20AM -0400, Albert Cahalan wrote:
> PostScript 3 is from 1997.

I'm betting some schools out there have printers older than that. :)


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

I think _typically_, people want it printed as full-page as possible.


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

That's a good example of why one would NOT want it full-page and rotated.
So yeah, I do agree that adding a UI level would be nice.  It'd have to
be optional, for the younger kids.  (And let the parents set some default,
maybe.)

Thx!

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

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

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

On 6/27/07, Bill Kendrick <nb...@so...> wrote:
> On Wed, Jun 27, 2007 at 12:21:20AM -0400, Albert Cahalan wrote:
> > PostScript 3 is from 1997.
>
> I'm betting some schools out there have printers older than that. :)

Yes, but they don't work and you couldn't buy ink anyway.
Printers are less reliable than floppy drives and mice.

> > That needed support in the GUI. A person might want
> > rotation or not.
>
> I think _typically_, people want it printed as full-page as possible.

See, I didn't have this assumption. My assumption was
that you'd always want it right side up.

Automatic rotation can be done in postscript.

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

[Caroline F. <car...@go...>]

On Wed, 2007-06-27 at 08:52 -0700, Bill Kendrick wrote:
> On Wed, Jun 27, 2007 at 12:21:20AM -0400, Albert Cahalan wrote:
> > PostScript 3 is from 1997.
> 
> I'm betting some schools out there have printers older than that. :)
> 
> 
> <snip> 
> > That needed support in the GUI. A person might want
> > rotation or not.
> 
> I think _typically_, people want it printed as full-page as possible.
> 
> 
> > 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 think generally if you were doing a school report you'd save it and
then play with it in the GIMP (or equivalent). 

Is the added complexity just going to affect user friendliness? It has
to be kid proof. 

Caroline

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

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

On Wed, Jun 27, 2007 at 04:58:49PM +0100, Caroline Ford wrote:
> 
> I think generally if you were doing a school report you'd save it and
> then play with it in the GIMP (or equivalent). 

Well, I can see making a picture, then printing it at the top of the
page and scribbling your name and classroom at the bottom right corner.


> Is the added complexity just going to affect user friendliness? It has
> to be kid proof. 

This is why Tux Paint Config is so full of options. :)

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

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

[Caroline F. <car...@go...>]

On Wed, 2007-06-27 at 09:03 -0700, Bill Kendrick wrote:
> On Wed, Jun 27, 2007 at 04:58:49PM +0100, Caroline Ford wrote:
> > 
> > I think generally if you were doing a school report you'd save it and
> > then play with it in the GIMP (or equivalent). 
> 
> Well, I can see making a picture, then printing it at the top of the
> page and scribbling your name and classroom at the bottom right corner.
> 
Ah okay. we mean different things by school report. For me a school
report is something a teacher would produce.
> 
> > Is the added complexity just going to affect user friendliness? It has
> > to be kid proof. 
> 
> This is why Tux Paint Config is so full of options. :)

Oh config certainly :) I was worried we were going to introduce complex
printer dialogs!

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

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

On 6/27/07, Caroline Ford <car...@go...> wrote:
> On Wed, 2007-06-27 at 09:03 -0700, Bill Kendrick wrote:

> > This is why Tux Paint Config is so full of options. :)
>
> Oh config certainly :) I was worried we were going to introduce complex
> printer dialogs!

Complex is no good. I don't think 2 to 6 icons, showing the page
as it will be printed, would be complex.

Really, shoving stuff into Tux Paint Config is like shoving
mistakes under the carpet. Say, "Tux Paint Carpet" anyone?
This makes some functionality needlessly adult-only.

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

[Karl O. H. <ka...@hu...>]

Tysdag 26. juni 2007 skreiv Albert Cahalan:
>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.

Perhaps the (truly amazing) sam2p would be worth looking at:
http://www.inf.bme.hu/~pts/sam2p/

-- 
Karl Ove Hufthammer