graphics

[Huub]

Hi,

I'm using Perl to print from database, which works great. Now I'd like to
print a .JPG picture with it. However, searching CPAN I find a LOT of
graphics modules. Any recommendation which one to use for this?

Thanks.

 

[Martijn Lievaart]

Hi,

I'm using Perl to print from database, which works great. Now I'd like
to print a .JPG picture with it. However, searching CPAN I find a LOT of
graphics modules. Any recommendation which one to use for this?

I'm looking into something similar right now. After searching CPAN, I
looked better at CD::Graph and Chart and found both very similar, and
lacking for my purpose. They are good though.

I then looked at driving gnuplot from perl, and it will probably serve
your needs. It's incredible what you can do with gnuplot.

It still didn't need my needs (for every x-pixel, draw min, max and avg)
so I'm currently deriving from GD::axestype to do it myself.

HTH,
M4

 

[Jürgen Exner]

I'm using Perl to print from database, which works great. Now I'd like to
print a .JPG picture with it.

I am puzzled.

"print" like in print to a sheet of paper? Normally you would use
whatever means your OS provides for that and normally yes, you could
initiate that via a Perl program, too, just like you would initiate any
other external command from a Perl program.

Or "print" like the print() function in Perl? Well, that is mostly for
text although of course you can use it for binary data, too.

Or what "print" are you talking about?

jue

 

[Huub]

I am puzzled.

"print" like in print to a sheet of paper? Normally you would use
whatever means your OS provides for that and normally yes, you could
initiate that via a Perl program, too, just like you would initiate any
other external command from a Perl program.

Or "print" like the print() function in Perl? Well, that is mostly for
text although of course you can use it for binary data, too.

Or what "print" are you talking about?

jue

Ok, looks like I haven't been clear enough.

I am talking about printing to paper and the intention is to print an
existing jpg picture on the paper after which the data from the database
is printed.

Reading the other reactions, I think it would be easier to first print
that image using Gimp or so, and then re-use the paper using Perl to
print the data. Though it would take at least twice as much time.

Any suggestion welcome.

 

[Willem]

Huub wrote:
) Ok, looks like I haven't been clear enough.
)
) I am talking about printing to paper and the intention is to print an
) existing jpg picture on the paper after which the data from the database
) is printed.
)
) Reading the other reactions, I think it would be easier to first print
) that image using Gimp or so, and then re-use the paper using Perl to
) print the data. Though it would take at least twice as much time.

What method are you using to print the data to the printer ?
Are you using some module ? Is it pure plain text ? Postscript ?

There's probably some Perl module out there that can print combined
text and jpg images to a printer.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[RedGrittyBrick]

I'm using Perl to print from database, which works great.

So how are you doing that? You might be

* Using a Win32 API to make GDI calls etc
* Using Perl print() statements to write a text file
then exec() a 'lp' command
* A gazillion other possibilities.

In order to provide a relevant answer, potential helpers might benefit
from a little more context.

Now I'd like to
print a .JPG picture with it. However, searching CPAN I find a LOT of
graphics modules. Any recommendation which one to use for this?

I'd have the Perl program write a Postscript file containing image data
and text, then use OS-dependant commands to spool that to a Postscript
printer or via a Postscript aware print subsystem like CUPS or
Ghostscript. Your mileage is likely to vary. CPAN is your friend.

 

[John Bokma]

Ok, looks like I haven't been clear enough.

I am talking about printing to paper and the intention is to print an
existing jpg picture on the paper after which the data from the database
is printed.

Reading the other reactions, I think it would be easier to first print
that image using Gimp or so, and then re-use the paper using Perl to
print the data. Though it would take at least twice as much time.


Any suggestion welcome.

Install Java, Apache FOP, and Saxon-B XSLT
Generate XML via your Perl program
Convert this XML via saxonb-xslt to fo
Convert fo to pdf (or pick any other of the formats supported) using
Apache FOP.

It sounds like a lot of trouble, but IMO it's extremely flexible, see:
http://johnbokma.com/mexit/2010/02/11/

It's most likely easier than generating your own PDF. Another option is
to just generate a HTML file and print that one via a browser (or
convert HTML to PDF and print that). But I am quite sure that XSL-FO
gives you more control over the output than HTML.

 

[Huub]

Huub wrote:
) Ok, looks like I haven't been clear enough. )
) I am talking about printing to paper and the intention is to print an
) existing jpg picture on the paper after which the data from the
database ) is printed.
)
) Reading the other reactions, I think it would be easier to first print
) that image using Gimp or so, and then re-use the paper using Perl to )
print the data. Though it would take at least twice as much time.

What method are you using to print the data to the printer ? Are you
using some module ? Is it pure plain text ? Postscript ?

There's probably some Perl module out there that can print combined text
and jpg images to a printer.


SaSW, Willem

I use DBI to get the data from the database, after which it is printed as
pure plain text. So I'm not converting anything to XML, HTML, pdf or so.
This has worked for some years now, and no problem.

And my initial question was if there is a Perl module that enables me to
print both a jpg image and the data from the database in 1 single
printjob. But if I understood it correctly, the Graphics modules are
intended to create a graphical image, rather than to fetch one for e.g.
printing on paper.

 

[Willem]

Huub wrote:
) I use DBI to get the data from the database, after which it is printed as
) pure plain text. So I'm not converting anything to XML, HTML, pdf or so.
) This has worked for some years now, and no problem.
)
) And my initial question was if there is a Perl module that enables me to
) print both a jpg image and the data from the database in 1 single
) printjob. But if I understood it correctly, the Graphics modules are
) intended to create a graphical image, rather than to fetch one for e.g.
) printing on paper.

Yes, you want a printing module for that, not a graphics module.

For example, on Win32 you have stuff like Win32:rinter, which can
print several image formats, according to the docs.

Or you could generate HTML or XSL-FO or something with the text
and the graphics you want, and then print that.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Steve C]

Hi,

I'm using Perl to print from database, which works great. Now I'd like to
print a .JPG picture with it. However, searching CPAN I find a LOT of
graphics modules. Any recommendation which one to use for this?

The intermediate form between binary data and a printer is a
page description language. ASCII is the original text-only PDL,
but you can't use it for anything more complex.

Good choices for page description with images are postscript, pdf,
or pcl, all of which can be generated from perl. HTML works too if
value ease over precision. It just depends on your printing
environment.

 

[Ilya Zakharevich]

I'd have the Perl program write a Postscript file containing image data
and text, then use OS-dependant commands to spool that to a Postscript
printer or via a Postscript aware print subsystem like CUPS or
Ghostscript. Your mileage is likely to vary. CPAN is your friend.

Nowadays it looks like PostScript would be the last choice...
Generating PDF might be easy (did not try it), and it is much easier
to print...

Myself, I would go through enscript or TeX - this would cover the
typesetting needs (instead of trying to reinvent things in Perl).

Hope this helps,
Ilya

 

[John Bokma]

Nowadays it looks like PostScript would be the last choice...
Generating PDF might be easy (did not try it), and it is much easier
to print...

Myself, I would go through enscript or TeX - this would cover the
typesetting needs (instead of trying to reinvent things in Perl).

Hope this helps,
Ilya

Over a year ago I played with lout:
http://en.wikipedia.org/wiki/Lout_(software)

Maybe also something to look into?

 

[RedGrittyBrick]

Nowadays it looks like PostScript would be the last choice...

I think it depends on your skillset, I happen to know a little
PostScript and like the language a lot, this obviously biases my choice.

Generating PDF might be easy (did not try it),

Yes, there appear to be some good CPAN modules for writing PDF.

and it is much easier to print...

This isn't something I find any problems with. Most laser printers above
entry level will support PostScript printing. Some of them support PDF
printing. Most (if not all) Unix/Linux systems will have print systems
that can rasterise PostScript for non-Postscript printers.

Myself, I would go through enscript or TeX - this would cover the
typesetting needs

I also use enscript and a2ps. I found writing TeX (or rather LaTeX)
still needs a lot of markup and the production chain can be complicated
and prone to generating mysterious error messages. What TeX toolset do
you use?

I use grutatxt a lot - which can generate HTML and LaTeX (and thence
PDF) from plain text. It is available as a Perl module. I'm not sure
about the inclusion of images other than for HTML though. I certainly
prefer keeping source matter in a plain text form rather than in any
proprietary form that is likely to become obsolete and unreadable.

The OP might look at these as well as markdown, asciidoc etc

(instead of trying to reinvent things in Perl).

That is a good point. It depends a bit on how much "typesetting" you
need to do but I guess I must agree.

 

[Mart van de Wege]

I also use enscript and a2ps. I found writing TeX (or rather LaTeX)
still needs a lot of markup and the production chain can be
complicated and prone to generating mysterious error messages. What
TeX toolset do you use?

Not speaking for Ilya, but at work I had to write something to generate
reports. I used SVG::TT:Graph to generate the graphs, Image::Magick to
convert them to PNG, Template Toolkit to build LaTex files referring to
the images, and LaTeX:river to render the LaTeX to PDF.

Works like a charm, even if the toolchain is long. LaTeX:river is a
bit finicky if you don't clean up your working directory though.

Mart

 

[Ilya Zakharevich]

Yes, there appear to be some good CPAN modules for writing PDF.

This isn't something I find any problems with. Most laser printers above
entry level will support PostScript printing. Some of them support PDF
printing. Most (if not all) Unix/Linux systems will have print systems
that can rasterise PostScript for non-Postscript printers.

You have a wrong (IMO) metric of "having problems". PS is a
programming language. There is no way to "verify" PS or debug PS:
there is no way to know whether a given PS file will print on your
neighbor's PS printer except for printing it.

Likewise, if you can rasterize PS with one version of GS, this does
not imply that it would rasterize with a different version of GS.
Basically, PS leads you in the same messy can of worms as most other
programming languages (only it has no debuggers or development tools).

PDF, on the other hand, contains just DATA, not PROGRAM. It must be
easy to verify (never tried it); then any non-buggy implementation
would be able to rasterize it.

I also use enscript and a2ps. I found writing TeX (or rather LaTeX)
still needs a lot of markup and the production chain can be complicated
and prone to generating mysterious error messages. What TeX toolset do
you use?

LaTeX + ams.

prefer keeping source matter in a plain text form rather than in any
proprietary form that is likely to become obsolete and unreadable.

It is exactly the opposite with me. LaTeX is known to be
non-backward-compatible. So I keep data in proprietary form with a
known script for to-LaTeX conversion. When backward-compatibility
breaks, I can compensate by editing the scripts...

Yours,
Ilya

 

[Ted Zlatanov]

MvdW> I used SVG::TT:Graph to generate the graphs, Image::Magick to
MvdW> convert them to PNG, Template Toolkit to build LaTex files
MvdW> referring to the images, and LaTeX:river to render the LaTeX to
MvdW> PDF.

MvdW> Works like a charm, even if the toolchain is long. LaTeX:river is a
MvdW> bit finicky if you don't clean up your working directory though.

Any chance you can publish your toolchain to convert a series of PNG
files to a PDF file?

Thanks
Ted

 

[John Bokma]

MvdW> I used SVG::TT:Graph to generate the graphs, Image::Magick to
MvdW> convert them to PNG, Template Toolkit to build LaTex files
MvdW> referring to the images, and LaTeX:river to render the LaTeX to
MvdW> PDF.

MvdW> Works like a charm, even if the toolchain is long. LaTeX:river is a
MvdW> bit finicky if you don't clean up your working directory though.

Any chance you can publish your toolchain to convert a series of PNG
files to a PDF file?

While most likely not an answer to your question, some time ago I wrote
this:

http://johnbokma.com/mexit/2009/02/24/jpeg-to-pdf-using-perl.html

to create a pdf with one JPEG per page.

 

[Mart van de Wege]

MvdW> I used SVG::TT:Graph to generate the graphs, Image::Magick to
MvdW> convert them to PNG, Template Toolkit to build LaTex files
MvdW> referring to the images, and LaTeX:river to render the LaTeX to
MvdW> PDF.

MvdW> Works like a charm, even if the toolchain is long. LaTeX:river is a
MvdW> bit finicky if you don't clean up your working directory though.

Any chance you can publish your toolchain to convert a series of PNG
files to a PDF file?

Hmm. Sure thing, but it's in three fairly substantive package files. Do
you want that posted here, or in a private mail?

Also, I may have to anonymise our company name, which is referred to
quite often in variables and directory/file names.

So tell me, how do you want it?

Mart

 

[Dr.Ruud]

I'm using Perl to print from database, which works great. Now I'd like to
print a .JPG picture with it. However, searching CPAN I find a LOT of
graphics modules. Any recommendation which one to use for this?

WebKit is great for this.
http://code.google.com/p/wkhtmltopdf/

 

[Peter J. Holzer]

You have a wrong (IMO) metric of "having problems". PS is a
programming language. There is no way to "verify" PS or debug PS:
there is no way to know whether a given PS file will print on your
neighbor's PS printer except for printing it.

Likewise, if you can rasterize PS with one version of GS, this does
not imply that it would rasterize with a different version of GS.
Basically, PS leads you in the same messy can of worms as most other
programming languages (only it has no debuggers or development tools).

PDF, on the other hand, contains just DATA, not PROGRAM.

There is no clear-cut boundary between data and program. True, PDF isn't
turing-complete (unless it contains JavaScript), but that doesn't make
the interpreter much simpler. The exclusion of flow-control from the PDF
language has other advantages, though: For example, you can determine
page boundaries by a static analysis of the file, which isn't possible
in Postscript (although there is a convention to use special comments
for that).

It must be easy to verify (never tried it); then any non-buggy
implementation would be able to rasterize it.

Newer versions of Acrobat Reader won't rasterize some PDFs generated by
Acrobat 10 years ago, because some features of early PDF versions have
been removed in later versions. OTOH, I am not aware of any
backwards-compatibility issues with PostScript (which also went through
a lot less revisions, although it is older).

LaTeX + ams.

LaTeX (or rather TeX) is a programming language, too.

It does have the advantage over page description languages like PDF of
PostScript that it handles much of the layout automatically (and
produces rather nice output).

It is exactly the opposite with me. LaTeX is known to be
non-backward-compatible. So I keep data in proprietary form with a
known script for to-LaTeX conversion.

Who is the proprietor of your proprietary format? You? Then you
naturally won't have a problem, as you know and control the format.
Somebody else? Then you may run into problems when that person or
company stops supporting that format or alters it in an incompatible
way.

hp