From: Ed (ed.trager@gmail.com)
Date: Thu Mar 24 2011 - 10:02:58 CST
Hi, Philippe,
For a long time I have had similar ideas.
In fact, in an experiment I performed back in September of 2009, I
wrote a utility program to produce a set of test cases for Devanagari
and also render the test case strings as a set of PNG images which
could be used to compare the results of rendering in a browser to the
PNG reference rendering. The utility spit out all the resulting PNGs
and also an HTML file so that one could quickly review results in a
browser window:
http://eyegene.ophthy.med.umich.edu/indic/
For the draft results for Devanagari shown at the above URL, I believe
I used the GPL'ed Chandas font (http://www.sanskritweb.net/cakram/ ;
the "glyph ids" shown on the page are obviously specific to the font
that was used). The Open Source (Linux) Pango layout engine along
with FreeType was used for the renderings shown in the PNG image
files.
The purpose of the experiment was to test the Pango layout engine,
initially against a set of Devanagari OpenType fonts, and to look for
bugs which might be present in either Pango or in the fonts
themselves.
My original idea was to eventually expand my test suite to cover *all*
Indic scripts. And not only that, but also to generate equivalent PNG
images using Uniscribe and also Apple OSX's rendering pipeline so that
one could compare all three OS's text layout engines side-by-side.
I quickly realized that such a project would soon consume a lot of my
time, as I would need to research and understand better the unique
properties of all of the Indic scripts. I inquired with people I knew
at one of the major Linux vendors (because one of my primary goals was
to ferret out the bugs in Pango) but was told that money was not
available for an outside contractor to perform such work. So I
stopped.
On a related note, for the Open Font Library project
(http://openfontlibrary.org/) I had separately written a program
called Fontaine ( http://unifont.org/fontaine/ ;
http://sourceforge.net/projects/fontaine/ ) which displays key meta
information about font files, including but not limited to font name,
style, weight, glyph count, character count, copyright, license
information and orthographic coverage. At one time, the JSON output
from Fontaine was transformed into a very nice report format on the
Open Font Library site. I had also written a demonstration web
application where a user could upload a font and the app would produce
a pretty presentation of Fontaine's report output : for font designers
and reviewers of works-in-progress, this output is extremely useful
for showing which glyphs are missing for any given orthography, inter
alia.
Web font technology via the CSS @font-face rules now enjoys broad
support among browsers. Using CSS @font-face and well-considered
Javascript on the front end --along with tools such as those described
above on a server backend-- would make it now possible to create a
very comprehensive font testing service as a web application that
would be quite useful to designers and users alike. However funding
and support from the Unicode Consortium or from one or more commercial
members of the Unicode Consortium or other interested vendors might be
required to make such a service a reality.
- Ed
==================================
On Wed, Mar 23, 2011 at 8:50 PM, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
> Then there should exist on the Unicode site, a HTML test page showing
> correctly encoded Myanmar sample text, with a reference bitmap
> rendering built with representative glyphs, and a way to change the
> name of the selected font to see if it matches the specs regarding not
> only the per character glyphs (those are already in the Unicode
> charts), but also for the possible alternate glyphs (if they exist),
> the expected reordering, the combinations in significant clusters, the
> expected ligatures (when they are mandatory), a non-ligatured
> rendering (if it's acceptble as a variant).
>
> Such test pages should be made for all complex scripts (notably all
> Indic scripts). This should even be done independantly of OpenType
> specifications (which are more technical and specific to some font
> technologies), so that it will not just test the font, but also the
> renderer and text layout engine, including in a web browser.
>
> The PDF given in a prior message also gives some other rendering
> constraints, notably for candidate line breaks for line wraps : this
> can also be tested in HTML by rendering the text in a narrow text
> column (possibly also by allowing the viewing user to rescale the font
> size, to make sure that all candidate line breaks effectively become
> true line wraps) : the reference image in the test page should then be
> shown side-by-side.
>
> A very basic Javascript would be needed that just adjust some CSS
> properties for the tested text (marked up with a simple CSS class that
> the Javascript will modify in its stylesheet if the user changes the
> selected font name to test and the font size) would be needed, even if
> the page content remains mostly static.
>
> There are some test pages developed in Wikipedia, but they are still
> incomplete (and lack the Javascript support for allowing someone to
> select another font to test easily). But those pages are pointing
> users to a few compatible fonts, even though the tests are still
> insufficient due to their limited coverage of the script capabilities
> and specificities (even on "rare" letters).
>
> 2011/3/22 Doug Ewell <doug@ewellic.org>:
>> I think there is some confusion here. It looks like Ngwe Tun is saying
>> that the Myanmar text on ayarunicodegroup.org is encoded in violation of
>> the correct Unicode *ordering conventions* for the script, not that the
>> encoding is an ASCII hack or something else other than Unicode (which is
>> what "non-Unicode font" and "migrate to Unicode Standards" usually
>> imply).
>>
>> I copied the text from Ayar's home page into BabelPad, a desktop app
>> which uses Uniscribe and has no access to any of Ayar's proprietary
>> fonts (using Code2000 instead), and didn't see any private-use
>> characters. But since I don't read Myanmar, it's entirely possible that
>> the text as encoded is complete garbage and needs to be reordered as
>> Ngwe Tun says.
>>
>> --
>> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
>> RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
>>
>>
>>
>>
>>
>
>
>
This archive was generated by hypermail 2.1.5 : Thu Mar 24 2011 - 10:09:26 CST