GSoC Status - Week 5 (Customizable prints)

[Gehad Elrobey]

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

> On 1 July 2015 at 21:47, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> >
> >
> > 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.
> >
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150701/5d6e4b08/attachment.html>