WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 12448
50528
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
Summary
SVG text smaller than 0.5px not displayed properly
Jeff Schiller
Reported
2010-12-04 15:01:38 PST
http://codedread.com/browser-tests/subpixel.svg
or <svg xmlns='
http://www.w3.org/2000/svg
'> <text x='10' y='30'>The two words should be the same size:</text> <g transform='scale(15)'> <text y='12' style='font-size:0.5px'>TINY</text> <text y='24' style='font-size:0.499999px'>TINY</text> </g> </svg> Both words should be small on the page. The latter one at font-size smaller than 0.5px is not displayed appropriately. Also, you can see the effect more dramatically here:
http://upload.wikimedia.org/wikipedia/commons/f/f9/PI.svg
Attachments
Test case showing the problem
(271 bytes, image/svg+xml)
2010-12-04 15:03 PST
,
Jeff Schiller
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jeff Schiller
Comment 1
2010-12-04 15:03:29 PST
Created
attachment 75617
[details]
Test case showing the problem
Nikolas Zimmermann
Comment 2
2010-12-09 01:13:05 PST
Thanks for the testcase, Jeff! I've traced it down: #1 0x0426c654 in WebCore::FontCache::createFontPlatformData (this=0x1a5965c0, fontDescription=@0x1d4adda0, family=@0x1d4adda0) at /Users/nikolaszimmermann/Coding/WebKit/WebCore/platform/graphics/mac/FontCacheMac.mm:214 (gdb) p fontDescription $61 = (const class WebCore::FontDescription &) @0x1d4adda0: { m_familyList = { m_family = { m_string = { m_impl = { <WTF::FastAllocBase> = {<No data fields>}, members of WTF::RefPtr<WTF::StringImpl>: m_ptr = 0x1a56e650 } } }, m_next = { <WTF::RefPtr<WebCore::SharedFontFamily>> = { <WTF::FastAllocBase> = {<No data fields>}, members of WTF::RefPtr<WebCore::SharedFontFamily>: m_ptr = 0x0 }, <No data fields>} }, m_specifiedSize = 0.49000001, m_computedSize = 0.49000001, The font size is stored correctly in the FontDescription, but then "computedPixelSize()" is used to determine the actual font size. 193 194 FontPlatformData* FontCache::createFontPlatformData(const FontDescription& fontDescription, const AtomicString& family) 195 { 196 NSFontTraitMask traits = fontDescription.italic() ? NSFontItalicTrait : 0; 197 NSInteger weight = toAppKitFontWeight(fontDescription.weight()); 198 float size = fontDescription.computedPixelSize(); (gdb) p size $63 = 0 FontDescription.h: int computedPixelSize() const { return int(m_computedSize + 0.5f); } This is the root of the problem. Just keeping my analysis here for the record.
Nikolas Zimmermann
Comment 3
2011-02-01 04:02:52 PST
The patch on
bug 12448
fixes this problem. Thanks a lot for the testcase, I've integrated it in my patch. *** This bug has been marked as a duplicate of
bug 12448
***
Simon Fraser (smfr)
Comment 4
2011-02-01 08:44:35 PST
Is it really the same thing? In this testcase the text is just a line of pixels (even if it's not sharp). In Firefox, the text is much bigger.
Nikolas Zimmermann
Comment 5
2011-02-01 09:49:33 PST
(In reply to
comment #4
)
> Is it really the same thing? In this testcase the text is just a line of pixels (even if it's not sharp). In Firefox, the text is much bigger.
Which testcase are you referring to?
Simon Fraser (smfr)
Comment 6
2011-02-01 10:00:07 PST
One in a bug that I can't find right now, but was probably marked as a duplicate of this.
Dirk Schulze
Comment 7
2011-02-01 10:03:20 PST
I guess Simon thought about
bug 52892
.
Simon Fraser (smfr)
Comment 8
2011-02-01 10:06:53 PST
Yep, that's the one. Sorry, I thought this was that bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug