[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1082831: marked as done (unpaper: The man page misleads users about supported file formats)

Your message dated Fri, 19 Dec 2025 13:19:06 +0100
with message-id <176614674618.2665700.14261390374240490181@cairon.jones.dk>
and subject line Re: unpaper: The man page misleads users about supported file formats
has caused the Debian Bug report #1082831,
regarding unpaper: The man page misleads users about supported file formats
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1082831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082831
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: unpaper
Version: 7.0.0-0.1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.unpaper@sideload.33mail.com

The man page states:

>   Input and output files can be in either .pbm, .pgm or .ppm format,
>   thus generally in .pnm format, as also used by the Linux scanning
>   tools scanimage and scanadf.  Conversion to PDF can e.g.  be
>   achieved with the Linux tools pgm2tiff, tiffcp and tiff2pdf.
>   …
>   unpaper accepts files in PNM format, which means they might be in
>   .pbm, .pgm, .ppm or .pnm format, which is what is produced by
>   Linux command line scanning tools such as scanimage and scanadf.

The man page clearly states that PNM is the sole input format that
unpaper accepts. Yet this bug report reveals that TIFF files are also
supported:

  https://github.com/unpaper/unpaper/issues/230

The man page does not only omit the TIFF capability, it misleads users
by suggesting conversion tools for TIFF. Why convert if unpaper
handles the format?

The bottom of the man page has:

===<8------------------------------
AUTHOR
       The unpaper authors

COPYRIGHT
       2022, The unpaper Authors
===<8------------------------------

That’s a bit silly. Did that come from upstream?  One author is
apparently Diego Elio Pettenò (https://mastodon.social/@flameeyes). An
anonymous copyright statement is bizarre. It suggests that the
copyright has no defense if someone violates it. It might even be
better to remove the copyright section in the absence of solid
info. If no one claims the copyright, perhaps it should be assigned to
FSF. But that would require a copyright holder to act.

-- System Information:
Debian Release: 12.7
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unpaper depends on:
ii  libavcodec59   7:5.1.6-0+deb12u1
ii  libavformat59  7:5.1.6-0+deb12u1
ii  libavutil57    7:5.1.6-0+deb12u1
ii  libc6          2.36-9+deb12u8

unpaper recommends no packages.

unpaper suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Hi Manny,

> The man page clearly states that PNM is the sole input format that
> unpaper accepts. Yet this bug report reveals that TIFF files are also
> supported:
>
>  https://github.com/unpaper/unpaper/issues/230
>
> The man page does not only omit the TIFF capability, it misleads users
> by suggesting conversion tools for TIFF. Why convert if unpaper
> handles the format?

I fail to see a bug here. The man page documents supported input
formats, and you have discovered that other formats are accepted as
well - undocumented and thereby unsupported.

You might consider filing a bugreport upstream, suggesting them to
document, and thereby promise to support - i.e. not silently remove that
undocumented feature again without warning - acceptance of either tiff
specifically or whatever the image2 plugin for ffmpeg supports (which
is the implementation detail currently causing tiff to also
accidentally be accepted, even if undocumented and thus unsupported).

Closing this as a non-bug,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


--- End Message ---
Reply to: