Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 20, 2015 at 4:59 PM, Dirk Hohndel d...@hohndel.org wrote: On Jul 20, 2015, at 07:30, Miika Turkia miika.tur...@gmail.com wrote: Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. Funny, that was my first reaction as well. Yes that is really missing, re-sizing the window is on my todo list. And no, I haven't spent enough time with it. And I think it is well known that I am not great when it comes to colors and design and stuff... I'm sure we'll get some user contributed templates if we make it easy enough to do so. Which reminds me. How would one export / import a template? My intention was to make the templates customizable with the Edit Template Dialog, While importing a template can take place by modifying the custom template code. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 21, 2015 at 3:15 PM, Dirk Hohndel d...@hohndel.org wrote: On Tue, Jul 21, 2015 at 11:24:19AM +0200, Gehad Elrobey wrote: On Mon, Jul 20, 2015 at 4:59 PM, Dirk Hohndel d...@hohndel.org wrote: I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. Funny, that was my first reaction as well. Yes that is really missing, re-sizing the window is on my todo list. And no, I haven't spent enough time with it. And I think it is well known that I am not great when it comes to colors and design and stuff... I'm sure we'll get some user contributed templates if we make it easy enough to do so. Which reminds me. How would one export / import a template? My intention was to make the templates customizable with the Edit Template Dialog, While importing a template can take place by modifying the custom template code. That doesn't reall answer my question. User Joe is a genius with CSS and made a perfect template for US PADI divers. User Hans is German and creates a template that follows official REGULATION 14.5.34 from 1934 for the correct formatting of dive log entries (please think this phrase with a heavy German accent and it will be as funny as I want it to sound) and creates a German template that prints nice A5 log entries. Etc. How can they share these templates with others with the same needs? What I'm looking for is a couple of buttons: - export custom template (create file dialog and write it to a file) - import custom template (again, file dialog) and then remember that template as one of the options people can pick; I guess you'd have to copy it to our data folder to make sure it stays around Does that make more sense? Yes Dirk I got that. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 21, 2015 at 11:24:19AM +0200, Gehad Elrobey wrote: On Mon, Jul 20, 2015 at 4:59 PM, Dirk Hohndel d...@hohndel.org wrote: I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. Funny, that was my first reaction as well. Yes that is really missing, re-sizing the window is on my todo list. And no, I haven't spent enough time with it. And I think it is well known that I am not great when it comes to colors and design and stuff... I'm sure we'll get some user contributed templates if we make it easy enough to do so. Which reminds me. How would one export / import a template? My intention was to make the templates customizable with the Edit Template Dialog, While importing a template can take place by modifying the custom template code. That doesn't reall answer my question. User Joe is a genius with CSS and made a perfect template for US PADI divers. User Hans is German and creates a template that follows official REGULATION 14.5.34 from 1934 for the correct formatting of dive log entries (please think this phrase with a heavy German accent and it will be as funny as I want it to sound) and creates a German template that prints nice A5 log entries. Etc. How can they share these templates with others with the same needs? What I'm looking for is a couple of buttons: - export custom template (create file dialog and write it to a file) - import custom template (again, file dialog) and then remember that template as one of the options people can pick; I guess you'd have to copy it to our data folder to make sure it stays around Does that make more sense? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 20 July 2015 at 13:06, Gehad Elrobey gehadelro...@gmail.com wrote:
On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 19 July 2015 at 13:23, Gehad Elrobey gehadelro...@gmail.com wrote:
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@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.
Yes, setColorMode works fine for me using Qt 5.5.0 on arch linux, I have
attached a colored and gray-scale printouts with the current settings.
ok, in that case won't use setColorMode() at all. just make it raster
for greyscale - same as the preview method and vector for color mode.
the whole greyscale thing has taken too much time already and is very
questionable on application level as most modern drivers and spoolers
should have a greyscale override anyway.
BTW there is something very annoying in cmake and we need to fix that...
I ll try to figure out this.
thanks.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 20, 2015 at 12:20 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 20 July 2015 at 13:06, Gehad Elrobey gehadelro...@gmail.com wrote:
On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 19 July 2015 at 13:23, Gehad Elrobey gehadelro...@gmail.com wrote:
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov
neolit...@gmail.com
wrote:
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@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.
Yes, setColorMode works fine for me using Qt 5.5.0 on arch linux, I have
attached a colored and gray-scale printouts with the current settings.
ok, in that case won't use setColorMode() at all. just make it raster
for greyscale - same as the preview method and vector for color mode.
the whole greyscale thing has taken too much time already and is very
questionable on application level as most modern drivers and spoolers
should have a greyscale override anyway.
Now we always rasterize for grayscale, I pushed the updates.
--
regards,
Gehad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 20, 2015 at 04:17:28PM +0300, Lubomir I. Ivanov wrote: - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: 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 I don't get this, either. And I usually build on my ArchLinux box with printing enabled. Same goes for the Windows and Mac builds... do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 20 July 2015 at 16:10, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: 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 do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( do you think the timings are OK for the pencils down date? what else is on your TODO list? mind that there might be user feedback which will require some effort - e.g. feature requests usually do that. thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 20, 2015 at 5:27 PM, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 20, 2015 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 04:17:28PM +0300, Lubomir I. Ivanov wrote: - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: 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 I don't get this, either. And I usually build on my ArchLinux box with printing enabled. Same goes for the Windows and Mac builds... do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Jul 20, 2015, at 07:30, Miika Turkia miika.tur...@gmail.com wrote: Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. Funny, that was my first reaction as well. And no, I haven't spent enough time with it. And I think it is well known that I am not great when it comes to colors and design and stuff... I'm sure we'll get some user contributed templates if we make it easy enough to do so. Which reminds me. How would one export / import a template? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@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. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 19 July 2015 at 13:23, Gehad Elrobey gehadelro...@gmail.com wrote:
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com wrote:
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@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
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue.. Sorry, what do you mean by global colors? do you mean the almond_colors instance of the color struct? ignore this for now. just give the colors proper names in the dialog (e.g. Background etc..) Hello Lubomir, I have fixed the names in the TemplateEdit dialog as you have suggested, I have also fixed the QPrintPreviewDialog grayscale issue and pushed them to my branch. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 21:49, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:37 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:13, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? i see... well bummer, i can't find if Qt has shaders, custom color palettes, color delegates and such for QPicture/QPainter. which means that to convert something to greyscale it needs to be rasterized first. Tomaz, if you have any idea, do say. i guess for now you can only *rasterize* the profile if greyscale is enabled. but this isn't a pretty solution...we may have to attempt to use the custom color tables for the profile after all (i.e. what Tomaz brought back). :( but why are the tables raster - are you rasterizing the whole page? shouldn't the CSS greyscale filter preserve the vector? It seems that the greyscale filter render the whole page including the tables. you mean, it rasterizes them? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:36, Tomaz Canabrava tcanabr...@kde.org wrote: I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? graphicsview-common.h:QColor getColor(const color_indice_t i, bool isGrayscale = false); so, 90% of the time we are using getColor without the isGrayscale boolean, triggering the false state. this is where you should do your stuff :) grep getColor inside qt-ui/profile and see where you should change. I already tried to do this, I also added isGrayscale members in DiveProfileItem, but there are some remaining elements that I couldn't change into grayscale (eg. cylinder pressure curve and numbers on horizontal/vertical axis) please check the screenshot attached, Am I missing something? yes, in a few places we are not using the get color correctly and this needs to be fixed: tankitem.cpp ( see the setColorAt calls ) rulerItem.cpp ( check for QColor usage ) profileWidget.cpp ( check for QColor ) diveprofileItem.cpp ( check for // This paints the colors of the velocities. ) getSacColor also doesn't takes into consideration printMode thanks Tomaz, i admit that when i saw that profile2 didn't support the greyscale color table, i didn't even bother fixing this. :( Gehad, if we can't find an easy way to preserve everything in vector while in greyscale we may have to use the custom color table for the profile, after all. because having the profile and table in raster because of the greyscale mode is a bit subpar? The QPrinter::setColorMode() work very nicely it converts the whole printouts to grayscale pages without the need to rasterize the page, the only drawback is that this doesn't work correctly with the QPrintPreviewDialog which I think we may use the css filter way to work around this issue - we will not have identical previewing and printing methods though , what do you think? -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 21:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:36, Tomaz Canabrava tcanabr...@kde.org wrote: I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? graphicsview-common.h:QColor getColor(const color_indice_t i, bool isGrayscale = false); so, 90% of the time we are using getColor without the isGrayscale boolean, triggering the false state. this is where you should do your stuff :) grep getColor inside qt-ui/profile and see where you should change. I already tried to do this, I also added isGrayscale members in DiveProfileItem, but there are some remaining elements that I couldn't change into grayscale (eg. cylinder pressure curve and numbers on horizontal/vertical axis) please check the screenshot attached, Am I missing something? yes, in a few places we are not using the get color correctly and this needs to be fixed: tankitem.cpp ( see the setColorAt calls ) rulerItem.cpp ( check for QColor usage ) profileWidget.cpp ( check for QColor ) diveprofileItem.cpp ( check for // This paints the colors of the velocities. ) getSacColor also doesn't takes into consideration printMode thanks Tomaz, i admit that when i saw that profile2 didn't support the greyscale color table, i didn't even bother fixing this. :( Gehad, if we can't find an easy way to preserve everything in vector while in greyscale we may have to use the custom color table for the profile, after all. because having the profile and table in raster because of the greyscale mode is a bit subpar? The QPrinter::setColorMode() work very nicely it converts the whole printouts to grayscale pages without the need to rasterize the page, the only drawback is that this doesn't work correctly with the QPrintPreviewDialog which I think we may use the css filter way to work around this issue - we will not have identical previewing and printing methods though , what do you think? well, does setColorMode() preserve at least the vector graphics of the hard-copy - for both the table and profile? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Fri, Jul 17, 2015 at 9:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:36, Tomaz Canabrava tcanabr...@kde.org wrote: I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? graphicsview-common.h:QColor getColor(const color_indice_t i, bool isGrayscale = false); so, 90% of the time we are using getColor without the isGrayscale boolean, triggering the false state. this is where you should do your stuff :) grep getColor inside qt-ui/profile and see where you should change. I already tried to do this, I also added isGrayscale members in DiveProfileItem, but there are some remaining elements that I couldn't change into grayscale (eg. cylinder pressure curve and numbers on horizontal/vertical axis) please check the screenshot attached, Am I missing something? yes, in a few places we are not using the get color correctly and this needs to be fixed: tankitem.cpp ( see the setColorAt calls ) rulerItem.cpp ( check for QColor usage ) profileWidget.cpp ( check for QColor ) diveprofileItem.cpp ( check for // This paints the colors of the velocities. ) getSacColor also doesn't takes into consideration printMode thanks Tomaz, i admit that when i saw that profile2 didn't support the greyscale color table, i didn't even bother fixing this. :( Gehad, if we can't find an easy way to preserve everything in vector while in greyscale we may have to use the custom color table for the profile, after all. because having the profile and table in raster because of the greyscale mode is a bit subpar? The QPrinter::setColorMode() work very nicely it converts the whole printouts to grayscale pages without the need to rasterize the page, the only drawback is that this doesn't work correctly with the QPrintPreviewDialog which I think we may use the css filter way to work around this issue - we will not have identical previewing and printing methods though , what do you think? well, does setColorMode() preserve at least the vector graphics of the hard-copy - for both the table and profile? Yes it does, you can test it on current master. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Fri, Jul 17, 2015 at 8:51 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:49, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:37 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:13, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? i see... well bummer, i can't find if Qt has shaders, custom color palettes, color delegates and such for QPicture/QPainter. which means that to convert something to greyscale it needs to be rasterized first. Tomaz, if you have any idea, do say. i guess for now you can only *rasterize* the profile if greyscale is enabled. but this isn't a pretty solution...we may have to attempt to use the custom color tables for the profile after all (i.e. what Tomaz brought back). :( but why are the tables raster - are you rasterizing the whole page? shouldn't the CSS greyscale filter preserve the vector? It seems that the greyscale filter render the whole page including the tables. you mean, it rasterizes them? Yes I did, though when I test the HTML file with chromium everything remains vector graphics, I am not sure why this happens with Qt webkit, I need to test this more. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 9:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:36, Tomaz Canabrava tcanabr...@kde.org wrote: I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? graphicsview-common.h:QColor getColor(const color_indice_t i, bool isGrayscale = false); so, 90% of the time we are using getColor without the isGrayscale boolean, triggering the false state. this is where you should do your stuff :) grep getColor inside qt-ui/profile and see where you should change. I already tried to do this, I also added isGrayscale members in DiveProfileItem, but there are some remaining elements that I couldn't change into grayscale (eg. cylinder pressure curve and numbers on horizontal/vertical axis) please check the screenshot attached, Am I missing something? yes, in a few places we are not using the get color correctly and this needs to be fixed: tankitem.cpp ( see the setColorAt calls ) rulerItem.cpp ( check for QColor usage ) profileWidget.cpp ( check for QColor ) diveprofileItem.cpp ( check for // This paints the colors of the velocities. ) getSacColor also doesn't takes into consideration printMode thanks Tomaz, i admit that when i saw that profile2 didn't support the greyscale color table, i didn't even bother fixing this. :( Gehad, if we can't find an easy way to preserve everything in vector while in greyscale we may have to use the custom color table for the profile, after all. because having the profile and table in raster because of the greyscale mode is a bit subpar? The QPrinter::setColorMode() work very nicely it converts the whole printouts to grayscale pages without the need to rasterize the page, the only drawback is that this doesn't work correctly with the QPrintPreviewDialog which I think we may use the css filter way to work around this issue - we will not have identical previewing and printing methods though , what do you think? well, does setColorMode() preserve at least the vector graphics of the hard-copy - for both the table and profile? Yes it does, you can test it on current master. alright, let's not waste anymore time with this. just make the actual print use setColorMode() with everything in vector when in greyscale, while for the preview, only in greyscale we are going to use QImage for the profile and the CSS filter for everything else. for color mode though, the preview and the actual print should be the same and everything should be in vector. this is technically a Qt bug of sorts, because the QPrintEngine greyscale property for some *very odd* doesn't work in the preview dialog. if there is more time towards the end of GSoC we are going to get back to this and attempt some workarounds. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 21:36, Tomaz Canabrava tcanabr...@kde.org wrote: I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? graphicsview-common.h:QColor getColor(const color_indice_t i, bool isGrayscale = false); so, 90% of the time we are using getColor without the isGrayscale boolean, triggering the false state. this is where you should do your stuff :) grep getColor inside qt-ui/profile and see where you should change. I already tried to do this, I also added isGrayscale members in DiveProfileItem, but there are some remaining elements that I couldn't change into grayscale (eg. cylinder pressure curve and numbers on horizontal/vertical axis) please check the screenshot attached, Am I missing something? yes, in a few places we are not using the get color correctly and this needs to be fixed: tankitem.cpp ( see the setColorAt calls ) rulerItem.cpp ( check for QColor usage ) profileWidget.cpp ( check for QColor ) diveprofileItem.cpp ( check for // This paints the colors of the velocities. ) getSacColor also doesn't takes into consideration printMode thanks Tomaz, i admit that when i saw that profile2 didn't support the greyscale color table, i didn't even bother fixing this. :( Gehad, if we can't find an easy way to preserve everything in vector while in greyscale we may have to use the custom color table for the profile, after all. because having the profile and table in raster because of the greyscale mode is a bit subpar? mind that AFAIK, we didn't get a *single* complain that the greyscale mode isn't working for a while. Dirk, feature wise do we even need greyscale printing? to my understanding having the software controlled greyscale on/off is a convenience, but aren't modern printers supposed to have a toggle for that (haven't used one in a while)? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 20:06, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue.. Sorry, what do you mean by global colors? do you mean the almond_colors instance of the color struct? ignore this for now. just give the colors proper names in the dialog (e.g. Background etc..) Hello Lubomir, I have fixed the names in the TemplateEdit dialog as you have suggested, I have also fixed the QPrintPreviewDialog grayscale issue and pushed them to my branch. hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 20:06, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue.. Sorry, what do you mean by global colors? do you mean the almond_colors instance of the color struct? ignore this for now. just give the colors proper names in the dialog (e.g. Background etc..) Hello Lubomir, I have fixed the names in the TemplateEdit dialog as you have suggested, I have also fixed the QPrintPreviewDialog grayscale issue and pushed them to my branch. hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 21:13, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? i see... well bummer, i can't find if Qt has shaders, custom color palettes, color delegates and such for QPicture/QPainter. which means that to convert something to greyscale it needs to be rasterized first. Tomaz, if you have any idea, do say. i guess for now you can only *rasterize* the profile if greyscale is enabled. but this isn't a pretty solution...we may have to attempt to use the custom color tables for the profile after all (i.e. what Tomaz brought back). :( but why are the tables raster - are you rasterizing the whole page? shouldn't the CSS greyscale filter preserve the vector? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
We d On Fri, Jul 17, 2015 at 3:37 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 21:13, Gehad Elrobey gehadelro...@gmail.com wrote: On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: hello Gehad, without looking at the code, the greyscale mode works as expected, but both the Preview and actual Print now razterize everything on Windows (profile and table). we want them in vector graphics on all OSes and Qt versions where possible. perhaps, that's something you've overlooked? I am forces to render the dive profile on a QImage so that I can convert it to grayscale image and then render it on top of the QWebview, Do you think there is a way to convert the vector graphics to grayscale? i see... well bummer, i can't find if Qt has shaders, custom color palettes, color delegates and such for QPicture/QPainter. which means that to convert something to greyscale it needs to be rasterized first. Tomaz, if you have any idea, do say. i guess for now you can only *rasterize* the profile if greyscale is enabled. but this isn't a pretty solution...we may have to attempt to use the custom color tables for the profile after all (i.e. what Tomaz brought back). :( but why are the tables raster - are you rasterizing the whole page? shouldn't the CSS greyscale filter preserve the vector? Just found out: http://doc.qt.io/qt-5/qcolormap.html lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com wrote: On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@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. BTW, sorry for the back and forth action, but as you can see this greyscale/preview issue is problematic and there is not optimal way to approach it. for now, at least. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:20, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). ok, i see. i will test rest of the commits, once i get the build working again. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote:
On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote:
On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote:
Should I convert the dive profile to QImage during previewing only or
should
I convert it during actual printing also which will affect the printing
quality?
i can't build ATM, but i think the logic here is a bit wrong:
https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673
We must pass a QPaintDevice with type QPixmap for previewing and with
type QPrinter for actual printing.
does that include QPrintPreviewDialog as well? if so that's wrong.
you can use a QPixmap if you are rendering an image to be shown in the
template edit dialog, but the actual QPrintPreviewDialog contents
should be pretty much the same as the printed contents (on a hardcopy
or in a PDF).
No, the preview function is used for the QPixmap in the TemplateEdit only,
while the QPrintPreviewDialog uses the actual print() function.
qt-ui\templateedit.cpp:134:9: warning: enumeration value 'NoButton'
not handled in switch [-Wswitch]
switch (standardButton) {
^
qt-ui\templateedit.cpp:134:9: warning: enumeration value 'Save' not
handled in switch [-Wswitch]
...
more related warnings here
please add a 'default' switch so that these warnings are eliminated.
in general, building with -Wall is a good idea.
reviewing the patches now.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue... 2) print in color doesn't work - always prints in color; i guess you haven't finished the correct to-greyscale conversation yet, as we were discussing it just yesterday 3) i get no text / data in the tables under the profiles. could this be a bug on my end? i see these as important to have before the next pull request. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 14:29, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. never mind, this is a tricky one. i'm just going to leave it be for now, so that users can actually test it from master eventually. can we at least have names for the colors (e.g. Background, Table...etc) instead of color 1, color 2...? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 2:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? The font-size is initialized to 9 in PrintDialog if the QSettingsGroup is not stored, I think the font-size is not initialized because you already had the QSettingsGroup but this specific item was missing as it was not initialized before. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue.. Sorry, what do you mean by global colors? do you mean the almond_colors instance of the color struct? . 2) print in color doesn't work - always prints in color; i guess you haven't finished the correct to-greyscale conversation yet, as we were discussing it just yesterday Yes, Print in color works well in the printing mode only and not in the QPrintPreviewDialog, as I didn't implement what we have discussed yesterday yet. 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 15:08, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 2:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? The font-size is initialized to 9 in PrintDialog if the QSettingsGroup is not stored, I think the font-size is not initialized because you already had the QSettingsGroup but this specific item was missing as it was not initialized before. yes, that seems to be the case. i've deleted the settings group from the win32 registry and now, after running subsurface the font size is correct (i.e. 9). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 13 July 2015 at 22:35, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the following tasks: - Enhancing the one dive per page template. - Refactoring the Printing class to handle QPrinter and QPixmap. - Implement the Preview section in TemplateEdit dialog. - Adding color tab to TemplateEdit. - Adding color palettes to template settings. nice, i will take a look tomorrow. This week I will mainly work to enhance the user experience and add remaining templates (eg. flow layout), Also I want to fix any bugs as soon as possible so testing the whole thing now can be very useful. I have done some work to fix the gray-scale issue in the dive profile, I have attached a picture of the dive profile after my progress, But there are still some dive profile items that I couldn't change to gray-scale (eg. numbers on the axis and the cylinder pressure curve), I also needed to change the QPixmaps to QImages and transformed them to gray-scale manually, So I am not sure If I am progressing in the correct direction regarding the dive profile gray-scale issue. at least a couple of times, i've said to approach the whole thing using the convert everything to greyscale via CSS method. mind that this is a feature that is not very important (not that many i want to print in greyscale requests by users out there) and we should attempt to save time by doing the easier solution. the approach of let's bring back the custom greyscale color table that was in Profile1 is going to eat a lot time and is questionable as a maintainable code-base feature, unless we decide to add customizable user colors in the profile at some point. have you encountered problems with the CSS filter approach? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 13, 2015 at 11:13 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 23:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 22:35, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the following tasks: - Enhancing the one dive per page template. - Refactoring the Printing class to handle QPrinter and QPixmap. - Implement the Preview section in TemplateEdit dialog. - Adding color tab to TemplateEdit. - Adding color palettes to template settings. nice, i will take a look tomorrow. This week I will mainly work to enhance the user experience and add remaining templates (eg. flow layout), Also I want to fix any bugs as soon as possible so testing the whole thing now can be very useful. I have done some work to fix the gray-scale issue in the dive profile, I have attached a picture of the dive profile after my progress, But there are still some dive profile items that I couldn't change to gray-scale (eg. numbers on the axis and the cylinder pressure curve), I also needed to change the QPixmaps to QImages and transformed them to gray-scale manually, So I am not sure If I am progressing in the correct direction regarding the dive profile gray-scale issue. at least a couple of times, i've said to approach the whole thing using the convert everything to greyscale via CSS method. mind that this is a feature that is not very important (not that many i want to print in greyscale requests by users out there) and we should attempt to save time by doing the easier solution. the approach of let's bring back the custom greyscale color table that was in Profile1 is going to eat a lot time and is questionable as a maintainable code-base feature, unless we decide to add customizable user colors in the profile at some point. have you encountered problems with the CSS filter approach? As the dive profile is rendered on top of the QWebView after the Html page is already displayed. the css filtering will not affect the dive profile and will only affect the content of the HTML page, that's why I though I should render a gray scale version of the dive profile. i forgot about that part. in that case, use the CSS filtering on the QWebView page but also convert the whole profile QImage/QPixmap to greyscale (not individual profile item classes using the custom color table). Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 22:35, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the following tasks: - Enhancing the one dive per page template. - Refactoring the Printing class to handle QPrinter and QPixmap. - Implement the Preview section in TemplateEdit dialog. - Adding color tab to TemplateEdit. - Adding color palettes to template settings. nice, i will take a look tomorrow. This week I will mainly work to enhance the user experience and add remaining templates (eg. flow layout), Also I want to fix any bugs as soon as possible so testing the whole thing now can be very useful. I have done some work to fix the gray-scale issue in the dive profile, I have attached a picture of the dive profile after my progress, But there are still some dive profile items that I couldn't change to gray-scale (eg. numbers on the axis and the cylinder pressure curve), I also needed to change the QPixmaps to QImages and transformed them to gray-scale manually, So I am not sure If I am progressing in the correct direction regarding the dive profile gray-scale issue. at least a couple of times, i've said to approach the whole thing using the convert everything to greyscale via CSS method. mind that this is a feature that is not very important (not that many i want to print in greyscale requests by users out there) and we should attempt to save time by doing the easier solution. the approach of let's bring back the custom greyscale color table that was in Profile1 is going to eat a lot time and is questionable as a maintainable code-base feature, unless we decide to add customizable user colors in the profile at some point. have you encountered problems with the CSS filter approach? As the dive profile is rendered on top of the QWebView after the Html page is already displayed. the css filtering will not affect the dive profile and will only affect the content of the HTML page, that's why I though I should render a gray scale version of the dive profile. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 13 July 2015 at 23:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 22:35, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the following tasks: - Enhancing the one dive per page template. - Refactoring the Printing class to handle QPrinter and QPixmap. - Implement the Preview section in TemplateEdit dialog. - Adding color tab to TemplateEdit. - Adding color palettes to template settings. nice, i will take a look tomorrow. This week I will mainly work to enhance the user experience and add remaining templates (eg. flow layout), Also I want to fix any bugs as soon as possible so testing the whole thing now can be very useful. I have done some work to fix the gray-scale issue in the dive profile, I have attached a picture of the dive profile after my progress, But there are still some dive profile items that I couldn't change to gray-scale (eg. numbers on the axis and the cylinder pressure curve), I also needed to change the QPixmaps to QImages and transformed them to gray-scale manually, So I am not sure If I am progressing in the correct direction regarding the dive profile gray-scale issue. at least a couple of times, i've said to approach the whole thing using the convert everything to greyscale via CSS method. mind that this is a feature that is not very important (not that many i want to print in greyscale requests by users out there) and we should attempt to save time by doing the easier solution. the approach of let's bring back the custom greyscale color table that was in Profile1 is going to eat a lot time and is questionable as a maintainable code-base feature, unless we decide to add customizable user colors in the profile at some point. have you encountered problems with the CSS filter approach? As the dive profile is rendered on top of the QWebView after the Html page is already displayed. the css filtering will not affect the dive profile and will only affect the content of the HTML page, that's why I though I should render a gray scale version of the dive profile. i forgot about that part. in that case, use the CSS filtering on the QWebView page but also convert the whole profile QImage/QPixmap to greyscale (not individual profile item classes using the custom color table). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 13, 2015 at 11:13 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 23:54, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 13 July 2015 at 22:35, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the following tasks: - Enhancing the one dive per page template. - Refactoring the Printing class to handle QPrinter and QPixmap. - Implement the Preview section in TemplateEdit dialog. - Adding color tab to TemplateEdit. - Adding color palettes to template settings. nice, i will take a look tomorrow. This week I will mainly work to enhance the user experience and add remaining templates (eg. flow layout), Also I want to fix any bugs as soon as possible so testing the whole thing now can be very useful. I have done some work to fix the gray-scale issue in the dive profile, I have attached a picture of the dive profile after my progress, But there are still some dive profile items that I couldn't change to gray-scale (eg. numbers on the axis and the cylinder pressure curve), I also needed to change the QPixmaps to QImages and transformed them to gray-scale manually, So I am not sure If I am progressing in the correct direction regarding the dive profile gray-scale issue. at least a couple of times, i've said to approach the whole thing using the convert everything to greyscale via CSS method. mind that this is a feature that is not very important (not that many i want to print in greyscale requests by users out there) and we should attempt to save time by doing the easier solution. the approach of let's bring back the custom greyscale color table that was in Profile1 is going to eat a lot time and is questionable as a maintainable code-base feature, unless we decide to add customizable user colors in the profile at some point. have you encountered problems with the CSS filter approach? As the dive profile is rendered on top of the QWebView after the Html page is already displayed. the css filtering will not affect the dive profile and will only affect the content of the HTML page, that's why I though I should render a gray scale version of the dive profile. i forgot about that part. in that case, use the CSS filtering on the QWebView page but also convert the whole profile QImage/QPixmap to greyscale (not individual profile item classes using the custom color table). Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? QImage should be used for both the preview and the actual print as it *should* give us a vector profile. basically we are aiming to have the preview as close as the actual print. then again, there was this huge lines issues with QImage on Linux in Qt5.x, so if this bug is still present QPixmap should be used. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 00:19, Lubomir I. Ivanov neolit...@gmail.com wrote: then again, there was this huge lines issues with QImage on Linux in Qt5.x, so if this bug is still present QPixmap should be used. via Q_OS_LINUX branching that is; same as the code we had in the previous printing stack. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Mon, Jul 13, 2015 at 11:22 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:19, Lubomir I. Ivanov neolit...@gmail.com wrote: then again, there was this huge lines issues with QImage on Linux in Qt5.x, so if this bug is still present QPixmap should be used. via Q_OS_LINUX branching that is; same as the code we had in the previous printing stack. Ok, I understand that -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
