On my mission to "muddying the waters", my deepest sympathy goes out to everyone whose Print Preview was broken by the latest update of DPI. Let that be a lesson for the Nuance developers out there, all of them.

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

No need to buy if all you want to do is try ...

DragonCapture KB Download (Latest)
DragonCapture Homepage

For me, DPI 15.61 is a big improvement over 15.3. The Advanced Scripting engine is far better, so that commands execute much more quickly and reliably. Also, Dragon works much better in Microsoft Outlook than it did in 15.3 (at least for me, I recognize that others have not found has to be the case).

As mentioned earlier, Print Preview was the only mode where the page did not jump around -- before v.15.6.

All other view modes did have the jumping issue already in v.15.3 -- just not as bad as with v.15.6

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

It's kind of interesting that you're saying Print Preview mode *didn't* have the problem. My redisplay-oriented mind wants to believe that's because Print Preview mode probably has a different redisplay algorithm. Surely Dragon sends the same windows messages to Word in all cases, so it seems unlikely that Dragon has the power to make Word jump in some modes and not in others.

I remember that Windows and Word use the printer driver (yes, weird) for calculations involving fonts and things. I can't remember if it was for PDFs or Word or whatever. But I remember thinking what in the world does a printer driver have to do with editing and not printing? I hazard a guess that the "device context" used to render graphical objects is connected to the printer driver somehow. This was years ago, but I remember I had to install a different printer driver before my editing program would work properly. As Robin used to say back in the 1960s, "Holy Complexity, Batman!" :-)

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

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

Yes KK that's true. When searching for solutions regarding the repagination problem in Word, I came across some articles saying that people should try changing their default Windows printer to something else.

 

The printer driver having a say in how text appears on screen is due to the fact, inter alia, that you'll want the best possible WYSIWYG connection between what you see on screen and what gets printed afterwards.

However, changing the default printer did not help with the Dragon Jumping Page issue. I tried different (real and virtual) default printers, but the Jumping Page problem always persisted.

Further, I can now confirm with certainty that DPI version 15.0 was completely free of the Jumping Page problem as shown in my videos, which only started with v.15.3 -- and now has become worse with v.15.6.

No matter what layout view mode Word is set to with v.15.0, there is no jumping of the page whatsoever. Note that this relates to the Jumping Page problem where the text caret is on screen, i.e. in the visible part of the document. The ancient Jumping Cursor problem (aka Word jumping back to the off-screen text caret on the beginning of any noise) is absolutely unchanged in every Dragon version since at least version 9 in 2006.

Looking at the release notes for version 15.3, where Nuance boldly claimed "Jumping cursor issues no longer occur", it can be concluded that in trying to solve this ancient "Jumping Cursor" problem, Nuance not only did not solve it -- but additionally and newly created the "Jumping Page" problem. The latter is even more severe than the former in my view, because it makes Dragon near unusable in every document that is longer than a couple of pages, as can be seen in my above videos.

Anyway, as I tried yesterday (on a different machine), v.15.0 is completely free of the Jumping Page issue, while in v.15.3, all view modes of Word except Page Layout view mode already exhibit the problem.

I will therefore go back to v.15.3 as soon as possible, maybe even back to v.15.0, all the more so since v.15.6 has a couple of additional drawbacks, as described in my first post of this thread. One more disadvantage of v.15.6 for me personally is that it completely has lost the ability to dictate into the DeepL Translator App, although Dragon Bar claims to have Full Text Control in this App.

 

@Nuance Team, whatever has been changed in DgnWord.dll or regarding the interaction between Word and Dragon, respectively, starting from v.15.3 and more so with v.15.6, undo it and go back to the way this worked in v.15.0, because 15.0 was the least broken version of the Microsoft Word dictation function in the history of NaturallySpeaking.

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

David+, you've done an excellent job (with certainty) of identifying the differences between off-screen and on-screen jumping issues and the relative behavior among version 15.0, 15.3, and 15.6. I hope that your work helps the Dragon developers to fix or mitigate the issues.

Matt, > For me, DPI 15.61 is a big improvement over 15.3. The Advanced Scripting engine is far better, so that commands execute much more quickly and reliably.

Matt, does this mean the new WinWrap Basic has been added to 15.6? I think I'm still running the old (Sax?) Basic in 15.3. Getting a whole new Basic engine seems like a good reason to upgrade.

 

Lindsay, > "Even easier is just to start scrolling through Microsoft Word document using the scrollbars with a mouse (not by voice command) with the Dragon microphone switched on and the second you make a noise or issue a voice command Dragon starts the jumping pages…" 

 

I confirm that this behavior also exists on my machine. Once I realized that you meant issue a mouse click by voice, the jump occurred. You're completely right - how do they expect users to scroll down by voice and make a mouse click?

 

It's the same issue that I labelled "my special circumstance" in one of my other postings. I was scrolling down by voice on a second document and eventually wanted to click by voice in it. But since the jumps were so awful, I stopped scrolling by voice. Instead, I did "move down 20 lines" by voice and thereby moved the insertion point as I scrolled. 

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

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

Yes, that's my understanding. For some reason, I can't find that in the technote, but I'm sure I read it when 15.6 came out.

This is a great reason for obtaining Ver. 15.61. Nuance finally retired SAX scripting with Ver. 15.3. DMPE 4.3 and Dragon 15.6 utilize WinWrap Basic; the same scripting engine we use in KnowBrainer 2017 (w/2020 AI Commands)

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

Forum Mission Statement
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ext 1

Absolutely.  I find my Advanced Scripting commands are far more reliable.  In particular, The SendKeys instruction works perfectly.  In fact, I've replaced all my SendSystemKeys with SendKeys.

I'd be interested to know (in order to inform Nuance Tech Support accordingly) whether anybody does not see any page jumping issue with Dragon v15.3 or v15.6, when carrying out the following steps:

 

1. Open a file with multiple pages, preferably more than ten pages, in any version of Microsoft Word (for example the attached file "Lorem ipsum dolor sit amet.docx")

2. Scroll down approximately halfway through the document

3. Place the text cursor (i.e. the blinking text caret | ) anywhere in the visible part of the document by mouse click

4. Dictate a short utterance or make any kind of noise into the microphone, e.g. by blowing -- the jumping occurs here

5. Scroll the document a couple of lines up or down using the scroll bars or the mouse wheel and repeat steps 3 through 5.

 

Thanks

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

I tried your experiment. I'm using Word 2019 in Page Layout and in Draft modes.

The moment I begin dictating - before Dragon has recognized the utterance as a command, as text, or as noise - the page sometimes "jumps" one (or more) lines. It appears that the position of the insertion point shifts to be closer to the centre of the screen.

The jump doesn't always happen, especially if I haven't been scrolling. The effect happens more regularly, at least for me, when the insertion point is near the top or bottom edge of the window.

After I use the mouse wheel to scroll, the jump occurs every time (or almost every time) at the start of the next utterance.

The far-from-ideal workaround: minimize scrolling by moving the insertion point rather than by repositioning the mouse pointer:

insert before XXX
insert after XXX

move [up or down] [1 - 999] [lines or paragraphs]
move [left or right] [1 - 999] [characters or words or sentence or paragraphs]

When NOT navigating by voice, the effect is minimized when I use keyboard commands rather than mouse actions:

Left and right arrow (move by character)
Up and down arrow (move by line)

Ctrl + left and right arrow (move by word)
Ctrl + up and down arrow (move by paragraph)

Home (go to start of line)
End (go to end of line)

Ctrl + Home (go to start of document)
Ctrl + End (go to end of document)

Page Up (go up one screen)
Page Down (go down one screen)

etc.

Thank you for trying it on your machine Alan.

 

 

This is exactly identical to what I'm seeing.

 

Thanks in advance for results from other forum members.

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

I tested this and the jumping cursor occurred. I guess I don't usually experience it, because I usually navigate by moving the text cursor to a particular spot, rather than using the mouse or mouse commands.

Thank you Matt.

Looking forward to further results from @everybody. 

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

A friendly *bump* along with a reminder to everyone reading this to take the test as described in the first post of this thread. 

 

Nuance Support keeps claiming that my computer setup is to blame for the problem, and I'd like to prove them otherwise, in order to hopefully make Nuance recognize that the jumping page problem (which is different from the ancient jumping cursor problem) is a general, new bug in NaturallySpeaking that has started with v.15.3.

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

I've tried to reproduce the jumping cursor problem and was only partially successful using a DLG 15.60.200.015 with Word 365 (Version 2012/Build 13530.20376).

I had started Dragon (mike off), opened the Dolor ipsum document, scrolled down to page 17, put the cursor after some word, turned on the microphone and dictated a few words.

 

Yes, the visible part of the document did change (so it looked like jumping), but the cursor remained where I set it and my words were written exactly where they should be.

 

Repeating the test I found that - at least on my machine - the "jumping cursor" rather seems to be unneccessary scrolling of the visible document area.

 

I don't know about Word in detail, but with Windows RichTextBoxes there's a method ScrollToCaret which brings the caret (text cursor) into view. It doesn't change the cursor position but adjusts scrolling inside the view port to make the caret visible.

Obviously, this method should only perform scrolling if the caret is not visible at the moment, but with Word exactly this seems to happen.

 

In the beginning, my caret was in the middle of the screen, but after dictation the viewport would either scroll down so that the caret was in the third line from the top or it would scroll up so that the caret was in the fifth-or-so but last line.

 

When the caret indeed is off-screen, then it's reasonable to scroll it into view so the user can see what Dragon recognized. Since I'm pretty sure Nuance didn't reinvent the wheel and that there is some method in Word to bring the caret into view as well, I think they're just always calling this method before making a change to the document (or even before starting a recognition). If this is the case, then Microsoft is to blame for unneccessarily scrolling the viewport when the cursor is already visible.

 

Does anyone else get these results?

 

hth,

mav

 

--Edited for typo

Thank you for posting your results Mav.

 

 

Correct, this is exactly what everyone else so far has been seeing, and this is the jumping page problem (which is new starting with Dragon v.15.3)

 

 

Yes, this is correct behaviour and every editor does this.

 

However, only Word (and only starting with Dragon v.15.3) scrolls up and/or down on every utterance or noise even when the caret is on screen, as can be seen in the videos I made.

 

As an interim result, I note that no one yet seems to have been able to confirm that they are not experiencing this problem.

 

Please start here for making your test run.

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

I downloaded and opened your "Lauren Ipsen" (sic.) Word document, allowed editing, used the mouse to drag the scrollbar down about halfway, used the mouse to place the editing cursor (caret) somewhere near the middle left-hand page (there were two pages side-by-side and about 70% displayed vertically and 100% horizontally). I blew into my mic - the page jumped 2 or 3 lines. I blew into my mic again and the page did not jump. I used the scroll wheel on my mouse to change the visibly displayed text. Again, I blew into my mic and the page jumped; inserting some text at that time did not cause the page to jump again. I tried various combinations of where I put the editing cursor and the jumping page results were 100% repeatable: after any scrolling (using the mouse to manipulate the scrollbar, using the mouse wheel to scroll, saying "page up/down", using the "page up/down" keys on my keyboard) the next time Dragon started to try to recognize a sound (blowing into the mic is a good choice, but I also tried coughing and dictating actual easily recognizable text) the page jumped a few lines (where a few lines could be any amount between 2 and 10 - you can tell because the mouse pointer and the editing cursor are no longer in sync vertically).

I am using Dragon® Professional Individual 15.3 (reverted from 15.6, never tried 15.61) and Word via Office 365 subscription installed locally on my hard drive and I am NOT signed in to my Office account. Windows 10 Professional, version 10.0.17134.

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

-Edgar
DPI 15.3, 64-bit Windows 10 Pro, OpenOffice & Office 365, Norton Security, Shure X2U XLR to USB mic adapter with Audio Technica DB135 vocal mic, Asus X299-Deluxe Prime, Intel Core i9-7940X (14 core, 4.3 GHz overclocked to 4.9 GHz), G.SKILL TridentZ Series 64GB (4 x 16GB) DDR4 3333 (PC4 26600) F4-3333C16Q-64GTZ, NVIDIA GIGABYTE GeForce GTX 1060 GV-N1060G1 GAMING-6GD REV 2.0 6GB graphics card with 3 1920x1080 monitors

Thank you Edgar. Your test result is 100% identical to what I am seeing and what is shown in this video of my playlist regarding the jumping page issue.

 

The interim result, i.e. nobody having reported that they are not seeing this problem, is still valid.

 

--
Start here for making your test run.

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

Sennheiser MKH Mic
Visual & Acoustic Feedback + Automatic Mic Control

Hi David,

 

I would confirm all your findings including your test. Every single installation of Word and Outlook has this issue old and new symptoms of jumping pages. People who cannot reproduce it are either not following the test procedure correctly or don't understand the issue. Nuance are blinkered when it comes to this problem but I have passed on your videos to my contacts anyway, not for the first time. Fortunately my work involves very little editing of large word documents.

 

Good luck,

Lindsay

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