Bug 299517 - Skanlite should support scan to pdf.
Summary: Skanlite should support scan to pdf.
Status: RESOLVED FIXED
Alias: None
Product: Skanlite
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: VHI wishlist
Target Milestone: ---
Assignee: Kåre Särs
URL:
Keywords: usability
: 347738 347739 371156 412130 439452 446612 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-06 18:34 UTC by ThorbjørnTux
Modified: 2023-04-27 16:22 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In: 21.12


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ThorbjørnTux 2012-05-06 18:34:04 UTC
There is really not much to say. I don't want to send anybody an 15.000 x 10.000 image - but I also don't want to send them an image with poor quality. I want to send them a pdf - and not do a lot of work to get there.


Reproducible: Always

Actual Results:  
-

Expected Results:  
-

-
Comment 1 Kåre Särs 2012-05-06 19:34:44 UTC
The easiest PDF generator actually just embeds an image into the PDF god or bad quality. The good thing with PDF is that you would have multiple page support. A totally new UI for multi-page scanning would have to be created.  Unfortunately _my_ itch for creating multipage UI is not high enough just yet... I would love to help and support anybody that wants to do it tho...
Comment 2 Mauro Molinari 2014-05-18 13:55:23 UTC
I really like Skanlite, but the lack of PDF (as well as multipage support) is a real limit :-(
I hope one day it will be enhanced to support this.
Comment 3 Florian Fainelli 2014-10-22 04:22:42 UTC
I agreee that is a critically missing feature, any ideas how hard it would be to support export to PDF?
Comment 4 Kåre Särs 2014-10-22 04:41:37 UTC
It is not hard to export _one_ image to one PDF, but multipage PDF would require some handling of the images before saving to the final PDF. It is not very hard, it just needs to be done...
Comment 5 Christoph Feck 2015-05-16 18:04:03 UTC
*** Bug 347739 has been marked as a duplicate of this bug. ***
Comment 6 King_DuckZ 2015-09-02 17:04:11 UTC
Any hope to have this feature? I see this feature request has been open for over 3 years and I think it's a really useful functionality for many users who don't know how to use other programs to make a pdf or who simply have to scan many documents.
Comment 7 Kevin Funk 2015-12-20 15:09:48 UTC
I'd really like to have this feature as well. It's *the* show-stopper for skanlite.

I'm using gscan2pdf to date for scanning. In case someone's interesting in implementing PDF support in skanlite, I strongly suggest looking at the gscan2pdf source (perl script) for inspiration how to generate a PDF (it's using imagemagick to achieve this, afaiu).

Code: http://sourceforge.net/p/gscan2pdf/code/ci/master/tree/bin/gscan2pdf
Comment 8 Kåre Särs 2015-12-20 20:10:36 UTC
I think the UI needs are quite different for PDF (multi-page document) scanning so it does not fit the current Skanlite UI, but I finally got enough inspiration to start something (a sponsoring offer pushed me a bit too ;)

https://quickgit.kde.org/?p=scratch%2Fsars%2Fskanpage.git

The raw start is here, but it is not ready for prime time yet. It needs Ki18n translations and some page size/printing features before we can try a first release. It needs threaded image saving and threaded PDF saving. 

To work properly Skanpage needs some fixes from libksane master (some of it could maybe be back-ported to 15.12)

It totally lacks the OCR feature at the moment but I don't think it should be a big problem to get some output through tesseract
Comment 9 Ian Whyman (thev00d00) 2016-09-20 20:22:10 UTC
So it's 2016 now, any change?
Comment 10 Christoph Feck 2016-10-19 03:31:33 UTC
*** Bug 371156 has been marked as a duplicate of this bug. ***
Comment 11 rockonthemoonfm 2017-01-24 12:52:14 UTC
yes, please, bring skanlite in feature parity with simple-scan
(feature request dated 2012)
Comment 12 Clemens 2017-02-12 10:03:32 UTC
I would love this feature too. This is the only reason I don't use Skanlite at all.
Comment 13 Jerrod Frost 2017-04-10 04:59:03 UTC
*** Bug 347738 has been marked as a duplicate of this bug. ***
Comment 14 what 2017-04-20 21:17:03 UTC
Another plus one for this much needed feature. Happy to test if required.
Comment 15 Pascal d'Hermilly 2017-07-04 19:47:50 UTC
is it wontfix?
Comment 16 Adrien Cordonnier 2018-05-14 10:53:12 UTC
Interestingly, Skanlite development page [1] lists open bug with max 40 votes (=2 voters) but not this bug report with 292 votes from 18 voters. As strange as it can be, changing its status to UNCONFIRMED would actually makes it more visible.

Skanlite git repo does not have a branch with Kåre Särs' changes to implement multipage scans in December 2015 [2]. Hopefully, we will be able to find it back.

Once Skanlite has multi-image support, they can be saved as a multi-page PDF with QtPdfWriter [3].

[1] https://www.kde.org/applications/graphics/skanlite/development
[2] https://bugs.kde.org/show_bug.cgi?id=299517#c8
[3] http://doc.qt.io/qt-5/qpdfwriter.html#details
Comment 17 Nate Graham 2018-05-14 21:38:20 UTC
Kåre, did anything ever come of your branch to add this feature?
Comment 18 Kåre Särs 2018-05-15 06:14:03 UTC
Well it is actually not a branch but a dedicated multi-page document scanning application. It compiles and you can create multi-page PDFs. You can rearrange/add/remove pages, but I'm not happy with the user-interface for acquiring the scans and the scanner-settings. I have not been able to test it extensively either since my Canon scanner does not work very well with sane...

The main UI is done with QML, but the scanning options provided by libksane are widget based. 

To make it work nicely, libksane should provide a model with the options maybe even a QAbstractItemModel for the "unknown" options and a set of ready made widgets and QML components to set the properties and display previews.

My itch to continue is unfortunately weak. I only scan documents maybe once every two years...
Comment 19 Adrien Cordonnier 2018-05-15 12:43:43 UTC
Kåre, is your code available online?
Comment 20 Kåre Särs 2018-05-16 07:45:38 UTC
Seems the old scratch repository addresses have changed.... Here is the current scratch repository.

https://cgit.kde.org/scratch/sars/skanpage.git/
Comment 21 Adrien Cordonnier 2018-05-16 12:35:43 UTC
If any one is interested, Skanpage fulfils exactly what is requested in this bug report. It works great. Despite Kåre's comment, I even think that it has the best UI among Skanlite, Kooka and Skanpage.

I was able to compile Skanpage on Debian 9 (stretch, current stable) after installing qtdeclarative5-dev and qt4-dev-tools (gcc and other lib being already installed). 

    git clone https://cgit.kde.org/scratch/sars/skanpage.git/
    cd skanpage/src
    cmake -DCMAKE_INSTALL_PREFIX=/opt/kde -DCMAKE_BUILD_TYPE=Debug .
    make
    sudo make install

It runs with:

    /opt/kde/bin/skanpage


The only missing feature in Skanpage is the ability to save in png or jpeg (or other image file formats) as you can only save as PDF.

There are a few quirks:
 * quality profile only changes resolution (not color mode),
 * "Best Quality"-profile is 600 dpi even if the scanner can do better,
 * changes to quality profiles are not saved for the next page,
 * saving does not use the default "Save as" dialog,
 * saving dialog asks for page settings (page size and print resolution) instead of reusing the scan settings for each page.
Comment 22 Michael D 2019-09-01 20:13:18 UTC
The backend for multipage scanning to pdf is there: e.g. the "convert" command from ImageMagick will easily merge multiple images files (e.g. jpeg) into a single pdf. Wouldn't this be "relatively simple" to implement? When feed scanning, for instance, the images could be placed in a tmp folder and then "convert" run on them to merge them into a pdf which is output to the user-selected folder.

On macOS, when selecting pdf as save format, there is an option to merge all scans into a single file, which is quite convenient.
Comment 23 Valter Mura 2019-09-12 16:52:45 UTC
This should be a very important feature, especially in a working environments (scanning in PDF and sending to other users).

Exactly as XSane does.
Comment 24 Kåre Särs 2019-11-26 11:34:02 UTC
*** Bug 412130 has been marked as a duplicate of this bug. ***
Comment 25 Olivier BELLEUX 2020-05-06 16:43:38 UTC
I totally agree: a scanning software must offer this archiving format; what would be good would also be to offer to choose the rights on the pdf produced (i.e. printing, comments, annotations etc) as well as to personalize the metadata.

Another format, alternative to pdf, but interesting for long-term archiving, is djvu (dejavu); on the other hand I do not know if the support of such a format is complee to implement.
Comment 26 Monkiki 2021-02-03 17:39:24 UTC
Still waiting for this feature :(
Comment 27 Justin Zobel 2021-03-13 01:01:33 UTC
Skanpage does this nicely. It's still in development but is available for eager testers here:  https://invent.kde.org/astippich/skanpage
Comment 28 Kåre Särs 2021-07-03 19:15:12 UTC
*** Bug 439452 has been marked as a duplicate of this bug. ***
Comment 29 Alexander Stippich 2021-08-08 13:17:57 UTC
In case more people want to try Skanpage, please use this link
https://invent.kde.org/utilities/skanpage
as the repo has been moved
Comment 30 John 2021-09-15 08:53:25 UTC
(In reply to Alexander Stippich from comment #29)
> In case more people want to try Skanpage, please use this link
> https://invent.kde.org/utilities/skanpage
> as the repo has been moved

I really really like Skanpage, please go on with doing a great (and necessary) job.
Comment 31 Edmund Laugasson 2021-09-22 21:43:17 UTC
Simple Scan is free and open-source software, it would be easy to look its source code (https://gitlab.gnome.org/GNOME/simple-scan) and copy its functionalities, like scan to PDF (including multipage PDF) into Skanlite with appropriate adaption.
Comment 32 Olivier BELLEUX 2021-09-23 15:19:35 UTC
(In reply to Edmund Laugasson from comment #31)
> Simple Scan is free and open-source software, it would be easy to look its
> source code (https://gitlab.gnome.org/GNOME/simple-scan) and copy its
> functionalities, like scan to PDF (including multipage PDF) into Skanlite
> with appropriate adaption.

I agree: if "Gnome" can do it with simple-scan, "KDE" should be able to do it with skanlite too... 

More generally, the desktop environment war shows us a good example of its harmful character: it would be better to play a winning game for all by developing applications together according to the toyota principles: 
- everything that is not visible (sane etc...) is common, 
- everything that is visible is specific (Qt or GTK).

Thus it would be possible to develop "one application" and its two graphical interfaces for our respective desktop environments.

Less dispersion, less waste of resources and more functionality for the users!
Comment 33 Nate Graham 2021-09-23 15:28:29 UTC
That's more or less how it actually works. :) The part that's the same (SANE) is common, and the part you can see (the user interface) is made with different tools: Qt and GTK and so on.What I think you're trying to say though is that Qt and GTK shouldn't be separate; we should have a single UI toolkit or set of low-level application development tools that are common to everybody, and each environment would just write a custom UI on top of it according to their HIG.

And yeah, that would be great. But Qt and GTK both *do* exist. And Enlightenment, and Flutter, and a bunch of others. We can't go back in time and delete them all except for one. For better or worse, we are stuck in a world with multiple GUI toolkits. And this means that you can't just grab the code from an app that's written in another GUI toolkit; it doesn't work like that. To use your car metaphor, it would be like trying to put the engine from a Volkswagen into a Honda. By the time you made it work, it would have been easier, cheaper and work better to just get a new engine for the Honda! That's the situation here with this feature; how SimpleScan implements the feature is not applicable for Skanlite because of all the other technical differences between them.

Fortunately, a new scanning app called SkanPage is under heavy development. It already has this feature and I expect it will eventually replace Skanlite over time. It uses the same backend SANE library but it's written with a more modern user interface component set which makes it easier to work on and extend in the future.
Comment 34 Olivier BELLEUX 2021-09-23 18:39:09 UTC
(In reply to Nate Graham from comment #33)
> That's more or less how it actually works. :) The part that's the same
> (SANE) is common, and the part you can see (the user interface) is made with
> different tools: Qt and GTK and so on.What I think you're trying to say
> though is that Qt and GTK shouldn't be separate; we should have a single UI
> toolkit or set of low-level application development tools that are common to
> everybody, and each environment would just write a custom UI on top of it
> according to their HIG.
> 
> And yeah, that would be great. But Qt and GTK both *do* exist. And
> Enlightenment, and Flutter, and a bunch of others. We can't go back in time
> and delete them all except for one. For better or worse, we are stuck in a
> world with multiple GUI toolkits. And this means that you can't just grab
> the code from an app that's written in another GUI toolkit; it doesn't work
> like that. To use your car metaphor, it would be like trying to put the
> engine from a Volkswagen into a Honda. By the time you made it work, it
> would have been easier, cheaper and work better to just get a new engine for
> the Honda! That's the situation here with this feature; how SimpleScan
> implements the feature is not applicable for Skanlite because of all the
> other technical differences between them.
> 
> Fortunately, a new scanning app called SkanPage is under heavy development.
> It already has this feature and I expect it will eventually replace Skanlite
> over time. It uses the same backend SANE library but it's written with a
> more modern user interface component set which makes it easier to work on
> and extend in the future.

Dear Nate, 

This is indeed more or less my idea: to do, as much as possible, in common on commonly used tools, in order to allow developers to concentrate on the specificities of their DE.

I find that each environment has its advantages and disadvantages; for me, KDE's track record outweighs Gnome or other DEs; but KDE can't be suitable for everyone, and that's good, otherwise Linux wouldn't exist.

On the other hand, reducing "what you can't see" to SANE seems to me to be reductive: it seems to me that some of the code is sandwiched between the stuff (in Qt or in GTK) that you click on and SANE.
Skanlite as well as Simple-scan are far from offering as many features as Xsane and its Windows 95 style interface.

The interface to SANE could be "terminal" for all or in GTK or Qt etc... while offering the same functionality.

This principle seems to me to be extensible to other cases: in instant messaging, protocols (irc, xmpp, matrix, telegram) and GUIs are not lacking (konversation, polari, kopete, pidgin, neochat...): wouldn't it be simpler to use only "libpurple" and its plugins and to graft a GUI to it either in GTK (Pidgin) or in Qt/qml (Kukupa which means "pigeon" in Maori)? That way the focus would be more on the code that you don't see but does almost everything rather than the code that you see but doesn't do much.
  
I read your blog posts every weekend and I have never read a critical, or hurtful, word for another DE from you. Unfortunately for many, developing software is reinventing the wheel, over and over again, to claim that the other guy can't code.

Instead of favouring the quantity of bad or average software, it seems to me that free software should favour transversal collaborations to provide less numerous but better quality software. With the amount of work provided for several competing software we could have a very good one with two Guis adapted to our DEs
Comment 35 Nate Graham 2021-09-23 19:50:19 UTC
It's not that it's a bad idea, but I'm not sure how it would work beyond what we're currently doing. Developers already use common libraries as much as possible if only to be lazy. :) But what's left after that is where most of the work actually goes, because producing a nice app is *so* much more than just adding a thin UI wrapper on top of library features. The UI is, like, most of the work. :)
Comment 36 Edmund Laugasson 2021-09-24 23:51:43 UTC
> I agree: if "Gnome" can do it with simple-scan, "KDE" should be able to do it with skanlite too... 

Not at all. Just simple-scan is currently nowadays program, what we can use. It has very few dependencies, therefore could be used also with KDE. It could be any other FLOSS program, if it does scan to PDF, including multipage PDF.

It is just usual need for everydays life to use PDF-files rather than image files, especially in case of multiple pages. It would be impractical to use multiple image files instead of one PDF-file. 

Also using PDF gives appropriate page format for printing. Having just image file makes it harder to print. Also harder to understand, how image fits onto A4 or whatever format would be used.
Comment 37 Kåre Särs 2021-09-25 21:48:39 UTC
Skanlite is optimized for photo scanning. Multi-page document scanning needs a totally different UI. I'm happy to say that we are now getting such UI with Skanpage:
https://invent.kde.org/utilities/skanpage

I have long been waiting for somebody to pick up the (multi page) document scanning part and now it seems we have that :)
Comment 38 Nate Graham 2021-09-25 22:16:00 UTC
If there are no plans to add this feature to Skanlite, should we close the feature request and tell people to use Skanpage instead?
Comment 39 Kåre Särs 2021-09-26 05:41:09 UTC
As soon as we get a Skanpage release I would do that yes.
Comment 40 Mauro Molinari 2021-09-26 07:17:24 UTC
Will Skanpage also support image scanning with at least the same features of Skanlite? If so, I was wondering whether Skanlite will still have a reason for existing... If not, I was wondering whether having two different applications to perform two such similar tasks would be beneficial for users...
Comment 41 Kåre Särs 2021-09-26 17:53:30 UTC
When scanning photos it is important to be able to select and adjust scan area and to have some kind of automatic naming of the scanned images. Both these feature examples are almost totally irrelevant when it comes to document scanning. With multi-page document scanning you want to be able to see and often organize page order before saving. That is a UI feature that is missing from Skanlite...
Comment 42 Nate Graham 2021-09-26 18:34:35 UTC
Ultimately I'd like a single app that does both. I think it's pretty cumbersome to have two apps that to the same task (scanning) but target different use cases for that task (images vs multi-page documents). I don't think it would be impossible to come up with a UI that lets a single app do both, even if it was something as crude as asking the user what they're scanning (images vs documents) and changing the UI accordingly.
Comment 43 Edmund Laugasson 2021-09-26 23:18:49 UTC
Yes - single KDE scanning app would be very much appreciated!
Comment 44 Bug Janitor Service 2021-10-10 08:50:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/skanlite/-/merge_requests/21
Comment 45 Alexander Stippich 2021-10-10 08:53:06 UTC
Before everyone gets too excited about the merge request: this does add single image PDF export to Skanlite, but does not support multi-page. This will only be available in Skanpage.
Comment 46 Alexander Stippich 2021-10-13 15:25:33 UTC
Git commit 73fb83e903ffa68fd9a551dde2cab307e4f9e908 by Alexander Stippich.
Committed on 13/10/2021 at 15:25.
Pushed by astippich into branch 'master'.

add single image PDF support

M  +34   -5    src/SkanliteImageSaver.cpp
M  +4    -0    src/skanlite.cpp

https://invent.kde.org/graphics/skanlite/commit/73fb83e903ffa68fd9a551dde2cab307e4f9e908
Comment 47 Kåre Särs 2021-12-07 15:27:30 UTC
*** Bug 446612 has been marked as a duplicate of this bug. ***