GSoC Status - Week 5 (Customizable prints)

[Gehad Elrobey]

On Wed, Jul 1, 2015 at 8:38 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

> On 1 July 2015 at 19:05, Dirk Hohndel <dirk at hohndel.org> wrote:
> > On Wed, Jul 01, 2015 at 05:23:32PM +0300, Lubomir I. Ivanov wrote:
> >> On 1 July 2015 at 17:18, Dirk Hohndel <dirk at hohndel.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150701/9ef7717c/attachment-0001.html>