32.82 KB, image/png
33.04 KB, image/png
21.99 KB, image/png
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 On web pages which contain non-printing ASCII characters or Unicode entities on the same line as regular text, sometimes that line becomes completely garbled upon first rendering. See the attached screenshots of the referenced web page, which contains a linefeed character (^L) at the beginning of most paragraphs. Reproducible: Always Steps to Reproduce: If the line is not garbled on first rendering, the 1. Selecting the entire line plus one other line with the mouse 2. Deselect by clicking somewhere else in the window. Actual Results: Now the line is garbled -- see screenshot attachment. To ungarble, 1. Select only the garbled line, or a portion thereof. 2. Deselect by clicking elsewhere. However, ungarbled text is not antialiased, making it stand out rather conspicuously. See screenshot.
Created attachment 160317 [details] Garbled lines beginning with the non-printing linefeed character #10 (^L)
Created attachment 160318 [details] Ungarbling text by selecting somewhere on the line. The first line of the first paragraph has already been ungarbled. Note that it is not antialiased. The first line of the second paragraph is in the process of being ungarbled. I have selected some text on the line. Note that to the right of the selection the text is antialiased, whereas to the left it is not. Once I deselect, the entire line will be not antialiased.
I should mention that this problem seems to occur only with TrueType fonts (Arial, Bitstream Vera Sans, etc.). I have not yet seen the problem occur with non-TrueType fonts.
I used to see this too a long while ago. Don't see it anymore. Questions: 1. Are you compiling mozilla yourself ? 2. What version of the freetype libraries are installed on your machine ? 3. What version of X/fontconfig.
> 1. Are you compiling mozilla yourself ? No, installed from SuSE RPMs (mozilla-1.7.2-10). > 2. What version of the freetype libraries are installed on your machine ? freetype-1.3.1-1000 3. What version of X/fontconfig. XFree86-184.108.40.206-46 fontconfig-220.127.116.1140221-0 The problem did go away for a few months, but it's back now. I upgrade my software fairly often, so I'm not sure if the problem was triggered by Mozilla or by one of the above-noted packages.
freetype 1.3.1 ? Huh ? The current version is 2.1.9 (although only 2.1.7 is currently supported due to bug 234035). I believe this may be a bad build from SuSE. Can you try a nightly from mozilla instead of SuSe's version http://www.mozilla.org/releases/#1.7.3 Are you also using a gtk1 or gtk2 version ? Like i said, i don;t see the problem anymore with a self-compiled build with all the latest libraries (and i do use the Bitstream Vera TTF fonts).
Sorry, I also have freetype2-2.1.7-11 installed. Versions 1 and 2 are distributed as separate RPMs so that both can be installed simultaneously for reasons of backwards compatibility. I don't believe I'm using a gtk version of Mozilla -- all the menus and widgets look nonstandard to me. I'll try a nightly build and get back to you.
Created attachment 160741 [details] Same page as viewed with mozilla-i686-pc-linux-gnu-1.7.3.tar.gz Same page as shown in Attachment #160317 [details] and #160318, except viewed with a Mozilla from mozilla-i686-pc-linux-gnu-1.7.3.tar.gz rather than from the SuSE RPM. Note that in this case none of the fonts are antialiased (is this something I need to set up manually somehow?) and the linefeed character is not displayed as in the SuSE screenshots. The text-garbling bug does not exist.
Just tried a 2004-09-30 nightly build from <http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/mozilla-i686-pc-linux-gnu.tar.gz>. Screenshot looks exactly the same as in Attachment 160741 [details]. Will try compiling from source if I have time.
Just compiled Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041001 from source. Again, page renders as in Attachment 160741 [details]; no text is antialiased. Is there some compilation or configuration option I need to enable to get antialiased text? So far this bug has only manifested itself when Mozilla antialiases the fonts, but I don't know how to make it do that on any non-SuSE installation.
Does about:buildconfig for the SuSE build list --enable-xft?
Configure arguments for the SuSE build: --disable-tests '--enable-optimize=-O2\ -march=i586\ -mcpu=i686\ -fmessage-length=0\ -fno-strict-aliasing' --enable-extensions=all --enable-xinerama --enable-crypto --enable-reorder --enable-strip --enable-svg --enable-svg-renderer-libart --disable-debug --disable-dtd-debug --disable-logging --enable-xft --enable-default-toolkit=gtk2 --with-default-mozilla-five-home=/opt/mozilla/lib --libdir=/opt/mozilla/lib --sysconfdir=/etc --mandir=/usr/share/man --prefix=/opt/mozilla --with-system-jpeg --with-system-png --with-system-mng --with-system-zlib --enable-calendar --enable-ldap-experimental Configure arguments for my self-compiled build: --disable-debug --prefix=/opt/mozilla-1.8a Should I try compiling a nightly release with the same options as the SuSE build (except for the prefix paths)?
If you want to do a build with --enable-xft to check, that would be great, but this is almost certainly an XFT-related issue (either bug in XFT or a bug in the fonts that XFT is using). Over to blizzard, since he seems to know about this stuff.
Boris wrote: > If you want to do a build with --enable-xft to check, that would be great I'm trying to do such a build, but it's not working. Let me know if I'm doing something wrong. Running ./configure with --enable-xft, I get the following error: configure: error: Cannot enable XFT support for non-GTK2 toolkits. If I then add --enable-default-toolkit=gtk2 I get the following error: configure: error: Cannot enable XFT and FREETYPE2 at the same time. If I then add --disable-freetype2, configure works, but I get the following error upon make: In file included from /usr/X11R6/include/X11/Xft/Xft.h:35, from nsDeviceContextGTK.cpp:77: /usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!" /usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use macros to include FreeType header files." /usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:" /usr/include/freetype2/freetype/freetype.h:23:2: #error " #include <ft2build.h>" /usr/include/freetype2/freetype/freetype.h:24:2: #error " #include FT_FREETYPE_H" nsDeviceContextGTK.cpp: In function `void xlfd_from_pango_font_description(GtkWidget*, const PangoFontDescription*, nsString&)': nsDeviceContextGTK.cpp:1120: warning: unused variable `char*tmp'
No, what you're doing should work, I think... Those are the flags firefox uses, for example...
Should I file a separate bug report for this compilation problem, then?
Yes, please do. cc me on it, ok?
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Bug still occurs in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050919.
roc, vlad, could you check this out?
I can't reproduce this on 1.5 on windows; I'll try linux later on today. I put up a new potential test case, as the original referenced URL is gone. Even on windows though, we render two of the ^L chars as boxes, and the last one ends up as a squished box (or a thick line).
Bug no longer occurs for me -- I'm now using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20061107 SUSE/1.1.1-0.1 SeaMonkey/1.1.1. I'm going to tentatively mark this bug as FIXED. (Or should it be WORKSFORME?)
We don't know what fixed this...