188733 - Need method to ensure users have Xprt (eg an Xprt XPI)

Status: RESOLVED WONTFIX

(Core Graveyard :: Printing: Xprint, enhancement)

Description

[Boris Zbarsky [:bzbarsky]]

We can't ship Xprint as the default print system unless there is a way to ensure
that users actually have an Xprt running.  We can wait for distributions to ship
it (RedHat seems very against....).  We can ship it with a base Mozilla install.
 We can have an Xprt XPI for users to install if they need it (in their profile,
eg).

This bug is filed to keep track of the progress on this front; Roland was most
in favor of the XPI approach when we talked earlier today (though I think
shipping with the base is preferable to that for systems known not to have Xprt).

This should block the bug on shipping Xprint instead of PS printing, but I
cannot find that bug.

Comment 1

[Boris Zbarsky [:bzbarsky]]

.

Comment 2

[kill this account]

I'm okay with Xprint as long as it does not interfer with the Postscript code.
If it does interfere in any way (including being the default) then that is a very 
serious matter.

As far as font technologies go there is a very strong push to move to client
side font handling (eg: Xft. As the architectural choice of X server side fonts
has seriously held back the Unix/Linux market for a long time now. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

Brian, the main thing interfering with the PostScript code is itself.  It currently:

1) Produces postscript that does not print on most printers.
2) Does a piss-poor job of handling encodings except for a few of the ISO-8859-*
   ones.
3) Does not allow a proper print preview (and Roland, who has spent a lot of
   time looking at it, says this would require a total rewrite to fix).
4) Is a mess of ugly spaghetti-code that is unreadable.
5) Is now completely unmaintained.

I feel that our default printing module should be whatever printing module
actually works and is maintained.  If no one ever fixes the glaring issues in
the PS code, why should we be using it?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Lastly, the font handling in the PS modules is pretty broken even in ISO-8859-1.
 It only knows about a fairly small list of fonts, and can't print anything
that's not in that list (it will substitute the fonts).

Comment 5

[kill this account]

Now that the ps code can convert/embed Truetype (bug 144663) it supports a much 
larger range of languages; eg: western, European, Arabic, Hebrew, Chinese,
Japanese

Comment 6

[Boris Zbarsky [:bzbarsky]]

Great!  Can we fix the other major issues too?  Especially #3 and #5 from my
list (the two go hand in hand).

Comment 7

[kill this account]

Louie/Pete: any comments on this?

Comment 8

[Jungshik Shin]

Out of five issues raised by Boris, 
I guess #2 is now taken care of by Brian's fixes for
bug 144668, bug 144669, bug 180473 and 
will be further imrproved in bug 190031. As for #1, I 
think given the way the average *nix users print (from 
Mozilla) these days(thanks to works done at http://www.cups.org
and http://www.linuxpringting.org), we  have to
worry much less than before about the need to make mozilla-generated
PS files directly printable on old level 1(and to a less
extent level 2) PS devices.

#3 is indeed a serious weakness of *nix printing (comp. with
that under MS Windows). 

Comment 9

[kill this account]

using Ghostscript one can convert down to level 2 or even level 1, see ps2ps
for an example

Comment 10

[Jungshik Shin]

Brian, that's exactly what I meant in my comment (where I wrote
: given the way the average *nix users ......we have to worry
much less than before ....). In the past, some people 
expressed concern about Mozilla-generated PS files not printable
on old PS devices, but my response always has been like that.
It's not as significant a problem any more as a few years ago.
What's done
at http://www.cups.org and http://www.linuxpringting.org make
the life of 'clueless' Mom and Pop much easier  
enabling them  to make use of ghostscript without
very little hassle just as they configure their printers
and print under MS Win and MacOS. Needless to say, seasoned *nix
users  know how to find their ways through even without those
tools.  
 

Comment 11

[Pete Zha]

>3) Does not allow a proper print preview (and Roland, who has spent a lot of
>   time looking at it, says this would require a total rewrite to fix).
AIK, the major problem of ps's print preview is about font. Since we use ps font
metrics to calculate the layout position but render them with toolkit
font(GDK/XFont). So, we could only *wish* the metrics of ps font is same as the
font we are using for render. Otherwise, the layout will look funny. But, this
problem will be fixed if we enable true type font. Because we will use same font
to do render and layout.

>5) Is now completely unmaintained.
That's really a problem. We will try to spend more time to resolve the major
problem of ps module.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> AIK, the major problem of ps's print preview is about font.

The major problem is bug 119491, which has nothing to do with font and
everything to do with architecture.

Comment 13

[Roland Mainz]

Brian Stell wrote:
> As far as font technologies go there is a very strong push to move to client
> side font handling (eg: Xft. As the architectural choice of X server side 
> fonts has seriously held back the Unix/Linux market for a long time now.

Noone said that we can't use Xft or or FreeType code with Xprint - both will
work happily together with Xprt when the matching code gets ported from
gfx/src/gtk/&&gfx/src/freetype/ to gfx/src/xlib/ (the only reason why I did not
do that yet is that Xft is not mature (yet) and I'd like to wait until that
code  becomes more stable (I do not want to sync both codes each month, lagging
always one week behind the work in gfx/src/gtk/ and finally running into  the
usual "you-need-approval-for-checkin"-trouble when the maintainers checkin new
stuff two hours before a milestone freeze)).
FreeType is on my radar but I have to strip-out the GDK/GTK+ references from the
FreeType code and replace them with plain X11 calls or |#ifdef| the whole stuff
(first option would be less painfull but it needs to be approved by the
gfx/src/freetype owner (bstell?)).

Comment 14

[kill this account]

> I have to strip-out the GDK/GTK+ references from the FreeType code and replace 
> them with plain X11 calls ... it needs to be approved by the gfx/src/freetype 
> owner (bstell?)).

I would prefer the direct FreeType code not have Gdk/Gtk references.

Comment 15

[Roland Mainz]

bz:
I need help with this from a XPI package expert.
In theory the implementation of the XPI is very simply:
1. At Mozilla startup a script from the XPI "Xprt server" package checks whether
the shell environment variable "XPSERVERLIST" is set or not. If it is set
nothing is done, if it is _not_ set the script continues with step [2].
2. If there is no Xprint server running the XPI script triggers the launch of
the Xprt server and waits until it is running, then sets the XPSERVERLIST env
variable.

Questions/issues so far:
1. I need to know a way to start a shell script when Mozilla is being launched
(the script is part of the XPI)
2. I need to know how to _GET_ a shell environment variable from within the XPI
glue (JavaScript?!)
3. I need to know how to _SET_ a shell environment variable from within the XPI
glue (JavaScript?!) that later called to libc/getenv() will return that value
4. Since the XPI package contents may be installed in the ~/.mozilla profile dir
it is required to put Xprt binaries for different platforms into different
subdirs to ensure that multiple packages can be installed without problems. I
have no clue how this can be implemented using XPI - and that's why I need a
guru for that...

Comment 16

[David P James]

*** Bug 218501 has been marked as a duplicate of this bug. ***

Comment 17

[Benjamin Smedberg]

1. I need to know a way to start a shell script when Mozilla is being launched
(the script is part of the XPI)

At what stage of "launch" do you need to do this, and why?

2. I need to know how to _GET_ a shell environment variable from within the XPI
glue (JavaScript?!)
3. I need to know how to _SET_ a shell environment variable from within the XPI
glue (JavaScript?!) that later called to libc/getenv() will return that value

You cannot do either of these from install.js

4. Since the XPI package contents may be installed in the ~/.mozilla profile dir
it is required to put Xprt binaries for different platforms into different
subdirs to ensure that multiple packages can be installed without problems. I
have no clue how this can be implemented using XPI - and that's why I need a
guru for that...

what's the issue? that seems like plain bread-and-butter xpinstall stuff, or am
I missing something?

--BDS

Comment 18

[Roland Mainz]

Benjamin Smedberg wrote:
> > 1. I need to know a way to start a shell script when Mozilla is being 
> > launched (the script is part of the XPI)
>
> At what stage of "launch" do you need to do this, and why?

Before or at the time the first Mozilla window comes up (BTW: Just curious: How
is the mozipcd started ?!)

> > 2. I need to know how to _GET_ a shell environment variable from within the 
> > XPI glue (JavaScript?!)
> > 3. I need to know how to _SET_ a shell environment variable from within the 
> > XPI glue (JavaScript?!) that later called to libc/getenv() will return that 
> > value
>
> You cannot do either of these from install.js

Erm... what about the code in
http://lxr.mozilla.org/seamonkey/source/js/src/js.c#2062 ? Isn't that reachable
from JavaScript ?
And the environment var should not be set from "install.js"... it should be set
after the Xprint server was started.

> > 4. Since the XPI package contents may be installed in the ~/.mozilla profile 
> > dir it is required to put Xprt binaries for different platforms into 
> > different subdirs to ensure that multiple packages can be installed without 
> > problems. I have no clue how this can be implemented using XPI - and that's 
> > why I need a guru for that...
>
> what's the issue? that seems like plain bread-and-butter xpinstall stuff, or 
> am I missing something?

Well, I wrote that comment at a time when I knew much less about the XPI stuff -
however I am still failing to make a package which does the following thing:

1. At install time a given tar.gz gets unpackged into the users's profile dir.
2. At Mozilla startup time (before the first window comes up - or together with
it) the script "xprint/run_xprint_from_tarball.sh start" is called (the script
is part of the tarball which was unpacked in step [1])
3. After [2] has been executed the script should run
"xprint/run_xprint_from_tarball.sh get_xpserverlist" and put the output into the
$XPSERVERLIST environment variable (the script itself cannot do that since it is
another process which cannot alter another process's set of env vars)
4. At Mozilla shutdown time (quit) the script 
"xprint/run_xprint_from_tarball.sh stop" gets called.

Comment 19

[Roland Mainz]

BTW: bz: Today's micro_xprint_server_031116141204.tar.gz for Linux/x86, build
from yesterdays trunk is currently 672kb, final version should be far smaller
than 500kb - still containing support for PS Type1/PS Type 42/TrueType/OpenType,
PostScript+PDF and CUPS/LPRng support... :)
Unfortunately I cannot attach it... someone (again!) lowered the mimimum
attachment size down to 500kb... ;-(((

Comment 20

[Benjamin Smedberg]

Just to make clear, xpinstall is mainly a tool to install files somewhere; all
of this stuff you want to do at startup has nothing to do with xpinstall and
everything to do with writing your own component... you might be able to write
it in JS, but I suspect that you will need to write a binary component.

> Before or at the time the first Mozilla window comes up (BTW: Just curious: How
is the mozipcd started ?!)

You need to write a component to do this. It should watch the app startup
observer topics and use nsIProcess (I think?) to run an arbitrary application
(which I presume includes a shell script, though I don't know precisely).

As for environment vars, js.c is the jsshell, it won't help you. You can read
environment variables from xpconnect code using nsIProcess, but if you want to
set them you have to write a binary component that calls PR_SetEnv.

> 1. At install time a given tar.gz gets unpackged into the users's profile dir.

Why a .tar.gz ?  If you can put the files directly into the XPI (a subdirectory
of the ZIP) you can just unpack them directly using xpinstall javascript.
Putting a .tar.gz inside of a ZIP file seems 

--BDS

and please don't post 500k attachments to bugzilla, even if you could ;)

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

> http://lxr.mozilla.org/seamonkey/source/js/src/js.c#2062 

err, that file is the source code for the jsshell executable. to my knowledge,
that is not even built in normal mozilal builds.

Comment 22

[Roland Mainz]

The last attempt to provide a solution for this (bug 226803) failed.
Since the XPI API does not provide a proper way without using huge amounts of
hacks this has now become a WONTFIX. Mozilla's XPI API is simple not capable of 
implementing this.

Comment 23

[Benjamin Smedberg]

roland, can you attach a source-patch-in-progress to this bug? (i.e. the shell
script you were planning to use with bug 226803, plus what you had of xpinstall
scripts).

Comment 24

[Peter Weilbacher]

Roland declared this WONTFIX in comment 22. Since then xprint support code was removed on trunk while Xprint itself was added to Xorg, so this is obsolete either way.