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

Status: RESOLVED INVALID

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

Description

[Roland Mainz]

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

Comment 1

[Chris Petersen]

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

Comment 2

[dcone (gone)]

This is just for you.

Comment 3

[Roland Mainz]

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

Comment 4

[Syd Logan]

I'll look into this for M11.

Comment 5

[Roland Mainz]

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

Comment 6

[Paul MacQuiddy]

Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!

Comment 7

[Syd Logan]

Mass moving these bugs to M13

Comment 8

[Alex Musil]

Moving Syd's non-PDT+ bugs to M15 to indicate that he will not have time to get
to them for Beta.

Comment 9

[Roland Mainz]

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

Comment 10

[Aaron Digulla]

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

Comment 11

[Alex Musil]

Moving to M20

Comment 12

[Roland Mainz]

To [e-mail]: 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...

Comment 13

[Aaron Digulla]

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

Comment 14

[Syd Logan]

assigning to kevin 

Comment 15

[Kevin McCluskey (gone)]

Reassigning to waqar

Comment 16

[shrirang khanzode]

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

Comment 17

[Kevin McCluskey (gone)]

Setting milestone to future.

Comment 18

[Jungshik Shin]

RM> To [e-mail]: 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

Comment 19

[Roland Mainz]

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

Comment 20

[Roland Mainz]

Xprint module now supports this feature without problems...

Comment 21

[Kevin McCluskey (gone)]

bulk reassigning Waqar's bugs to Don.

Comment 22

[Roland Mainz]

rods:
Any idea how we can implement this ?

Comment 23

[dcone (gone)]

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

Comment 24

[sujay]

Roland, please check if this is fixed...thanks.

Comment 25

[Roland Mainz]

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.

Comment 26

[Roland Mainz]

Updating summary, this is PostScript-module only; feature is working in Xprint
module...

Comment 27

[James Henstridge]

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.

Comment 28

[alge]

Attachment: Partially implements MOZ_DOCUMENT_TITLE, see comment #27

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

Comment 29

[James Henstridge]

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.

Comment 30

[alge]

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

Comment 31

[Aaron Digulla]

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[]);. 

Comment 32

[alge]

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.

Comment 33

[Joe M]

Attachment: Slight modification so patch 139469 applies clean

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 34

[alge]

Comment on attachment 139469 [details] [diff] [review]
Partially implements MOZ_DOCUMENT_TITLE, see comment #27

obsoleted by new patch

Comment 35

[alge]

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

Comment 36

[James Henstridge]

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

Comment 37

[Kenneth Herron]

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

Comment 38

[alge]

Attachment: Patch for nsPrintJobPipePs instead of nsPostScriptObj

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.

Comment 39

[alge]

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

Comment 40

[alge]

Attachment: Same patch + cleaning up our mess (add nsMemory::Free)

Comment 41

[Kenneth Herron]

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.

Comment 42

[alge]

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

Comment 43

[Wayne Mery (:wsmwk)]

reassigning to defaults as no one seems to be on top of the patch.

Comment 44

[Kenneth Herron]

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