GSoC Status - Week 5 (Customizable prints)

[Tomaz Canabrava]

On Wed, Jul 1, 2015 at 3:47 PM, 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.
>

pixel = (uchar*) (image->scanLine(i)+j);
uchar v = (uchar) ((11*pixel[0]+16*pixel[1]+5*pixel[2])/32);
pixel[1]=p[2]=p[0]=v;


>
>
>> > 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
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150701/1370a606/attachment.html>