Serious concerns about the print framework in 2.9

[jmfauth]

A few days ago I took a look (again) at wxPython 2.9

To draw data, one needs a DC and its size (a rectangle
of n x m pixels). The developer has this rectangle to
prepare the drawing and the user sees this rectangle
on the screen. I'm calling this the "real rectangle".

Now the problem, mainly PrintPreview.

In wx2.8.11, the PrintPreview uses "correct values"
for the real rectangle (logically varying as fct of the
zoom factor). It is possible for the developer to make
precise drawing.

In wx2.9, the DC size is fixed (printer values) and the
PrintPreview is doing its own scaling (or is attempting to do).
This has the side effect, it destroys all the precise
work you may have prepare in a "printout.drawing_function()".

For a "general drawing", the impact of this may not be
too dramatic, but as soon as one wishes to draw scientific
data, it is really problematic. Drawing such data is simply
impossible. I even succeed to find cases where data are
plotted, but nothing is visible !

It is impossible to have a perfect print preview (unless
the real rectangle matches the paper rectangle), but
the trick to understand it that in the former case (2.8)
the rounding errors are somehow "consistant" and one
ends up in having a suitable plot.

In the latter case (2.9), the "rounding errors" are
for each zoom factor different making a suitable
plot impossible.

I can only strongly recommend to revert to the previous
situation, not perfect, but at least working.

jmf

[Václav Slavík]

Hi,

On Feb 8, 2011, at 8:33, jmfauth wrote:
> In the latter case (2.9), the "rounding errors" are
> for each zoom factor different making a suitable
> plot impossible.
>
> I can only strongly recommend to revert to the previous
> situation, not perfect, but at least working.

"Not perfect" is a great understatement and "working" isn't exactly the word I'd use for it. 2.8's preview regularly god the results completely wrong, showing different word wrap or even number of pages from the version that would be printed. This was finally fixed in 2.9.

If you're depending on 2.8's bugs, you should consider changing your code to remove such assumptions. If you can reproduce incorrect preview in one of the wx samples (after some reasonably-sized modifications), please create a ticket and attach such patch there so that we can reproduce the behavior.

Thanks,
Vaclav

[jmfauth]

On Feb 8, 10:53 am, Václav Slavík <vsla...@gmail.com> wrote:
> Hi,
>
I do not wish to discuss the pros and the cons of 2.8 or 2.9.
To be pragmatic, just take a look of this image.

[link]

The top image is a taken from a preview in 2.8 and the bottom
image is a 2.9 preview. The images look the same for all
preview zoom factors.

I reduced the problem to the minimum. Now assume this is
a preview of "scientific data", the blue rectangle is
a coordinate system and the two red lines are the data.
The data correspond to the y min and y max of the
rectangle.
Obviously there is something wrong here. It is impossible
to draw data correctly.

Where the problem is coming from? I do not know and I can
not point the guilty part of the wx code.

As I have a large experience in drawing this kind of stuff.
I suspect the problem is coming from the internal scaling
of the preview and the way how data a scaled and rounded,
this is what I was calling a "non consistent rounding error".

In the present case, the blue rectangles are drawn with
a dc.DrawRectangle() and a dc.SetClippingRegion() and the
data, the red lines, are drawn with a dc.DrawLine().
My feeling is that these objects are not drawn and/or scaled
and/or calculated with an identical "algorithm" leading to
light differences, generally of 0 or 1 pixel. The top red
line which should correspond to the top border of the rectangle
is shifted by one pixel. The bottom red line should correspond
to the bottom border of the rectangle and is not drawn at all.

Note: if my printout_instance.drawdata() is throwing these data
to a pdf printer (can be 2.8 or 2.9), they look correct, similarely
to 2.8 for all zoom factors of the pdf viewer. This is somehow
indicating the 2.9 printpreview is not working the way one expect
I should.

To summarize the present status:
2.8: "not correct" but usable
2.9: "may be considered as more correct, but not usable".
Unfortunate.

Test: wxPython-2.8.11.0-ansi, wxPython-2.9.1, Python 2.7 on Windows 7.

Sorry, I can help more. I'm only an end user.

PS: the screenshots of the pxy and wese applications at
[link] are showing the kind of applications I'm writing.

Regards,
jmf

[Václav Slavík]

Hi,

On Feb 11, 2011, at 17:43, jmfauth wrote:
> Where the problem is coming from? I do not know and I can
> not point the guilty part of the wx code.

As I said, it would be enough to show us usable (i.e. small patch against a sample) code that demonstrates the problem clearly. An image is not debuggable, sorry (and yours doesn't even show anything that would clearly point to a problem in wx itself).

Vaclav

[jmfauth]

On Feb 12, 2:41 pm, Václav Slavík <vsla...@gmail.com> wrote:

Well, I figured out that you could understand what's
happen beyond the scene.

Do not ask me to dive in the wx code, the only thing I can
do is to provide my test drawing function (Python).

One another way to illustrate the problem and check
the drawing is to just draw the dc.size().

Question / comment / suggestion:

Usually when I draw my scientific data (2d), I use my
my own lib to handle all this "rescaling" stuff and I rely
only on the basic primitives, DrawLine(), DrawRectangle(), ...
to render the results (with wx or with other tools).

When one recalculates a "scale", one ends up with float
values (understand non integers, screen pixel units).
One common error which leads to "non consistent error"
is to round these values instead of truncate, int(), them.

Just an idea.

---

# ok, for all zoom factors in 2.8; varying dc.size
# not ok for all zoom factors in 2.9; dc.size on *my*
# platform == (6778, 4760); inconsistences: red lines may
# or may not be drawn or may or may not be 1-pixel shifted.

def PlotOnDC(dc):
print 'dc.size', dc.GetSize()

# preparation of the rendering area
# may be assumed to be hard coded
dcwi, dche = dc.GetSize()[0], dc.GetSize()[1]
c = 0.2
p1x, p1y = c * dcwi, c * dche
p2x, p2y = dcwi - c * dcwi, dche - c * dche
p1x, p1y = int(p1x), int(p1y)
p2x, p2y = int(p2x), int(p2y)
wi = p2x - p1x
he = p2y - p1y

pen = wx.Pen(wx.BLUE, 1, wx.SOLID)
dc.SetPen(pen)

dc.DrawRectangle(p1x, p1y, wi, he)
dc.SetClippingRegion(p1x, p1y, wi, he)

pen = wx.Pen(wx.RED, 1, wx.SOLID)
dc.SetPen(pen)
c = 30
dc.DrawLine(p1x - c, p1y + 0, p2x + c, p1y + 0)
dc.DrawLine(p1x - c, p2y - 1, p2x + c, p2y - 1)

---


# ok, for all zoom factors in 2.8; varying dc.size
# failed for all zoom factors in 2.9; dc.size on *my*
# platform == (6778, 4760)

def PlotOnDC(dc):
print 'dc.size', dc.GetSize()
dcwi, dche = dc.GetSize()[0], dc.GetSize()[1]
pen = wx.Pen(wx.BLUE, 1, wx.SOLID)
dc.SetPen(pen)
dc.DrawRectangle(0, 0, dcwi - 1, dche - 1)


I really do not see, what I can do more.