graphics
in [Perl]
|
Prev: stuff
Next: FAQ 6.16 How can I do approximate matching?
From: Dr.Ruud on 11 Jun 2010 18:53 Huub wrote: > 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/ -- Ruud
From: Peter J. Holzer on 13 Jun 2010 06:56 On 2010-06-11 03:19, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote: > On 2010-06-10, RedGrittyBrick <RedGrittyBrick(a)spamweary.invalid> wrote: >>> Generating PDF might be easy (did not try it), >>> 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. > > 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). >>> 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? > > 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). >> 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. 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
From: Ted Zlatanov on 14 Jun 2010 13:58 On Fri, 11 Jun 2010 22:02:21 +0200 Mart van de Wege <mvdwege(a)mail.com> wrote: MvdW> Ted Zlatanov <tzz(a)lifelogs.com> writes: >> On Thu, 10 Jun 2010 22:37:56 +0200 Mart van de Wege <mvdwege(a)mail.com> wrote: >> 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::Driver to render the LaTeX to MvdW> PDF. >> MvdW> Works like a charm, even if the toolchain is long. LaTeX::Driver 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? >> MvdW> Hmm. Sure thing, but it's in three fairly substantive package files. Do MvdW> you want that posted here, or in a private mail? MvdW> Also, I may have to anonymise our company name, which is referred to MvdW> quite often in variables and directory/file names. I don't know the code so I can't say how it should be packaged. You can send it to me if you prefer but regardless you should check with your company about any potential copyright issues, of course. On Fri, 11 Jun 2010 13:50:20 -0500 John Bokma <john(a)castleamber.com> wrote: JB> some time ago I wrote this: JB> http://johnbokma.com/mexit/2009/02/24/jpeg-to-pdf-using-perl.html JB> to create a pdf with one JPEG per page. That was interesting too. I am interested in the LaTeX chain because I want that environment for the TeX capabilities, but I can use a straight JPG->PDF converter as you posted too. Thanks Ted
From: Mart van de Wege on 14 Jun 2010 16:53 Ted Zlatanov <tzz(a)lifelogs.com> writes: > On Fri, 11 Jun 2010 22:02:21 +0200 Mart van de Wege <mvdwege(a)mail.com> wrote: > > MvdW> Ted Zlatanov <tzz(a)lifelogs.com> writes: >>> On Thu, 10 Jun 2010 22:37:56 +0200 Mart van de Wege <mvdwege(a)mail.com> wrote: >>> > 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::Driver to render the LaTeX to > MvdW> PDF. >>> > MvdW> Works like a charm, even if the toolchain is long. LaTeX::Driver 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? >>> > MvdW> Hmm. Sure thing, but it's in three fairly substantive package files. Do > MvdW> you want that posted here, or in a private mail? > > MvdW> Also, I may have to anonymise our company name, which is referred to > MvdW> quite often in variables and directory/file names. > > I don't know the code so I can't say how it should be packaged. You can > send it to me if you prefer but regardless you should check with your > company about any potential copyright issues, of course. Hmm. If it's for study purposes, I don't think my boss would mind. The code is fairly tied to our specific environment, and AFAIK you're not working for a competitor, so that's just fine. So I'll just do a search and replace on the identifying bits. The code is fairly straightforward, and seeing as that you probably have some more experience in Perl than I have, you should manage just fine. The hardest bits to understand are the bits where I transform the query results into SVG::TT::Graph datasets. And the template files are in Dutch of course. Don't expect it to run though. For that you need the underlying database. If I tar it up, it'll be a few 10s of kilobytes. Is that OK to mail as an attachment? And I suppose your email address as given in your postings is the right one? Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
From: Ilya Zakharevich on 14 Jun 2010 17:34
On 2010-06-13, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote: >>>> Generating PDF might be easy (did not try it), >>>> 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. >> >> 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. Of course there is: decidability (this is a math term; the layman's variant would be something like a guaranteed ability to verify). >> 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). Given that there is not even "same-version-compatibility", so IMO it is silly to discuss backward-compatibility. For a recent example, see http://groups.google.com/group/comp.lang.postscript/browse_thread/thread/238439c8b1f7df7c > LaTeX (or rather TeX) is a programming language, too. TeX is. On the other hand, it is easy (and very productive) to operate AmS-LaTeX as a page description language. >> 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? Yes. Yours, Ilya |