Printing and windows dpi/font-size settings.

[MagnusW]

Hi,

My customers reported that the the print (and print preview, and in my case pdf output using SynPdf) depends on the windows dpi settings. A lot of my customers run laptops with font size 125%. They get nervous when a 100 page document suddenly is 98 pages, and get afraid that information is missing.

In my case it is difficult to trace where this might happen, I use TRVReportHelper and custom code for handling of margins and headers and footers.

But..., I tested with your ActionTestUni.exe and I did indeed get some slight differences.

Since we are printing to a printer-canvas, which should get it's size and DPI from the printer should this not be totally independent of the windows font-size?

As for the Result in ActionTest it seems that the printed font-size stays the same. But the vertical spacing between lines is sometimes changed, for example in the '-'-lists. Also the images: the icons you have before TRVAControlPanel and TRVAPopupMenu seems not to be correctly scaled.

Regards,

/Magnus

[Sergey Tkachenko]

This question is not simple, so the answer will be long.

There are two main types of objects we need to concern about:
- text
- non-text (line width and size in tables, sizes of resized images, etc.)

In the text below, "absolute size" means size measured in real units, like cm or inch; "logical size" means size in pixels.

Sizes of text are usually defined in points. So text is scaled according to the device resolution.
By default, size of non-text objects are defined in screen pixels. So, when screen resolution grows, objects still have the same size in pixels, but looks visually smaller. When printing on TRVPrint, their sizes are multiplied by the ratio "printer resolution / screen resolution". So absolute sizes on paper are independent of the printer resolution, but are dependent on the screen resolution (i.e. have the same proportion to text as on the screen).

So, by default, when you move to a device having the larger screen resolution:
- absolute size of text remains the same, but logical size increases.
- absolute size of non-text objects decreases, but logical size remains the same.
This disproportion is the same for screen and printer.

[Sergey Tkachenko]

How can we change the default behavior?

1) You can tell TRVPrint to use a fixed screen resolution. For example 96 dpi.
Assign RichViewPixelsPerInch := 96.
After that, absolute sizes of printed non-text objects become independent of the screen resolution, they will be the same on devices having screen resolution 96dpi and 300dpi.
So we solved the printing problem:
- printing becomes independent of the screen resolution not only for text, but also for non-text
- no disproportion between text and non-text objects on printing.

But there is a new problem.

So, by default, when you move to a device having the larger screen resolution:
- absolute size of text remains the same, but logical size increases.
- absolute size of non-text objects decreases, but logical size remains the same.

This disproportion remains on the screen. So, on devices having screen resolution <> 96, proportions between text and non-text are not the same on screen and printer.

[Sergey Tkachenko]

2) In addition to assigning RichViewPixelsPerInch = 96, you can also fix the resolution used for text:
RVStyle1.TextStyles.PixesPerInch := 96.
It fixes logical size of text on the screen.
After that, no disproportion between text and non-text sizes on devices having different resolution, both for screen and for printer.

But there is a new problem: too small size of everything on high-res screens.
For example, the screen's dpi = 300, but TRichView displays content as if the screen's dpi = 96, objects are by about 3 times smaller than they should.

[Sergey Tkachenko]

3) There is another solution: using twips instead of pixels to define sizes of non-text objects.
Leave RichViewPixelPerInch and RVStyle1.TextStyles.PixelsPerInch unchanged, but assign
RVStyle.Units := rvsuTwips.

1 twip = 1/20 of point. If you define all sizes in twips, all non-text object will be scaled like text. When you move to a device having the larger screen resolution:
- absolute size of text remains the same, but logical size increases.
- the same for non-text.
This proportion is the same for screen and printer.

So this is the best method to make your application independent on the screen resolution. But you should be very accurate when defining any size, you must know that they are not in pixels.

Additional information: http://www.trichview.com/help/units_of_measurement.html

[Sergey Tkachenko]

Does (3) solve all the problems?

Not completely. There are still sizes that measured in pixels, and not affected by RVStyle.Units.
They are:
- TRichView.LeftMargin, TopMargin, RightMargin, BottomMargin, MinTextWidth, MaxTextWidth properties
- sizes of unresized images; if the image is resized (more exactly, if their "image width" and "image height" properties are defined, they are measured in RVStyle.Units; but unresized images are displayed at their logical size; the only solution is defining "image width" and "image height" properties explicitly. I can make an example assigning these properties for all images in the document where they are unassigned.

[Sergey Tkachenko]

And one more problem with TRVReportHelper.

Drawing using TRVReportHelper works like printing in TRVPrint.
However, the component needs to know the target canvas resolution.

TRVPrint uses the real printer canvas, so it knows the printer resolution, using GetDeviceCaps(Canvas.Handle ...)

But when you use TRVReportHelper to generate PDF, you use Canvas received from a PDF generator.
While PDF generator may assume that PDF is generated in some specific resolution, I believe it provides a screen-compatible Canvas, so GetDeviceCaps(Canvas.Handle ...) returns the screen resolution. If this resolution is different from the resolution assumed by PDF, page will be sized incorrectly (this effect must be very noticeable, page content does not fit page size).
There is a way to specify a desired resolution in TRVReportHelper, but it's not completely trivial (it is used in ReportBuilder wrapper, for example).
I did not test SynPdf yet, sorry. Does it use the screen resolution of PDF files, or you can specify your own resolution?

[MagnusW]

Hi Sergey, I really appreciate your detailed answer, it helped me a lot.

I went with number 2) because it fixed the immediate problem, of printing existing richview documents, originally written 100% but now being printed in 125%

Now I am about to start looking at no 3), to solve the problem of where the same text is being edited by different persons on machines with different settings, and it feels like this is the way to go.

Just one short question, what happens with existing rvf which has been authored and saved with rvstuPixels, will they look ok if inserted in a RichViewEdit with rvsuTwips, or do I have to do some conversion of all RVF's in my database.

Oh, one more question, I also have licenses for the ScaleRichView, does this give me any other options? This might be a bigger change for me though because there are already RichViewEdits all over my code base so I am primary researching no 3).

Regards,
/Magnus

[Sergey Tkachenko]

"Pixels per inch" settings are not stored in RVF, so a conversion may occur only when document's units (twips or pixels) are not the same as editor's units.
When loading RVF, the behavior depends on "allow change units" RVFOption:
- sizes from the document are converted to the editor's units,
or
- the editor's units are changed to the document's units.

In ScaleRichView, internal dpi is always assumed to be 96, both for text and non-text, both for screen and printer (RichViewPixelsPerInch is set to 96 and must not be changed). So it provides WYSIWYG even if sizes are defined in pixels.
But when scaling page to 100%, it uses the screen dpi, so sizes are not small even for high-dpi display.