spoke to Chase and Asa about this: by mozilla 1.8final, the gtk2 builds should be the default linux (*nix as well?) builds. (couldn't find an existing bug for this after several searches.)
setting TM to 1.8beta for consideration: would rather get this done sooner rather than later.
Will these be GTK2 + XFT builds? Or just GTK2? Are we effectively dropping support for older systems with buggy XFTs (a lot of them, since XFT took a while to stabilize...)?
I'm in favour of this. The GTK1 non-XFT builds look so ugly, it's just embarrassing that we ship them.
(In reply to comment #2) > Will these be GTK2 + XFT builds? Or just GTK2? Are we effectively dropping > support for older systems with buggy XFTs (a lot of them, since XFT took a while > to stabilize...)? GTK2+Xft
I appreciate that a lot of people find the XFT font rendering to be better. At the same time, there are significant issues with the XFT versions that shipped with RH 8 and RH9, for example (see bug 205621, bug 180328). I can't find the bug number for the xft/freetype bug that caused text to slant diagonally upward, so I don't know when it was fixed upstream (as in, which OS releases would have broken versions installed). If we had a way to avoid using XFT when we detect a broken version, that would be great. Failing that, I guess we just update our minimal requirements and relnote this carefully....
I found an interesting case where using the XFT lib from XFree86 4.4.0 at runtime triggers bugs on japanese font rendering. It is highly reproductible : 1 - Use any latest xft build (seamonkey 1.7.3 or trunk - firefox 1.0 or trunk) 2 - Go to http://www.php.net/manual/ja/ref.bzip2.php 3 - Restore any minimized window in front of mozilla's one 4 - Minimize the window you just restored, mozilla should get back the focus 5 - Repeat step 3 and 4 several times (between 1 and 15 times) 6 - Some part of japanese text is garbaged. All latin text is ok Switching tabs can also leads to the same issue. The bug can even show up instanly after loading the page. It should not be a blocking bug while highlighting japanese garbage "corrects" it but it's really annoying for japanese users. This is not a mozilla bug (xft related) but it probably should be taken in consideration before considering intl xft/gtk2 builds as the "standard builds"
> with RH 8 and RH9, for example (see bug 205621, bug 180328). I can't find the > bug number for the xft/freetype bug that caused text to slant diagonally upward, > so I don't know when it was fixed upstream (as in, which OS releases would have > broken versions installed). > That was a bug in freetype, not Xft and didn't show up in any production releases.
will they be an gtk2+xft INSTALLER version?
Adrian, not unless someone comes forward to write it. For now, any "official" Mozilla builds will be just the tar.gz
> Adrian, not unless someone comes forward to write it. I've had a patch in bug 183389 since August. It's awaiting bryner's sr
FYI: gtk2 installer works and is built by lhasa tbox (which tries to push it to the servers), but it doesn't actually package it up with XPIs, etc.
Will the installer packaging stuff automatically use filenames with gtk2+xft in it, or does that need to be fixed before one of us flips that on on lhasa?
the filename magic works now (bug 283574)
dbaron/Chase: can you flip the switch on lhasa to get the installers built? The tbox script also needs to push the XPIs to a unique xpi directory Let me know if there's anything else I need to do.
Seems seamonkey1.0a was released with GTK2 as the default builds (tgz+installer), with '-gtk1' labeled builds as an alternative. -> FIXED ?
Hmm, am I right in that this doesn't needs any code fixes? In that case, this is FIXED by the takeover of the suite by the new SeaMonkey team. We still support GTK1, but GTK2 is our default Linux toolkit now.