Frustrating print / printpreview problem

Question

5.00/5 (1 vote)

See more:

To start, I've been chasing this problem for days and have hit a wall so I've landed here begging for some insight.

Here's the situation:
I have a multi-document app, 6 different document types and each are viewable through a tabbed interface. Of these 6 different document types, one does not have the problem that I am about to describe. There difference between that one document and the others is that it is a single page document while the other are multi-page.

The problem:
When I print a document (even when I print just 1 page as selected via the print dialog) then follow that with a second print request (1 page for example) the page prints with huge fonts. Eye balling the output it would appear to be a 24 point font at least. The problem persists on subsequent print requests, until I do a print-preview. Once I do a print preview, which will work just fine (sometimes the printpreview will have the same large font problem but a 2nd print preview request will correct the problem), then follow that by another print request the printed output will be perfect: whatever is screwed up is corrected by the interveening print preview request.

This is driving me crazy: I cannot see any substantial difference between between the document that behaves correctly and the documents with the problem. I have gone line by line comparing the different sets of print logic and again, there is no substantial difference between the one with the correct behavior and the ones wth the problem.

I'm not looking for a solution, just a place to start as: I have exhausted every possibility I could imagine, scoured posted questions / solutions here and at CodeGURU, etc.

For reference, I'm using Visual Studio 2005, C++ / MFC. The view window for all employs CScrollView / QZoomView (enables a zoom capability for views). I had initially thought QZoomView was the cause of the problem but none of the print activities are handled in QZoomView.

Any and all suggestions appreciated

Posted 18-Nov-11 0:32am

Mike Gaskey

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Answer 1 · 2011-11-18T00:39:00

Solution 1

Dots on screen do not map 1:1 to dots on paper. You need to change the image mapping mode for the different ouptut device context as described here[^].

Posted 18-Nov-11 0:39am

Richard MacCutchan

Comments

Roger Allen 18-Nov-11 9:55am

This is true, but the standard MFC print preview architecture takes all of that into account for you. Unless he is directly messing with the mapping mode, I see this as a red herring.

Richard MacCutchan 18-Nov-11 12:35pm

Are you sure about this? It's a long time since I've used MFC but I certainly remember going through this issue myself when trying to print.

Mike Gaskey 18-Nov-11 14:35pm

I added TRACE statments in key locations in the print and print preview related routines and the mapping mode is changed, at various times it is: MM_TEXT, MM_LOENGLISH and MM_ANISOTROPIC. I'm not sure it matters though since it corrects itself after the 2nd print preview request. I'm reviewing the TRACE output to see if I can identify a problem. Thanks.

Roger Allen · Answer 2 · 2011-11-18T03:50:00

Solution 2

Is your OnPrint code returning the HDC's supplied in the same state as when you received it?

Posted 18-Nov-11 3:50am

Roger Allen

Comments

Mike Gaskey 18-Nov-11 14:35pm

I'll check and thanks for the suggestion.

Mike Gaskey 20-Nov-11 14:23pm

Well I solved the problem. To sort of recap: the map mode chages I referenced earlier were valid, changes between screen display and print output. I could see no problem with the HDC's. What I did identify as the problem was the deletion of fonts at the end of the print process and subsequent recreation on the next print function. Establishment of fonts was controlled by a *first time switch* that I had reset at the end of the printing operations, which then drove the deletion and recreation the next time around. Killing the reset cleared up the problem though in all honestly I do not understand this behavior.

Thanks for the help. I'm not sure I would have found the problem had I not gotten the advice from the both of you, that advice helped me to identify the problem by a process of elimination.