W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2013

Re: Allow @font-face and TTF font embedding in tests? (Japanese fonts)

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Wed, 13 Feb 2013 14:35:29 -0500
Message-ID: <f31d375b4ef4a48fcc023ee079eabe08.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Chris Lilley" <chris@w3.org>
Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>, "taka" <takaoshiyama@gmail.com>

Le Mar 12 février 2013 11:31, Chris Lilley a écrit :
> Hello Gérard,
> Tuesday, February 12, 2013, 12:01:50 AM, you wrote:

Hello Chris,

>> Hello all,
>> This spun from
>> http://lists.w3.org/Archives/Public/public-css-testsuite/2013Feb/0008.html
>> We never discussed this issue before.
>> Should we allow and promote TTF font embedding in CSS3 tests ?
> We   should  allow  font  embedding in tests, certainly. Firstly, some
> test  may  be  testing  exactly  @font-face.  Secondly, some tests are
> easier  to  write  if  it  is  known  that  a  font  is available with
> particular properties.

This is the case with Taka's tests. The specific fonts must be

> Thirdly, it can produce more consistent results
> by  providing  a  font  to  be  used  and  thus  not  relying  on  the
> availability  or  not  of  so-called  'web  safe  fonts'  (which, like
> so-called web-safe colors, are anything but safe).
>> Benefits:
>> - no prerequisite to read
>> - no download, no installation to do

Also, no searching to do! We have 2 tests on deseret alphabet



and this can be unusually long and extraordinary difficult (for normal
testers) to find, download and install an adequate font for such tests.

We should be providing all necessary fonts for any/all tests in


and we do not.

>> Drawbacks:
>> - download and processing can be much longer: eg ipam.ttf is 8MB
> But subsetting and compression can help there.

WEFT can subset a font; I don't know about compression.

>> - not all user agents support TTF font embedding
> If they don't support a particular font format (or font downloading at
> all) then:
> -  for  tests where the downloadable font is helpful but not required,
> they  are  no  worse  off  and  go  to the next font in the list, or a
> fallback
> -  for  tests  which  do  depend  on  downloadable  fonts,  then  they
> (correctly) fail the test
>> Any comment is welcomed.
> I  would  prefer  to see woff rather than raw truetype or opentype
> fonts.

Unfortunately, I am not familiar with woff right now ... and how to
create a .woff format with/from a .ttf format...

> The font
> data  is the same when decompressed, but it is smaller to transmit and
> can contain useful metadata. WOFF is widely supported.

Taka, ideally, you should have something like the following in your tests:

	font-family: IPAMincho;
	src: local(IPAMincho),
        url("support/IPAMincho.woff") format("woff"),
        url("support/ipam.ttf") format("truetype");
        /* Filesize: 8046712 bytes; version: 00303 */

	font-family: IPAGothic;
	src: local(IPAGothic),
        url("support/IPAGothic.woff") format("woff"),
        url("support/ipag.ttf") format("truetype");
        /* Filesize: 6235344 bytes; version: 00303 */

I think unicode-range definition would not be useful here as your tests
really and strictly require one of 4 specific and unique fonts only.


>> ---------
>> I also believe that any/all fonts necessary to tests should be
>> fetchable, downloadable from
>> http://www.w3.org/Style/CSS/Test/Fonts/
>> Gérard
> --
> Best regards,
>  Chris                            mailto:chris@w3.org

Contributions to the CSS 2.1 test suite:

CSS 2.1 Test suite RC6, March 23rd 2011:

CSS 2.1 test suite harness:

Contributing to to CSS 2.1 test suite:
Received on Wednesday, 13 February 2013 19:36:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:25 UTC