QA/Firefox3.1/FontFace TestStatus: Difference between revisions

From MozillaWiki
< QA‎ | Firefox3.1
Jump to navigation Jump to search
Line 80: Line 80:
|-
|-
|downloadable-font-markupdifference.html
|downloadable-font-markupdifference.html
font-|Check what happens when applying HTML markups to downloaded fonts
|Check what happens when applying HTML markups to downloaded fonts
|style="background:#ffaaaa;" |Fails
|style="background:#ffaaaa;" |Fails
|For example, when you apply &lt;em&gt; to a text rendered with downloaded fonts, the italic FACE IS CALCULATED. However, when you apply &lt;em&gt; to a text rendered with font in user's environment, the ITALIC FACE of that font-family is used. The former calculated face and latter italic face is different, so they are rendered slightly differently.
|For example, when you apply &lt;em&gt; to a text rendered with downloaded fonts, the italic FACE IS CALCULATED. However, when you apply &lt;em&gt; to a text rendered with font in user's environment, the ITALIC FACE of that font-family is used. The former calculated face and latter italic face is different, so they are rendered slightly differently.

Revision as of 17:32, 5 September 2008

« QA/Firefox3.1/FontFace TestPlan

Notes

@font-face test status Test Plan: @font-face TestPlan

Executed Tests

(Tests Already Executed)

Tests marked with star (*) shows that some unexpected features were found. See Possible Risks section for details.

Tests on Mac OS X

Executed Tests

file description status failure cause
downloadable-font-conflictname.html When the family name is same as a font family name in user's environment Sometimes fails Font is not loaded
downloadable-font-diacritic.html Check if the diacritic marks are displayed correctly Passes
downloadable-font-fallback.html Check the fallback functions Fails When trying to download a font from src: url(A), url(B), url(C) which is
  • url(A): violates same-site restriction
  • url(B): file in wrong format (ex.html,pdf)
  • url(C): valid TrueType Font file

Firefox downloads file from url(B) and displays nothing. Firefox should download file from url(C) and render with that font, or at least render with default font

downloadable-font-familywithseveral.html Check what happens when multiple @font-face rules are used for one font-family Sometimes fails Font is not loaded
downloadable-font-iframe.html Check if the downloaded fonts can be used from other documents (Answer should be no) Passes
downloadable-font-japanese.html Incorrect rendering of some Japanese fonts Fails see Bugzilla for detail [bug451426]
downloadable-font-layouttest.html Check the layout of downloaded fonts Fails Layout of default font used. Mentioned in [bug441473 #33]
downloadable-font-leavepagetest.html Check if the firefox crashes when leaving the page during the font download Sometimes crash Crash only seems to happen when you invoke firefox with -reftest option. But I'm not sure exactly when this happens. Still investigating the exact cause. [bug451462]
downloadable-font-ligature.html Check if the ligatures are displayed correctly Passes
downloadable-font-loadtest.html Check how much downloadable fonts can be handled in a page without any crash Sometimes fails Fonts are not loaded
downloadable-font-markupdifference.html Check what happens when applying HTML markups to downloaded fonts Fails For example, when you apply <em> to a text rendered with downloaded fonts, the italic FACE IS CALCULATED. However, when you apply <em> to a text rendered with font in user's environment, the ITALIC FACE of that font-family is used. The former calculated face and latter italic face is different, so they are rendered slightly differently.
downloadable-font-printtest.html Check if the downloaded fonts are used when you print out the document Passes
downloadable-font-sameorigin.html Check if the same-site restriction is working properly Passes

LoadTest

  • even 100 @font-face rules per page seems to be pretty scalable. When 210 (230 for the first page you load) or more @font-face rules are used in a document, firefox will crash.

Tests on Windows XP SP3

Executed Tests

file description status failure cause
downloadable-font-conflictname.html When the family name is same as a font family name in user's environment Passes
downloadable-font-diacritic.html Check if the diacritic marks are displayed correctly Passes
downloadable-font-fallback.html Check the fallback functions Fails The priority of fonts in fallback function seems to be wrong.

When a rule was like

@font-face { font-family:test; src: ; } .test { font-family:test, fantasy; }

it displays the default font, not the fantasy font.

Please be careful that fallback function has different problems in Windows and Mac.

downloadable-font-familywithseveral.html Check what happens when multiple @font-face rules are used for one font-family Fails When you specify a non-italic face with a font-style:italic rule, it is rendered in italic. It should not be in italic. It should be rendered using the exact font face you specified.
downloadable-font-iframe.html Check if the downloaded fonts can be used from other documents (Answer should be no) Passes
downloadable-font-japanese.html Incorrect rendering of some Japanese fonts Passes
downloadable-font-layouttest.html Check the layout of downloaded fonts Fails Layout of default font used. Mentioned in [bug441473 #33]
downloadable-font-leavepagetest.html Check if the firefox crashes when leaving the page during the font download Crashes This page will redirect to www.google.com while the font download is processed. Maybe slightly different from [bug451462 ]
downloadable-font-ligature.html Check if the ligatures are displayed correctly Passes
downloadable-font-loadtest.html Check how much downloadable fonts can be handled in a page without any crash Sometimes fails Layout bug ([bug441473 #33])

It seem to happen when it fails to download the font before the first rendering. But I'm not sure when it happens. The place it happens changes every time.

downloadable-font-markupdifference.html Check what happens when applying HTML markups to downloaded fonts Fails For example, when you apply <em> to a text rendered with downloaded fonts, the italic FACE IS CALCULATED. However, when you apply <em> to a text rendered with font in user's environment, the ITALIC FACE of that font-family is used. The former calculated face and latter italic face is different, so they are rendered slightly differently.
downloadable-font-printtest.html Check if the downloaded fonts are used when you print out the document Passes
downloadable-font-sameorigin.html Check if the same-site restriction is working properly Passes

LoadTest

  • 20 @font-face rules per page is pretty scalable. When you scroll the page or do some action during the downloading and rendering of a font, rendering will take a lot more time. So if more than 50 @font-face rules are used, it would take too much time for a user to wait (nearly 10 seconds, but not measured)

Planned (but not executed) Tests

(Tests Not Executed Yet)

  • OpenType Font test on Windows
    • Some OpenType fonts cannot be rendered only when using @font-face rules. See xyz for details.
    • Test case is not ready yet since we still cannot find a proper OpenType font for this test. This is due to the font license issues.

Possible Risks

(Known bugs, not-yet-implemented features, questions)

Bugs already filed in Bugzilla

  • Firefox crashes when you leave the page before the font download finishes.
  • Unknown gryph change happens to some Japanese characters when font (which does not contain Japanese characters) is downloaded and rendered.
    • Now filed as bug 451426
    • It happens when the file is encoded in Japanese encoding (Shift_JIS, EUC-jp). But it also happened on files encoded in UTF-8.
    • As written in bug 451426, this feature can be divided into two features
      • Some characters are rendered incorrectly from the moment it's loaded
      • Some characters are rendered differently after you re-focus on the firefox window
    • The latter feature reproduced on firefox 3.0.x, even on the pages that was not using downloadable fonts
    • The former feature reproduced only on nightly builds with the patch applied.

Bugs not filed in Bugzilla

  • The layout after the new fonts load seems to be based on the old layout, as is mentioned in bug 441473 #33
  • Fallback function not working on Mac OS X
    • When it fails to download the font from every URI written in src, it just doesn't display anything ... shouldn't it display in default font?
    • Also, when the url written in src did exist but was not in a proper format, it displays nothing. Even if they had other candidates after that url, those candidates are ignored.

Suspected Features

  • It takes so much time to download and render texts when many @font-face rules are written in one document

Expected Features

  • No support for EOT, dataFork TrueType, Bitmap Fonts

Bugs that will reproduce on Firefox 3.0.x

(that means, these bugs are not coming from the patch code, but are coming from the codes already implemented and landed)

Some fonts are not rendered on Windows

  • Some fonts are not rendered on Windows
    • Problem 1: @font-face rule does not work on some fonts. It fails to construct the font face.
    • Problem 2: Some fonts are not applied when using the characters not included in the font. This problem reproduces on Firefox 3.0.1
  • List of fonts and the result
Font face Patched Build / @font-face Patched Build / font-family Firefox 3.0.1 / font-family
Hiragino Kaku Gothic ProN W3 ✕ ✓ ✓
Verdana ✓ ✓ ✓
Chalkboard ✕ ★ ★ 
   ✓ Successfully rendered using the correct font face
   ✕ Failed. default font used
   ★ Fail on some occasions. Details described under the table
  • Problem 1: @font-face Hiragino Kaku Gothic ProN, Chalkboard
    • When using these fonts as downloadable fonts, firefox fails to construct the font face and uses default fonts to render the whole sentence
  • Problem 2: font-family: Chalkboard;
    • When using only the ordinary Latin alphabets, sentence is rendered using the chalkboard face, which is correct
    • When using the characters such as Ắ or 日, the whole sentence is rendered using the default font face
      • Expected result: The sentence is rendered using chalkboard characters, EXCEPT for the characters which is not included in chalkboard font
      • Internet Explorer 7 renders the text as expected

Unknown gryph change happens to some Japanese characters

  • Unknown gryph change happens to some Japanese characters when font (which does not contain Japanese characters) is downloaded and rendered.
    • details described above, filed as bug 451426

Fonts I use

(A list of fonts that I use in my test cases I developed so far)

Fonts I downloaded from Internet

Retrieved from "https://wiki.allizom.org/index.php?title=QA/Firefox3.1/FontFace_TestStatus&oldid=107614"