281402 - better build defaults for GTK2 toolkit

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We've gotten into the habit of making it easy for people to do GTK1 builds but
requiring a lot of options for the normal way of doing GTK2 builds.  I propose
that we make a bunch of defaults depend on the toolkit:  in particular Xprint,
FreeType2, and core X fonts.  (We've already done this for Xft.)

(FWIW, Firefox 1.0 shipped with --disable-freetype2 but with the other two enabled.)

I'd be interested in thoughts on whether this is the right set of things to change.

(I'd also be interested in making things not being present lead to errors (with
info on how to reconfigure) instead of silent disabling so that a set of
configure options leads to a known configuration rather than something dependent
on what was installed on the build machine, but that's probably another patch.)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch (untested)

Comment 2

[Benjamin Smedberg]

I fully support this as it stands. Not-basing the default options on the
build-time checks needs further discussion. I also think we should make gtk2/xft
the default now, based on build-time checks.

Comment 3

[Roland Mainz]

dbaron:
Why are you disabling Xprint with this patch ? It's more or less the only
functional print module for i18n stuff right now (unless people want to depend
on Ghostscript, too) ?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #2)
> I also think we should make gtk2/xft
> the default now, based on build-time checks.

I filed bug 282871 on this.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #3)
> Why are you disabling Xprint with this patch ? It's more or less the only
> functional print module for i18n stuff right now (unless people want to depend
> on Ghostscript, too) ?

Given the recent changes to allow Xft to interact with Postscript, I don't think
that's true anymore.  And that claim will be even more tenuous once bug 234182
lands.

Comment 6

[Jungshik Shin]

Even with this change, '-disable-freetype2' has to be explicitly specified for
gtk2 + xft build (which we want to make the default), doesn't it? I suggest that
'freetype2' is disabled by default for all toolkits (or at least for Gtk2). See
also bug 281319.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd be quite happy to make --disable-freetype2 the default for all toolkits, but
I'll certainly make that change for GTK2.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, wait, the patch already does that for GTK2.

Comment 9

[Julien Lafon (Hitachi)]

(In reply to comment #0)
> We've gotten into the habit of making it easy for people to do GTK1 builds but
> requiring a lot of options for the normal way of doing GTK2 builds.  I propose
> that we make a bunch of defaults depend on the toolkit:  in particular Xprint,
> FreeType2, and core X fonts.  (We've already done this for Xft.)
Could you list some technical reasons why you want to remove Xprint support from
Mozilla? I'd like to see here a justification before such a critical feature is
being removed from the default build configuration.

(In reply to comment #5)
> (In reply to comment #3)
> > Why are you disabling Xprint with this patch ? It's more or less the only
> > functional print module for i18n stuff right now (unless people want to depend
> > on Ghostscript, too) ?
> 
> Given the recent changes to allow Xft to interact with Postscript, I don't think
> that's true anymore.  And that claim will be even more tenuous once bug 234182
> lands.
1. The Type1 font downloader code in bug 234182 is incomplete. It lacks several
capabilities such as an outline optimizer, code to avoid that too many outlines
are included in one glyph and other bits to ensure that the code matches the
Adobe specs.
The code has more defects but I think it's better that roland does a detailed
analysis.
2. The code from bug 234182 lacks fallbacks to deal with possible bugs in the
printer firmware (the Xprint Postscript DDX has three font download modes to
deal with this class of problems: Type1, Type3 and image, other fallback methods
are provided to bypass issues in the HP printer firmware).
3. In Xprint the Postscript driver is just one of many (PCL, PDF and our own
commercial SVG driver) - you're not only removing an alternative way to generate
and spool Postscript jobs, you're completely removing Mozillas ability to print
other formats and use other kinds of print spoolers (as recent work on the
Postscript module already removed support for non-CUPS spoolers). Again, I'd
like to see a justification for decreasing the value of Mozillas print subsystem.

Comment 10

[Jungshik Shin]

Well, Xprint has many advanced features. However, it also has a (serious)
problem in that it still relies on XLFD (that has been cursed by many people for
many years) for font and glyph selections. When used with gtk2 + Xft build, that
means a rather big discrepancy between the print-out and the screen rendering
(without any print-specific CSS rules applied)

As for the outline optimization, I don't think Xprint does any better than my
patch. I've just installed the latest release of Xprint and painstakingly
configured X font paths and generated fonts.scale/dir files (that I have been
relieved of doing for a couple of years. [1]) and printed attachment 174046 [details]
(attached to bug 234182) using Xprint. The PS output generated by Xprint is
whooping 54MB while the PS output generated by my patch is 3.4MB. What makes
this huge difference? Well, Xprint's font embedding appears to be  inefficient.
Apparently, it embeds the same glyph over and over as it shows up in the text
stream. If that's not the case, its repeated use of glyphshow may 'amplify'the
output size many times.  Ok, the size may not matter much as long as your PS
rasterizer is gs running on a modern computer. However, it becomes important
when it comes to a real printer. I sent the 54MB ps file to a HP LJ 4005 with
24MB memory and it just gave up after a while.   

I also tried printing 'UTF-8 sampler' at
http://www.columbia.edu/kermit/utf8.html Unfortunately, Xprint (more precisely
the Xprint client included in mozilla) failed miserably (most of charcters are
not rendered at all even though I made sure all the trueytpe fonts that are
available to fontconfig are also available to Xprint) while with my patch, I got
a more or less faithful replica of the screen rendering. (bug 234182 comment #22)

Having said that, I don't have any strong opinion as to whether or not to
include Xprint by default in gtk2+Xft. Actually, I'm slightly more inclined to
keep it just for the sake of offering a choice to users. (To European users, it
may be a viable option)

[1] To be fair, I have to say that the Xprint installation program (or start-up
script) does a good job of reading off font paths for TTF from fontconfig file
and adding them all to the Xprint font path, but it overlooked
/etc/fontconfig/local.config. It can be fixed rather easily. Once that's fixed,
I won't have to go through the 'ordeal' of setting up X11 font path. 

Comment 11

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

> (as recent work on the Postscript module already removed support for non-CUPS 
> spoolers)

isn't the CUPS support just an addition, and the normal way of using lpr still
works?

Comment 12

[Kenneth Herron]

(In reply to comment #11)
> > (as recent work on the Postscript module already removed support for non-CUPS 
> > spoolers)
> 
> isn't the CUPS support just an addition, and the normal way of using lpr still
> works?

The classic unix print spooler, which pipes the print job into a command (lpr by
default), is still present and should work just as always. The VMS print spooler
is known to be broken on the trunk, but that's just waiting for someone to
submit a patch.

Comment 13

[Julien Lafon (Hitachi)]

(In reply to comment #10)
> Well, Xprint has many advanced features. However, it also has a (serious)
> problem in that it still relies on XLFD (that has been cursed by many people for
> many years) for font and glyph selections. When used with gtk2 + Xft build, that
> means a rather big discrepancy between the print-out and the screen rendering
> (without any print-specific CSS rules applied)
1. Can you list examples where you get a discrepancy?
2. Do you think that Xft support would be an improvement? This discussion needs
to be split into a) Xft/non-RENDER, b) Xft/RENDER extension (which should be
available with one of the next X.org releases) and c) Xft/STSF-bridge (for
Solaris only).

> As for the outline optimization, I don't think Xprint does any better than my
> patch.
I do not see any code in your patch which does outline combining, filtering,
smoothing and alignment as implemented in the Xprint _Postscript_[1] DDX. Also
there is no usually no BCI enabled in the truetype font code while Xprint always
has BCI support enabled.

[1] I'd like to emphasize that there is more than one driver ('DDX') in Xprint

> I've just installed the latest release of Xprint and painstakingly
> configured X font paths and generated fonts.scale/dir files (that I have been
> relieved of doing for a couple of years. [1]) and printed attachment 174046 [details] [edit]
Why are you doing that? Both /etc/init.d/xprint and xprintadm take care of the
xprint server and related deamon processes.

> (attached to bug 234182) using Xprint. The PS output generated by Xprint is
> whooping 54MB while the PS output generated by my patch is 3.4MB. What makes
> this huge difference? Well, Xprint's font embedding appears to be inefficient.
This sample is 12MB here, mainly due the fact that the font downloader pushes
fonts as whole block (256 glyphs per block) and not as a sparse font (Roland:
why is the Postscript not using a sparse font?). If are you able to reproduce
the problem on another machine then please file a bug and assign it to me. Thanks!

> Apparently, it embeds the same glyph over and over as it shows up in the text
> stream. If that's not the case, its repeated use of glyphshow may 'amplify'the
> output size many times.  Ok, the size may not matter much as long as your PS
> rasterizer is gs running on a modern computer. However, it becomes important
> when it comes to a real printer. I sent the 54MB ps file to a HP LJ 4005 with
> 24MB memory and it just gave up after a while.   
HP CLJ 4550 just prints the job w/o complains.

> I also tried printing 'UTF-8 sampler' at
> http://www.columbia.edu/kermit/utf8.html Unfortunately, Xprint (more precisely
> the Xprint client included in mozilla) failed miserably (most of charcters are
> not rendered at all even though I made sure all the trueytpe fonts that are
> available to fontconfig are also available to Xprint) while with my patch, I got
> a more or less faithful replica of the screen rendering. (bug 234182 comment #22)
Again I cannot reproduce the problem here on Suse9.2_x64 (using the Xprt server
from that OS). Almost all glyphs are printed out.

> Having said that, I don't have any strong opinion as to whether or not to
> include Xprint by default in gtk2+Xft. Actually, I'm slightly more inclined to
> keep it just for the sake of offering a choice to users. (To European users, it
> may be a viable option)
Well, we have the _strong_ opinion to keep it as the builtin Postscript module
lacks seveal features such as support for printing out of the calendar, alpha
channel and OpenGL support, PDF/PCL/SVG output etc.

Comment 14

[Jungshik Shin]

(In reply to comment #13)
> (In reply to comment #10)
> > Well, Xprint has many advanced features. However, it also has a (serious)
> > problem in that it still relies on XLFD (that has been cursed by many people for
> > many years) for font and glyph selections. When used with gtk2 + Xft build, that
> > means a rather big discrepancy between the print-out and the screen rendering
> > (without any print-specific CSS rules applied)
> 1. Can you list examples where you get a discrepancy?

It's obvious because with gtk2+xft and Xprint, the font/glyph selection
mechanism for the screen rendering IS different from the font/glyph selection
mechanism for the printing. Just take a look at nsFontMetricsXft.cpp and
nsFontMetricsXlib/Gtk.cpp. 

> > As for the outline optimization, I don't think Xprint does any better than my
> > patch.
> I do not see any code in your patch which does outline combining, filtering,

 I didn't say my patch does that. If Xprint does the job so well, why is the
output size with Xprint over 10 times (or 4 times) larger than what I get with
mine? 


> > I've just installed the latest release of Xprint and painstakingly
> > configured X font paths and generated fonts.scale/dir files (that I have been
> > relieved of doing for a couple of years. [1]) and printed attachment 174046 [details]
[edit] [edit]
> Why are you doing that? Both /etc/init.d/xprint and xprintadm take care of the
> xprint server and related deamon processes.

I already answered this question in my post. That's because those scripts don't
take a look at local.config and I have a bunch of font directories listed there.
 
> > (attached to bug 234182) using Xprint. The PS output generated by Xprint is
> > whooping 54MB while the PS output generated by my patch is 3.4MB. What makes
> > this huge difference? Well, Xprint's font embedding appears to be inefficient.
> This sample is 12MB here, mainly due the fact that the font downloader pushes
> fonts as whole block (256 glyphs per block) and not as a sparse font (Roland:

 Well, still it's almost 4 times larger than what I get with my patch and some
old PS printers may not be able to cope with that large file. Ok, really old PS
printers may not be able to deal with 3.4MB file, either. Although you  do a
good job with the outline optimization,  apparently your font embedding
algorithm needs an improvement.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

I realized I botched the core X fonts changes (by overwriting the configuration
(in env var) before testing it).

Comment 16

[david avery]

one issue - cairo gfx and svg backend depends on freetype2 and fontconfig being
available to build and run

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

MOZ_ENABLE_FREETYPE2 is really about whether we enable our special font
preferences to allow use of freetype2 fonts at user-configured locations (rather
than found, e.g., through fontconfig).  Use of those prefs should really really
be discouraged, so I hope that code doesn't actually depend on MOZ_ENABLE_FREETYPE2.

Comment 18

[tor]

The cairo renderer backend uses freetype/fontconfig independently
of mozilla's freetype2 option.  The depreciated libart backend does
use the freetype2 code, but as it's being phased out it shouldn't
be a blocker for your configure changes.

Comment 19

[Jungshik Shin]

MOZ_ENABLE_FREETYPE2 is about whether to access freetype APIs via nsIFreeType
interface and as tor wrote, only the libart backend for svg relies on that aside
from gfx-gtk1/xlib.  

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk, 2005-03-12 08:53/57 -0800.

Comment 21

[Philip K. Warren]

With this change, is it possible to enable Core X fonts support with GTK2 any
more? AIX doesn't currently ship with XFT or Xrender, so our GTK2 builds just
use the core x font support.

Currently the AIX build is failing with this patch. I've tried setting
mk_add_options MOZ_ENABLE_COREXFONTS=1 in the mozconfig file, but that doesn't
seem to have any effect.

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

set in in the environment for configure (i.e., drop the "mk_add_options ")