no QPrinter::PostScriptFormat in qt5
I tried to migrate from qt 4.8.4 and get the folloving error:
bq. mat’ : is not a member of ‘QPrinter’
19> C:\Qt\Qt5.0.1\5.0.1\msvc2010\include\QtPrintSupport\qprinter.h(66) : see declaration of ‘QPrinter’
19>src\qwt_plot_renderer.cpp(250): error C2065: ‘PostScriptFormat’ : undeclared identifier
I have this problem now, too. Porting to Qt5 is a real pain, they have done incredible things.
He just removes the postscript support, a feature people depend on, with the comment
I really wanted to do this since many years already! :)
And in the documentation not the slightest hint of this. Infact the Qt5 documentation for print support [qt-project.org] even still claims support for PostScript:
Qt’s printing system also enables PostScript and PDF files to be generated, providing the foundation for basic report generation facilities.
Well, basic report generation has just been cut in half by Qt5.
Qt is falling apart and everybody’s watching.
Hey Lars, now that I think of it, Why don’t you ditch QPrinter and print support altogether? Who prints things nowaways anyways, it’s all on the little tablets and smartphones, right?!
@DerManu: Nobody is holding a gun to your head forcing you to port a working Qt4 application to Qt5. The process is clearly causing you aggravation and whining about it incessantly will not help. Either stick with Qt4, or propose reinstating the Postscript support in Qt5 by putting up the patch and agreeing to maintain it.
While I agree that there was some whine with that cheese, I can’t see how two threads (this one and whining about it incessantly will not helpthis [qt-project.org]) which do contain constructive discussion for the greater part can be described as incessant whining. If you feel annoyed by my occasional dry remark, I’d like to apologize, and suggest you skip them ;).
As you say, this is true for applications. Unfortunately it is not true for library developers like me, who have clients that want Qt4 and clients that want Qt5 support. A very high priority is giving them a good user experience using the library, instead of making them jump through hoops. And just dropping — in some cases essential — feature sets like PostScript support out of thin air is pretty steep (without even deprecating it beforehand!). Nobody is holding a gun to your head forcing you to port a working Qt4 application to Qt5.
I see that this is often the argument in open source software, which is great in principle. But lets be realistic. I use Qt as a framework to get my work done, I don’t have the time to take on major maintenance work in that framework itself, if I want to keep developing my own library. propose reinstating the Postscript support in Qt5 by putting up the patch and agreeing to maintain it.
I cannot recall anything more than a brief mention (that I cannot locate) about PostScript removal before Qt5 release (not like the longer discussion that surrounded QWeakPointer). It will be interesting to see what comes of a paying customer request to Digia about removal of PS. Has someone lodged a bug report over the documentation?
DerManu, my apologies… a bit harsh. Can I put it down to a bad day at the office?
If your clients want to use Qt5 they have accepted the capabilities of Qt5. Are they asking that your library does not do things that Qt5 cannot do, or is this more a case of wanting to maintain the same capabilities on your part? I appreciate that in scientific publishing circles PostScript is often preferred (as a LaTeX input for example) but a pdf2ps is often a reasonable approach.