From: Dr.Ruud on
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
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
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
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
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
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: stuff
Next: FAQ 6.16 How can I do approximate matching?