GSoC Status - Week 5 (Customizable prints)

Lubomir I. Ivanov neolit123 at gmail.com
Wed Jul 1 06:51:13 PDT 2015


On 1 July 2015 at 16:37, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Wed, Jul 01, 2015 at 04:11:39PM +0300, Lubomir I. Ivanov wrote:
>> On 1 July 2015 at 15:37, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>> >
>> >
>> > On Wed, Jul 1, 2015 at 10:20 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
>> > wrote:
>> >>
>> >> how so?
>> >> in *all* of the previous implementations both resolution and colorMode
>> >> were visible/reflected on the preview!
>> >>
>> >
>> > I tested the color mode selection in the old printing code and it was not
>> > working in QPrintPreviewDialog, so this may be a QT5 bug?
>> > I tested with both v4.4.2 and commit f8a3a85 and it didn't work in any of
>> > them.
>
> So when is the last time this worked?

before Tomaz implemented profile2 and then it became a bit complicated
to integrate b&w profiles in profile2 (i.e. use our old custom color
tables from the GTK version).
i can't recall well the details, but i think the cause is that all the
"items" became new classes and all of then needed to be aware if
"grescale" is turned on before rendering the profile for prining.

>
>> i could be a Qt5 bug, indeed.
>
> 4.4.2 can still be built with Qt4 IIRC
>
>> the 4.x subsurface b&w print didn't work at all due to profile2.
>
> Yes, that is something that hasn't been addressed, yet.
>

explanation above.

>> >> both PrintDialog::onPaintRequested() and PrintDialog::printClicked()
>> >> call the same method Printer::print() which then calls
>> >> Printer::render() and greyscale mode becomes optional.
>> >>
>> >> what am i missing?
>> >
>> > I am doing exactly the same thing, and I call
>> > QPrinter::setColorMode(GrayScale) and I call Profile::setPrintMode(), am I
>> > missing something?
>>
>> right, so if you confirm that it simply doesn't work, then
>> setColorMode() is unreliable for b&w previews and we need to find an
>> alternative.
>> (and which is used for both the preview and the actual print).
>
> I'm lost here. What exactly isn't working? If you set
> QPrinter::setColorMode(GrayScale) and then print to a color printer, you
> still get color? Or you get something unusable on a color printer?
>

the print preview refuses to be greyscale even if
setColorMode(GrayScale) is set.

>
>> >> the profile2 custom color table is also doable but for now we should
>> >> simply use QPrinter::GrayScale.
>> >>
>> >
>> > I thing a solution for this we can use css to turn the whole page to gray
>> > scale before rendering also we will need to use the custom color table, what
>> > do you think about this?
>>
>> i don't understand CSS very well, but if that's a viable solution we
>> should definitely give it a go.
>
> Qt has fairly decent support of using CSS to style things. We don't use
> that a lot in Subsurface for a number of reasons but if that can be used
> to solve some of the printing challenges then I'm all for it.

that's mostly CSS related to the QWebView / webkit integration, which
is used for the new printing. the CSS support there should be full as
in a web browser.
Qt widgets on the other hand also support CSS, but AFAIK that's only a subset.

>
>> the problem i see here is that if the user defines a custom color CSS
>> for his template, we then need to override it if the b&w mode is
>> selected...messy.
>> let me ask Dirk in a separate email about the whole b&w/color print.
>
> Yeah, let's make sure I understand the issues there for real :)

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.

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.

lubomir
--


More information about the subsurface mailing list