2010-10-22 17:43:31 +00:00
|
|
|
Test
|
|
|
|
|
Test
|
2010-11-29 21:37:39 +00:00
|
|
|
Test
|
2010-10-22 17:43:31 +00:00
|
|
|
This test checks getBoundingClientRect() on zoomed HTML and SVG elements
|
|
|
|
|
|
|
|
|
|
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
|
|
|
|
|
|
2010-11-29 21:37:39 +00:00
|
|
|
Gray rectangles: 100x50
|
|
|
|
|
Green rectangles: 100x50, zoom=200%
|
|
|
|
|
Blue rectangles: 200x100, zoom=50%
|
|
|
|
|
|
2010-10-22 17:43:31 +00:00
|
|
|
Checking HTML elements:
|
|
|
|
|
|
|
|
|
|
PASS div1.left is 0
|
|
|
|
|
PASS div1.top is 0
|
|
|
|
|
PASS div1.width is 100
|
|
|
|
|
PASS div1.height is 50
|
|
|
|
|
PASS div1.right is 100
|
|
|
|
|
PASS div1.bottom is 50
|
|
|
|
|
|
|
|
|
|
PASS div2.left is 0
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS div2.top is 25
|
|
|
|
|
PASS div2.width is 100
|
|
|
|
|
PASS div2.height is 50
|
|
|
|
|
PASS div2.right is 100
|
|
|
|
|
PASS div2.bottom is 75
|
|
|
|
|
|
|
|
|
|
PASS div3.left is 0
|
|
|
|
|
PASS div3.top is 300
|
|
|
|
|
PASS div3.width is 200
|
|
|
|
|
PASS div3.height is 100
|
|
|
|
|
PASS div3.right is 200
|
|
|
|
|
PASS div3.bottom is 400
|
2010-10-22 17:43:31 +00:00
|
|
|
|
|
|
|
|
Checking SVG elements:
|
|
|
|
|
|
|
|
|
|
PASS svg1.left is 0
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS svg1.top is 250
|
2010-10-22 17:43:31 +00:00
|
|
|
PASS svg1.width is 150
|
|
|
|
|
PASS svg1.height is 50
|
|
|
|
|
PASS svg1.right is 150
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS svg1.bottom is 300
|
2010-10-22 17:43:31 +00:00
|
|
|
PASS rect1.left is 0
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS rect1.top is 250
|
2010-10-22 17:43:31 +00:00
|
|
|
PASS rect1.width is 100
|
|
|
|
|
PASS rect1.height is 50
|
|
|
|
|
PASS rect1.right is 100
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS rect1.bottom is 300
|
2010-10-22 17:43:31 +00:00
|
|
|
PASS image1.left is 100
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS image1.top is 250
|
2010-10-22 17:43:31 +00:00
|
|
|
PASS image1.width is 50
|
|
|
|
|
PASS image1.height is 25
|
|
|
|
|
PASS image1.right is 150
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS image1.bottom is 275
|
|
|
|
|
PASS text1.left is 100
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text1.top is 282.5
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text1.width is 46
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text1.height is 6.5
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text1.right is 146
|
|
|
|
|
PASS text1.bottom is 289
|
2010-11-29 21:37:39 +00:00
|
|
|
|
|
|
|
|
PASS svg2.left is 75
|
|
|
|
|
PASS svg2.top is 100
|
|
|
|
|
PASS svg2.width is 150
|
|
|
|
|
PASS svg2.height is 50
|
|
|
|
|
PASS svg2.right is 225
|
|
|
|
|
PASS svg2.bottom is 150
|
|
|
|
|
PASS rect2.left is 75
|
|
|
|
|
PASS rect2.top is 100
|
|
|
|
|
PASS rect2.width is 100
|
|
|
|
|
PASS rect2.height is 50
|
|
|
|
|
PASS rect2.right is 175
|
|
|
|
|
PASS rect2.bottom is 150
|
|
|
|
|
PASS image2.left is 175
|
|
|
|
|
PASS image2.top is 100
|
|
|
|
|
PASS image2.width is 50
|
|
|
|
|
PASS image2.height is 25
|
|
|
|
|
PASS image2.right is 225
|
|
|
|
|
PASS image2.bottom is 125
|
|
|
|
|
PASS text2.left is 175
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text2.top is 132.5
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text2.width is 49
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text2.height is 6.5
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text2.right is 224
|
|
|
|
|
PASS text2.bottom is 139
|
2010-10-22 17:43:31 +00:00
|
|
|
|
2010-11-29 21:37:39 +00:00
|
|
|
PASS svg3.left is 900
|
|
|
|
|
PASS svg3.top is 500
|
|
|
|
|
PASS svg3.width is 300
|
|
|
|
|
PASS svg3.height is 100
|
|
|
|
|
PASS svg3.right is 1200
|
|
|
|
|
PASS svg3.bottom is 600
|
|
|
|
|
PASS rect3.left is 900
|
|
|
|
|
PASS rect3.top is 500
|
|
|
|
|
PASS rect3.width is 200
|
|
|
|
|
PASS rect3.height is 100
|
|
|
|
|
PASS rect3.right is 1100
|
|
|
|
|
PASS rect3.bottom is 600
|
|
|
|
|
PASS image3.left is 1100
|
|
|
|
|
PASS image3.top is 500
|
|
|
|
|
PASS image3.width is 100
|
|
|
|
|
PASS image3.height is 50
|
|
|
|
|
PASS image3.right is 1200
|
|
|
|
|
PASS image3.bottom is 550
|
|
|
|
|
PASS text3.left is 1100
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text3.top is 565
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text3.width is 92
|
2012-04-23 17:42:19 +00:00
|
|
|
PASS text3.height is 13
|
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
SVG <text> with font-size smaller or equal to 1 does not paint correctly
https://bugs.webkit.org/show_bug.cgi?id=14242
misplaced text in SVG
https://bugs.webkit.org/show_bug.cgi?id=17053
Don't render very small (but zoomed) text inside SVG
https://bugs.webkit.org/show_bug.cgi?id=19393
Tiny fonts scaled up end up too large in Safari
https://bugs.webkit.org/show_bug.cgi?id=20192
Stretched SVG Text has awful glyph spacing
https://bugs.webkit.org/show_bug.cgi?id=21774
REGRESSION (r72141?): svg/batik/text/smallFonts.svg failing on Leopard
https://bugs.webkit.org/show_bug.cgi?id=49846
[Gtk] Text height in zoomed SVG is 1px too high
https://bugs.webkit.org/show_bug.cgi?id=50313
SVG text smaller than 0.5px not displayed properly
https://bugs.webkit.org/show_bug.cgi?id=50528
When rendering text, we're selecting a font with a size, as specified in the markup.
This can lead to problems, if the context, where the text is rendered upon, is scaled. If a parent
element of the <text> defines a transform=".." or the outermost <svg> containing a viewBox the
problem becomes apparent.
Consider following two snippets, which should render exactly the same:
<svg viewBox="0 0 100 100"><text x="25" y="50" font-size="25">test</text></svg>
<svg viewBox="0 0 1 1"><text x="0.25" y="0.5" font-size="0.25">test</text></svg>
When selecting a font size below 0.5, FontCacheMac would request a font with size 0,
which AppKit turns into 12. This lead to huge text rendering, instead of small text on Mac.
Other platforms have different problems (Qt simply scales the font, leading to pixelation etc.)
To fix this in a cross-platform fashion, we now always compute the final font size on screen,
remove any scaling from the context, draw the text using the scaled font size, then reapply
the context scale. This makes the example snippets above render exactly the same and fixes
numerous of bugs, present since years. As we're now heavily using floating-point font sizes
internally, depending on the scale of the document, it's very important to use the new
floating-point text metrics information (floatAscent/floatDescent/floatHeight) everywhere in SVG.
Fixes existing tests: css3/zoom-coords.xhtml (cross-platform inconsistencies should be gone, mac now reports floatHeight values for SVG text height)
svg/hixie/text/003.html (no more pixelation)
svg/batik/text/smallFonts.svg (small fonts aren't rendered huge anymore on mac)
svg/hixie/viewbox/preserveAspectRatio/001.xml (bug 21774, no more awful spacing)
svg/zoom/page/zoom-zoom-coords.xhtml (cross-platform inconsistencies should be gone, inspired by bug 50313)
Tests: svg/text/font-size-below-point-five-2.svg (reduction from bug 50528)
svg/text/font-size-below-point-five.svg (reduction from bug 50528)
svg/text/scaled-font.svg (reduction from bug 12448)
svg/text/small-fonts-2.svg (reduction from bug 14242)
svg/text/small-fonts-3.svg (reduction from bug 17053)
svg/text/small-fonts-in-html5.html (reduction from bug 19393)
svg/text/small-fonts.svg (reduction from bug 20192))
* rendering/svg/RenderSVGInlineText.cpp: Cache 'float scalingFactor' & 'Font scaledFont', whenever the on-screen representation changes.
* rendering/svg/RenderSVGInlineText.h:
* rendering/svg/RenderSVGText.cpp: Update scalingFactor/scaledFont, if necessary.
* rendering/svg/SVGInlineTextBox.cpp: Switch to new font rendering strategy. Always use scaledFont, and remove any context scale before drawing.
* rendering/svg/SVGInlineTextBox.h:
* rendering/svg/SVGTextLayoutEngineBaseline.cpp: Use floating-point metrics everywhere.
* rendering/svg/SVGTextMetrics.cpp: Ditto.
* rendering/svg/SVGTextMetrics.h: Ditto.
* rendering/svg/SVGTextQuery.cpp: Ditto.
* svg/SVGFont.cpp: Adjust stroke thickness, when drawing SVGFonts into a normalized context (no more scale).
* svg/SVGTextContentElement.cpp: Make <text> elements always dependant on window size changes in combination with viewBox set.
* svg/SVGTextPositioningElement.cpp: Remove now unnecessary code to determine wheter relative lengths are used as text attributes.
* svg/SVGTextPositioningElement.h:
2011-02-03 Nikolas Zimmermann <nzimmermann@rim.com>
Reviewed by Dirk Schulze.
small text which is scaled to be large renders pixelated
https://bugs.webkit.org/show_bug.cgi?id=12448
Update SVG test results after fixing small font size support. Land new mac/mac-leopard baseline, as text looks slightly different
in each testcase, as the font-size used for on-screen rendering has changed, this results in hinting differences, inter-glyph
space changes, etc. This commit only includes the textual result changes, the pixel test baseline will land in chunks in follow-up commits.
To those who have to rebaseline their platforms: Some of the svg/text pixel test results may look questionable on first sight,
- svg/text/select-* tests:
These tests render a certain string 'Foobar' and query the metrics using SVG Text DOM API (getExtentOfChar(firstChar) and getExtentOfChar(lastChar)).
A red rectangle is drawn, to represent the size of the string, which gives precise results using floating-point accurancy.
Using eventSender, a selection is simulated, by clicking the first char, holding down, and moving towards the last character.
The blue selection rect which is drawn, should in theory be equal to the red rectangle.
In practice it is not, as the selection rect is aligned to integer boundaries (see floor calls in Font::selectionRect...).
Since we switched to use floating-point precision metrics, the actual drawn selection may exceed the red rectangle up to 1px.
- svg/text/selection-(doubleclick|tripleclick).svg:
These tests use DRTs dumpSelectionRect() which draws a red rectangle, highlighting the SelectionController::bounds() obtained through RenderView.
In theory this red rectangle, should be equal to the drawn blue selection rect. Again it isn't, as the bounds() methods uses selectionRectForRepaint()
of RenderText, which returns an enclosingIntRect of the actual selection. The drawn selection starts at y=0.93 in the first testcase, the selectionRectForRepaint()
call returns an IntRect, which starts at y=0. That explains why the red rectangle starts slightly higher as it should be. Again this is no problem, the repaint
rect may be 1px larger, if it would be smaller, we had a problem. The only way to fix this, would be to pass around FloatRect as repaint rects, but that's not worth it.
- css3/zoom-coords.* / svg/zoom/page/zoom-zoom-coords*:
These tests have different expectations now, as we're using the floatAscent/floatDesent/floatHeight FontMetrics methods instead of
the integer variants ascent/descent/height - hopefully we'll see consistent results across platforms for these tests now, if not please comment in the bug report.
* css3/zoom-coords-expected.txt:
* css3/zoom-coords.xhtml:
* platform/mac-leopard/Skipped:
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-01-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/coords-dom-04-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/filters-image-03-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.checksum: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.png: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/paths-dom-02-f-expected.txt: Added.
* platform/mac-leopard/svg/W3C-SVG-1.1-SE/pservers-grad-17-b-expected.txt: Added.
...
Canonical link: https://commits.webkit.org/67568@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@77485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2011-02-03 14:46:25 +00:00
|
|
|
PASS text3.right is 1192
|
|
|
|
|
PASS text3.bottom is 578
|
2010-10-22 17:43:31 +00:00
|
|
|
|
|
|
|
|
PASS successfullyParsed is true
|
|
|
|
|
|
|
|
|
|
TEST COMPLETE
|
|
|
|
|
|