× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hello,

while this isn't related to IBM i in particular, I guess the topic is interesting enough for the general community, probably facing similar issues.


Am 24.05.2023 um 08:41 schrieb x y <xy6581@xxxxxxxxx>:

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.

About "not rendering well", without a visible example what exactly "not well" means I can only guess. I think when you save a PDF, pixel pictures are compressed with JPEG by the application you're using. JPEG works fairly well with photos and comparable "smooth" input data. "Computer pictures" are often not "smooth" and have sharp contrasts. The block-orientated optimizer in JPEG often leaves error pixels on such edges, and those are depending on the "quality" setting of the individual JPEG compressor.

Don't use JPEG for screen shots and comparable graphics.

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.

It was a surprise to view the printed output from a Brother laser color printer: even in portrait orientation, the printed screen shot was crisp and easily readable.

Printers have higher resolution than displays. Also, depending on your PDF viewer, there might be a setting to display pixel pictures slower but more precise vs. quicker with less quality.

The downside is the large image sizes will slow response on the Internet for first-time viewers but that may be a minor issue (recapturing thousands of images as BMP's--now, that's not a minor issue).

I think there is no need to recapture them. As long as you still have the originals, you can use e. g. ImageMagick (on Linux and probably other platforms) to mass-convert them easily to PNG for space saving. PNG has superseded GIF as "in-browser picture format" for non-photo pictures quite some time ago.

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.

White lettering? You're not using color? Are we talking about 100% white, or maybe more grey'ish?

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. Unless you're using color, then green becomes some hue of red, blue becomes some hue of orange and things will look alien.

With an upper-case "N" in iACS, the vertical bar on the right is noticeably thinner than the vertical bar on the left. With Mochasoft's TN5250 program, both bars appear to be identical. I've tried around 20 fixed-width formats and fiddled with the iACS font settings, all to no avail. My guess is that the Java API painting the screen is not optimized for this environment.

That matches what I remember from John's experiences he was telling.

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.

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.

On my Mac, I'm using Menlo Regular. Mocha has very soft (heavily antialiased) characters, but still not too much. The out doesn't feel blurry. iACS uses less antialiasing, I can spot "stairs" on a capital A. If interested, I can place screen shots for visual comparison.

I'm not using a high-resolution "retina" display.

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.

I'm still contemplating on a way to "fake" screens in MediaWiki to get rid of pixelated screen shots altogether…

:wq! PoC




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.