W3C home > Mailing lists > Public > www-style@w3.org > March 2015

Re: RTL characters in Ahem

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 12 Mar 2015 14:46:44 +0900
Message-ID: <CALYZoVO9jGGz6azog-7H6O0sLnWfsGk6xEZJYmxqqPP-4Mf07Q@mail.gmail.com>
To: Richard Ishida <ishida@w3.org>
Cc: Koji Ishii <kojiishi@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Just a practical consideration here. On some platforms Firefox will
explicitly reject the use of fonts without shaping information (i.e.
OpenType layout or AAT tables) for scripts that require it. So simply
tweaking the cmap for Ahem to add a mapping from an Arabic codepoint to an
existing glyph will *not* work for Firefox on all platforms. We need to do
this to avoiding using fonts that somewhat randomly include glyphs for
Arabic without also including the needed shaping information.

For scripts that require complex shaping, you really, really, really need
to be testing with appropriate fonts, not fonts with lots of missing
pieces. Yes, you'll be testing something but that something may not have
anything to do with the something that is actually used when real fonts are
used for a given script.

John

On Thu, Mar 5, 2015 at 9:25 PM, Richard Ishida <ishida@w3.org> wrote:

> On 05/03/2015 05:20, Koji Ishii wrote:
>
>> You can use "font-family: ahem, cssot" to get such effects, can't you?
>> See a test in Chromium[1].
>>
>
> On 05/03/2015 04:42, John Daggett wrote:
> > I don't think simply adding single glyphs within certain scripts to Ahem
> > is such a great idea. Displaying Arabic or Thai requires more than just
> > single glyphs, it requires fonts with shaping information, in the form
> > of AAT, OpenType or Graphite tables. Similarly, vertical writing mode
> > support requires fonts with vertical metrics and support for vertical
> > alternates.
> >
> > For complex layout features, tests should use fonts that at least mimic
> > the core set of required features that an actual font used for content
> > would require. There might be clever type designers out there who could
> > design a pan-Arabic-CJK-Thai Ahem testing font with the full set of all
> > the proper features actual fonts would contain but it's not a simple
> > task I think. Using the full set of Noto fonts from Google [1] would be
> > a more sensible approach I think. Yes, those fonts are not a trivial
> > size but I don't really think the size of these fonts is such a big
> problem.
> >
> > Yes, you can fudge things and add glyphs to Ahem. That will allow you to
> > test some features but not others. However, those tests won't be testing
> > the same codepath used by browsers when they actually display real
> > content with real fonts with these different features enabled. Real
> > fonts are readily available. It would be better to use them instead for
> > tests.
>
>
> I agree that the Ahem font isn't suitable for many types of test related
> to complex or vertical scripts (for that matter, I can easily think of, and
> was today working on, tests that would not be appropriate for the Ahem font
> even when working in English), but I think there are tests where it can be
> used effectively.
>
> What originally kicked off this idea was the test at
> http://www.w3.org/International/tests/repo/run?base=css-text-3&batch=text-
> align&test=text-align/text-align-start-009.html
> which i wanted to look like the others in the set.
>
> Of course, for that test i needed a character with strong RTL direction.
> In the end, I had to resort to using &lrm; at the start of the line to get
> a strong RTL character.  It works mostly, but produces a very thin white
> line in IE, which will spoil automated ref testing, if that ever happens.
>
> What I wanted to do was just start the line with אאא... and end up with a
> clean orange blob shape.
>
> I was also imagining testing for things like grapheme cluster boundaries
> with orange blobs, so that people unfamiliar with scripts like telugu or
> tibetan could easily tell whether the test passed or failed.
>
> hth
>
> ri
>
>
>
Received on Thursday, 12 March 2015 05:47:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC