This is another print capability that needs to be implemented manually for printers that doesn't support it like Print To File
Created attachment 127367 [details] Patch It supports collated and uncollated copies.
Comment on attachment 127367 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=127367&action=review > Source/WebKit2/WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp:329 > + collated = 0; This puzzled me. Why do you set collated to 0 in this case? Is it so that if there are uncollated copies left the count will start from scratch?
(In reply to comment #2) > (From update of attachment 127367 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=127367&action=review > > > Source/WebKit2/WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp:329 > > + collated = 0; > > This puzzled me. Why do you set collated to 0 in this case? Is it so that if there are uncollated copies left the count will start from scratch? No, there can't be collated and uncollated at the same time, they are mutually exclusive. When collatedCopiesLeft() is 0, it's because collated == collatedCopies - 1, so we reset it to 0, so that next page is collated again.
Comment on attachment 127367 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=127367&action=review >>> Source/WebKit2/WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp:329 >>> + collated = 0; >> >> This puzzled me. Why do you set collated to 0 in this case? Is it so that if there are uncollated copies left the count will start from scratch? > > No, there can't be collated and uncollated at the same time, they are mutually exclusive. When collatedCopiesLeft() is 0, it's because collated == collatedCopies - 1, so we reset it to 0, so that next page is collated again. OK, makes sense
Committed r108089: <http://trac.webkit.org/changeset/108089>