QPrinter & QPainter render() problem

[Mannion]

I have a problem when calling Qwidget::render() on a specific printer connected via a network to a PC running XP. I am quite new to using the Qprinter class so I apologise if I am missing something obvious. I get a repeatable crash when rendering to the printer in question. The only diffreence I can see between the working printers and the crashing one is the printer resolution. I seem to get the problem no matter what I render. The crash always seesm to occur at the render() call.

Here is attached example code:


void MainWindow::menuPrintTest(){
double xscale; double yscale; double scale;
double printerWidth ; double printerHeight ;
double widgetWidth; double widgetHeight ;
QFont printFont("courier", 16);
printFont.setFixedPitch(TRUE);
QTextEdit *qteTestPrintRequest = new QTextEdit("",w);
qteTestPrintRequest ->setFont(printFont );
qteTestPrintRequest ->setFixedHeight(1750);
qteTestPrintRequest ->setFixedWidth(1050);
widgetWidth = qteTestPrintRequest ->width();
widgetHeight = qteTestPrintRequest ->height();

QString qsConcat = "Test Printout For Checking XP Print Request Bug\n";
for (int i=0; i<30; i++){ qsConcat+= "Test Printout for Checking XP Print Request Bug\n" ; }
qteTestPrintRequest->append( qsConcat );

QPrinter printer(QPrinter::HighResolution);
QString docName = "Test Plot";
if ( !docName.isEmpty()) {
docName.replace (QRegExp (QString::fromLatin1 ("\n")), tr (" -- "));
printer.setDocName (docName);
}
QPrintDialog dialog(&printer);
if ( dialog.exec() ) {
{
{
QPainter painter(&printer);
printerWidth = printer.pageRect().width();
printerHeight = printer.pageRect().height();
xscale = printerWidth/(widgetWidth);
yscale = printerHeight/(widgetHeight);
scale = qMin(xscale, yscale);
painter.scale(scale, scale);
qteTestPrintRequest ->render(&painter);
}
}
}
}





The qDebug() output for the scaling is as follows:

printerWidth = 4908.0
printerHeight = 6408.0
widgetWidth = 1050.0
widgetHeight = 1750.0
xscale = 4.674
yscale = 3.662
scale = 3.662

As a matter of interest the output on one of the working printers is

printerWidth = 4760.0
printerHeight = 6814.0
widgetWidth = 1050.0
widgetHeight = 1750.0
xscale = 4.533
yscale = 3.894
scale = 3.894

[high_flyer]

Try printing something small - does it still crash then?
Also, you have a memory leak - you never delete 'qteTestPrintRequest' (but that should not play a role in the problem you have).

[Mannion]

Thankyou

I will try a print that is well within the pageRect() dimensions.

[Mannion]

I don't want to duplicate effort. My great thanks to all who have helped so far.

I hope that this is helpful to all concerned but this thread is being discussed in more detail on this link.

http://www.qtforum.org/article/37518/qprinter-qpainter-render-problem.html#post117656

[Mannion]

"I do need to rsolve this ASAP and would be willing to pay for a solution/resolution.":http://www.qtforum.org/article/37518/qprinter-qpainter-render-problem.html#post117656

The code above seems to work perfectly with all other configurations of Printer & PC tested. The problem seems to be that my simple test printout is generating a huge print document approximately a factor of 4000 times bigger (e.g. 213MB for a single A4 sheet) when sent to the specific printer involved:

Xerox Work Centre 7428 PS

The only potential leads I have are that it may be due to

1. A specific printer driver issue

2. QPrinter printer(QPrinter::HighResolution);
A guess.

3. qteTestPrintRequest->render(&painter);
Using render with a QTextEdit widget instead of using qteTestPrintRequest ->print(&printer);

4. Some other unidentified issue with the code posted above?

[wysota]

Maybe you should bother to answer high_flyer's question from post #2?

[Mannion]

Well I did on the link. I had assumed that those interested would follow it. I am genuinely sorry if that has been misleading or unhelpful.

The scaling factor seemed to have no effect on the outcome even when I sent an image significantly within the pageRect bounds.

The problem is not a crash but just that a huge file is generated on a particular printer (as stated in my last post). I have to the best of my knowledge identified the current status of the problem in summarised form. If I can clarify anything I would be very happy to do so. As always I am extremely grateful for any insight gleaned from those kind enough to help.

The use of the link was merely a genuine, honest attempt to minimise the amount of work generated for those kind enough to help and to reduce any duplication. If you would prefer that I duplicate all that transpires on that link then I have no problem with that.

Please advise. I am quite new to this forum.

Thanks Again
M

I can see now in hindsight that my URGENT capitals may have come across in the wrong way. I was not intending to shout about anything other than my offer of payment. It was not in any way impatience. I can see that it seems out of context without the preceding posts on the linked to forum.

I apologise for the confusion and potential offence that my clumsy post may have caused (Embarrassed smiley!)

Added after 1 5 minutes:

Capitals now editted.

[wysota]

So does printing a smaller document and/or in a smaller resolution help or not? I read the thread behind the link twice and I didn't see the answer to this question.

Also what happens if you print to PDF instead of to the printer? How large is the file generated?

[Mannion]

OK my apologies when re reading the thread it is less clear than I had thought but in the summary conclusions and in the context of my original, incorrectly posted crash query there was no crash caused by the resolution. If you are asking if the extreme print document size might be caused specifically by the dimensions of the rendered widget then that is another and interesting matter. In my last post I stated that the scaling factor seemed to have no effect on the huge print document phenomenon (that is other than a proportional change in its size).

I did not have the chance to test specifying a different a resolution setting in my rare opportunity on site as there were problems with drivers on site and security & IT etc.

Thankyou for your PDF output idea. I will test and respond. Currently the problem only happens specifically when outputting to the Xerox Work Centre 7428 PS printer.

Thanks again M

[wysota]

Thankyou for your PDF output idea. I will test and respond. Currently the problem only happens specifically when outputting to the Xerox Work Centre 7428 PS printer.
The point is to see how large the document is when still in postscript format. Apparently later the printer driver rasterizes the document which inflates its size. How much memory does the printer have?

[Mannion]

Well even though it can print ok directly to my test printer when using:

QPrinter printer(QPrinter::HighResolution);
the test application does seem to generate quite a large pdf weighing in at 4,164 KB for a single page single image renderred widget. This is, however, not in the same league as the Xerox prints which are over 50 times larger. I'm not sure how significant this is as it is my first attempt at any form of Qt PDF file generation.

I ran a test with

QPrinter printer(QPrinter::ScreenResolution);
and it produced a file of 197KB.

Likewise with

QPrinter printer(QPrinter::PrinterResolution);
the file size produced was 131KB

To my untrained eyes this seems quite a significant difference is that what is expected in terms of resolution quality?

I have attached the rapidly thrown together demo code and I apologise for any potentially obvious mistakes. I shall continue testing different parameters.


void MainWindow::menuPrintTest(){
double xscale; double yscale; double scale; double printerWidth ; double printerHeight ; double widgetWidth; double widgetHeight ;

QFont printFont("courier", 16);
printFont.setFixedPitch(TRUE);
QTextEdit *qteTestPrintRequest = new QTextEdit("",w);
qteTestPrintRequest ->setFont(printFont );
qteTestPrintRequest ->setFixedHeight(500); //NEW
qteTestPrintRequest ->setFixedWidth(750); //NEW
widgetWidth = qteTestPrintRequest ->width() ; //+200; //NEW MOD
widgetHeight = qteTestPrintRequest ->height() ; //+300; //NEW MOD
QString qsConcat = "Test Printout For Checking XP Print Request Bug\n";
for (int i=0; i<30; i++){ qsConcat+= "Test Printout for Checking XP Print Request Bug\n" ; }
qteTestPrintRequest->append( qsConcat );

QPrinter printer(QPrinter::HighResolution);
printer.setOutputFormat(QPrinter::PdfFormat); //PDF ADD
printer.setOutputFileName("Test.pdf"); //PDF ADD

QString docName = "Test Plot";
if ( !docName.isEmpty()) {
docName.replace (QRegExp (QString::fromLatin1 ("\n")), tr (" -- "));
printer.setDocName (docName);
}
//QPrintDialog dialog(&printer); //PDF REMOVE
//if ( dialog.exec() ) { //PDF REMOVE
{
QPainter painter;
painter.begin(&printer);
printerWidth = printer.pageRect().width();
printerHeight = printer.pageRect().height();
xscale = printerWidth/(widgetWidth);
yscale = printerHeight/(widgetHeight);
scale = qMin(xscale, yscale);
painter.scale(scale, scale);
qteTestPrintRequest ->render(&painter); //qteTestPrintRequest->print(&printer);
painter.end();
} //QPAINTER CTOR BRACE
}
//}else{} //PDF REMOVE
delete qteTestPrintRequest;
}

Added after 4 minutes:

Changing the size of the renderred QTextEdit widget seems to only change the file size proportionally.

http://doc.qt.nokia.com/4.7-snapshot/qprinter.html#PrinterMode-enum
States that for QPrinter::PrinterResolution

This value is deprecated. Is is equivalent to ScreenResolution on Unix and HighResolution on Windows and Mac. Due do the difference between ScreenResolution and HighResolution, use of this value may lead to non-portable printer code.
and for QPrinter::HighResolution

On Windows, sets the printer resolution to that defined for the printer in use. For PostScript printing, sets the resolution of the PostScript driver to 1200 dpi.

If it weren't for this I would be looking at substituting QPrinter::PrinterResolution for QPrinter::HighResolution.

Still my big question is if it is ok to use QTextEdit->render(&painter)




In response to your post:


The point is to see how large the document is when still in postscript format. Apparently later the printer driver rasterizes the document which inflates its size. How much memory does the printer have?

The printer still manages to print the document it just takes a long time to send the data to the printer. In the test the 213MB was the size observed in the printer document queue on the PC running the test app.

It is a fairly modern, high spec printer serving a large-ish office. It must have a sizeable memory. All of the other printers tested were of a lower spec to the problem printer.

[wysota]

the test application does seem to generate quite a large pdf weighing in at 4,164 KB for a single page single image renderred widget.
Hmmm... are you printing a widget or a document? What does the document contain?


To my untrained eyes this seems quite a significant difference is that what is expected in terms of resolution quality?
Yes, of course. Your screen has a resolution of around 100DPI, the printer's high resolution is probably around 1200DPI which means one page is 144 times larger.

[Mannion]

Hmmm... are you printing a widget or a document? What does the document contain?

A widget as per the code, more specifically:



QFont printFont("courier", 16);
printFont.setFixedPitch(TRUE);
QTextEdit *qteTestPrintRequest = new QTextEdit("",w);
qteTestPrintRequest ->setFont(printFont );
qteTestPrintRequest ->setFixedHeight(500); //NEW
qteTestPrintRequest ->setFixedWidth(750); //NEW
widgetWidth = qteTestPrintRequest ->width() ; //+200; //NEW MOD
widgetHeight = qteTestPrintRequest ->height() ; //+300; //NEW MOD
QString qsConcat = "Test Printout For Checking XP Print Request Bug\n";
for (int i=0; i<30; i++){ qsConcat+= "Test Printout for Checking XP Print Request Bug\n" ; }
qteTestPrintRequest->append( qsConcat );


Yes, of course. Your screen has a resolution of around 100DPI, the printer's high resolution is probably around 1200DPI which means one page is 144 times larger.
Yes I agree that this point is redundant. However compression and the discrepancy between the Printer and High resolutions are not covered by this observation. Clearly something else is going on.

Added after 16 minutes:

After examining the PDF documents it seems as though the differences in PDF file size could be down to resolution and compression alone. The differences between HighResolution and PrinterResolution are a little less easy to explain. Perhaps they represent the difference between some lower printer resolution setting and the printer's high resolution setting. The resolution of the PrinterResolution PDF is quite low indeed.

The only clear link to the Xerox problem that I can identify is that the Xerox would perhaps have the potential for a very high resolution upper setting. This could perhaps partially explain the factor of 4000 in the queued printer document size.

Does this make any sense to you or am I barking up the wrong tree?

It seems like this issue would probably crop up an awful lot if this is all that is happening. Is the QTextEdit->render() call part of the issue?

Can I get high resolution scaled images without setting the highest available printer resolution?

[wysota]

A widget as per the code,
Then you are printing an image, a bitmap, which is large per definition. Not that I see any point in printing a widget and not a document contained in it.


Yes I agree that this point is redundant. However compression and the discrepancy between the Printer and High resolutions are not covered by this observation. Clearly something else is going on.
I don't see anything "clear" here. You get a 200 MB printer job because you rasterize an image in high resolution. This just has to take time and memory.


Can I get high resolution scaled images without setting the highest available printer resolution?
If your image has 100 DPI then scaling it up to 1200 DPI doesn't make sense and you can print it in 100 DPI, the quality will be the same.

But first think if you should really be printing the widget and not the document it contains (which would have much higher quality and much lower volume).

[Mannion]

There is no document to print unless you mean the .text property. All the text is added via append

The widgets are renderred off screen. I got very poor results using the screen resolution setting

Added after 6 minutes:

The exact same renderring request ( in terms of code )produced a local queued printer document over 4000 times larger with the problem printer than with several printers of at least 600dpi

[wysota]

There is no document to print unless you mean the .text property.
So... are you printing an empty QTextEdit widget? Are you aware of the distinction between QTextEdit and QTextDocument?

[Mannion]

There is no subterfuge here. I am doing exactly what is in the code at the very beginning of the thread. Nothing has changed. I'm not sure where the questions regarding what I am printing are coming from. If the code is not clear please let me know and I will respond immediately. Once again I am genuinely sorry for anything miscommunicated and I do appreciate your efforts to help.

Added after 32 minutes:

For clarity this is the constructor that I used


QTextEdit *qteTestPrintRequest = new QTextEdit("",w);

Here is the test example text


QString qsConcat = "Test Printout For Checking XP Print Request Bug\n";
for (int i=0; i<30; i++){ qsConcat+= "Test Printout for Checking XP Print Request Bug\n" ; }
qteTestPrintRequest->append( qsConcat );

Here is the key focal point of the thread which involves printing a widget (There was certainly no intent to mention printing a document. I am unsure as to how I gave that impression and I apologise for the confusion)


qteTestPrintRequest ->render(&painter);

I am deliberately trying to render the widget in this way and I am aware that there may be an issue with this line and I have pointed this out in several places above. This approach, which indeed involves rendering a bitmap, worked using several PC/Printer configurations. So far in testing this approach has only caused a problem with 1 particular printer where the application produces a printer document (terminology referring to printer queue) over 4000 times larger. In the other tests for example my test printer configuration produced an equivalent document comprised of 3 full pages rendered using this widget rendering approach with a size of 158KB.

If this approach is definitely a dead end for any of the reasons I have stated previously or for any other reason then I do need to consider other options although this would obviously incur an unwanted time penalty.

I have already asked the question

Will I have to use QTextDocument & html or QGraphicsScene to achieve this end result?



Added after 1 5 minutes:

Your information has provided me with many interesting avenues to pursue and I will endeavour to pursue any leads that you produce. For example you have raised the resolution issue. Is the resolution being rendered at the printer related to the pageRect dimensions? There certainly seems to be some correlation.

If so then the follwing is interesting. The three different resolution settings on my test printer and the HighResolution setting on the problem printer produce the following results:

Test Printer (No Problem)
===================

Using: QPrinter printer(QPrinter::PrinterResolution);
xscale,yscale,scale = 6.347, 13.628, 6.347
printer.pageRect().width() = 4760.0
printer.pageRect().height() = 6814.0
QTextEdit.width() = 750.0
QTextEdit.height() = 500.0
Printer queue document size 297 KB

Using: QPrinter printer(QPrinter::ScreenResolution);
xscale,yscale,scale = 1.016, 2.180, 1.016
printer.pageRect().width() = 762.0
printer.pageRect().height() = 1090.0
QTextEdit.width() = 750.0
QTextEdit.height() = 500.0
Printer queue document size 263 KB

Using: QPrinter printer(QPrinter::HighResolution);
xscale,yscale,scale = 6.347, 13.628, 6.347
printer.pageRect().width() = 4760.0
printer.pageRect().height() = 6814.0
QTextEdit.width() = 750.0
QTextEdit.height() = 500.0
Printer queue document size 297 KB


Problem Printer (Xerox Work Centre 7428 PS
=================================

Using: QPrinter printer(QPrinter::HighResolution);
xscale,yscale,scale = 6.544, 12.816, 6.544
printer.pageRect().width() = 4908.0
printer.pageRect().height() = 6408.0
QTextEdit.width() = 750.0
QTextEdit.height() = 500.0
Printer queue document size 213 MB

The problem printer queue document size is produced at a very similar scale factor to that of the more reasonable sized HighResolution equivalent on the test printer and yet is over 717 times larger. The ratio of the squares of the scale factors is approximately 1.06:1

[wysota]

There is no subterfuge here. I am doing exactly what is in the code at the very beginning of the thread. Nothing has changed. I'm not sure where the questions regarding what I am printing are coming from.
They are coming from my opinion that you are doing something you are not supposed to be doing and I'm wondering if it is on purpose or if you just didn't find a better way of obtaining your goals.


If this approach is definitely a dead end for any of the reasons I have stated previously or for any other reason then I do need to consider other options although this would obviously incur an unwanted time penalty.
It's a matter of using the right resolution for printing. 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. If you keep the printout resolution in the range of your screen resolution, you should obtain reasonable print jobs.

[Mannion]

It's a matter of using the right resolution for printing. 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. If you keep the printout resolution in the range of your screen resolution, you should obtain reasonable print jobs.
This is absolutely not true
I have just run of a quick confirmation test using the ScreenResolution setting (from a high resolution adapter) The results were dreadful as I have already clearly stated. I am not sure why you find this impossible to believe.

If a widget is used as a means to rendering a high quality output such as multiple detailed graphs for example as one of my actual application requirements. You often want to render that widget at a much higher resolution than that of the screen. 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.


They are coming from my opinion that you are doing something you are not supposed to be doing and I'm wondering if it is on purpose or if you just didn't find a better way of obtaining your goals.
There is still no need for questions as all of the answers are in the source code. It is crystal clear what I am doing. I am either doing it wrong or not there is no lack of clarity as to what I am doing. Indeed I am actually asking if what I am doing is correct, that is the whole point of the thread. I'm not sure how our wires have become so crossed? I am sorry if it is the way that I have framed the question.

There may be a better way of achieving my goals in respect to some aspects of the problem ie in terms of complete flexibility and best practice etc. However the solution I have tried is a much quicker solution and ticks all the right boxes in terms of quality and indeed queued printer document size apart from a curious specific printer issue which you have never directly addressed. This is why it was a very deliberate approach with an awareness, that I clearly stated, that there are other potential approaches.

If indeed the only response is never render a widget directly then there should not be so much information readily available showing how to do it. Also this response could have been stated after my first post after a cursory look at my source code. From the information supplied this is not however clear. Why the difference between the test printers and the problem printer? That is surely a useful question. Why do the file sizes not match your explanation of it all being down to resolution dimensions. Look at the figures it simply is not.

[wysota]

This is absolutely not true
What exactly is not true? The Nyquist-Shannon sampling theorem?


I have just run of a quick confirmation test using the ScreenResolution setting (from a high resolution adapter) The results were dreadful as I have already clearly stated.
I have no idea what you consider "dreadful".


I am not sure why you find this impossible to believe.
Because the laws of physics are identical to everyone.


If a widget is used as a means to rendering a high quality output such as multiple detailed graphs for example
This is just silly. "Widgets" and "high quality" are nowhere near each other. If you want a graph then render a graph, not a widget.


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.
You mean the documentation actually advises you to render widgets? Could you point me to the relevant paragraph?


Indeed I am actually asking if what I am doing is correct
Generally speaking yes, but when it comes to your printer then apparently no. Apparently your printer driver takes a bitmap and converts each pixel of it to post-script definition instead of taking the original vector definition and using that for printout. Since you force rasterization of your data by rendering a widget to a bitmap, you surrender the vector definition of your scene in favour of a finite resolution (whatever you choose it to be).

[Mannion]

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

This is absolutely not true
which was referring to a very specific point

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 (http://www.flickr.com/photos/67590837@N07/6979110505/in/photostream)

&

ScreenResolution Unscaled Example (http://www.flickr.com/photos/67590837@N07/6979110453/in/photostream)


It was also referring to

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.




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

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.

[wysota]

2. No
2.a. Use a QTextDocument based approach (this is likely to incur a time penalty)
Hold on! What time penalty?

[Mannion]

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.

[wysota]

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?

[Mannion]

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).

[wysota]

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.

[Mannion]

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?

[wysota]

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.

[Mannion]

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?

[wysota]

It should definitely work.

[Mannion]

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?

[wysota]

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.