KnowBrainer Speech Recognition
Decrease font size
Increase font size
Topic Title: Microsoft Word Jumping Page Problem in DPI/DPG 15.61 & DMPE 4.3.1
Topic Summary: Unfortunately Unresolved
Created On: 08/25/2021 11:41 AM
Status: Post and Reply
Linear : Threading : Single : Branch
Keyword
 08/25/2021 11:41 AM
User is offline View Users Profile Print this message

Author Icon
Lunis Orcutt
Top-Tier Member

Posts: 39370
Joined: 10/01/2006

Typically, when you are dictating into any application; not just Microsoft Word and Outlook, you will experience something we call "Jumping Page" or page shutter (bounce down and up) when you dictate. The cursor doesn't move but the process is painful because it can be difficult to find the cursor and the constant jumping is aggravating. This problem typically occurs when you are working on a document that cannot be fully viewed on your monitor. Many of you may think that this problem is exclusive to Microsoft Word but this might be because Microsoft Word is the only application you are dictating longer documents in. We ran into the same problem on this forum utilizing Microsoft Edge, with some of our suffering long-winded answers.

 

The solution may be as simple as maximizing your window. Please give this a shot and post back with your results. 



-------------------------

Change "No" to "Know" w/KnowBrainer 2020
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ex 1



 08/25/2021 12:43 PM
User is offline View Users Profile Print this message


Alan Cantor
Top-Tier Member

Posts: 4185
Joined: 12/08/2007

I work almost exclusively with maximized windows, and I see the problem regularly.
 08/25/2021 02:14 PM
User is offline View Users Profile Print this message

Author Icon
dilligence
Top-Tier Member

Posts: 1432
Joined: 08/16/2010

I solely use maximized windows. Microsoft Word so far, is the only application I'm having the jumping page problem in (don't know about Outlook, haven't really tried it extensively yet)....



-------------------------


Auto Box© Demo now available



 08/26/2021 03:43 AM
User is offline View Users Profile Print this message

Author Icon
Mav
Top-Tier Member

Posts: 440
Joined: 10/02/2008

Thanks for pointing out exactly that it's not a jumping _cursor_ problem but a jumping _page_ problem - those two have been mixed many times!

 

I think it is an effect of the underlying edit control itself and the way Dragon communicates with the editor.

 

Each edit control has a document/text, a cursor position (or selection range) and a viewport rectangle showing a part of the document.

 

Most of those controls I know have a way of programmatically moving the viewport so that the cursor is visible (which does not always have to be the case - put the cursor at the end and then scroll up your multi page document, for example).

 

Usually, this function is being invoked whenever you input text at the cursor position - the user wants to see what has been entered. There might be other cases where moving the viewport is being invoked, but it all revolves around putting the viewport around the current cursor position.

 

Because of the way Dragon communicates with edit controls, everything is done in 2 steps:

 

1. Replace a given character range with a given text (this is used to add dictated text into the document). This usually is done by first selecting the character range to replace and then to replace the currently selected text with the new text.

 

2. Set the new cursor position or selection (this is used to position the cursor behind the last dictated word or to perform selection by voice, in which case #1 is an operation not changing the contents of the document).

 

Since Dragon sometimes tells the editor to replace 0 characters at character index 0 in the document with an empty string (effectively not changing anything, but nevertheless changing the selection temporarily), this could lead to a case where the cursor is put to the beginning of the document and the viewport is adjusted so that it shows the new cursor position.

 

Immediately afterwards, according to step #2, the new cursor position at the end of the document is applied and the viewport is adjusted again, leading to a visible "page jump".

 

Because setting the viewport to the cursor position does not have any effect if the cursor currently is already visible, the final viewport will probably not be identical to the one you were seeing before the page jump, hence the noticable flicker and searching for the cursor after the jump.

 

The problem is that identifying the cases where Dragon tells the editor to perform such a null-operation is far from easy.

From my experience, it mostly happens when Dragon picks up some noise.

The recognition itself fails, but the editor is told to replace 0 characters at position 0 with an empty string and afterwards to set the selection to the previous location, triggering a repositioning of the viewport nevertheless.

 

While this doesn't fix the problem, I think it could help to understand what's going on behind the sheets.

 

If my assumptions are correct, Nuance could be able to fix this problem by letting their Word compatibility module identify such a null-operation case and then instead of performing this replace-nothing-with-nothing simply doing nothing.

But trying to have them fix anything (even trying to make them understand the problem) is a fight against windmills.

 

hth,

mav

 08/26/2021 11:39 AM
User is offline View Users Profile Print this message

Author Icon
kkkwj
Top-Tier Member

Posts: 831
Joined: 11/05/2015

Hi Mav, it seems to me your analysis is generally correct except for the "replace 0 characters at position 0" part, which requires a jump to the top of the document. I never see that big of a jump (but maybe you do). The jumps I see (usually by noise, as you say) generate repositioning movements to bring the cursor closer to the center of the viewport. The redisplay algorithms I worked with long ago usually defined a range of lines around the viewport center point. If the cursor was within the range, the smart redisplay operations would leave everything alone because a redisplay would not produce a better visual result. Apparently, the Word redisplay is not that smart yet. :-(

-------------------------

Win10/x64, AMD Ryzen 7 3700X, 64GB RAM, Dragon 15.3, SP 6 PRO, SpeechStart, Office 365, KB 2017, Dragon Capture, Samson Meteor USB Desk Mic, Klim and JUKSTG earbuds with microphones, 3 BenQ 2560x1440 monitors, Microsoft Sculpt Keyboard and fat mouse

 08/26/2021 04:03 PM
User is offline View Users Profile Print this message

Author Icon
Lunis Orcutt
Top-Tier Member

Posts: 39370
Joined: 10/01/2006

The Jumping Page problem we are referring is not about accidental noise or moving the cursor to the top of page. Our Jumping Page problem occurs when we are attempting to dictate into a document that is over a page. From that point on, every time we dictate, Dragon correctly drops our dictation into the cursor address but then rapidly moves the page up or down 2 to 3 inches and then moves the page backup. The cursor hasn't moved from the middle or end of the document but the page shuttering is annoying. Unfortunately, maximizing the document doesn't work after all. It worked once but didn't work today so our solution is a no go.

Looks like we'll have to wait for DPI 15.7; hopefully released in time for Windows 11



-------------------------

Change "No" to "Know" w/KnowBrainer 2020
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ex 1



 08/27/2021 02:14 AM
User is offline View Users Profile Print this message

Author Icon
Mav
Top-Tier Member

Posts: 440
Joined: 10/02/2008

I've tried simulating the jumping page in Word using a simple VBA macro by executing those steps the Dragon Word Addin most likely is performing as well:

  1. Select the text range to change
  2. Replace this range's text with the new (dictated) text
  3. Set the new selection
  4. Scroll the current selection into view

The page jump does not occur in this situation (even if I let Word insert 0 characters at position 0) because replacing a text range off-screen does not automatically trigger the repositioning of the viewport.

But I've noticed something else more in line with what Lunis wrote.

When your document is being displayed in a way that the cursor is at the botton end of the window/viewport, then typing a new letter does not trigger a repositioning of the viewport.

Telling word to scroll the current selection into view (even though it actually is visible), on the other hand, will scroll up the viewport!

So that's a case where the behavior differs between typing manually and using Dragon.

 

I've just successfully recreated the effect:

Open a new word document.

Enter "=rand(10,10)" in the very first line and press return; you'll get 10 paragraphs with 10 sentences each, which should be enough to fill about 3 pages.

Now scroll the document vertically so that the cursor at the end of the text is at the very bottom of the viewport, the bottom of the cursor perhaps even 1-2 pixels off-screen (hidden by the status line). 

If you type in this situation, the viewport doesn't move.

But if you turn on the microphone and start an utterance, the page will jump up a little (although not as much as when you tell Word to scroll the current selection into view).

 

Still not 100% the behavior Lunis described but I got a feeling we're getting closer.

 

hth,

mav

 

 

 

Statistics
32177 users are registered to the KnowBrainer Speech Recognition forum.
There are currently 0 users logged in.
The most users ever online was 12124 on 09/09/2020 at 04:59 AM.
There are currently 436 guests browsing this forum, which makes a total of 436 users using this forum.

FuseTalk Standard Edition v4.0 - © 1999-2021 FuseTalk™ Inc. All rights reserved.