GSoC Status - Week 7 (Customizable prints)

Lubomir I. Ivanov neolit123 at gmail.com
Sun Jul 19 12:56:19 PDT 2015


On 19 July 2015 at 13:23, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>
>
> On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> On 17 July 2015 at 22:17, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> > On 17 July 2015 at 22:10, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>> >>
>> >> Yes it does, you can test it on current master.
>> >>
>> >
>> >
>> > this is technically a Qt bug of sorts, because the QPrintEngine
>> > greyscale property for some *very odd* doesn't work in the preview
>> > dialog.
>>
>> (edit) "some *very odd* reason".
>>
>> will need to go AFK in a bit; drop me a line when you need me to
>> review again - e.g. tomorrow.
>
>
> I have fixed the gray-scale issue as we discussed, Now we always use
> QPrinter::setColorMode() during actual printing which produce nice grayscale
> prints, and use the css filter with the profile rasterization only during
> the previewing in the QPrintPreviewDialog with grayscale selected, I pushed
> the updates to my branch.
>

just pulled the latest commits (at 185eff2a60).

the preview works as expected - rasterized when greyscale and vector
when in color.
but the actual print always ends in color for me (table and profile)!

looking at the code the branch here is entered correctly:

if (printOptions->color_selected && printerPtr->colorMode()) {
    printerPtr->setColorMode(QPrinter::Color);
} else {
    printerPtr->setColorMode(QPrinter::GrayScale); // <-------------
this is called when "print in color" is unchecked
}

but setColorMode() simply doesn't work!
are you sure this works for you?
if it works for you but not for me, it could be Qt version specific in
which case setColorMode() is *completely unreliable* and we need to
use the raster/greyscale/css thing for the actual print as well.

---

BTW there is something very annoying in cmake and we need to fix that...

sometimes(tm) it fails randomly for me in an absolutely clean build with:

In file included from qt-models\filtermodels.cpp:2:0:
qt-ui/mainwindow.h:15:27: fatal error: ui_mainwindow.h: No suc
h file or directory
 #include "ui_mainwindow.h"

my set of commands are:
mkdir ./build
cd ./build
cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug
-DUSE_LIBGIT23_API=1 -DCMAKE_C_FLAGS="-Wall" -DCMAKE_CXX_FLAGS="-Wall"
-DCMAKE_COLOR_MAKEFILE=0 -DLIBGRANTLEE_FROM_PKGCONFIG=1
-DLIBGIT2_FROM_PKGCONFIG=1 -DLIBDC_FROM_PKGCONFIG=1 -DNO_DOCS=1
-DNO_MARBLE=1 -DNO_TESTS=1 -DNO_PRINTING=0 ..
make -j4

if for some reason it doesn't end up with the ui_mainwindow.h, it
builds correctly but then if i decide to change something in a source
file e.g. printer.cpp and try to call 'make'.
it throws this:
CMakeFiles\printing_templatesLink.dir\build.make:48: recipe for target 'CMakeFil
es/printing_templatesLink' failed
make[2]: *** [CMakeFiles/printing_templatesLink] Error 1
CMakeFiles\Makefile2:215: recipe for target 'CMakeFiles/printing_templatesLink.d
ir/all' failed
make[1]: *** [CMakeFiles/printing_templatesLink.dir/all] Error 2

and i need to clean *the entire* build folder and rebuild the entire tree again!
i can't call that an efficient build system...

you can try asking on IRC why these errors are happening if no one
responds in this thread.
my guess is that not many people are building with NO_PRINTING=0, ATM.

lubomir
--


More information about the subsurface mailing list