View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007101 | Scribus | Graphics / Image Frames | public | 2008-06-21 16:25 | 2008-06-22 20:37 |
Reporter | knieriem | Assigned To | jghali | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | unable to reproduce | ||
Platform | i686 | OS | Debian | OS Version | Etch |
Product Version | 1.3.3.12svn | ||||
Summary | 0007101: Some pictures in documents saved as PDF get a column of black pixels at the right | ||||
Description | When saving a document as PDF, one can turn on the "Resample Images to:" option, so the generated PDF will only contain images at the chosen resolution. For some values of the target resolution, some images might have a black pixel column at the right side. This seems to depend on the actual resolution of the photo in the image frame. For instance, it might have an actual resolution of 720DPI. When choosing "Resample images to 87 DPI", the result will show that black column, but for 84 DPI it will be ok. It is irrelevant whether the images get encoded into the PDF as zip or jpeg, or what the image format of the source file is. The attached archive contains two PDF files, one at 87, the other at 84 DPI. The former shows the black pixel column. I get the same results with Scribus 1.3.4. | ||||
Steps To Reproduce | -Open test133.sla in Scribus, perhaps with LANG=C prepended. -Select "Save as PDF". -Turn on the "Resample Images to:" option at the bottom -Select 87 DPI. -Save the PDF, then open it in a viewer - it should show the black pixels at the right. -With 84 DPI it should look ok. | ||||
Tags | No tags attached. | ||||
Patch | |||||
2008-06-21 16:25
|
|
|
Hmmm, strange... i cannot reproduce the issue on Windows... Neither with 1.3.3.12 nor with 1.3.5svn |
|
Cannot replicate this with 1.3.3.12 final or 1.3.5svn |
|
The place, where the resampling is done, apparently is line 5367 in scribus-1.3.3.12/scribus/pdflib.cpp. I temporarily replaced smoothScale by scaleImage, and the effect vanished. Since smoothScale is part of Qt, I suppose the problem could have something to do with the particular version of libqt-mt on my system: 3.3.7-4etch1 Which version of libqt-mt are you using, perhaps I could try that one ... ? Thanks, Michael |
|
qt-3.3.8 for me on Windows |
|
After installing a backport to Debian Etch of libqt3-mt (v3.3.8b-5), the problem actually has gone away. (It's strange that there is no obvious difference between Qt's kernel/qimage.cpp of versions 3.3.7 and 3.3.8, and no hint in the changelog that somehing related to this has been fixed. Perhaps only the Debian package was affected by this problem, or there is a bug somewhere that still persists, but which is unvisible now due to different build/runtime conditions.) |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-06-21 16:25 | knieriem | New Issue | |
2008-06-21 16:25 | knieriem | File Added: blpixel.tar.gz | |
2008-06-21 17:22 | jghali | Note Added: 0019870 | |
2008-06-22 11:56 |
|
Note Added: 0019871 | |
2008-06-22 11:56 |
|
Resolution | open => unable to reproduce |
2008-06-22 11:58 |
|
Status | new => resolved |
2008-06-22 15:14 | knieriem | Status | resolved => feedback |
2008-06-22 15:14 | knieriem | Resolution | unable to reproduce => reopened |
2008-06-22 15:14 | knieriem | Note Added: 0019872 | |
2008-06-22 15:19 | jghali | Note Added: 0019873 | |
2008-06-22 19:00 | knieriem | Note Added: 0019874 | |
2008-06-22 20:37 | jghali | Status | feedback => resolved |
2008-06-22 20:37 | jghali | Resolution | reopened => unable to reproduce |
2008-06-22 20:37 | jghali | Assigned To | => jghali |
2008-06-22 20:37 | jghali | Status | resolved => closed |
2008-08-21 21:52 | jghali | Relationship added | has duplicate 0006782 |
2015-09-17 20:10 | Kunda | Category | Graphics / Image Frames => Graphics/Img Frames |
2015-09-17 20:11 | Kunda | Category | Graphics/Img Frames => Graphics / Image Frames |