The default bug view has changed. See this FAQ.

Artifacts left behind when reducing horizontal scale of text with font-family="sans-serif"

RESOLVED FIXED in mozilla12

Status

()

Core
SVG
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: Marek Raida, Assigned: Robert Longson)

Tracking

Trunk
mozilla12
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(8 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)

Repaint problems when using some sans-serif font (Arial, Helvetica) in bold weight and shrinking/transforming text from right to left.
Problem is not there with all fonts, only some, and never in normal weight.
It is visible on large texts (starts with font-size over 100px, the bigger the problem more visible)

Reproducible: Always

Steps to Reproduce:
1. Create text element, with font-family="Helvetica", font-weight="bold" and font-size="120px"
2. encapsulate text element to group and apply to group animateTransform, scale, from something big (like 2) to something small (like 0.5)
3. on the direction from right to left, some fonts are not repainted/cleared correctly
Actual Results:  
there are artifacts left

Expected Results:  
should be none

Reproducible always on my system on given link http://svg.kvalitne.cz/mix/repaint.svg
Created attachment 408951 [details]
original testcase

Here a copy of the reporter's testcase for Bugzilla.

FWIW, I can't currently reproduce, using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre
(Reporter)

Comment 2

8 years ago
I took also screenshot, could be of some use, maybe...

http://svg.kvalitne.cz/mix/repaint.png
Created attachment 408963 [details]
reporter's screenshot

Attaching the screenshot here. (It's best to testcases/screenshots directly to the bug, rather than posting them elsewhere.  That way, if someone takes a look at this bug in 6 months or a few years, they'll still be able to see what was broken, even if you've modified / moved / removed the file on your own server.)
(In reply to comment #3)
> Attaching the screenshot here. (It's best to testcases/screenshots directly to
> the bug, rather than posting them elsewhere.

Sorry -- "It's best to _attach_ testcases/screenshots [etc]"
Confirmed on WinXP (I see behavior matching what's captured in the screenshot above).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091028 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

8 years ago
I today tried it in office on six different computers, two of them running WinVista and problem reproducible on all of them...
Created attachment 409203 [details]
no-SMIL testcase (using JS for animation)

Here's a simple, no-SMIL testcase that just tweaks the 'transform' attribute at periodic intervals.  On Windows XP, I get tons of artifacts left over by the 'A' character, and a few left over by the 'V' character.  Tested a mozilla-central nightly as well as Firefox 3.5.3. (both are affected, though mozilla-central nightly is marginally better):

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091029 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Created attachment 409204 [details]
screenshot: no-SMIL testcase, using Firefox 3.5.3

Here's a screenshot of the no-SMIL testcase, using WinXP Firefox 3.5.3.
Created attachment 409205 [details]
screenshot: no-SMIL testcase, using mozilla-central nightly
Created attachment 409206 [details]
no-bold testcase (Using JS for animation)

Here's a testcase with "bold" removed.  It still triggers the bug, though I had to take finer samples to make it noticeable.
Created attachment 409207 [details]
screenshot: no-bold testcase, on mozilla-central nightly

Just attaching a screenshot of mozilla-central nightly for this one.
Summary: Text repaint issue in specific conditions → Artifacts left behind when reducing horizontal scale of text with font-family="sans-serif"
Version: unspecified → Trunk
FWIW: This is not a regression since 3.0.  I can reproduce this with latest 3.0.x nightly (tried both "no-SMIL" and "no-bold" testcases)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.16pre) Gecko/2009110206 GranParadiso/3.0.16pre
(Assignee)

Comment 13

8 years ago
Unfortunately these characters stick out of the glyph cell for the font and we invalidate based on the glyph cell rather than the actual bounds of the character.

Determining the actual bounds is more expensive.

Early patches for bug 520506 contained a fix for this issue by nsSVGGlyphFrame::UpdateCoveredRegion from using AddBoundingBoxesToPath to using AddCharactersToPath not sure what else can be done really.

Note that the final patch for bug 520506 did not contain that change though.
(Assignee)

Comment 14

5 years ago
Created attachment 587689 [details] [diff] [review]
patch

If you've looked at the patch in bug 616892 you've already seen this fix embedded in that patch. I'm struggling to land the patch for bug 616892 though as it causes a single reftest failure on Linux. Fortunately this bit can land on its own and fix this bug.
Assignee: nobody → longsonr
Attachment #587689 - Flags: review?(roc)
Attachment #587689 - Flags: review?(roc) → review+
(Assignee)

Comment 15

5 years ago
pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/04ed59232267
Flags: in-testsuite+
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/04ed59232267
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Blocks: 489877
You need to log in before you can comment on or make changes to this bug.