On Wed, Jul 1, 2015 at 8:47 PM, Gehad Elrobey <[email protected]> wrote:
> > > On Wed, Jul 1, 2015 at 8:38 PM, Lubomir I. Ivanov <[email protected]> > wrote: > >> On 1 July 2015 at 19:05, Dirk Hohndel <[email protected]> wrote: >> > On Wed, Jul 01, 2015 at 05:23:32PM +0300, Lubomir I. Ivanov wrote: >> >> On 1 July 2015 at 17:18, Dirk Hohndel <[email protected]> wrote: >> >> > On Wed, Jul 01, 2015 at 04:51:13PM +0300, Lubomir I. Ivanov wrote: >> >> >> >> >> >> basically, i was going to ask about the whole b&w vs color printing. >> >> >> given that in the new print stack the user will have complete >> control >> >> >> of colors, layout and so on via templates, do we still need the >> "print >> >> >> in color" toggle, which will supposedly override the template colors >> >> >> and convert everything to greyscale. >> >> > >> >> > My instinctive reaction would be that this seems odd and redundant. >> If you >> >> > want greyscale, build a greyscale template. But I may be missing >> >> > something. >> >> > >> >> >> i would say, yes. >> >> >> also, we might have an easy solution to do that via CSS (suggested >> in >> >> >> a previous email), but Gehad needs to confirm it. >> >> > >> >> > Can you explain why you think the answer is yes? >> >> > >> >> >> >> it would act like an override, so if one likes a template, he/she can >> >> still toggle off the "print in color" and produce b&w output of said >> >> template. >> >> if it's way too difficult to implement, i guess we can consider it as >> >> redundant and remove the option completely. >> > >> > So IIRC the problem we had was that you had to pick smart "colors" >> (i.e., >> > good gray values) for b/w prints to look reasonable. >> > >> > So if I build a nice color template - how would this pick colors that >> work >> > well? >> > >> >> the text and tables would can be templated with custom colors, but the >> profile2 is what comes from the C++/Qt side (as an image) i.e. it >> needs further work to get it to what we had before - a custom >> greyscale color table or a custom color table, in that matter. >> >> in theory profile2 can even support custom colors which can be exposed >> to print templates...but that's extra work. >> >> > I'm not saying I'm against having it - I'm asking if this is worth >> > focusing time on vs. just creating a couple of strong b/w templates (and >> > fixing the profile2 problem which I think you have either way, >> correct?). >> > >> >> fixing the smart colors in profile2 would require the most energy, i'd >> say. every single class in the qt-ui/profile/ folder would need a >> "greyscale" flag, or some other way of doing it. >> the current solution which i'm proposing is (when "print in color" is >> off) is to simply tell the entire page to be converted to greyscale >> (no color table, just luminocity extraction or averaging, whatever the >> CSS option uses). >> >> > I am thinking if there is a way to apply some kind of b&w filters on the > QPainter after rendering the profile, this will be an easy solution to the > dive profile coloring problem instead of using a color table, I will look > into that. > At least this can work for Linux as we are currently using QImage to render the profile on which can be easily transformed to gray scale image. -- regards, Gehad
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
