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
|
|
|
<?xml version="1.0" standalone="no"?>
|
|
|
|
|
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
|
|
|
|
|
|
|
|
|
|
<svg
|
|
|
|
|
xmlns="http://www.w3.org/2000/svg"
|
|
|
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
|
|
|
viewBox="0 0 100 100"
|
|
|
|
|
>
|
|
|
|
|
<g transform="matrix(0.1 0 0 0.1 10 10)">
|
|
|
|
|
<text font-family="'Arial'" font-size="120px">0,1,2,3,4</text>
|
|
|
|
|
</g>
|
|
|
|
|
<g transform="matrix(1 0 0 1 10 25)">
|
|
|
|
|
<text font-family="'Arial'" font-size="12px">0,1,2,3,4</text>
|
|
|
|
|
</g>
|
|
|
|
|
<g transform="matrix(12 0 0 12 10 40)">
|
|
|
|
|
<text font-family="'Arial'" font-size="1px">0,1,2,3,4</text>
|
|
|
|
|
</g>
|
|
|
|
|
<g transform="matrix(24 0 0 24 10 55)">
|
|
|
|
|
<text font-family="'Arial'" font-size="0.5px">0,1,2,3,4</text>
|
|
|
|
|
</g>
|
|
|
|
|
<g
|
|
|
|
|
transform="matrix(0.3 0 0 0.3 10 65)"
|
|
|
|
|
>
|
|
|
|
|
<text font-family="'Courier'" font-size="9">
|
|
|
|
|
<tspan x="0" y="0">For this test case to be successful, all</tspan>
|
|
|
|
|
<tspan x="0" y="15">lines of text must look the same. In Safari </tspan>
|
|
|
|
|
<tspan x="0" y="30">Beta 3, a text with a font size of 1 or smaller</tspan>
|
|
|
|
|
<tspan x="0" y="45">is not painted correctly, even if the coordinate</tspan>
|
|
|
|
|
<tspan x="0" y="60">transformations make it equivalent.</tspan>
|
|
|
|
|
<tspan x="0" y="75">Bug 14242</tspan>
|
|
|
|
|
</text>
|
|
|
|
|
</g>
|
|
|
|
|
</svg>
|
