Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 21, 2015 at 3:15 PM, Dirk Hohndel 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 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 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 Mon, Jul 20, 2015 at 4:59 PM, Dirk Hohndel wrote: > > > > > On Jul 20, 2015, at 07:30, Miika Turkia 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 Jul 20, 2015, at 07:30, Miika Turkia 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 Mon, Jul 20, 2015 at 5:27 PM, Gehad Elrobey wrote: > > On Jul 20, 2015 3:27 PM, "Dirk Hohndel" 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 3:27 PM, "Dirk Hohndel" 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? ___ 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 4:27 PM, Dirk Hohndel wrote: > On Mon, Jul 20, 2015 at 04:17:28PM +0300, Lubomir I. Ivanov wrote: >> >> - 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? >> > >> > >> > 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. Some fix for the issue of too small fonts might be required. Referring to this comment on this thread: "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." 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 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 wrote: > > > On Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov > wrote: >> >> On 20 July 2015 at 14:59, Gehad Elrobey 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 Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov wrote: > On 20 July 2015 at 14:59, Gehad Elrobey 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 20 July 2015 at 14:59, Gehad Elrobey 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 12:20 PM, Lubomir I. Ivanov
wrote:
> On 20 July 2015 at 13:06, Gehad Elrobey wrote:
> >
> >
> > On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov
> > wrote:
> >>
> >> On 19 July 2015 at 13:23, Gehad Elrobey 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
> >> >> wrote:
> >>
> >> >> > On 17 July 2015 at 22:10, Gehad Elrobey
> >> >> > 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 20 July 2015 at 13:06, Gehad Elrobey wrote:
>
>
> On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov
> wrote:
>>
>> On 19 July 2015 at 13:23, Gehad Elrobey wrote:
>> >
>> >
>> > On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov
>> > wrote:
>> >>
>> >> On 17 July 2015 at 22:17, Lubomir I. Ivanov
>> >> wrote:
>>
>> >> > On 17 July 2015 at 22:10, Gehad Elrobey
>> >> > 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 19 July 2015 at 13:23, Gehad Elrobey wrote:
>
>
> On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov
> wrote:
>>
>> On 17 July 2015 at 22:17, Lubomir I. Ivanov wrote:
>> > On 17 July 2015 at 22:10, Gehad Elrobey 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 Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov wrote: > On 17 July 2015 at 22:17, Lubomir I. Ivanov wrote: > > On 17 July 2015 at 22:10, Gehad Elrobey 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 17 July 2015 at 22:17, Lubomir I. Ivanov wrote: > On 17 July 2015 at 22:10, Gehad Elrobey 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 17 July 2015 at 22:10, Gehad Elrobey wrote: > > > On Fri, Jul 17, 2015 at 9:01 PM, Lubomir I. Ivanov > wrote: >> >> On 17 July 2015 at 21:54, Gehad Elrobey wrote: >> > >> > >> > On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov >> > wrote: >> >> > >> >> On 17 July 2015 at 21:36, Tomaz Canabrava 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 Fri, Jul 17, 2015 at 8:51 PM, Lubomir I. Ivanov wrote: > On 17 July 2015 at 21:49, Gehad Elrobey wrote: > > > > > > On Fri, Jul 17, 2015 at 8:37 PM, Lubomir I. Ivanov > > wrote: > >> > >> On 17 July 2015 at 21:13, Gehad Elrobey 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 Fri, Jul 17, 2015 at 9:01 PM, Lubomir I. Ivanov wrote: > On 17 July 2015 at 21:54, Gehad Elrobey wrote: > > > > > > On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov > > wrote: > > > >> On 17 July 2015 at 21:36, Tomaz Canabrava 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 17 July 2015 at 21:54, Gehad Elrobey wrote: > > > On Fri, Jul 17, 2015 at 8:46 PM, Lubomir I. Ivanov > wrote: > >> On 17 July 2015 at 21:36, Tomaz Canabrava 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 17 July 2015 at 21:42, Tomaz Canabrava wrote: > We d > > On Fri, Jul 17, 2015 at 3:37 PM, Lubomir I. Ivanov > wrote: >> >> On 17 July 2015 at 21:13, Gehad Elrobey wrote: >> > >> > >> > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov >> > 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 > i can see some QImage examples, but non to affect a whole QPainter/QPaintDevice. but overall, i don't think that QPicture supports palettes and greyscale, because it acts like a script. :( 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 wrote: > On 17 July 2015 at 21:36, Tomaz Canabrava 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:49, Gehad Elrobey wrote: > > > On Fri, Jul 17, 2015 at 8:37 PM, Lubomir I. Ivanov > wrote: >> >> On 17 July 2015 at 21:13, Gehad Elrobey wrote: >> > >> > >> > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov >> > 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:37 PM, Lubomir I. Ivanov wrote: > On 17 July 2015 at 21:13, Gehad Elrobey wrote: > > > > > > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov > > 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. -- 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:36, Tomaz Canabrava 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)
We d On Fri, Jul 17, 2015 at 3:37 PM, Lubomir I. Ivanov wrote: > On 17 July 2015 at 21:13, Gehad Elrobey wrote: > > > > > > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov > > 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 21:13, Gehad Elrobey wrote: > > > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov > 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)
> 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 > > >> >> >>> >>> -- >>> regards, >>> >>> Gehad >>> >>> >>> ___ >>> subsurface mailing list >>> subsurface@subsurface-divelog.org >>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >>> >>> >> > > > -- > 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:20 PM, Tomaz Canabrava wrote: > > > On Fri, Jul 17, 2015 at 3:13 PM, Gehad Elrobey > wrote: > >> >> >> On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov >> wrote: >> >>> On 17 July 2015 at 20:06, Gehad Elrobey 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 >>> 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 >>> wrote: >>> >> >> > >>> >> >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" < >>> neolit...@gmail.com> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> On 14 July 2015 at 00:16, Gehad Elrobey >> > >>> >> >> >> 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? >> > > > 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? > > >> >> -- >> regards, >> >> Gehad >> >> >> ___ >> subsurface mailing list >> subsurface@subsurface-divelog.org >> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >> >> > -- 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 3:13 PM, Gehad Elrobey wrote: > > > On Fri, Jul 17, 2015 at 8:08 PM, Lubomir I. Ivanov > wrote: > >> On 17 July 2015 at 20:06, Gehad Elrobey wrote: >> > >> > >> > On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov > > >> > wrote: >> >> >> >> On 14 July 2015 at 14:38, Gehad Elrobey >> 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 >> wrote: >> >> >> > >> >> >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" < >> neolit...@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> On 14 July 2015 at 00:16, Gehad Elrobey >> >> >> >> 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? > 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. > > -- > regards, > > Gehad > > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > > ___ 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 wrote: > On 17 July 2015 at 20:06, Gehad Elrobey wrote: > > > > > > On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov > > wrote: > >> > >> On 14 July 2015 at 14:38, Gehad Elrobey 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 > wrote: > >> >> > > >> >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" > > >> >> > wrote: > >> >> >> > >> >> >> On 14 July 2015 at 00:16, Gehad Elrobey > >> >> >> 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 20:06, Gehad Elrobey wrote: > > > On Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov > wrote: >> >> On 14 July 2015 at 14:38, Gehad Elrobey wrote: >> > >> > >> > On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov >> > wrote: >> >> >> >> On 14 July 2015 at 13:19, Gehad Elrobey wrote: >> >> > >> >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" >> >> > wrote: >> >> >> >> >> >> On 14 July 2015 at 00:16, Gehad Elrobey >> >> >> 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 Tue, Jul 14, 2015 at 1:43 PM, Lubomir I. Ivanov wrote: > On 14 July 2015 at 14:38, Gehad Elrobey wrote: > > > > > > On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov > > wrote: > >> > >> On 14 July 2015 at 13:19, Gehad Elrobey wrote: > >> > > >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" > >> > wrote: > >> >> > >> >> On 14 July 2015 at 00:16, Gehad Elrobey > 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 14 July 2015 at 15:08, Gehad Elrobey wrote: > > > On Tue, Jul 14, 2015 at 2:01 PM, Lubomir I. Ivanov > wrote: >> >> On 14 July 2015 at 14:51, Gehad Elrobey wrote: >> > >> > >> > On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov >> > wrote: >> >> >> >> On 14 July 2015 at 14:43, Lubomir I. Ivanov >> >> wrote: >> >> > On 14 July 2015 at 14:38, Gehad Elrobey >> >> > 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 2:01 PM, Lubomir I. Ivanov wrote: > On 14 July 2015 at 14:51, Gehad Elrobey wrote: > > > > > > On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov > > wrote: > >> > >> On 14 July 2015 at 14:43, Lubomir I. Ivanov > wrote: > >> > On 14 July 2015 at 14:38, Gehad Elrobey > 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 14 July 2015 at 14:51, Gehad Elrobey wrote: > > > On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov > wrote: >> >> On 14 July 2015 at 14:43, Lubomir I. Ivanov wrote: >> > On 14 July 2015 at 14:38, Gehad Elrobey 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 Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov wrote: > On 14 July 2015 at 14:43, Lubomir I. Ivanov wrote: > > On 14 July 2015 at 14:38, Gehad Elrobey 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:43, Lubomir I. Ivanov wrote: > On 14 July 2015 at 14:38, Gehad Elrobey 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. 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:38, Gehad Elrobey wrote: > > > On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov > wrote: >> >> On 14 July 2015 at 13:19, Gehad Elrobey wrote: >> > >> > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" >> > wrote: >> >> >> >> On 14 July 2015 at 00:16, Gehad Elrobey 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..) >> >> . >> 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. > ok >> >> 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. 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 wrote: > On 14 July 2015 at 13:19, Gehad Elrobey wrote: >> >> On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" wrote: >>> >>> On 14 July 2015 at 00:16, Gehad Elrobey 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 1:29 PM, Lubomir I. Ivanov wrote: > On 14 July 2015 at 13:19, Gehad Elrobey wrote: > > > > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" > wrote: > >> > >> On 14 July 2015 at 00:16, Gehad Elrobey 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 13:19, Gehad Elrobey wrote: > > On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" wrote: >> >> On 14 July 2015 at 00:16, Gehad Elrobey 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 13:19, Gehad Elrobey wrote:
>
> On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" wrote:
>>
>> On 14 July 2015 at 00:16, Gehad Elrobey 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]
...
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:20, Lubomir I. Ivanov wrote: > On 14 July 2015 at 13:19, Gehad Elrobey wrote: >> >> On Jul 14, 2015 12:15 PM, "Lubomir I. Ivanov" wrote: >>> >>> On 14 July 2015 at 00:16, Gehad Elrobey 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 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 Mon, Jul 13, 2015 at 11:22 PM, Lubomir I. Ivanov wrote: > On 14 July 2015 at 00:19, Lubomir I. Ivanov 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
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 00:19, Lubomir I. Ivanov 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 14 July 2015 at 00:16, Gehad Elrobey wrote: > > > On Mon, Jul 13, 2015 at 11:13 PM, Lubomir I. Ivanov > wrote: >> >> On 13 July 2015 at 23:54, Gehad Elrobey wrote: >> > >> > >> > On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov >> > >> > wrote: >> >> >> >> On 13 July 2015 at 22:35, Gehad Elrobey 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 Mon, Jul 13, 2015 at 11:13 PM, Lubomir I. Ivanov wrote: > On 13 July 2015 at 23:54, Gehad Elrobey wrote: > > > > > > On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov > > > wrote: > >> > >> On 13 July 2015 at 22:35, Gehad Elrobey 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 13 July 2015 at 23:54, Gehad Elrobey wrote: > > > On Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov > wrote: >> >> On 13 July 2015 at 22:35, Gehad Elrobey 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 Mon, Jul 13, 2015 at 10:33 PM, Lubomir I. Ivanov wrote: > On 13 July 2015 at 22:35, Gehad Elrobey 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 22:35, Gehad Elrobey 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
