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.