GUI goes blank - error occurred in libfreetype
Brought to you by:
ra28145
Menu
▾
▴
#55 GUI goes blank - error occurred in libfreetype
gscan2pdf v2.13.2
Debian GNU/Linux "bookworm" (testing)
libfreetype6 v2.12.1
perl v5.36.0-7
After some time scanning (sometimes even on the first document after a restart), various GUI elements go blank and the TTY spits out the following errors.
This error was supposedly fixed in v2.8.0 of gscan2pdf - is this a regression, user-misconfiguration, system-misconfiguration, ...?
The only workaround is to close the application and start it again, which can be rather inconvenient when scanning in larger documents.
(net.sourceforge.gscan2pdf:528832): Gtk-WARNING **: 21:54:09.818: drawing failure for widget 'GtkCheckButton': error occurred in libfreetype
(net.sourceforge.gscan2pdf:528832): Gtk-WARNING **: 21:54:09.818: drawing failure for widget 'GtkBox': error occurred in libfreetype
(net.sourceforge.gscan2pdf:528832): Gtk-WARNING **: 21:54:09.818: drawing failure for widget 'GtkBox': error occurred in libfreetype
(net.sourceforge.gscan2pdf:528832): Gtk-WARNING **: 21:54:09.818: drawing failure for widget 'GtkBox': error occurred in libfreetype
(net.sourceforge.gscan2pdf:528832): Gtk-WARNING **: 21:54:09.818: drawing failure for widget 'GtkMessageDialog': error occurred in libfreetype
So I did some more digging, and it appears that this error might be related to specific versions of libfreetype and/or the saved settings in my user account. I will try deleting caches etc and see if I can repro. But might be good to keep it in the knowledgebase regardless.
I'm astounded that this hasn't been reported before, as I get this reasonably frequently when I have a large amount of OCR output, but not reproducibly so, so I haven't been able to nail down the problem or fix it.
Ah, interesting that it's maybe only related to OCR... and yes, I scan all my documents with OCR enabled, even though mostly it fails due to a lot of my documents being in japanese these days..
I did reset various settings etc, but still the only way to manage to finally get the document I had trouble with scanned in was by driving the UI "blind".
As you say, it's difficult to reproduce reliably in general (except with that one document), but the fact that other software packages log the same error it seems the common cause is libfreetype and not gscan2pdf itself. Since I also noticed it usually happening "after a while" or only with larger documents, perhaps it's a memory leak or a buffer overflow somewhere.
Still, I wonder if it would be possible to trap the error inside gscan2pdf, and try to render the UI elements anyway. Perhaps using a fall-back font or resetting libfreetype (sorry, I don't know the API), etc.
gscan2pdf doesn't call libfreetype directly, but uses GooCanvas to draw the text. So presumably the bug is somewhere between libfreetype and GooCanvas.