On Wed, Jul 1, 2015 at 9:01 PM, Lubomir I. Ivanov <[email protected]> wrote:
> On 1 July 2015 at 21:47, 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. > > > > a QPixmap does support color filters, but i'm not sure if QPainter > does, as a whole. > either way, this would still mean that the entire composition is ran > trough a single processing stage and it would be far from the > hardcoded color table unless we start dwelling into complicated > multidimensional signal processing. > > i'd suggest you leave this research for now, while implementing the > CSS thing and focus on the other tasks, like the template editor > dialog and the user-ready template. > > okay, I will continue working on the templateEdit dialog. -- regards, Gehad
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
