Need Testers for NoStaples: A PyGtk Scan-to-PDF Application

[staringmonkey]

I actually had fixed this on my site, but now the deb's are being hosted at GitHub so I unfortunately I don't have control over the MIME type.

[Vadi]

Starts great now without any scanners.

Some interface feedback though:

- View tab in preferences should have the combo boxes aligned by width (see Window Layout in gnome hig)

- You can click on the add/remove blacklist buttons without having anything selected. It doesn't hurt, but makes no sense either - the buttons should be disabled

- NoStaples toolbar doesn't obey my system preference - it uses "small icons, no text" while my default is "big icons and text". It's understandable though why would you want it different from the system default, but offer an option in preferences for changing it (and follow system by default - you can't decide what is better for a user than he can)

- will let you know more when I plug in the scanner...

[staringmonkey]

Great feedback as usual, Vadi. I will put all these items on my TODO list. Let me know how it goes when you get your scanner up and running. I will be keeping my fingers crossed.

[Olav]

Hello again!

Version 0.4 is now available for your testing pleasure.

Hello again as well, good to see you are still motivated.

First I should say that I am now able to start the program and make some scans with it. So this is indeed progress

I have not tested very thoroughly, yet I did find another crash situation. It happens whenever I choose to scan in "Lineart" mode. Colour scans work with no problem. I have attached a screen shot and a log file.

Again I must emphasise that you should not lose any sleep over this if it is a failure that is unique to my prehistoric scanner. I can't imagine anyone else still using this dinosaur, and in a few days I will also receive the new Epson scanner that I have ordered.

Some other remarks:

• In the Options menu, under resolution, I find numbers like 3276800, 6882180, 10485760, 14090240, et cetera. These probably have some technical meaning, but no "real world" meaning that is obvious to me. I would expect to see DPI values (like 75x75, 100x100, 300x300 and so on).
  
• After saving a document it is cleared from the application. If you realise after saving that you wanted to add another page, you have to start scanning again from page one. I think you can see how this could become quite annoying, quite quickly.
  
• Being able to set the page size is important. I see you have already marked it as TODO which is good. In most parts of the world we do not use "Letter" at all, only A4 and its family. So if you care about world wide popularity, you should perhaps try to make this a bit of a priority

In the spirit of full disclosure I should mention that I will almost certainly stick with gscan2pdf for my personal scanning. It has all the features I need and has been unproblematic for me. Only "unpaper" can't always be trusted. But as far as I can see it is a problem in that program, not in gscan2pdf itself.

I will certainly keep an eye on your progress though, because I just like it when people are ambitious and doing projects like these!

In fact, I was just thinking of a little project of my own, where people would be able to store PDFs in a database for easy search and retrieval. Something like a *very* lightweight EDMS. Still dreaming though, and unfortunately I suck at Python.

[Olav]

I have attached a screen shot and a log file.

Well, I thought I did. So here:

[staringmonkey]

Olav, I am very glad to hear from you again! And I am happy to have more specific answers to each of your concerns/bugs this time around.

I have not tested very thoroughly, yet I did find another crash situation. It happens whenever I choose to scan in "Lineart" mode. Colour scans work with no problem. I have attached a screen shot and a log file.

I am amazed that everyone tests the Lineart functionality. Amazingly, I have already had this reported in three separate places. Its Ticket #23.

[*] In the Options menu, under resolution, I find numbers like 3276800, 6882180, 10485760, 14090240, et cetera. These probably have some technical meaning, but no "real world" meaning that is obvious to me. I would expect to see DPI values (like 75x75, 100x100, 300x300 and so on).

It looks your "old dinosaur" specifies its resolution in some unit other than DPI. (I'm guessing bits.) I was aware this would be an issue for some devices, but I did not actually have a ticket for it. I do now: #37.

[*] After saving a document it is cleared from the application. If you realise after saving that you wanted to add another page, you have to start scanning again from page one. I think you can see how this could become quite annoying, quite quickly.

Yes, eventually I would like to include an "import PDF" option, as well as an "insert from image file" option, but both of those are a version or two away as I continue to establish core functionality. Still, I'm glad you brought it up so I could document it. Ticket #38.

[*] Being able to set the page size is important. I see you have already marked it as TODO which is good. In most parts of the world we do not use "Letter" at all, only A4 and its family. So if you care about world wide popularity, you should perhaps try to make this a bit of a priority

It is! This is actually Priority #1 for the 0.5 release milestone. The real fun bit is going to be setting it up so that it outputs a PDF whose resolution exactly matches the scan resolution. Its a tricky business getting those two things to line up, but it absolutely will be the focus of 0.5, now that I have some of the most glaring device support issues resolved.

You may also be interested to note that Priority #2 for the next release is translation/localization support, which I know you had expressed interest in.

In the spirit of full disclosure I should mention that I will almost certainly stick with gscan2pdf for my personal scanning. It has all the features I need and has been unproblematic for me. Only "unpaper" can't always be trusted. But as far as I can see it is a problem in that program, not in gscan2pdf itself.

I certainly can't begrudge you that, and that makes me appreciate your testing all the more. My goal with this application is not necessarily to displace gscan2pdf, but to offer a similar application with a more refined/constrained/accommodating design. Hopefully, I am making headway in that direction. (Also see following paragraph for more long-term thinking.)

In fact, I was just thinking of a little project of my own, where people would be able to store PDFs in a database for easy search and retrieval. Something like a *very* lightweight EDMS. Still dreaming though, and unfortunately I suck at Python.

It is funny that you should mention that, as my long-term goal is to have a companion application that does *exactly* this. This is why I have already put so much effort into PDF metadata support. As I use this in my home office I am very carefully tagging all my documents so that some day when NoStaples is fairly well established I can move on to *drum roll* "NoStacks", which I intend to be a lightweight document management system. Of course, this is pretty far in the future, but I don't think its too far-fetched. I already have an array of sketches and notes (including ideas for integrating the two applications). If you would be interested in hacking on something like that or just discussing what you would like to see in such an application, I would be more than happy to receive the input.

Cheers!
Bouvard

[Olav]

Hi, thanks for making all the tickets.

As promised, my response:

I am amazed that everyone tests the Lineart functionality.

It shouldn't have to surprise you. "Line art" seems to be best in terms of speed, storage efficiency, printing and OCR (if that ever becomes viable on Linux...). I scan almost everything in line art, 300 DPI. Except photos of course.

It looks your "old dinosaur" specifies its resolution in some unit other than DPI. (I'm guessing bits.) I was aware this would be an issue for some devices,

Now I am surprised. I would have expected Sane, as the layer between the scanner and the application, to solve such problems and provide a uniform interface to talk to the scanner. Oh well, what do I know.

Yes, eventually I would like to include an "import PDF" option, as well as an "insert from image file" option,

That would be good, gscan2pdf does it too...

but both of those are a version or two away as I continue to establish core functionality.

If you don't just clear the document immediately after scanning, you can perhaps even skip three versions before you implement your import function. Also, I really think it should be a user's *choice* whether they want to continue, or start a new document. Even better if it were a configurable preference!



About paper sizes...

The real fun bit is going to be setting it up so that it outputs a PDF whose resolution exactly matches the scan resolution. Its a tricky business getting those two things to line up,

Sorry if I am stating what is already obvious to you. But I was under the impression that PDF doesn't really have resolution, or if it does, that it doesn't have much to do with the scanning resolution. After all, there can be pages scanned with different resolutions (but the same paper size) in a single PDF file. Scanned pages can also be upscaled or downscaled to fit the PDF paper size.

Yes, I could see how this is going to be fun

You may also be interested to note that Priority #2 for the next release is translation/localization support, which I know you had expressed interest in.

I may perhaps contribute a translation then, as I have done for several other open source programs.

It is funny that you should mention that, as my long-term goal is to have a companion application that does *exactly* this. This is why I have already put so much effort into PDF metadata support. As I use this in my home office I am very carefully tagging all my documents so that some day when NoStaples is fairly well established I can move on to *drum roll* "NoStacks", which I intend to be a lightweight document management system. Of course, this is pretty far in the future, but I don't think its too far-fetched. I already have an array of sketches and notes (including ideas for integrating the two applications). If you would be interested in hacking on something like that or just discussing what you would like to see in such an application, I would be more than happy to receive the input.

I have to think about it some more. My current thinking is it needs to be a web application, so you can access your documents wherever you are. My PHP skills are slightly less crappy than my Python skills, so I may end up hacking something together. Not tomorrow though, but... later

[staringmonkey]

Hey again Olav,

It shouldn't have to surprise you. "Line art" seems to be best in terms of speed, storage efficiency, printing and OCR (if that ever becomes viable on Linux...). I scan almost everything in line art, 300 DPI. Except photos of course.

I suppose that's true, especially since you can apply post-process smoothing to the lineart image when you view it. Although I tend to prefer the fidelity of grayscale, especially since disc space is a essentially non-factor. Still, I'm glad to have it working now, especially if others are actively using it.

Now I am surprised. I would have expected Sane, as the layer between the scanner and the application, to solve such problems and provide a uniform interface to talk to the scanner. Oh well, what do I know.

SANE enumerates six or seven valid units of measure. Included in these are "bit", "dpi", "percent", etc. I will be unifying these for NoStaples, but its going to be a non-trivial effort, as some of them are not literally translatable (percent to dpi, for instance, requires another variable).

If you don't just clear the document immediately after scanning, you can perhaps even skip three versions before you implement your import function. Also, I really think it should be a user's *choice* whether they want to continue, or start a new document. Even better if it were a configurable preference!

Now I'm a bit confused... it should only be clearing the document after scanning if you click "Quick Save"... if you just click "Close" in the scan progress window then you should have an opportunity to manipulate the pages, reorder them, scan additional pages, etc. Are you referring to clearing the pages immediately after saving? I suppose that would make sense, although I might need to rethink some other design decisions.

Sorry if I am stating what is already obvious to you. But I was under the impression that PDF doesn't really have resolution, or if it does, that it doesn't have much to do with the scanning resolution. After all, there can be pages scanned with different resolutions (but the same paper size) in a single PDF file. Scanned pages can also be upscaled or downscaled to fit the PDF paper size.

Well, it does and it doesn't. PDF has a concept of "page size", which is important to set so that "single click" printing of a PDF document works as expected. The size of the page is the size of a "physical" copy, which is to say, independent of DPI. The scanned image can, of course, be scaled to fit the target PDF page size, providing that the aspect ratio of the image can be maintained. The path of least resistance is to specify up-front that the device scans at a size which precisely matches the PDF that you want to output. This then dove-tails into the issue of how resolutions are specified. I think you will see that it can be a little be tricky to match input and output resolution when the device is specifying its resolution in "bits". Still, I'm sure I can get there.

I may perhaps contribute a translation then, as I have done for several other open source programs.

That would be great, I've had another offer to do an Arabic translation. I would be very grateful to have those when the support is in place.

I have to think about it some more. My current thinking is it needs to be a web application, so you can access your documents wherever you are. My PHP skills are slightly less crappy than my Python skills, so I may end up hacking something together. Not tomorrow though, but... later

I agree from a purely utilitarian perspective that having it be a web-based app is a no-brainer, but I do not have much interest in creating that sort of application. My experience with web-based document systems is that they tend to be lowest-common-denominator systems with very poor user interfaces. I much prefer having a highly efficient desktop experience, even if it does constrain where I can use it. Also, I think the web-constraints are less relevant in the days of remote-mountable filesystems. Perhaps, I just don't want to touch PHP.

[Olav]

Are you referring to clearing the pages immediately after saving?

Yes, saving. Sorry for the confusion.

[RainKap]

Hello again!

Version 0.4 is now available for your testing pleasure. This release should fix all outstanding issues that have been discussed in this thread. (Though not all outstanding issues, by any means.)

If anyone has a minute to test the new release and file tickets (or just respond here) regarding any issues that they find that would be hugely appreciated.

This version has a debugging script built in that should help me troubleshoot problems with particular devices, so if you your device fails, please attach the output of `nostaples --debugdevices` to your bug report.

As always the release is available here:
http://www.etlafins.com/nostaples

(Or: via direct-link to the Intrepid deb.)

Bug-tracking is here:
http://bouvard.lighthouseapp.com/pro...aples/overview

And the source is here:
http://github.com/bouvard/nostaples/tree/master

Thank you for all your help
Bouvard

Hi there - I read about NoStaples in the latest issue of Linux Format. I'm running Ubuntu Hardy Heron (AMD64 version) on my dual Opteron desktop, with an HP Scanjet 3530c attached via a USB port. I downloaded and installed the .deb for version 0.4.0 of NoStaples and started it, but it didn't see the scanner.

scanimage --list-devices gave me:
device `hp3500:libusb:001:003' is a Hewlett-Packard ScanJet 3500 scanner

XSane sees it and scans OK; I can also run the HP-supplied ******* software in a ******* VM running in VirtualBox. Any suggestions please?

Output of 'nostaples --debugdevices' follows.

Device 1

Name: hp3500:libusb:001:003
Vendor: Hewlett-Packard
Model: ScanJet 3500
Type: scanner

Option 1

Name: filler
Title: Scan Mode Group
Desc: Scan Mode Group
Type: 5
Unit: 0
Size: 4
Cap: 0
Constraint Type: 0
Constraint: None
**Failed to get current value for option.**

Option 2

Name: tl-y
Title: Top-left y
Desc: Top-left y position of scan area.
Type: 2
Unit: 3
Size: 4
Cap: 0
Constraint Type: 1
Constraint: (0, 19575603, 1387)
Value: 0

Option 3

Name: tl-x
Title: Top-left x
Desc: Top-left x position of scan area.
Type: 2
Unit: 3
Size: 4
Cap: 0
Constraint Type: 1
Constraint: (0, 14149222, 1387)
Value: 0

Option 4

Name: br-y
Title: Bottom-right y
Desc: Bottom-right y position of scan area.
Type: 2
Unit: 3
Size: 4
Cap: 0
Constraint Type: 1
Constraint: (0, 19575603, 1387)
Value: 19559219

Option 5

Name: br-x
Title: Bottom-right x
Desc: Bottom-right x position of scan area.
Type: 2
Unit: 3
Size: 4
Cap: 0
Constraint Type: 1
Constraint: (0, 14149222, 1387)
Value: 14149222

Option 6

Name: resolution
Title: Scan resolution
Desc: Sets the resolution of the scanned image.
Type: 1
Unit: 4
Size: 4
Cap: 0
Constraint Type: 2
Constraint: [50, 75, 100, 150, 200, 300, 400, 600]
Value: 200

Ian Park