[Kde-print-devel] [Bug 190646] implement in the printing system the feature "print only odd/even pages"

[Sergio]

https://bugs.kde.org/show_bug.cgi?id=190646


Sergio <sergio.callegari at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergio.callegari at gmail.com




--- Comment #19 from Sergio <sergio callegari gmail com>  2009-09-06 18:30:28 ---
Am I right to say (if not please correct me) that:

1) In Nokia's bug traker for QT the feature request is at
http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318

2) such feature request is accompanied by very little supporting material.
Specifically, there is no link to this bug report, nor any indication that the
lack of odd/even page selection brings as a consequence one of the most
criticized KDE regression from 3 to 4.

3) possibly as a consequence, only a very low priority has been given to the
feature request

4) the feature is not (not yet) in the planned feature list for qt 4.6, meaning
that we might have to do without it for another year or more if it does not get
accepted.

5) among the feature requests on Nokia's site there is no mention at all of
other printing features that kde 3 had, that acrobat reader has and that the QT
printer dialog misses, such as
- smart page selections (e.g. "4,5,7-10")
- page reordering for booklet printing

6) in principle if the new code mentioned above is accepted, there is a chance
to do the page selection much better than it was in kde 3. There, the
application had to render all the pages, and the page selection was done
afterwords. Here the application can be aware of the page selection and only
render those pages that need to (e.g. think of printing only page 1 from a 2000
page PDF).

7) It would be nice and possible to get features that were not even available
in kde 3. I am specifically thinking of distinguishing odd/even (namely page
selection made on source page numbers) from front/back (namely odd/even page
selection made with reference to what actually goes on paper. For instance,
imagine the case where one has a document were he is interested only in pages
1,7,8,9 and 11 and he wants to select them and printer them with manual duplex.
He would need first to do the page selection on the source pages, and then the
front/back selection with regards to what goes on print. Or think of a document
where all even pages are "intentionally left blank for notes". It would be nice
to first select odd pages only and then to still be able to select the front
pages and the back pages for manual duplex.

8) There appears to be a strong request for "software supported manual duplex".
However, it would be weird to have this request considered as alternative
(mutually exclusive) to even/odd page selection. Furthermore it would be
strange to see this request delaying the simpler odd/even selection mechanism.
So it makes little sense to ask for "software supported manual duplex"
/instead/ of even/odd page selection.

9) "Software supported manual duplex" would need some help from the print
system (typically cups) side. For instance, locking the printer throughout the
operation is necessary since linux is a multiuser OS (something that the
typical desktop user may easily forget). Also, the printer description in the
print system database should contain information about how the manual duplex is
to be done (since such information belongs there and not in the desktop
environment). So it would be nice to first have the cups camp accept the idea
of supporting manual duplex, and only then think of introducing it in kde.

I am mentioning the above points since it helps me better understand how to
most proficiently support the enhancing of the printing features of kde 4.

My current feeling is that there have been many complaints about the lack of
features in kde 4 with regards to kde 3, to the point of making some developers
unhappy. Indeed, developers have a point in saying that the users should
realize that features depending on other software projects (such as QT in this
case) cannot be instantaneously implemented by KDE developers only.

On the other hand, it is understandable that most users see just "KDE" and not
the pieces it depends upon and so they write/complain to KDE lists and not
elsewhere. To me, the real problem is that there is no thorough passing of the
feature requests from the KDE bug reporting system to the upstream projects
task trackers, with the unfortunate result that upstream no one really can
appreciate how important some features are considered by KDE's users.

Is there some way to fix this?
- Should we start linking this bug into
http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318?
Would it be better to crosspost?
- Should we start requesting some support for "assisted manual duplex" in cups
now?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.