| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: I9f5c8a9135271161e2bce50bc413ea01a08c3a76
Reviewed-by: Akseli Salovaara <akseli.salovaara@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously copy and paste from PDFs made by Qt would paste garbage
into the target document, and searching was not possible. The bug
happened because the internal buffer would open its data stream in
truncate mode rather than append mode, thereby losing content, and
producing a slightly corrupted PDF.
Task: QTBUG-4912
Task: QTBUG-3661
RevBy: Trond Kjernåsen
(cherry picked from commit f7ee0c9efcb6cb36a95f49bc998524e25480f8ba)
|
|
|
|
|
| |
Task-number: QTBUG-6226
Reviewed-by: Eskil
|
|
|
|
|
|
| |
This fix just fixes up coding bugs here and there
Reviewed-by: Brad
|
|
|
|
| |
Reviewed-by: Samuel
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the width is multiplied into the dash, it needs to be divided out,
otherwise you can get a dashOffset which is greater than the pattern at
the index, and the dash can become negative. This will in turn lead to
passing a negative width to the rasterizer, which at some point will
get cast to an unsigned int and overflow. Depending on the position of
the line and size of the buffer, this will either crash or produce
garbled output.
Task-number: QT-4444
Reviewed-by: Samuel
|
|
|
|
|
|
|
|
|
|
|
| |
Change 979d1d3bbc0c68789edbe93f03464d41d7a8469a requires
qt_format_text() to honor the Qt::TextForceLeftToRight flag. Without
this, the text will be laid out RTL twice, and the output will be
broken. Since printing is done through QPicture, this fixes printing
when the UI is reversed.
Task-number: 261033
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the Windows print engine, we try to send a text item as a raw string
of characters to the printer driver if this is possible. This is to
facilitate using PDF-printers as much as possible, allowing them to
save the text in the document so for searching etc. We can only safely
do this if all the characters in the string are ASCII-compatible, i.e.
in the 7 bit range, since this is the only part of the set which is
guaranteed to be compatible across code pages.
Task-number: 180655
Reviewed-by: Trond
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
We need to floor instead of round to prevent rectangles that are on the
edge from being shifted one pixel down / right.
Task-number: 258776
Reviewed-by: Kim
|
|/
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trond
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Samuel
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
| |
Problem introduced by 7661126bc86ed105c02fd9b084ac5a91f12f10c4, which
introduced always rounding up when converting the rectangle's
coordinates to integers. This would e.g. cause off-by-one errors for the
cursor in QTextDocument. Some code paths depended on the ceiling of the
coordinates, and these have been reverted.
Task-number: 257914
Reviewed-by: Samuel
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
| |
Task-number: 254407
Reviewed-by: Gunnar
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In qt_scale_image_16bit() and qt_scale_image_32bit(), when a sample
point was located on the border between two pixels in the source image,
the sample point was rounded up instead of down. If a sample point was
exactly on the bottom or right edge of the source image, the function
would therefore sample a pixel outside the image. Because of how the
target rectangle is rounded, a sample point will never be exactly on
the top or left edge of the source image, so we will not get a similar
problem there.
I extended the lance test pixmap_scaling.qps.
Task-number: 258533
Reviewed-by: Samuel
|
|
|
|
| |
Reviewed-by: Samuel
|
|
|
|
|
|
|
| |
Polygonal vector paths may have types==null, in which case this
would have crashed.
Reviewed-by: Eskil
|
|
|
|
|
|
|
|
|
| |
The reason being that there was an assumption that any non-curved path
was a continous polyline. For paths with multiple subpaths in it
we need to split this up into multiple strokePolygonCosmetic calls.
Task-number: 257621
Reviewed-by: Kim Motoyoshi Kalland
|
|
|
|
|
|
|
|
|
| |
We normally pad the clip rect with the size of the pen and miterlimit
to avoid this, but this didn't handle the case where there was a long
diagonal dash. We also need to multiply the padding with the longest
dash.
Reviewed-By: Tom Cooksey
|
|
|
|
|
|
|
| |
This is a huge impact on performance whenever this path is
taken.
Reviewed-By: Tom Cooksey
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not all to happy with this fix, but its the best that one can
acheive given the current design. The problem is that QPdfBaseEngine
sets a number of states as part of updateState(), but only when we are
playing back through the alpha engine. These states are used in some
draw functions, also when we are recording in the alpha engine. This
leads to the states and their checks being out of sync. So to follow
the existing pattern in the code we need to not touch d-> vars prior
to a check to usesAlphaEngine.
Reviewed-By: Eskil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, don't call QWSWindowSurface::winId() in the destructor, as it
will actually request a new id if there isn't already one around - which
is a bit silly and highlighted the "real" bug.
Second, make sure QWSDisplay::Data::takeId() asks for 1 new id before
waiting for more ids to arrive. This is because waitForCreation() calls
QWSServer::processEventQueue(). If the events in the queue cause
takeId() to be called, QWSDisplay::Data::takeId() gets called
recursively. Even though there will be a create 15 ids command in the
queue, that will only allow 15 QWSDisplay::Data::takeId() calls to
return. The 16th call to QWSDisplay::Data::takeId() on the stack will
not be able to return because all the IDs have been taken and (because
it has been called recursively) no new create id commands have been
generated. So the 16th call to takeId() spins in waitForCreate().
Reviewed-by: Paul
|
|
|
|
|
|
|
|
|
|
|
| |
Add SuperH to the ever growing list of architectures which can't
correctly dereference a short* which is not 16-bit aligned. Turning this
into a white-list rather than a black list might make sense at some
point, but as QT_ARCH_I386 isn't defined on windows, the white list
looks even uglier at the moment. :-)
Task-number: 257077
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
| |
Line and polygon strokes did not respect the join/cap styles set
on a painter.
Task-number: 256914
Reviewed-by: Samuel
|
|
|
|
|
| |
Task-number: 256720
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that we did an accelerated move, i.e. scrolled the
widget's contents in the backing store and repainted the old area. We
cannot do this trick when the widget has been invalidated (show(),
resize()). In this case the widget had never been painted, so we
basically scrolled the content of its parent and the widget itself
appeared as invisible.
Auto-test included.
Task-number: 255117
Reviewed-by: Paul
|
|
|
|
|
|
|
|
|
|
| |
The documentation is a bit ambiguous on what the expected behavior here
is, but the behavior was consistent across paint engines before 4.5.
QPaintEngineEx introduced inconsistencies in the raster and OpenGL paint
engines, so this patch reverts the behavior back to what it was in 4.4.
Task-number: 256549
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
|
| |
Change from a relative to an absolute fuzzy compare as was the case
pre-4.4. With a relative fuzzy compare points that have an x or y
coordinate of 0 will never be merged with points that are very close to
0, for example (1e-15, 0).
Task-number: 251909
Reviewed-by: Trond
|
|
|
|
|
|
|
|
| |
Make sure not to use the broken QRect constructor, and do an early check
on whether the clip rect is empty in QRasterizer::rasterizeLine().
Task-number: 254105
Reviewed-by: Trond
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
The predefined dash patterns for Mac have always been off, compared to
the ones in the raster engine and the GL engine.
Task-number: 255292
Reviewed-by: Kim
|
|
|
|
|
|
|
|
| |
Though this variable always will be initialized in
QX11PaintEngine::begin() valgrind complains about conditional jump or
move depends on uninitialised value(s).
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
We didn't actually check the depth of the target window before
calling the qt_x11_drawImage() fu, that will only work with
depths >= 24.
Task-number: 255311
Reviewed-by: Samuel
BT: yes
|
|
|
|
|
|
|
|
|
|
|
| |
The blend functions assume the width / height of the images being
blended to be greater than 0. A width of 0 caused the first iteration of
a duff's device memcpy (QT_MEMCPY_USHORT) to be executed, thus blending
8 pixels instead of none.
BT: yes
Task-number: 255014
Reviewed-by: Trond
|
|
|
|
|
|
|
|
| |
The R and B channels were swapped on little endian machines with
BGR layout.
Task-number: 254934
Reviewed-by: Samuel
|
|
|
|
|
|
|
| |
This won't leak on error case, and will work with arbitrary sizes.
Also changed from int to short as instructed by Samuel.
Reviewed-by: Samuel <qt-info@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reworked the 85f98acaa3a38079071bea711e43c9a86edec1f6 fix, since
it broke glyph positioning in the GL engine under Windows.
Instead of changing the glyph cache margin, which impacts where
the glyph is positioned, we just make the image the glyph is drawn
into 4 pixels bigger in width/heigth.
The margin in QImageTextureGlyphCache needs to be reworked..
Task-number: 254450
Reviewed-by: Eskil
|
|
|
|
| |
Reviewed-by: Trust Me
|
|\ |
|
| |
| |
| |
| | |
Task-number: 252491
|
| |
| |
| |
| | |
Task-number: 252493
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 30f7edc0aab629499b74263391ae529ad31b2ff8.
There is no way to restore float-equal warning using the pragma trick.
This means (as it was mentioned in the said commit log) anyone that
includes qtransform.h will be forced to deal with float-equal.
Reviewed-by: Samuel Rødal
|
| |
| |
| |
| | |
The typo was in commit 30f7edc0aab629499b74263391ae529ad31b2ff8.
|
|/
|
|
|
| |
Task-number: 254179
Reviewed-by: Norwegian Rock Cat
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to optimizations, there are few cases where comparing with a constant
is needed, e.g. in operator*=. G++ will give us a warning for this.
Since we know what we are doing, surpress the warning.
The only drawback for this workaround is if somebody includes
qtransform.h in his code and disable the float-equal warning since
the warning will be activated again.
Reviewed-by: Samuel Rødal
|