Closed
Bug 341030
Opened 18 years ago
Closed 17 years ago
Adjacent ASCII characters rendered at different sizes
Categories
(Core :: Graphics, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bzbarsky, Unassigned)
References
Details
Attachments
(2 files)
BUILD: 2005-06-01-08 trunk nightly
STEPS TO REPRODUCE (in SeaMonkey, but I bet I could try to set equivalent font prefs in Firefox):
1) Install Fedora Core 4 with a bunch of fonts
2) Set default Proportinal font to "Serif" at 16px
3) Set default Serif font to "serif"
4) Set default Sans-serif font to "sans-serif"
5) Set default Monospace font to "Courier" at 14px
6) Set minimum font size to 14px
7) Load https://bugzilla.mozilla.org/attachment.cgi?bugid=340019&action=enter
8) Type "Updated to comments" in the attachment description textfield (the one
right below the file upload control).
EXPECTED RESULTS: text renders at the same size
ACTUAL RESULTS: Text looks almost camel-cased. I'll post a screenshot.
Reporter | ||
Comment 1•18 years ago
|
||
Note that the "Browse" button has a similar issue...
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.9a2?
Comment 2•18 years ago
|
||
I've seen basically the same behaviour in a non-cairo non-pango build too, although not in textboxes (usually I see it on devmo^WMDC articles)
Flags: blocking1.9a2? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha6
Hm, I can't reproduce this with those font settings, ubuntu feisty. The text comes out all the same size.
Reporter | ||
Comment 4•17 years ago
|
||
Those are generic font settings. So the exact fonts they actually map to will likely depend strongly on your distribution. I'd be happy to tell you what fonts those are in this case if I knew how to get that information.
Comment 5•17 years ago
|
||
I think we need to wait for more info from Boris on this.
A log with FC_DEBUG=1 in the environment would give useful info on the actual fonts used.
Comment 6•17 years ago
|
||
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
Reporter | ||
Comment 7•17 years ago
|
||
Though note that in this case the bug did _not_ appear. In current builds it seems to be random: sometimes it appears, sometimes not. On the same content.
Comment 8•17 years ago
|
||
Looks like "Luxi Sans" is the (Type 1) font involved, hintstyle full, rgba none.
Do you have a freetype older than 2.1.10?
I wonder if this could be due to
http://savannah.nongnu.org/bugs/?12263
Reporter | ||
Comment 9•17 years ago
|
||
> Do you have a freetype older than 2.1.10?
Yes. freetype-2.1.9-2 according to rpm -q.
And yes, I can see how that bug could cause this problem if some of the glyphs are coming from one font size and others from a different font size.
Updated•17 years ago
|
Priority: -- → P4
Reporter | ||
Comment 10•17 years ago
|
||
For what it's worth, I haven't seen this in a while. But we've mucked about with default font stuff, I believe, so I may no longer be using the same fonts...
Updated•17 years ago
|
Target Milestone: mozilla1.9 M8 → ---
Comment 11•17 years ago
|
||
freetype 2.2.10 is our refplatform requirement and we can't reproduce this anymore... going to drop this off the list unless someone else can reproduce it.. marking WFM/invalid/fixed
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking1.9+ → blocking1.9-
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•