Closed Bug 6810 Opened 26 years ago Closed 17 years ago

[ps] UNIX printing should set the correct title (e.g. -T option)

Categories

(Core :: Printing: Output, enhancement, P3)

All
Linux
enhancement

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: roland.mainz, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

Unix printing should launch lp/lpr with a title (that banner pages get a more
usefull info than "job xxxx", for example).

Maybe this can be implemented by printf-Style formattings:
%t  Page title (be carefull with the charset; maybe page charset must be
converted to system charset, chars like " must be escaped...)
%f  Page file (e.g. xxx.html)
%u  URL

----

The default should be
lpr -T "%t"
(for BSD systems like Linux)

lp -t "%t"
for Solaris (System 5 !?) OSes
Status: NEW → ASSIGNED
Target Milestone: M8
This issue still occurs in the June 30th Build (1999063009).
Target Milestone: M8 → M9
Assignee: dcone → syd
Status: ASSIGNED → NEW
Target Milestone: M9 → M10
This is just for you.
????
What is for me ? And who is "me" ??
Blocks: 11275
Target Milestone: M10 → M11
I'll look into this for M11.
Group: netscapeconfidential?
Group: netscapeconfidential?
What is the problem with this feature ?

The implementation should be easy:
(java pseudo-code:)
-- snip --
String s = doc.getTitle();
String cmdstring = "lp -t \" + s + "\";
runtime.runCmd( cmdstring, stdin, postscriptOut, stderr );
-- snip --

The only thing we should take care is that the title is correctly escaped that
special chars won't be interpreted anything else than a title...
Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!
Mass moving these bugs to M13
Target Milestone: M13 → M15
Moving Syd's non-PDT+ bugs to M15 to indicate that he will not have time to get
to them for Beta.
OK, then please tell me where to get the following things:
- The current page title, e.g. something like getPageTitle()
- A encoder which transforms the page encoding into the local encoding
Then I'll write this little piece of code...
Even if I cannot get the title/URL/etc. in the script to print the page, the
postscript code for it should contain the same information as the windows
version (URL, Title, Page number, Date, etc). I just don't get why Netscape for
Windows has these since ever and Unix doesn't. It's not that it would be hard to
add this :-(
Moving to M20
Target Milestone: M15 → M20
To digulla@hepe.com: Printing banner (info), page number etc. is the job of the
print system and should not be part of Mozilla itself. 
In Unix/X11 the Xprt (X print server) or a special filter in the lp-printsystem
would be the location where to "enable" page count/number printing...
So that's why Unix and Windows printouts differ: Mozilla just passes this
information to the Windows printer and omits it on Unix. In that case, you
really have to put these information into ENV variables or replace specific
parts of the commandline (as suggested in the first post in this thread).
assigning to kevin 
Assignee: syd → kmcclusk
Status: ASSIGNED → NEW
Reassigning to waqar
Assignee: kmcclusk → waqar
Depends on: 62125
Depends on: 67096
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Setting milestone to future.
Target Milestone: --- → Future
RM> To digulla@hepe.com: Printing banner (info), page number etc. is the job of the
RM> print system and should not be part of Mozilla itself.
RM> In Unix/X11 the Xprt (X print server) or a special filter in the lp-printsystem
RM> would be the location where to "enable" page count/number printing...

  I don't think that's the case. You might be right if what the printer
system is handed over is just a plain text file. Then, the printing system
can do whatever it wants to do (adding header, footer with page number,
title, etc). However, what Netscape gives the printing system is, in
Unix/X11, a postscript file. Do you think the printer system has to/can
manipulate this postscript file (e.g. resizing the whole page and adding
header and footer)?  Things like n-page up, duplex printing, banner page
with title are certainly in the realm of the printing system. However,
adding headers and footer with the page title, page number, date, the
URL of the page has to be taken care of by Mozilla. Please, also note
that Unix/X11 version offers a way to print to a file. If the printing
system has to add header and footer, PS file obtained by 'printing to
a file' would be different from the hardcopy.


AD> So that's why Unix and Windows printouts differ: Mozilla just passes this
AD> information to the Windows printer and omits it on Unix. In that case, you
AD> really have to put these information into ENV variables or replace specific
AD> parts of the commandline (as suggested in the first post in this thread).

  I guess your original question is still valid. I've been also wondering
why Windows version of NS can add date, page number, URL (which is very
handy), title while Unix/X11 version can't.

  When I printed out with 2001-04-03 build for Linux, I was pleasantly
suprised to see the page title, page number ( x of y ) and date (current)
were printed in header and footer. However, there's still one item
missing which is present in print-out of MS-Windows version, which is
the URL of the page being printed. Now, I got really curious as to why
on earth  MS-Windows version can print all four items (title, url, date,
and page number) while Unix/X11 version can only three of them (title,
date and page number). I guess this(printing out URL as well in Unix/X11
version of Mozilla) should be an easy fix.

   Jungshik Shin
OT: Who wrote the header/footer stuff for Unix ? I currently have much "fun"
with this feature because it breaks a lot of stuff in Xprint (header/footer font
is incredibly large (~~1/6 of page height)... ;-((
Xprint module now supports this feature without problems...
OS: Solaris → Linux
Hardware: Sun → All
bulk reassigning Waqar's bugs to Don.
Assignee: waqar → dcone
rods:
Any idea how we can implement this ?
-> I think this is a UI issue on linux.. is this fixed already?
Assignee: dcone → rods
Roland, please check if this is fixed...thanks.
No, this has not been fixed.

This bug is about setting the print jobs title for the print spooler. Currently
we include the title in the page itself but to not pass it to the print spooler
system.
Updating summary, this is PostScript-module only; feature is working in Xprint
module...
Summary: UNIX printing should set the correct title (e.g. -T option) → [ps] UNIX printing should set the correct title (e.g. -T option)
Blocks: 157675
It looks like this should be fairly easy to implement.  Simply extend
nsPostScriptObj::settitle() to set an environment variable holding the document
title (say MOZ_DOCUMENT_TITLE), with code similar to that used to set
MOZ_PRINTER_NAME in nsPostScriptObj::Init().  As with the Xprint code, the title
would need to be converted from UCS2 first.

Then it is a simple matter of modifying print.postscript.print_command in
unix.js to include '-J "${MOZ_DOCUMENT_TITLE}"' in the print command.
This patch sets MOZ_DOCUMENT_TITLE to the title of the document (duh), using
nsIPlatformCharset and nsIUnicodeEncoder to convert from PRUnichar to native
encoding.
It does _not_ make it suitable for inserting in a command line, so the patch is
not ready for checkin.
Just looking for some feedback.

(This is also my first c++-ish patch, so there may well be horrible things in
it.)
Attachment #139469 - Flags: review?(Roland.Mainz)
In what way is the environment variable set by the patch not suitable for use on
a command line?  The whole point of using an environment variable here (as
opposed to substituting in the document title directly) is so it can be used on
the command line without worrying about shell quoting issues.

The shell should just pass "${MOZ_DOCUMENT_TITLE}" to lpr as a single argument
(unevaluated), no matter whether it includes spaces, quotes, dollar signs or
other punctuation.  You can test this quite easily with a few Python scripts,
for example:

--- Start printargs.py ---
#!/usr/bin/python
import sys; print sys.argv
--- End printargs.py   ---

--- Start call-system.py ---
#!/usr/bin/python
import os
os.environ["MOZ_DOCUMENT_TITLE"] = "abc def \" \" `echo foo` $USER"
os.system("./printargs.py \"${MOZ_DOCUMENT_TITLE}\"")
--- End call-system.py   ---

(I chose Python here because it doesn't do any special substitutions in strings
itself).  If you run the second program, it should show that the first was
called with only a single argument and none of the potentially evil characters
got touched.
Ok, let me rephrase that, I did not check it to be suitable for use in a command
line. (=
I think we should at least check it's length before passing it to system.

If that's not a problem, we still have the design issue, setting environment
variables is not a particulary nice way to do this. One solution could be to set
the variables on the same command line ("MOZ_PRINTER_NAME=sumthin
MOZ_DOCUMENT_TITLE=\"a title\" lpr <und so weiter>").
When you do that, why not 
 
	lpr -T$(title) 
 
? When Mozilla prints the page, it could expand some variables (like $(title), 
$(url), $(date)) in the command which would allow for some very sophisticated 
things. 
 
As for whitespace and variable processing (example: The title of the document 
is "make $$$ fast" -> "lpr -Tmake $$$ fast"), mozilla should first split the 
print command into words (space delimited) and then call execv(const char 
*path, char *const argv[]);. 
re #31:
Problem is, we don't want to pass on -T if there is no title, just as we don't
want to pass -P if we don't want to specify a printer.

> which would allow for some very sophisticated things. 
Sophistication is not the goal here, IMHO. Simple, clean code is. Right now
popen()/system() or whatever seems to be a lot simpler than exec*(). Let /bin/sh
do the dirty work instead of us reinventing the wheel.
This bug hasn't had activity for quite a few months, so excuse me if I'm
digging up a corpse. But I wanted to add that this feature would be extremely
useful for people who print to community printers. These print systems, which
are used by hundreds or thousands of people, often print cover pages which
include the job title (along with the print date, user name, etc.). Right now,
the job title is nondescript (to be exact, it says "stdin"). I can see this as
a particular inconvenience for users at universities (as myself) and
businesses, among others.

I've attached an update to the previous patch, so that it applies cleanly.
Unfortunately, I'm not at all qualified to back up its validity. Just hoping I
might encourage someone else who knows better.
Comment on attachment 139469 [details] [diff] [review]
Partially implements MOZ_DOCUMENT_TITLE, see comment #27

obsoleted by new patch
Attachment #139469 - Attachment is obsolete: true
(In reply to comment #33)
> This bug hasn't had activity for quite a few months, so excuse me if I'm
> digging up a corpse. 

The reason I didn't push my patch was that Someone was rewriting the ps module.
Right now it's sort of messy, with lots of global variables, env variables,
etc.. Which makes it impossible to print several documents simultaneously and
stuff. My patch added more globals and sort of made the change to a new ps
even harder, so I dropped it.

Now it seems like nobody cares(?) about postscript, so maybe some "bad" code to
fix a problem is the way to go. I still think somebody should check it for 
security reasons, though. (The XXX in the patch.)
I think the XXX can be removed.  Since the document title is in an environment
variable, if the print command is written appropriately, the string shouldn't
get interpreted by the shell.

The appropriate print command would look something like this:

  lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME} \
      -T "${MOZ_DOCUMENT_TITLE:-Mozilla: Untitled Document}"

This way, lpr will be passed 2 or 3 arguments (depending on whether
$MOZ_PRINTER_NAME is set), no matter what characters are in $MOZ_DOCUMENT_TITLE
(it also provides a slightly nicer document title in the case where no title is
set).
(In reply to comment #35)
> Now it seems like nobody cares(?) about postscript, so maybe some "bad" code to
> fix a problem is the way to go. I still think somebody should check it for 
> security reasons, though. (The XXX in the patch.)

Actually, I'm hoping to work on this during the gecko 1.9 development cycle, by
adding a print job class that can construct an lpr command rather than just
setting some environment variables and launching an opaque command. See bug
135695 comment 20.

I'd prefer not to add any more environment variables to the classic printing
support, though I'm not absolutely opposed to it. Any new code should definitely
support multiple simultaneous print operations though, which means treating the
environment as a shared resource. If you want to pursue this, you should look at
gfx/src/ps/nsPrintJobPS.cpp, specifically the nsPrintJobPipePS class and the
environment-handling functions toward the end of the file.
Attachment #139469 - Flags: review?(roland.mainz)
Hopefully this should work with multiple simultaneous print jobs.
But it's a one-night-job so please be merciful. (:
Adding a global here, for unicode->native charset(locale) conversion of title.
Attachment #187366 - Flags: review?(kherron+mozilla)
also changed the lpr and lp lines as in comment #36.
Attachment #176614 - Attachment is obsolete: true
Attachment #187366 - Attachment is obsolete: true
Attachment #187379 - Flags: review?(kherron+mozilla)
Attachment #187366 - Flags: review?(kherron+mozilla)
Comment on attachment 187379 [details] [diff] [review]
Same patch + cleaning up our mess (add nsMemory::Free)

Alge,

To start with, I think it'd be better design to set MOZ_DOCUMENT_TITLE for
every print job, rather than setting it only for jobs that have a title. In
reality, virtually every print job has a title, so I'd rather not junk up the
model command line with the fallback title logic. Also, the fallback title
should not contain "Mozilla"; see bug 293268 and bug 285696.

It looks like you're leaking the unicode encoder object. EnvLockInit()
unconditionally creates a new encoder for every print job, and it's not freed
anywhere. Also, based on other uses of unicode encoders, it looks like you
should set the encoder's error behavior with SetOutputErrorBehavior().

I don't know how large this encoder object is, or how expensive it is to
initialize it. I also don't know if it's possible for the local character set
to change while mozilla is running. I suspect it'd be better to allocate an
encoder for each print job, rather than allocating it once and caching it for
reuse. If you take that route, you should store the encoder in an nsCOMPtr<>
instead of a raw pointer.

Personally, I think I'd do the character set conversion inside of
SetJobTitle(), and then substitute the fallback title in StartSubmission() as
is done with the CUPS logic. SetJobTitle() has to be threadsafe, so if I were
using a cached encoder I'd do the whole thing in StartSubmission().


>-/* Routines to set the MOZ_PRINTER_NAME environment variable and to
>- * single-thread print jobs while the variable is set.
>+/* Routines to set the MOZ_PRINTER_NAME and MOZ_DOCUMENT_TITLE environment variables 
>+ * and to single-thread print jobs while the variable is set.
>  */

Could you format your code to fit in 80 columns where it's not inconvenient?
Also, "the variable is" should be "these variables are".


>+    nsresult res = gNativeEncoder->GetMaxLength(PromiseFlatString(aTitle).get(), srcLength, &destLength);
>+    if( NS_SUCCEEDED(res) ) {
>+        nativeTitle = NS_STATIC_CAST(char*, nsMemory::Alloc(destLength+1));
>+        if(nativeTitle) {
>+            gNativeEncoder->Convert(PromiseFlatString(aTitle).get(), &srcLength, nativeTitle, &destLength);
>+        }
>+    }
>+    
>+    if(!nativeTitle)
>+        return PR_FAILURE;
>+
>+    /* Make sure title is null-terminated */
>+    nativeTitle[destLength] = '\0';
>+    
>+    /* Construct the new environment string */
>+    char *newVar = PR_smprintf("%s=%s", EnvJobTitle, nativeTitle);
>+    if (!newVar)
>+        return PR_FAILURE;

If you leave the character set conversion in this function, could you avoid
doing two separate memory allocations here? You could make your first
allocation large enough for the full environment string, or you could just
convert into a fixed-size buffer on the stack. It wouldn't be a big deal if
long titles were truncated.
Attachment #187379 - Flags: review?(kherron+mozilla) → review-
(In reply to comment #41)

Kenneth, thanks for you time and comments. (=

> (From update of attachment 187379 [details] [diff] [review] [edit])
> To start with, I think it'd be better design to set MOZ_DOCUMENT_TITLE for
> every print job, rather than setting it only for jobs that have a title. 

Agreed. Should the fallback be localizable by some means, though? For the time
being I've made it a static const char and use it for both PS and CUPS.

> It looks like you're leaking the unicode encoder object. EnvLockInit()
> unconditionally creates a new encoder for every print job, and it's not freed
> anywhere. Also, based on other uses of unicode encoders, it looks like you
> should set the encoder's error behavior with SetOutputErrorBehavior().

As far as I can tell, EnvLockInit is only called once (by PR_CallOnce()),
so it shouldn't be leaking? I'll look at the error behaviour.

> I don't know how large this encoder object is, or how expensive it is to
> initialize it. I also don't know if it's possible for the local character set
> to change while mozilla is running. I suspect it'd be better to allocate an
> encoder for each print job, rather than allocating it once and caching it for
> reuse. 

You think so? If the charset can change, I'll agree, but I can't see how the
locale can change while an application is running on *nix..

> Personally, I think I'd do the character set conversion inside of
> SetJobTitle(), and then substitute the fallback title in StartSubmission() as
> is done with the CUPS logic. SetJobTitle() has to be threadsafe, so if I were
> using a cached encoder I'd do the whole thing in StartSubmission().

I'll stick with the cached encoder, so.. You think I should move the conversion
from EnvSetJobTitle to StartSubmission?

> Could you format your code to fit in 80 columns where it's not inconvenient?
> Also, "the variable is" should be "these variables are".

OK.

>> [EnvSetJobTitle]
> If you leave the character set conversion in this function, could you avoid
> doing two separate memory allocations here? You could make your first
> allocation large enough for the full environment string, or you could just
> convert into a fixed-size buffer on the stack. It wouldn't be a big deal if
> long titles were truncated.

Sure, I'll just allocate one string that's big enough.

Now I'll just have to get a better network connection so I can do cvs diff to
make a new patch. GPRS is a bit too expensive and slow. (=
reassigning to defaults as no one seems to be on top of the patch.
Assignee: rods → printing
QA Contact: sujay
The patch for bug 193001 rendered this irrelevant. Gecko doesn't call lpr directly any more; it prints through a GTK API.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: