GSoC Status - Week 5 (Customizable prints)

[Lubomir I. Ivanov]

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.

lubomir
--