QPrinter & QPainter render() problem

Sorry for the late reply, especially as your responses have been so prompt. Unfortunately I had unavoidable commitments. Thank you once again for your response it did clear some issues up for me. I will run a series of tests based on your replies and assess my options for achieving a reasonably rapid and satisfactory solution.

Can I take the opportunity to reinforce the hopefully obvious notion that I am posting as a relative novice in this area and I have the greatest respect for your obvious competence and experience in this field. I think I need to be clearer in my statements and I apologise for the areas of vagueness that have lead to some miscommunication.


I think it is also important that I stress that I am very aware that in many ways the approach I am using is not the best practice for printing out text and graphs. It would, however, have been extremely beneficial to utilise this approach if it could have been achieved reliably as it would result in the most expedient solution for my very specific, current circumstances. In my initial tests I encountered no problems and it seemed likely that this approach may have provided a more than satisfactory implementation for the functionality that was required.

This approach can produce very high quality and more than satisfactory results proven through numerous subjective tests. Timing was critical and this approach also offered a very quick solution for relatively complex layouts of plots, graphics, text and custom widgets, largely reusing existing code.


In summary my initial question was can the specific (and possibly relatively rare) printer issue be avoided using the approach outlined. The potential responses I identified were.

1. Yes
1.a. the implementation for direct rendering of widgets is wrong and needs to be corrected
1.b. by changing settings used (e.g. change the QPrinter::***Resolution *Note that setting the QPrinter::ScreenSetting option seems to dramatically lower the output quality)
1.c. substitute use of QTextEdit->render(&painter) for QTextEdit

2. No
2.a. Use a QTextDocument based approach (this is likely to incur a time penalty)
2.b. Use a QGraphicsScene based approach (this is likely to incur a time penalty)
2.c. It is a printer driver issue that cannot be avoided using the proposed approach. Use 2.a. 2.b. or another approach to implement required printout functionality.


It was important to note the finding that there was a significant difference in printout quality when using the settings QPrinter::HighResolution & QPrinter::ScreenResolution and that this was a fundamental point in my query hence my comment

Quote:

---

This is absolutely not true

---

which was referring to a very specific point

Quote:

---

If you want to print a widget then its resolution is equal to the resolution of your screen and upscaling it to the maximum resolution supported by a printer doesn't make sense.

---

in the very specific context that it is not true that there is never an advantage to upscale a widget to a higher resolution than a screen resolution. Upscaling many widgets can produce significantly better printout results. This depends on every aspect of the upscaling process involved and does not necessarily breach any fundamental laws of sampling. E.g.

HighResolution Upscaling Example

&

ScreenResolution Unscaled Example


It was also referring to

Quote:

---

If you keep the printout resolution in the range of your screen resolution, you should obtain reasonable print jobs.

---

specifically in the context that the results obtained using this approach have been frequently subjectively assessed by testers as very poor indeed. In terms of my requirements this definition of reasonable is not sufficient.

Quote:

---

You render the widget off screen and indeed the screen resolution is largely irrelevant. It is then advisable to render at the HighResolution setting. This is exactly what the documentation recommends for high quality printouts.

---

I apologise for this I meant to refer specifically to the documentation regarding the PrinterMode setting where it states

Quote:

---

ScreenResolution will produce a lower quality output than HighResolution and should only be used for drafts.

---

I reiterate again that I know this approach is not optimal or best practice for achieving the highest quality printouts.

Quote:

---

Originally Posted by Mannion

2. No
2.a. Use a QTextDocument based approach (this is likely to incur a time penalty)

---

Hold on! What time penalty?

That's a fair point so let me clarify. Firstly I am referring to development time. Here are 3 further points defining the initial problem.

1. At the time I was working on a very tight deadline which is still there but effectively it has now been pushed back slightly out of necessity.

2. I also had a requirement for a relatively complex layout of footers, headers, images, custom widgets, QwtPlots and formatted text. Virtually all of this was achievable almost immediately if I could achieve decent quality printouts using the approach I have defined. This strategy seemed to work and a prototype was achieved very quickly and passed fairly varied testing and everyone was happy. A beta test with a specific printer identified that there was in fact an issue and you know the rest.

3. A brief spell of research identified some of the other options such as the use of QTextDocument and QGraphics scene. I had very little experience of printing using Qt in general and no experience of using either of the 2 approaches just mentioned. It was not clear that in the available time I could achieve all of the required functionality using these methods. Indeed none of my initial research identified clearly that all of the requirements could be met. I am pretty sure that they could however but within the very tight time constraints there was only one possible option.

Quote:

---

Originally Posted by Mannion

Firstly I am referring to development time.

---

But QTextEdit uses QTextDocument internally. If there is time penalty then it's related to using QTextEdit instead of QTextDocument and not the other way round. That's my point from the very beginning -- why are you using QTextEdit instead of QTextDocument?

Thanks again for your response.

I am using QTextEdit in the form shown in my code. I can then easily layout the QTextEdit and other standard Qt and custom rendered widgets to fit within a larger more complex layout widget, that also incorporates headers and footers, that can easily (relatively speaking in the context of this thread) be scaled and printed.
If I can relatively easily achieve the same functionality using a QTextDocument then it sounds very promising indeed, especially as the deadline has effectively gone now and I have a small amount of available time. It may be worth noting that my html knowledge is very basic indeed.

Requirements are as follows:
=====================
1. Scaling of full document or similar functionality
2. Headers & Footers. (I know this is possible from Blanchette and Summerfield)
3. Formatting and layout of Images
4. Formatting and layout of QwtPlots

The 3 possible layouts consist of a heade and footer as follows:
Header: consisting of 2 Images (currently 2 QLabels)
Footer: consisting of an image (currently 1 QLabel) a line of formatted text (currently QTextEdit) and 2 blocks of text (currently QLabels)

Page1: Body: formatted text (currently QTextEdit) with lots of tabulations and aligned data in several blocks.
Page2: Body: A Title (currently (QTextEdit) & a layout of a number of vertically arranged QwtPlots (between 2 & 4).
Page3: Body: A Title (currently (QTextEdit) & a layout of a number of vertically arranged QwtPlots (between 2 & 5).

I think your main error is that you think in term of widgets instead of in terms of data you want to visualize. Widgets are meant to be used on screen. Period. If you want to print a plot then you don't put a widget inside a layout and print that but you take whatever the abstract representation of QwtPlot is (sorry, I'm not an expert on Qwt) that keeps the data in mathematical form and you compose a document from the plot and whatever other pieces of data you might have and then print that in one go hoping that there is code path for your usecase that is better than complete rasterization of the document. Apparently your printer reacts badly on such full rasterization.

Your requirements seem to suggest you should be using GraphicsView or QTextDocument possibly with custom elements representing plots. That's my point of view, at least.

Thanks again for getting back to me.

It does seem like I will have to change tack to guarantee a solution to the printer issue. Another nail in the coffin is that even if I try to fudge the widget rendering approach further by using the ScreenResolution setting to minimise the printer hang all indicators are that the queued printer document size will still be disproportionately large for the quality produced.

I was aware that it was an extremely inelegant solution and that it was not guaranteed to work. It is a pity as it will involve a development time hit as the widget rendering approach was very easy to throw together extremely quickly and up to a point produced nice results, moreover it is already written and checked for 11 print permutations.

I appreciate your analysis and consideration of the available options. The plus side is that I am about to learn a crash course on printing with QTextDocument or QGraphicsScene. Do you have a recommended choice out of the two bearing in mind my layout requirements?

Quote:

---

Originally Posted by Mannion

Do you have a recommended choice out of the two bearing in mind my layout requirements?

---

I think it mainly depends how much paragraphed text you have and whether you need to deal with text flow. The less of that, the bigger chance GraphicsView is better.

By the way, maybe a solution is to print to pdf and then send that pdf to the printer? Not very elegant but it might save you some time.

Quote:

---

By the way, maybe a solution is to print to pdf and then send that pdf to the printer? Not very elegant but it might save you some time.

---

This is certainly worth considering and could be a life saver in the short term. Thankyou for the advice.

It seems trivial to achieve this with off the peg QWidgets and I have achieved good results. I had a quick test attempt at generating a pdf by rendering a custom widget consisting of a layout of QwtPlots and it failed to produce anything. I will investigate further but I wonder if I am I missing anything obvious with generating pdfs from custom widgets or should it work?

It should definitely work.

There have been quite a few developments regarding the QWidget::render(&painter) printout issue. I will try and update all of the details in due course.

The immediate issue is that I have discovered that he inflated print queue size issue seems to effect a number of more modern printers. I am currently working with a Samsung CLP-325W which produces a, worst case, 3 page complex layout document rendered using QWidget::render() that is > 310MB in size. It seems to handle the large data requirement relatively easily though starting to print in under 25 seconds. So my first question is are printer queue sizes of this order necessarily a problem?

It depends on the printer and the system operating the driver. If the printer was connected to a system having 256MB of memory then I believe sending 300MB to the printer through USB 1.1 might cause problems.