185008 - RFE: Make PostScript module optional for Xlib toolkit

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, enhancement)

Description

[Roland Mainz]

RFE: Make PostScript module optional for Xlib toolkit, e.g.
--enable-default-toolkit=xlib should disable the PostScript module unless
someone uses --enable-postscript explicitly...

Comment 1

[Roland Mainz]

References: The same RFE exists for the Qt toolkit - see bug 184982 ("Make
PostScript module optional for QT") ...

Comment 2

[Roland Mainz]

Attachment: Patch for 2002-12-07-08-trunk

Comment 3

[hacker formerly known as [e-mail]]

I'm not fond of certain configure options automatically disabling other options
(thereby making it harder to document in --help).  Why is this necessary?  Is
adding --disable-postscirpt really that big of an issue?

Comment 4

[Roland Mainz]

Christopher Seawood wrote:
> I'm not fond of certain configure options automatically disabling other 
> options (thereby making it harder to document in --help). 

--enable-default-toolkit= is already a "macro" which expands to a couple of
other options internally.

> Why is this 
> necessary?  Is adding --disable-postscirpt really that big of an issue?

We're looking to lower the footprint in the Xlib toolkit, disabling the PS
module saves ~500KB in the distribution archive (Xlib toolkit should be a
low-footprint and pure X11 version of Mozilla).
And Qt does not need three print modules (e.g. "PS", "QPrinter", "Xprint"), so
disabling the one with the lowest count of features&&functionality makes sense,
too ...

Comment 5

[hacker formerly known as [e-mail]]

> --enable-default-toolkit= is already a "macro" which expands to a couple of
> other options internally.

No, it doesn't.  --enable-default-toolkit= sets defines based upon the toolkit
selected and enables xremote for the x11 based toolkits.  That's it.  And
there's no configure option to enable/disable xremote in any other fashion.

> We're looking to lower the footprint in the Xlib toolkit, disabling the PS
> module saves ~500KB in the distribution archive (Xlib toolkit should be a
> low-footprint and pure X11 version of Mozilla).

Then use the --disable-postscript option when building your xlib distribution. 
Not everyone that builds with xlib or qt will automatically want to use xprint
or qt's other solution (first I've heard of it).  We know postscript works
everywhere (if not for all locales) but the others are relative unknowns.

What you want to accomplish is completely doable without changing the defaults.

Comment 6

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

Er. Qt does not at the moment support QPrinter, and to my knowledge not XPrint
either (I may be wrong here).

Disabling the only supported printing method for a toolkit does not sound like
the way to go.

Comment 7

[Roland Mainz]

Christopher Seawood wrote:
> > --enable-default-toolkit= is already a "macro" which expands to a couple of
> > other options internally.
>
> No, it doesn't.  --enable-default-toolkit= sets defines based upon the toolkit
> selected and enables xremote for the x11 based toolkits.  That's it.  And
> there's no configure option to enable/disable xremote in any other fashion.

Then there should be an option which expands to a full set of toolkit-specific
"default options".

> > We're looking to lower the footprint in the Xlib toolkit, disabling the PS
> > module saves ~500KB in the distribution archive (Xlib toolkit should be a
> > low-footprint and pure X11 version of Mozilla).
>
> Then use the --disable-postscript option when building your xlib distribution. 
> Not everyone that builds with xlib or qt will automatically want to use xprint
> or qt's other solution (first I've heard of it).  We know postscript works
> everywhere (if not for all locales) but the others are relative unknowns.

This is not true either. The PostScript module never did work very well and it's
currently broken on some platforms (for example on Solaris it only works if the
"SunOS4.x"-commpatibility packages are installed) - and it's the one with the
lowest count of features&usuablity (and a constant source of bug reports which
are not resolved, too).

> What you want to accomplish is completely doable without changing the defaults

Currently yes, but in the future the Qt and Xlib modules won't support the PS
module anymore (e.g. the "glue" is being removed to merge the print module code
with the main toolkit code, saving another bunch of extra code).

Comment 8

[Roland Mainz]

Christian Biesinger wrote:
> Er. Qt does not at the moment support QPrinter, and to my knowledge not XPrint
> either (I may be wrong here).

The whole printing code is defunct in the Qt port. And getting the PostScript
module working is one of the last tasks on the long list in this area (and it is
likely that this step will be completely skipped in favour of QPrinter and
Xprint).

> Disabling the only supported printing method for a toolkit does not sound like
> the way to go.

Supporting QPrinter (which is available in all Qt libraries by default) and
Xprint is more usefull here.
Remember that bug 184982 ("Make PostScript module optional for QT") is a result
of complains by the Qt/KDE community - who complained a lot of the PS module in
the old days (when Qt was still working), too. Native PS support in a Qt-based
application doesn't make much sense since it Qt has it's own printer support
code and the PS module breaks portability (for example Qt/Emeded won't be able
to make any usefull use of the PostScript module) as well.

Comment 9

[hacker formerly known as [e-mail]]

"toolkit" default options?  We do expand to the default.  The default is to
support postscript.  What you're describing is a set of distribution specific
options and we don't even default to the options that are used for an official
Mozilla.org build much less everyone else's variant.

> in the future the Qt and Xlib modules won't support the PS module anymore

That's news to me.  PS printing is currently the standard method for printing on
a number of platforms.  It shouldn't be dropped just because someone wants the
speed of xlib builds or likes the look of a Qt build.

As we barely work with Qt/X11 out of the box, Qt/Embed is not a real concern at
this point.  And there's nothing that stops them from using the existing
--disable-postscript option if someone did want to attempt to build against
Qt/Embed.