174.14 KB, application/pdf
173.52 KB, application/pdf
173.87 KB, application/pdf
173.72 KB, application/pdf
9.38 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+ If a font is changed in the Fonts tab of the Appearance preference pane, and the user reloads the document to apply the changes, the old measurements are used and the resultant rendered page may look funny if the metrics of the old and new typefaces differ. Reproducible: Always Steps to Reproduce: Start with the default Western font set to the proportional font, as Times 14. Visit http://bugzilla.mozilla.org/show_bug.cgi?id=184092#c5 . Do Navigator:Preferences:Appearance:Fonts. Switch Proportional (Serif) face to Lucida Grande 14 and close Preferences. Command-R (reload) Actual Results: The proportional font was changed to Lucida Grande 14, but the page was redrawn using the measurements from Times 14. Because Times is, in general, narrower than Lucida Grande at the same point size, various bits of text will overrun each other. Reload again, and the text will be drawn properly. When switching from Lucida Grande back to Times, gaps will be visible instead of overruns. Expected Results: The text should have been measured and drawn properly after the first reload. Actually, the page should have been rendered again after the font was changed. (And it should have been done properly.) Note that if multiple windows are open, and a change is made to the font selection, the change is applied to the background windows but not the foreground window. And the measurement bug is still present. (This is probably a separate bug.) 0.6.0+-2003012807/10.2.3
Duplicate of bug 185957 ?
I don't think so. Bug 185957 is about the page not being redrawn with the new fonts, which I mention here, but that's not what this bug is about. This bug is about text not being remeasured. Mark
Mark, please attach a couple of comparitive screen captures demonstrating the problem. (They don't have to be huge, just some part of the page that looks wrong.) Also, does this also happen using Mozilla? Please test it.
These images were prepared using Chimera 0.6.0+-2003020507. The bug is also present in Mozilla 1.3b-20030212. Reassign it over there?
Confirmed using Chimera/2003021707.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: saari → font
Component: General → Layout: Fonts and Text
Product: Camino → Browser
QA Contact: winnie → ian
Version: unspecified → Trunk
Probably something (table code?) is botching the reflow reason.
Actually, based on the comment that the problem is only happening in the foreground window, I suspect that's wrong. Perhaps something funny is going on with nsPresContext::ClearStyleDataAndReflow .
I'm unable to reproduce this in Mozilla, but I can reproduce it in Camino. Could you give steps to reproduce for Mozilla?
This fixes it. I need to poke into the prefs code to figure out why this works in other places. This also makes Camino apply font pref changes immediately.
Assignee: font → dbaron
Target Milestone: --- → mozilla1.6alpha
Summary: Text is not remeasured when font is changed and document is reloaded → [Camino]Text is not remeasured when font is changed and document is reloaded
David, Pink, is that patch something we should include in Camino 0.8?
I don't suppose there's any chance that this patch still applies, is there? The remeasuring problem's certainly still present in Camino 0.9a1 and DeerPark 1.1a1, and one still has to switch prefPanes or close the prefs window for font changes in Camino take effect.
David: do we still want that patch?
(In reply to comment #13) > Created an attachment (id=129888)  > patch > > This fixes it. I need to poke into the prefs code to figure out why this works > in other places. This also makes Camino apply font pref changes immediately. My apologies if this seems too elementary a question, but how do I apply the patch?
mento, dbaron: can you confirm that the remeasuring issue has been fixed sometime between when I made comment 16 and now? I've tried on bugzilla and a couple of other places (to rule out the bugzilla skin change being involved), and it seems fixed in Camino 1.0 (and a recent trunk). Camino's font prefs not updating until you switch prefPanes or close the prefs, on the other hand, has gotten really annoying with some bugs I've been QAing recently ;) so that part is definitely still b0rken.
(In reply to comment #19) > Camino's font prefs not updating until you switch prefPanes or close the prefs, > on the other hand, has gotten really annoying with some bugs I've been QAing > recently ;) so that part is definitely still b0rken. Should we just go ahead and file a new bug on that? Does Apple give guidance anywhere about whether prefs should always commit edits in real time, or wait until the prefs window is closed, or what? I suspect this is not the only pref pane where we fail to commit edits until un-selecting/closing. (For instance, the General prefs pane doesn't currently do this either, though a patch I've written for fixing another bug brings this behaviour to it.) cl
You need to log in before you can comment on or make changes to this bug.