Success with scrolling capture on a big project.

  • 3
  • Praise
  • Updated 1 year ago

Thanks.  Snagit did it !

It allowed me to complete a job not possible by any other means I could figure out.

There were a few hiccups and flaws in the way it works, and some inefficiencies that made the project take longer than it needed to be, but nonetheless it succeeded.

I am writing to thank the folks at Snagit for a great product, and also to offer a few ideas and improvements suggested during the process.

I am writing a long document (779 pages needed to be captured).  It has been created in MS Word.  It is visually rich, with many detailed fonts and high resolution graphics.  The work needs to be distributed in graphical format rather than text.  That means capturing the image of each page.  To preserve all original detail, graphical output at 600 dpi would be best.  It turns out this is not so trivial an issue.  It might sound straight forward, but various tools to render document files are not generally designed to do this.

Word (and Powerpoint) are actually superlative at their screen rendering.  Their output to screen is as high fidelity to the source material as any software out there, substantially better than most.  If I could capture a screen view from those apps, I would get maximum detail.

However, my monitor is only so many pixels big, and while it is a nice 4K monitor, it is smaller than the desired image size, so a single page cannot be rendered at once, full view, at the desired scale.  Word can zoom in quite far, giving me the desired resolution, but to capture a full page would mean multiple captures then stitching the images together to get the full page.  That is obviously where the idea of Snagit scrolling capture comes in.

There is no easier way.  If I use Word to export to pdf, graphic image quality is degraded.  If I "print" to a pdf printer, output quality is badly degraded.  PDF converters all assume that original media needs to be downscaled to create small or web friendly files.  This harks back to limitations relevant 20 and 30 years ago, not so much today, but nonetheless, PDF for my purposes was trash, and I tried a dozen different takes on this before giving up.  (When I finally got good captures with Snagit, I deleted many GB's of trashy captures and renders that I had spent two weeks doing before that.)  The trials were far more detailed and thorough than this synopsis, but you get the idea.

With Snagit scrolling capture, I got the images I wanted, and I completed my project.

However, the process was still laborious, only 10% of the time spent scrolling and capturing, the easy part, then 90% stripping out the pages per se from background areas, then saving individual pages.

From this experience, I found two small flaws in Snagit, and two big suggestions for how to make big page captures more efficient and automated.

Flaw 1

On pages that are mostly blank, e.g. last page of a chapter where there are a few lines of text at the top then mostly blank space below, Snagit gets confused and drops a lot of the page.  For example, if fully detailed pages come out at 2000 pixels height, the long scroll of several pages captured will all be correct except in the middle where that blank page will be maybe half height, just 1000 pix.  I must then go back and capture that page again, or else manually render the page in a graphics program.  This was annoying and extra work when it happened, but it was not too often.

Flaw 2

I work with fonts that are large and detailed.  They rendered easily and quickly and flawlessly in Windows XP and Win 7, but Win 10 has made mince meat out of font rendering.  I also work with large graphics, thus the need for high res rendering.  The problem with respect to Snagit is that detailed fonts and images can take a long time to render (in Windows 10).  If I am doing a scrolling capture, and I get to a text line that has such a font, there is a time lag or delay in the graphical image getting to the page.  If I keep scrolling before the text is rendered, Snagit gets confused and ends up dropping pieces of a page, splicing pages together, or the out of sync late data gets dropped on the wrong page.  I was able to minimize this by scrolling very slowly, but there were still too many times that I had to recapture the images.  Can this race condition be fixed?

Suggestion 1

Once I captured a large scroll, there could be 20, 40 , or 60 pages on a capture.  I then had to manually separate them and save each as an individual image file.  That could be partially automated by writing scripts in my graphics program, but it was still laborious and time consuming.  It would be nice if Snagit could recognize page breaks and do the page separations automatically.  This could perfectly well be an interactive thing, asking the user up front to define where pages start and stop based on border or boundary colors, or pixel size of a selection or bounding box.  Once Snagit then knows how to recognize page from background, then parsing the page and saving individual files automatically would be immensely useful.

Suggestion 2

As valuable as Snagit was to succeed in my project, there was still a crucial limitation.  I set my Word project to full width of window or screen, then scrolled vertically for a long column of captured pages.  If I wanted to capture pages even larger, the width would have overflowed the sides.  I understand that Snagit could have handled that, and that works just fine for capturing one page at a time.  But for capturing 779 pages, one page at a time is untenable.  Scrolling vertically and capturing 50 pages at a time worked.  Trying to capture extra wide images in a long column of fifty did not work well if at all.  So how can I capture very wide renders, many pages at a time?  Imagine for instance that I want to render at 1000 dpi.  For an 8.5 x 11 inch page, that would be 8,500 x 11,000 pixels.  Word or any app can zoom in and render that detail, but just one screen at a time.  It seems to me that the way to get a monster screen that is 8500x11000 pixels is by creating a virtual monitor or graphics driver, the same way that virtual printers have become popular for creating PDF's and others.

If Snagit could create a virtual monitor or graphics board, the OS would install it like any other monitor.  Then, when running Snagit for such a capture, I could simply tell Word or whatever program to display on Monitor #3.  Word could then render 8500 x 11000 full screen, neither it nor the OS any the wiser that there is no physical monitor or video board.  The render would be written to virtual video memory, from which Snagit snags it.  Snagit might inherently know how to recognize page transitions, or I the user could simply hit "capture" after every time I click "next page".  Individual page files would be saved automatically with auto-incrementing numbers, and most of the tedium and labor of these monster captures would be avoided.

In any case, big Thanks - you got the job done.

Photo of meg99az


  • 2 Posts
  • 0 Reply Likes

Posted 1 year ago

  • 3
Photo of Bill Hoag

Bill Hoag, Employee

  • 73 Posts
  • 9 Reply Likes
Hi! I'm glad Snagit was able to help you out, and will pass along your suggestions. There is one other Snagit feature that might help -- use Word to print to Snagit's printer. This will create a multipage Snagit document with good resolution, probably 200 DPI by default. Before you print, you can drill into the advanced Snagit printer properties and increase the DPI (e.g., 600) for high resolution. Printing large docs at high resolution can take a few minutes, depending on your hardware. Any particular page can by copied from the multipage doc by right-clicking and select Copy.
Photo of meg99az


  • 2 Posts
  • 0 Reply Likes
Thank you very much for the reply.  Since I got Snagit for this purpose, it is new to me, need time to explore all its features.  I will try it.  Appreciate it.