Menu

#382 gscan2pdf up/down left/right scroll bar on laptop or small screen

v1.0_(example)
open
nobody
None
5
2022-01-19
2021-02-23
MooCan
No

Hello,

I'm using ubuntu and debian with Mate Desktop and screen resolution is 1366x768 with 13inch screen.
I don't see and never have an up/down scroll bar and left/right scroll bar in the main window.

After a scan in the image output I can use the "pan tool" to move from up to down and from left to right.
But in OCR output the "pan tool" do not have any effect.

For example,
1 - To change data in the OCR output which is at the bottom or outside the viewable area of the scan you need to click on next and pass each text field one by one or select the last field that is viewable and then click on the next button many times to get the field that I need to change. If you start with a minimal view where the entire document is visible, you cannot see what is written.

2- As it is enlarged automatically at the first next button click (or when you click on a text field on the OCR output), after 10 text field I don't know where am I on the document. As I can't move directly the OCR output as in the Image output from left to right or up to down I need to go back to Image output, reselect pan tool and/or zoom out to see where am I on the document and then continue OCR verification from next field. I need to do this each time that I'm loosing where am I on document or to check what the document is showing.

In the "split horizontally" view it is a little more easier but to move document from right/left or up/down you need to reselect pan tool each time, zoom out and then continue OCR checking.

I joined some screencapture in zip file with tabbed view, split horizontailly and vertically view.

Is there any GTK "tweak" that can be set to enforce scroll bar to be displayed ?

Regards,
Fabien

1 Attachments

Discussion

  • Jeffrey Ratcliffe

    At the moment, the pan/rectangular selection/combined tool buttons only change the behaviour of the image viewer. The OCR viewer only uses the combined tool - i.e. moving the mouse with the middle button pressed, you can pan the view, and the scroll wheel zooms the viewer.

    The two views are tied, so that panning/zooming the image view should modify the OCR view in the same way.

    I'll look at making the pan/rectangular selection/combined tool buttons also affect the OCR viewer.

     
  • MooCan

    MooCan - 2021-02-27

    Hello,

    Thank you so much for the tip about "i.e. moving the mouse with the middle button pressed, you can pan the view" .... this is a button that I never use.
    I only use the mouse wheel for scrolling and Ctrl + mouse wheel for zoom in/out like in many applications.

    About the scroll bar is it normal that there is no scroll bar or is it related to the desktop I am using because I know some applictions sometimes needed a modified CSS for displaying hidden UI settings when possible.

    And about the "auto zoom" when I click on an OCR output text field to select it, is that the normal way or desktop-related ? Because when I click on an OCR Output text field to select it, which is for example an email address or more than 15 characters (there are not that many words of such length) it's ok , you don't need to zoom out much, but if the text field is just with a few characters like "de", ":", "N°", "of", "in" I'm seeing only this flied on the screen.

    See what you can do, but already the advice you give me on using the mouse wheel to click and then move the view is already a great improvement for my use.

    Regards

     
  • Jeffrey Ratcliffe

    I didn't want to add a scrollbar, as it would reduce still further the amount of screen available for the document, although Gtk3 has improved things a great deal by automatically hiding scrollbars when they are not being moved.

    About the auto-zoom for the OCR output - this is my workflow - having scanned the document and run it through tesseract, I switch to "view/split vertically" and then using "sort by confidence", I click on the left arrow "go to least confident text", which then auto zooms to that word, which I can compare to the original and correct, if necessary. Correcting it sets the confidence to 100%, and so clicking "go to least confident text" takes me to a new word, and so on. When I am fairly sure I have corrected everything, I look at the whole page again, and then save.

    At the moment, I have hard-coded the amount of screen around the word when auto-zooming. It zooms to fit the word to the screen, and then zooms out one step. Would it be useful for you to be able to adjust this to automatically zoom out further?

     
  • FeRD

    FeRD - 2022-01-19

    If I can be permitted to butt in and respond to the most recent question: Yes, in fact I was about to open a new report suggesting something along those lines.

    The core issue here is that usually, identifying a single word isn't actually a process that's performed by merely looking at just that one word in isolation. We tend to make identifications contextually, and so we recognize words not only by their letter forms, but just as importantly, by reading the adjacent words before and after the "target".

    Say I have a document that contains the sentence "I have an apple." But unlike whatever font you're reading this in, probably, my document is printed in a font that uses bulbous, closed letter 'a' forms. (Think Monaco, Futura, or even *gag* Comic Sans.) Looking at the third word of that sentence in isolation, it'd be really easy to misread it as "on" due to the similarity between a lowercase 'a' and a lowercase 'o' in those fonts. With only one other letter for context and two extremely common words to choose from, either is equally plausible. But in context, meaning within the wider context of the entire sentence... well, there's just no chance I read it as, "I have on apple."

    Now, you can argue that using the vertical split view and having the original text image alongside the OCR view alleviates that. While that's true to a certain extent, it doesn't completely solve the problem because:

    1. The image view zooms in tandem with the OCR view, so it doesn't actually provide any additional context for the identification.
    2. Speaking as a left-handed user (but by no means, speaking for all left-handed users — only myself, and anyone who voices their agreement), the two views feel backwards, and would be more comfortable to work with if they swapped sides.
    3. While it's true that having the split view open makes it easier to identify OCR words by looking at the source image, having additional context would make it easier to identify them without needing to look at the image. Some users may prefer to work that way.

    My preferred solution to this, again speaking only for myself, would be to have a mode available in some fashion — preference, checkable menu item, toolbar button, #DONTCARE — that tells gscan2pdf, "Autopan the OCR view, but keep it zoomed to whatever level I choose. Modify the current position only along the x and y axes, never the z." That way, once I've got the text zoomed to a comfortable reading level with sufficient context, I know that won't be interfered with.

     

Log in to post a comment.

Auth0 Logo