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. > > I'll be happy to be convinced that I'm wrong and that this adds a > valuable > > feature... I'm just poking at this to understand if this is the right > > space to focus our energy on. > > > > i think we should leave out the support for a special b&w color table > in profile2 and just make the print dialog option "print in color" > (when off) hard-translate everything to greyscale. > > lubomir > -- > -- regards, Gehad
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
