Starting scan creates error
gscan2pdf.spec still lists perl-Gtk2-Ex-Simple-List as a dependency
I've almost finished a complete rewrite. It's probably going to be called scantpaper. Needless to say, the aim to be better in lots of ways, including error handling. I've just got to nail the last couple of bugs and write a few more tests.
gscan2pdf hangs on File Save
I've almost finished a complete rewrite. It's probably going to be called scantpaper. Needless to say, the aim to be better in lots of ways, including error handling. I've just got to nail the last couple of bug and write a few more tests.
I played with the many options long enough and got it working. I do not know what the problem was. Along the process, it hung in other places as well. In my opinion, the system should never hang. It should timeout and give a relevant error message. Although having this support page is valuable and appreciated, it should be unnecessary in at least this situation. There is no bug in gscan2pdf that I am aware of; it just lacks error messages so that the user can debug the situation in most cases. Thanks...
Thanks for the report. Please start gscan2pdf from the command line with the --log=log option, reproduce the error, and post the log file.
gscan2pdf hangs on File Save
This bug has now hit Debian sid. I'll have to skip the test in sid to avoid FTBFS. Your bug report is now seeing some attention.
300x300 without a unit should normally default to dots (pixels) per inch. And living in a land that uses SI units, I would be also happy for it to default to pixels per cm. But the new behaviour ends up being 72 ppi, which makes far less sense than anything else.
Okay, so I filed a bug against ImageMagick (I hope to have gotten this right). But I'm not quite convinced here. So yes, identify doesn't report a resolution anymore, but isn't this actually correct without a unit? I mean, what does 300x300 tell without a unit? Edit: Okay, the bug report leading to the breaking commit explains this for agnostic people like me: From the JFIF specification: units: 1 byte 0 = no units, X and Y specify the pixel aspect ratio 1 = X and Y are dots per inch 2 = X and Y...
Okay, so I filed a bug against ImageMagick (I hope to have gotten this right). But I'm not quite convinced here. So yes, identify doesn't report a resolution anymore, but isn't this actually correct without a unit? I mean, what does 300x300 tell without a unit?
If you compare the output of identify, whereas in previous versions, the resolution metadata was still present in the image, plus the undefined units, in this new version, the resolution is completely missing. I'm calling this a bug in Imagemagick.
$ magick -version Version: ImageMagick 7.1.2-9 Q16-HDRI x86_64 5cff2fc4f:20251128 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI OpenMP(4.5) Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype heic jng jp2 jpeg jxl lcms lqr openexr pangocairo png raqm raw rsvg tiff webp x xml zlib zstd Compiler: gcc (14.3) $ magick -units Undefined -density 300 xc:white test.jpg $ identify -verbose test.jpg...
Thanks for the report. Debian testing still has 7.1.2-8, so I can't reproduce this. Please try the following with 7.1.2-9 and attach the jpg to the report: magick -units Undefined -density 300 xc:white test.jpg What does the following then return? identify -verbose test.jpg
Addendum: I'm trying to build gscan2pdf-2.13.5 with perl-5.40.0 on NixOS 25.11.
Addendum: I'm trying to build gscan2pdf-2.13.5 with perl-5.40 on NixOS 25.11.
Test-suite fails with ImageMagick >=7.1.2-9
t/241_threshold.t fails since imagemagick 7.1.2-5
Gscan2pdf has been updated to 2.13.5 on nixpkgs. Tests are passing and everything is working as expected. Thank you!
Tests fail with ImageMagick 7.1.1-33
Set locale to C for tests that compare textual messages
This issue was resolved in gscan2pdf-2.13.5.
This issue was resolved in gscan2pdf-2.13.5.
For those who are stuck to LibTIFF 4.6.0, here is a patch rebased to gscan2pdf-2.13.5.
OK. But it is Okular that is inserting the CR characters, not gscan2pdf. The difference is the formatting. When Writer created the PDF, it created a single text box. Okular can see that it is all one text box, and gives you the text you expect This was lost when converting to JPG. OCR created a box per word, in order to get the word positions correct. OCR does not give much hint of the fonts used, so these must be guessed. It would be possible to embed the text in the PDF differently, but then the...
Thanks for your patch. I apologise for not getting to it. I wasn't intending to make another gscan2pdf release, and hoped that I would be able to make a solid scantpaper release sooner.
Make t/3722_user_defined.t compatible with ImageMagick 7.1.1-33
Superseded by 2.13.5.
Replace tiff2pdf with convert in tests
tiff2pdf is back in LibTIFF 4.7.0.
:construction_worker: post-release commit
:bookmark: bumped version to 2.13.5
:globe_with_meridians: updated list of translators
:globe_with_meridians: updated Ukrainian translation
:globe_with_meridians: updated German translation
:globe_with_meridians: updated French translation
:globe_with_meridians: updated Swedish translation
:globe_with_meridians: updated Russian translation
:globe_with_meridians: + Lao translation
:sparkles: support imagemagick v7
:sparkles: support imagemagick v7
:white_check_mark: fix segfaults on some systems caused by initialising Gtk before threads
:art: improve number formatting
:bug: don't try to create spinbuttons with no step
Hello, to be clearer I think it would be better to make small test files. So here they are. I wrote a small text with Writer and then exported it to pdf: Test_gscan2pdf.pdf Then, I converted it to jpg file (with The Gimp): Test_gscan2pdf.jpg Then, imported into gscan2pdf, did OCR, then exported again to pdf: Pascal06_Test_gscan2pdf.odt_2025-11-05.pdf Then, open the original pdf (Test_gscan2pdf.pdf ), select first paragraph and past here: “A Hare one day ridiculed the short feet and slow pace of the...
I'm travelling for a week, and the machine I'm writing this from is not yet set up for releases. I'll try and get a release out ASAP, but that might not be for a week.
I confirm that all tests are now passing with this latest patch. Is a new release planned soon, or should we go ahead and apply this patch ourselves in NixOS/nixpkgs?
Thanks! I've now built, scanned and saved a document successfully. (including running tests t/169_import_scan.t and t/3722_user_defined.t, which were previously disabled on NixOS). And it's on ImageMagick 7.1.2-8.
Hello, IMHO, I think the problem doesn't come from Okular. Following my given example, if you look into the gscan2pdf OCR recognition tab: https://2plz.fr/lutim/gallery#TggvwUqP/DKILVETY.png Almost each word are "separated" so that gives a line feed after them. It gives this text if you copy / past from the generated pdf: Conformément à l’article 12 du Règlement du Fonds, le Fonds a procédé à sa deuxième distribution. Ce deuxième remboursement de capital s'élève à un montant de 5.74 € par part, soit...
Hello, IMHO, I think the problem doesn't come from Okular. Following my given example, if you look into the gscan2pdf OCR recognition tab: https://2plz.fr/lutim/gallery#TggvwUqP/DKILVETY.png Each word are "separated" so that gives a line feed after each word. It is definitely not the same thing as the raw text output
Thanks! I've now built, scanned and saved a document successfully. (including running tests t/169_import_scan.t and t/3722_user_defined.t, which were previously disabled on NixOS). And on ImageMagick 7.1.2-8.
This updated patch fixes the gscan2pdf startup message issue
Great! This builds without error. It still has the failure when running: Warning: missing packages Save image and Save as PDF both require imagemagick even though the log finds imagemagick: INFO - Found Image::Magick 7.1.2 INFO - Found unpaper v7.0.0 INFO - convert --version INFO - Spawned PID 45574 INFO - Found imagemagick6 7.1.2-7 INFO - magick --version INFO - Spawned PID 45575 INFO - Found imagemagick7 7.1.2-7
OK. I misunderstood. But it is going to be difficult for me to influence how Okular formats text it places into the clipboard.
I think that these last two failures might be subtle differences in imagemagick v6 & v7 again. I'm, travelling though so can't test my assumption. If someone could test this updated patch. I would be grateful.
I'm able to reproduce this result. To me, it looks a bit like the NixOS ImageMagick package has issues: Running the 51_process_chain.t magick command directly: $ magick 'label:The quick brown fox' -alpha Off -depth 1 -colorspace Gray -family 'DejaVu Sans' -pointsize 12 -density 300 -rotate 90 test.pnm magick: unable to read font `(null)' @ error/annotate.c/RenderFreetype/1745. The same command succeeds on Ubuntu 24.04. FYI: $ fc-list : family FiraCode Nerd Font,FiraCode Nerd Font Ret TeX Gyre Pagella...
Thank you! I confirm that the latest patch solves the issue with t/241_threshold.t. I've just noticed that I had t/3722_user_defined.t disabled. This test contains one last call to the old "convert" command. I also have two other failures left in: - t/51_process_chain.t - t/53_process_chain.t Those two seem to be due to an OCR precision issue. I've updated Tesseract from 3.05.02 to 5.5.0, but the failure persists. Could this be due to a difference in default font? We're using the open-licenced Liberation...
Thanks, but it's not a solution for me. The best would be that when I select all the text in a pdf and then past in an other document, it would keep the same number of line feed...
gscan2pdf add CR after each word using Tesseract
Glad you could find a solution
Fix hang running t/11271_save_pdf2_g4.t
:art: changes due to perltidy v20250105
:sparkles: support imagemagick v7
Hello Jeffrey, thanks a lot for your reply. No worry :) Fatality I just scanned a bunch of documents now and I tested to "save as text". Indeed, the job is great compared to the same document in pdf. Very weird...
:white_check_mark: another attempt to fix failing test 1111 under riscv64
:white_check_mark: skip test 380 as it consistently times-out on riscv64
:bookmark: release 2.13.4-2
:white_check_mark: fix failing test 1111 under riscv64
Fix hang running t/11271_save_pdf2_g4.t
:art: changes due to perltidy v20250105
:sparkles: support imagemagick v7
:globe_with_meridians: update to Hungarian translation
Post-release commit
This now works for me.
I take it back. Must have been caching. With 7.1.2.7 from Debian sid, I can now reproduce the bug. I'll work on a fix now.
I've successfully tested this last patch with imagemagick 7.1.2.7 from Debian sid.
I've successfully tested this last patch with imagemagick 7.1.2.3 from Debian sid.
And another try.
Another try.
The test from the original post still fails. The new patch also introduces new failures. Build and test log attached.
Thanks for the feedback. I missed a load of convert calls. Please try this new patch instead.
Thank you for the patch. Unfortunately, the same test failure persists with this patch and imagemagick 7.1.2-5. Full build and test log is attached.
As imagemagick 7.1.2-5 is not yet in Debian testing, I can't easily reproduce this; so please test this patch, which I hope will fix it.
t/241_threshold.t fails since imagemagick 7.1.2-5
Apologies for the lack of response. gscan2pdf also offers a "Save as text" option. Does that do a better job?
Hello, nobody here ?
Pass PNG and TIFF images by a file name to PDF::Builder
Add created files to Recents list
gscan2pdf add CR after each word using Tesseract
one screenshot shows when the djvu is saved and doesn't appear anything the second secrenshot produces a pdf corrupted that can not be opened with evince (visor de documentos), but it can be opened with okular, here is the pdf file this happened with garuda (arch)
tiff file
Thanks for the report. Please attach a TIFF file with which I can reproduce the problem.
Tiff files sometimes cant be saved as djvu nor pdf (corrupted last one) on Garuda
I'm having a similar problem, maybe I should start a new issue? I'll explain a bit, I'm using a Fujitsu S1300 scanner with document feeder and duplex capability. I have been scanning the whole morning switching between manual double and single sided. ( the option was visible on "Page Options" tab ) After a break with the computer in standby and the scanner off, I no longer see the "Single sided"/"Double sided" switches. The reason I prefer manual mode is because on auto the quality is worse ( vertical...
I have chased this down. In new versions of Ubuntu (at least 2.4.0 and up) Firefox is installed as a Snap with permissions that prohibit rendering local html files. Unfortunately Firefox does not drop an exit code, it just displays an error message. There is some discussion about fixing this. I don't know if this will happen. A workaround is to uninstall Firefox Snap and reinstall from .deb. Another possibility would be to convert the file to an .md file and okular will open it Okular is very likely...