duplicate

*** This issue has been marked as a duplicate of 59506 ***

closed

Adding updated info from followup on issue 59506 here...  

Some people will want collate on as the default... just for convenience.  Many
people have asked for it, and unfortunately it was given to them in OO 3.0
without any real regard to the consequences.  Many people will have severe
problems with the default being "on", and our business is one of them (as I
explained in a previous comment, above).

There might be some type of different options under other OS's (MSWin/MacOS),
but under Linux it is very problematic using the collate function on.

The suggestion about storing the collate setting per printer is probably not
practical, since there is no user interface in OO that addresses saved options
on a per-printer basis (unless they want to resurrect the spadmin tool, which is
now pretty much dead).  Storing such a setting in a document doesn't really make
any sense.

So the only best remaining way to handle the problem is to make an option in
tools->printing that can hold a user's preference for collation:

1) Remember previously used state (begin with setting off)
2) Always default to off
3) Always default to on
4) Always remain off (and don't show option in print dialog)

With the default setting for new installations set to #1 (since that is most
logical).

The above change would solve the problem for most people once and for all. 
Although there should also be a way that a system administrator can set the
default for new users, to make the problem absolutely solvable on systems where
printers do their own collation all the time (which is most modern laser
printers and copiers).

pardon me, but a listbox on an option page that nobody finds that configures the
on/off behavior of a single checkbox seems a tad overengineered to me.
Especially since it does not satisfy you requirement that a site administrator
can force collation to off.

How about you get the configuration file entry for the site administrator that
supports "Collate persistent (as last state)" and "Never collate" ? Please be
also advised, that we're talking only the print dialog here, not whatever any
script will do if printing a document.

I agree that my UI suggestion be overdoing it a tad...as an administrator, I
tend to like lots of options :)

As an alternative, I suggest that the print dialog should be changed to remember
the previously selected state for collate, for all users, and start off with
collate unchecked (OFF) for new installs, since that it is the safest setting
for all situations.  Everyone will get what they want and need.  Those irritated
with the old behavior of it always reverting to uncollated will only have to
check it once.  Those who don't know the difference, don't care, or won't mess
with it, will have a default that does not cause problems for page printers.

Then for further refinement or lockdown, give options in the configuration file
entry for the site administrator that could turn it off and/or hide it.

I don't think having only a config file without changing the print dialog
default behavior is good enough, since that presupposes that sites (and even end
users) know there is the problem to begin with.  For example, I didn't discover
the problem until after implementation was already completed and OO 3.0/1 rolled
out to users because I never thought to test multiple copies of large documents.
 It never occurred to me that OO would send hundreds of identical 50MB print
jobs when collation used to work fine with collate "off".  After the network
became saturated and server and end-user performance suffered, only then did I
discover it... (and had absolutely no way to fix it).

Whatcha think?  A reasonable compromise?

It would be useful to know if this issue only affects Linux or also other
platforms as well.  For example, if you set collate "ON" in MacOS version and
send 2 copies of a 10MB multipage document to an intelligent page printer, does
it send 20MB (2 x 10) to the printer or just 10MB?  (It is easiest to determine
this by including large bitmap graphics in the test document, then check the
CUPS logs to see the size for a 1 qty print job, vs a 2 qty print job)

Do note, however, that the proposed solution would not adversely affect other OS
versions.

Considering that the current behavior, if it may be a real problem, is not an
"error" in the meaning of "Ooops something is broken" but the result of an
intended enhancement, this issue should be qualified as enhancement as well.

@crxssi: Please don't set "Target milestone" by yourself. Let DEV/QA people do it.

Sorry, didn't know I wasn't supposed to set targets... perhaps "wishful
thinking?" :)

You imply it might not be a real problem....trust me, it is for sites like mine.
 We can't afford the network and CPU load that sending zillions of unnecessary
copies of print job data places on us, especially when it is completely
avoidable (since *all* our printers will always automatically collate).

Anyway, I do agree with your reasoning about the issue type.  It isn't
necessarily an "error" ("defect")... the inherent behavior of sending multiple
redundant copies in the print job has always been there when collate was "on",
even before the defaults were changed.  It is just that many of us wouldn't know
about the problems (or have issues with it) until the option was forced as
default "on" every time the print dialog appears.

However, it is somewhat more that just an "enhancement", because it is
attempting to fix latent problems/issues that arose from the previous
"enhancement".  Since there aren't all that many "issue types" in the QA system,
I suppose "enhancement" would best fit... but with more of an urgency than a
typical "enhancement" would justify.

Fortunately, I believe the minimal "fix" (start OFF, then remember previous
state across dialogs and sessions) is probably easy to define, understand, test,
and implement, and with no negative consequences; all while retaining the
original intent of the first "enhancement": making it so nobody will have to
constantly change the collate option flag.

AFAIR the reason why the same content is sent to printer multiple times in case
of "Collate" is selected was that many printer drivers didn't handle collating
correctly, so it was decided not to use the "Collate" function of them but
instead of that emulate it by sending multiple copies explicitly.

Maybe it is time to reconsider that? Or do we still fear/know that some printer
drivers screw it up?

wrt. to whether "Collate" should be the default: if we hadn't changed it
recently, I just would do it as most users know it from other applications. OTOH
(changing something back and forth is also unfortunate, so an acceptable
compromise that keeps the new default would be nice.

IMHO the idea to keep the setting permanently until it is changed again is good
and should be this acceptable compromise for everybody as with this enhancement
the default setting after installation doesn't matter so much anymore.

@mba: I think you lost me :-) Does that mean you think persistence of the
collate box is enough ?

Yes. :-) If the setting in the print dialog would be remembered the question
what should be the default probably is moot.

But we shouldn't forget the original problem of the reporter: can we hand over
handling the "Collate" property to the printer drivers or are there any reasons
to still implement it in our code?

@mba:  Oh, I understand WHY OO emulates collation- non-page-printers (cheap
inkjet, for example) can't collate on their own.  And before OO started really
using CUPS, there probably weren't a whole lot of options to interact with
printers correctly.  And OO is not the only application under Linux that does
this (it just affects us the most).  It would be best left up to CUPS to handle
the whole collate process.  I don't know enough about CUPS to know if it has a
readable property to determine if the printer can collate on its own.  I also
don't know if you can tell CUPS to do the collation, and CUPS will decide if the
printer is smart or stupid and handle it properly, itself.  This is, of course,
the root cause of our issues.  Perhaps this CUPS interaction concept should be
yet another issue number, assigned to PRINT?

@pl/mba: Our (my) problem would be 75% solved with just adding persistence.
However, if there is no way for me to get the starting default to be OFF, some
of my problem remains, since I am forced to rely on education to let every user
know they need to change it manually, at least once.  And, then, every time
there is an upgrade.  I would still hope for a sysadmin setting/config file, or
environment variable or something.  But I will take whatever I can get as a
major improvement over what we have right now.  :)

So persistence plus an configuration entry without UI should do the trick. I
added persistence yesterday to the new dialog, that leaves the config entry.

@pl:  yes (assuming persistence will last across dialog pop-ups AND across
sessions)  Thanks so much... sounds like at least that part could be pushed out
quickly.

@EVERYONE:  I need to correct something I said in my very first posting...  I
implied the issue is only a problem when printing more than one copy of
multi-page documents with collate ON. This is not correct, it is worse...  The
problem occurs even when printing more than one copy of *single-page* documents
with collate ON!  So 100 copies of a single 50MB page also sends 5000MB to the
printer.

I do wish I could find some type of hack to immediately change the default so I
can roll out 3.1.0 here (our compiling OO is not an option).  The problem is
severe enough for us that I had to halt our rollout upgrade from 2.3 to 3.1 that
we spent several weeks configuring, testing, and documenting :(  Isn't there
some secret file I can hack?

sorry, that is as far as I can see hardcoded in
svtools/source/dialogs/prndialog.cxx lines 136 and 137.

target

Hi! I just want to remember that the settings in the Tools -- Options usually
set the default behavior for all documents. These settings can be altered per
document via the usual print dialog options. Letting the print dialog remember
the last state "breaks" this kind of behavior.

So my proposal is to add this kind of option setting the default to either Tools
-- Options -- OpenOffice.org -- Print (all modules) or for each of the modules
(if required).

I don't like to add another option there, but it respects the current behavior.
And since many of our users (non-admins) fear too many options, I would like to
remember that we will need a replacement for the overstuffed Tools -- Options
dialog (URL on request *g*).

Why can't "Tools-Options" just take over the remembered value?

@christophnoack: No, it breaks nothing by having the print dialog remember the
last collate setting used.  The collate setting is not saved with documents
(neither is the number of copies, for example).  As long as it is not saved with
the document, then remembering the last setting used will not break (interfere)
with anything else. 

As far as using "tools->options": I first proposed that we use
tools->options->print by adding a selection for collate.  But that was shot down
by "pl" (read the 5th message from the top).

I see the advantage and disadvantage of both approaches.  It seems the most
logical place to address it would be in tools->options.  But the *easiest* (and
fastest) way to address the problem is by just having the print dialog remember
the last used setting; storing that state in some config file.  The latter
approach requires zero UI changes/testing.

More importantly, "pl" has supposedly already added code for it to remember the
state in the print dialog, so it is probably moot now to worry about it.

I will just be happy if this is fixed in the next release- whatever form the fix
takes.  ANYTHING is better than the current behavior in 3.0.0 - 3.1.0 

FYI: The persistence is not just for the collate checkbox, but for all controls
that are not stored in the document (copy count, N-Up, etc.); this was what came
out of our discussions with the application people.

Yikes!!!!!!!!!  You don't want persistence on number of copies!  I can see that
being a big problem!

User opens document, prints 100 copies.  Closes document.  Next day, they open
some other document and then print it.  Users will not think about number of
copies, because they assume 1 (like all other applications)... but they get 100!

Even worse- next day, user opens another document, then prints using the
quick-print icon.  They get 100!

If there is one thing I know really well, it is user behavior.  Trust me, you
don't copies to be persistent.  Persistence with collate makes sense, because
that is a decision that is likely to never change.  But copies should always
default to "1".  It is much, much safer.

BTW, Print->Options and Print->Properties are things stored in the document
itself (I just checked); which makes sense.  So there are only two other
options- collate and copies.  I don't see "N-up" or anything else...

N-Up is new in the revised print dialog. And I'll take into consideration making
the copycount 1 each time; I can understand your reasoning.

@pl: great!  Hey- N-up sounds like another really neat option! (If it is what I
think it is- printing multiple pages on a single page side/face).  But beware- I
suspect that is another option that should probably always default to "1".  At
least there is far less "damage" (print resources) if that is accidentally left
on, if you know what I mean.

Added a config setting in VCL.xcu in the "PrintDialog" section so that you can
switch the Collate CheckBox to off always; administrators can do that in the
file <office>/share/registry/data/org/openoffice/VCL.xcu by changing the value
for key "CollateBox" from "Default" to "AlwaysOff" (actually case insensitive).
In the default case you can also set the initial value for the collate box there
by changing the value for the key "Collate" (which is currently "true"). This
value however will get overwritten by the user checking the collate checkbox on/off.

changes committed to CWS printerpullpages

@pl: that is great news, indeed. From what I am reading of what you programmed,
that is exactly the type of behavior that will allow the collate problems to be
fixed for *everyone*.  I (and my users) can't thank you enough.  Hopefully this
can be made into documentation somewhere too, since others are bound to hit the
same problem.  Is there any expectation this will make it into release sooner
than 3.2?

As for the N-Up- I talked about that with some people at work, and they are
quite excited about that option. Would be nice for "preview printing" and
archival of large documents to paper.  We all still think it would be best if
that were also not made a persistent/remembered setting, although it would be
far, far, far less "damaging" than the issue with collate or number of copies.

N-Up is not persistent as per your suggestion. The CWS will hopefully get
integrated in a month or so (no promise though, things could come up), so a
development milestone for testing should be available well before 3.2. At least
that is the plan.

target

I am guessing the change in target is bad news and we won't be able to upgrade
from OpenOffice 2.X for another year?  :(

I consider the change in target "bad news", yes. OTOH I wouldn't want "almost"
ready printer code to make 3.2 a bad version. Whether you can migrate or not
only you can tell.

Well, I don't want untested or unstable code in a mainline release either.  But
I was at least hoping the proposed
<office>/share/registry/data/org/openoffice/VCL.xcu setting would be available
quickly.  Since that doesn't affect the UI, it should be a safe place to start,
wouldn't it?

As for upgrading- the problem is so serious, there is no way I can roll out 3.X
to my users if I cannot disable the collate option (or at least default it to "no").

Sometimes things don't happen as you want it. When we (mainly pl) started to
work on the printing stuff in CWS printerpullpages, we all thought that we would
finish in time for 3.2. As it doesn't make a lot of sense to have several work
spaces changing the same code at the same time, it seemed to be appropriate to
fix issues like this one in the CWS "printerpullpages" also. Unfortunately now
this means that because the main feature in this CWS is not ready in time also
the smaller fixes will have to wait also. You might complain about bad planning,
but that's unfair: hindsight is easier than foresight.

I think pl did a great job, not only in what he has achieved in this work, but
also in taking the responsibility for product quality and not rushing things too
much.

please verify in CWS printerpullpages

Verified with cws printerpullpages = The Checkbox for the collate is persistent
now but this fix brings some side effects like that the first page of third,
will be printet at the backside from third page by duplex printing.
I'll file an follow up issue.

When will there be a patch? We have 60 people here and each of them is printing
30-40 times a day on some Cannon IRC2380i.

WE NEED A PATCH!

Only 60?  I have over 150 users and we have been waiting over a year.  I had to
completely halt the rollout of OpenOffice 3.0 because this problem was too
severe for us.  Waited through 3.0, 3.1, then 3.2.  I am praying it is in 3.3 (I
think it is).  I, too, was hoping there would have at least been a back door fix
or something until the new print system stuff was rolled out.

A whole Year! o0 I give my best wishes to 3.3 too...

"if the issue is just marked as FIXED but not CLOSED, then this probably means
that the latest milestone doesn't contain the fix yet..."

@ pooradmin: Just stop complaining: Try OOO330_m2 which will be OOo 3.3 and see
if the fix will work for you.

Well, the collate print option seems to work correctly on Lenny 64 :) Just a few
days more and i can install the German version.

Thank you so much! You all save my live :D