[Development] Plans for printing in 5.3 onwards

[John Layt]

On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote:
> 
> Since the feature freeze is on the 14th I have been eagerly awaiting the
> changes that have been indicated already have been done so I can carry on
> testing. Have I missed some updates or something? I am concerned because I
> know how many people use the printing and we need to try and get these
> changes tested and fixed where necessary in good time for the final so the
> transition is not really noticed by the users. So is there any update on
> these patches or should we consider waiting until Qt 5.4 to ensure they are
> all ready correctly?

Sorry, needed to wait until the full stack of changes had been completed and 
integrated before pushing. The revised patches are up for review, I'm not sure 
we'll get it done in time, but it's worth a crack, otherwise I'll have to slog 
through the old code again fixing all the bugs I found for 5.3, only to 
replace the code again in 5.4.

Apologies for the rebase, but it was needed.

Main changes are:
* Removed QPageMargins and added QMarginsF instead
* QPageLayout uses QMarginsF and now has an enum and attribute for 
QPageLayout::Units to track what units are used for all the margins.  Turns 
out while this complicates some public api, it also simplifies the way the 
class is used in real code.
* QPageSize also has a QPageSize::Unit, that duplicates QPageLayout::Unit but 
I couldn't find a nice place to put a common enum.
* Both QPageLayout::Unit and QPageSize::Unit don't have a value for 
DevicePixels anymore as it doesn't make sense.  That simplifies api in a 
number of places by removing the resolution parm.

The main issues outstanding I see:
* Mac issue with PMPaper: in my testing I need the extra PMRetain to prevent a 
crash, but Morten gets a memory leak with it, and Andy reports it crashes for 
him anyway.  Try the latest code, if the issue still persists I'll look for an 
alternative way of doing things.
* Win is reported as being slow, that's an issue with the old code too, but 
the new code may make it slightly slower.  It's due to the DC being refreshed 
every time a setting is changed, which is plain slow.  Once the new code is in 
and handling the layout calculations, I think it's possible to remove the DC 
refresh at every step and just init the DC when start() is called.

If anyone else wants to test this, there's a few things you can run besides 
the auto tests:

examples/widgets/richtex/textedit
tests/manual/dialogs 
tests/manual/qprintdevice_dump

Cheers!

John.