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

This issue still occurs in the June 30th Build (1999063009).

This is just for you.

???? What is for me ? And who is "me" ??

I'll look into this for M11.

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

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

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

Reassigning to waqar

spam : changing qa to sujay (new qa contact for Printing)

Setting milestone to 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...

bulk reassigning Waqar's bugs to Don.

rods: Any idea how we can implement this ?

-> I think this is a UI issue on linux.. is this fixed already?

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...

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.)

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

(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.

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.

also changed the lpr and lp lines as in comment #36.

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.

(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.

The patch for bug 193001 rendered this irrelevant. Gecko doesn't call lpr directly any more; it prints through a GTK API.