John Y suggested having the emulator software provide an export option that outputs a vectorized graphical format.
But now you've got me brainstorming. The emulator software itself could, in principle, provide an export option that outputs a vectorized graphical format. < <
He also asked if any emulators currently output vectorized images.
(Do any do this already?) < <
My experience with 5250 emulators is limited to CA, ACS and Mocha so I can't answer his question but vectorized images is key to Snagit's performance.
Since 2010 I've been using Snagit to capture documentation images from Mocha (primarily), CA and ACS with outstanding results. The images captured by Snagit are vectorized; and are legible even severely reduced within the Snagit Editor.
To give you some idea as to how small the images I use are: when providing software specs to programmers I use Word with 2 columns in landscape mode on 8.5" x 11" paper - narration on the left, mocked up screens on the right. I use the same format for user documentation. In short: I'm reducing 132 character screens down to about 4.5" wide. In some case, even smaller so I can stack images and insert arrows and callouts.
The other reason I favor Snagit is convenience. All my post-capture work - cropping, extending, combining, hiding, highlighting, etc. - is fully supported by Snagit.
I looked at Green Space briefly yesterday. Now I have to figure out how to remove it from my laptop - their uninstall doesn't work.
ps. About my laptop: 4K main screen and a 1920 auxiliary monitor. Most of the image capturing is done on the 4K screen.
Roy Luce
Direct – 847-910-0884
833-937-8368
Email – lwl@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of John Yeung
Sent: Wednesday, May 24, 2023 10:09 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Getting quality screen shots: update
On Wed, May 24, 2023 at 8:54 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:
Results: I used their "Capture" tool to grab an image from a 26" 1920x1050 monitor. The default output was an 8 MB BMP file. Even scaled to 100% on the monitor, the PDF didn't render well.
BMPs are AFAIK uncompressed and thus generally not a good idea. TIFF has alway been the format of choice for pixel-based pictures in the publishing world. There are (lossless) compressed and uncompressed variants.
It was still a useful exercise to see if the software handled BMP any better than other formats. But the more OP talked about it, the more confident I became that the software should do just fine with more sophisticated formats.
John Yeung also was reporting differences in font rendering on Windows when comparing iACS to other software. I'm using Windows only for playing games, so I can't tell what the visible differences are. It might be related to Java not using the OS font rendering capabilities, thus possibly no or different antialiasing strategies which might result in your perception about "CA looking better than iACS" after importing screen shots into a PDF.
I think the issue is not PDF per se. The images were scaled down to a ridiculously small and low-fidelity version in both the Word and PDF output. At that size, the results would not be good in any format whatsoever.
There is no "might be related to Java". ACS absolutely does not use OS rendering capabilities. It does (now) have (its own) antialiasing. To my recollection, CA never had antialiasing. I know I loved the bitmapped IBM3270 font in CA at a particular size. Most if not all of the viable fonts for use with CA had fixed, bitmapped sizes. If one of the sizes was comfortable for you, then it looked very crisp.
For quite a while, I could not stand ACS. I could not find any combination of fonts and settings that was remotely acceptable to my eyes. ACS eventually got better "enough" and more fonts became available. I am now reasonably satisfied with ACS using JetBrains Mono NL Medium 16, which seems specifically designed for Java rendering (but also works well in other contexts).
The black background on those screen shots will make your toner vendor happy if you print. I'm going to put my maintenance fee to work and see if there's an option in Capture that remaps/switches the black background and white lettering.
Depending on the way of antialiasing, this might also be a source of additional quality degradation, especially when color comes into play. Imagine what happens to pixels "in between" white and black on character edges when you just flip 100% black and 100% white pixels. "Inverting" the whole picture might be a better way.
I'm sure inversion, in whatever scheme you can think of, is included in OP's "remaps/switches" terminology. And it's also irrelevant.
Either the software has a way to make suitably attractive and legible dark letters on light background, or it doesn't. OP's only recourse if it doesn't is to use some other software that does, whether it's another emulator or image processing software.
Interesting finding: there is a *distinct* difference between the Mochasoft and iACS (at least using Andale Mono) screen renderings. While the iACS app does a lot more than just 5250 emulation and is a terrific product, *Mochasoft renders a much crisper image in both window and full-screen mode*. The iACS letters are bigger; the spacing between the lines in Mochasoft is larger, and the letters are slightly smaller.
That's for the same reason ACS looks different (and generally worse) than CA.
I don't know Mocha on Windows, but on my Mac, the the window size influences the appearance. Font size, line spacing as well as character spacing can be influenced this way. I've found a sweet spot for my window dimensions for looking good on 24×80 and not much smaller characters and similar spacing in 27×132. Drawback is that on 24×80 I have considerable "unused" window space left and right of the actual content.
Since legibility is the most critical in 132-column mode, I always optimize for that. ACS and CA both have settings that allow the font to stay the same size when switching modes, and I always make use of that. In CA, that meant the window would grow or shrink automatically depending on the mode. In ACS, I optimize the window size for 132-column mode and leave it there. The extra empty space in 80-column mode is a very, very tiny price to pay for sane font behavior.
If the "pseudo-graphical" look iACS provides for some on-screen elements (window borders, etc.) isn't mandatory, it might feasible to just copy the text instead of a bunch of pixels. The next needs proper formatting, though. But the "bad look" issue from pixelated JPEG artifacts will no longer be an issue.
The results of truly copying "just the text" would be horrible, without inordinate post-processing to put in the underlines and such, which are a vital element for a person reading the document to connect what's in the docs with what they see on a live screen. And some things might not even work at all as true text, like the cursor, rule line, and column separators. I don't see it as a viable option at all.
But now you've got me brainstorming. The emulator software itself could, in principle, provide an export option that outputs a vectorized graphical format. (Do any do this already?) Done properly, the result could be scaled up or down arbitrarily, with *increased* quality (not just "bigger pixels") as it is scaled to visually bigger sizes. It could even possibly include blinking as an animation!
John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
