Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Combatting effect of ClearType

dboggs
New Contributor I
601 Views
Using QuickWin, I routinely produce a graph in a child window, for user to see on the screen, configure interactively, etc. Then, when acceptable to him, I open another child window and reproduce the graph using black&while only, and at much higher resolution--the virtual window size is higher than the screen and the visible window is usually minimized. This is only for the purpose of saving the window as a bmp file, to be eventually printed.

This all works fine, EXCEPT that if the user has Windows screen properties set to use ClearType, all of my graphical text is diddled--it is fuzzy at the edges (smoothed), and surprisingly, with a variety of colors. Yes that makes it look better on the screen, but it does not look good in the high-res bmp file. The printed output looks much better if ClearType is turned off.

So, how can I do this under program control? I really can't instruct my customers to simply turn clearType off before running the program, and turn it back on after.

Ideally, I would not send my QuickWin graphics to a screen window at all, but rather to some kind of "virtual window" that existed only in memory, or someplace where ClearType does not know to monkey with it.

Any ideas out there?
0 Kudos
2 Replies
Paul_Curtis
Valued Contributor I
601 Views
Transforming a screen graphic to a bmp (not much of a transformation, actually) and then printing the bmp limits the output resolution to that available on the screen, whereas other devices such as printers have much much higher native resolution. The proper way to do this in windows is to create a separate device context for the printer, and then repeat your drawing exercise sending the output to the printer device context, as indicated by its handle hDC; ie, your drawing routine is written with the device context handle hDC as an input argument, so that the same code can be used in a device-independent manner, and will produce output which uses the full available resolution of the selected device both for graphic elements as well as text; windows nicely hides the details in the device driver.
0 Kudos
dboggs
New Contributor I
601 Views
Thanks for the very quick response. Two comments:

First, the bmp file resolution is not limited to the screen. I can make a child window with a virtual size much larger than the screen (practically unlimited), and the full window can be saved to a bmp file. It is actually very easy and works very well.

Second, I realize that your solution is probably better, but I don't have any idea how to achieve it using QuickWin. I am a novice! Any guidance you could give would be great. Also, realize that the ultimate goal here is not high-res output on any particular printer, particular page size, etc., but rather a high-resolution file (I use bmp which will be immediately converted to tif) which can then be put to use in a wide range of applications--only one of which is printing. More commonly, the tif file will be put into a Word document, then converted to a pdf, and sent to a client, who will then do who-knows-what with it. We have a long successful history of high-res tif files used like this, and I am just trying to utilize it in the Fortran QuickWin environment.
0 Kudos
Reply