Re: RFS: bmeps, command line tool for converting bitmap images to eps-files
On Fri, 2006-01-06, at 15:55:15 +0530, Kapil Hari Paranjape wrote:
> Dear Anders,
>
> On Wed, 28 Dec 2005, Anders Lennartsson wrote:
> > I'm looking for a sponsor for a set of deb-packages of bmeps and the libraries.
>
> I am not a DD so I cannot sponsor your upload but here are some
> comments on your package.
>
> > This application is a tool to convert various bitmaps to
> > eps-format. It is released by the upstream author Dirk Krause under
> > LGPL. The upstream web-site is at http://bmeps.sourceforge.net.
> >
> > >From the control file:
> > The bmeps packages contain tools for converting bitmap images to
> > eps-files. Currently bmeps can handle .pnm, .ppm, .pgm, .pbm, .jpeg,
> > and .png images. The conversion functions are also available in
> > library form.
>
> Since PNG and JPG files can be included in PS level 3 essentially
> without conversion you could perhaps give some reasons why such
> conversion could be useful.
Bmeps is a project to add bitmap graphics support to dvips. This makes
it useful for including bitmaps in LaTeX documents. This is
particularly useful when producing dvi-documents, but less useful for
pdfLaTeX since then some bitmaps can be included already.
>From the manual page:
The EPS images are intended for use with text processing and DTP
systems (i.e. LaTeX), not for direct printing. No attempts are made
to fit pages of any paper size, scaling and rotating is left up to the
text processing software using the EPS images.
You can produce EPS level 1, 2 or 3. Different compression and
encoding mechanisms are avail- able: run-length-compression (requires
EPS level 2), flate compression (requires EPS level 3) and
ASCII-85-encoding (requires EPS level 3).
Alpha channels in PNG files can be used to mix against a user
specified background colour and/or to create an image mask for EPS
level 3 output files.
There is also the option of of extending dvips with the capability to
include (compressed) bitmaps, which I assume depends on the
possibility of including bitmaps in PS level 3(?). In fact, there is a
patched dvipsk included in the source tar-file, although not the latest
version, that does this.
> > The packaging specific parts and files are viewable on
> > http://www.lennartsson.se/svn/debian/bmeps
> > (at least will be, after syncing tonight)
>
> I couldn't access the packages from there but from the sources lines
> given below I could.
With a browser you can look in there, in trunk or tags, to see the
files in the debian directory, rules, changelog etc, which are under
version control by subversion.
> > debs are available from
> > deb http://www.lennartsson.se/ debian/
> > deb-src http://www.lennartsson.se/ debian/
>
> 1. Lintian points out the following errors:
How did you instruct lintian to do this? (ok, I'll read the man again...)
> a. The debian/compat file and the DH_COMPAT variable in
> debian/rules are two ways of doing the same thing. You should
> pick one.
Thanks for pointing this out.
> b. While your debian/changelog says you bumped the standards version
> your debian/control file does not indicate the same.
Oops.
> 2. The orig.tar.gz contains the original tar.gz as a file. Is there a
> reason for packaging this way rather than the more conventional
> way of keeping the original tar.gz as Debian's orig.tar.gz?
Packaging with dbs normally involves this method. I suppose it is a
matter of taste or philosophy, but building the package by first
unpacking the original tar-file, applying any pathces, and so on,
seems nice to me. It clearly separates the upstream files from the
debian-specific parts, including patches. For my bmeps package you can
look at the changes to the upstream at
http://www.lennartsson.se/svn/debian/bmeps/trunk/patches
Other similiary packging methods are cdbs or dpatch. Of course they
may seem to be overkill for simple packages but I started out by using
dbs on simple packages to learn the method.
> 3. The debian/changelog refers to earlier versions of bmeps but there
> were no earlier versions in the archive!
Hmm, must earlier versions be archived? The necessary (debian) files are
available in svn and the upstream tar-files are available from
sourceforge. So it is in principle possible to build them. But they
were originally built on various states of sid, which I don't keep
track of when i upgrade, so I don't see the value of keeping the
binary packages.
> All the best with getting your package accepted by a "real" sponsor.
>
> Regards,
>
> Kapil.
> --
Thank you,
Anders
Reply to: