From: Harshula (firstname.lastname@example.org)
Date: Sun Sep 13 2009 - 11:48:15 CDT
On Mon, 2009-09-07 at 23:35 +0600, Chris Fynn wrote:
> A limitation of this is that applications may use a different rendering
> engine than that used by the windowing environment of the operating
Firstly, it's not the rendering engine that would do the parsing and the
compliance check of the font, it would be the font management layer.
Secondly, the cached font metadata would only be checked when the OS or
an application wants to know if a font supports a particular script.
e.g. Similar to fontconfig and FcLangSet.
> The operating system checking for support of a script might be
> of some use as far as the UI of the OS is concerned ~ but not
> necessarily for much else.
That's good because this discussion is about displaying a correct and
consistent operating system UI.
> Anyway what is the OS actually going to check for? Beyond a cursory
> check to see that there are glyphs for all the characters in the Sinhala
> block and some OpenType lookups assigned under the script tag for
> Sinhala things become difficult. You can't easily check for particular
> lookups since one font may compose ligatures using GSUB & GPOS lookups
> while another font has pre-composed ligatures and uses only GSUB lookups
> - a third font may do things yet another way. For instance to get a font
> to actually work under an application like InDesign the developer might
> need to use completely different set of OpenType features than Microsoft
> specifies for Sinhala - and, to get them to work today, those lookups
> may need to be under the DFLT script tag rather than under the script
> tag for Sinhala. Are you going to do a run-time check for all these
The font parsing should happen when the font is installed, hence
complete parsing of the font, including all the tables, has no run-time
impact. I've already explained it here:
> Since OpenType fonts for complex scripts can be implemented in several
> different ways, what happens when an operating system or application is
> eventually faced with complying with a whole set of standards saying it
> should check that fonts meet some set of requirements for each of the
> different complex scripts and languages it supports? For each script
> Does it need to take account of all different ways a font can be
Each operating system has defined/implemented an interface between the
renderer/layout-engine and the fonts. e.g. The Indic modules of Pango,
ICU and QT stay in-sync to implement a consistent interface. And the
font would be checked according to that interface.
> - what happens when such standards are updated or changed?
Same as what happens to the renderer/layout-engine. i.e. You update the
> IMO this could rapidly get very complex and a nightmare to maintain.
> In fact I fear *requirements* like this could turn out to be be a big
> disincentive for developers to add support for complex scripts - or at
> least further delay them adding such support.
This is only applicable to operating system developers. How is it a
disincentive? The OS developer would first implement the renderer/layout
> What happens if my OS rejects a Sinhala font that actually works - can
> the font developer try and claim compensation from me when his customers
> demand their money back and the fault turns out to be my less than
> perfect run time checking not his font?
How is this any worse than the current situation? Currently, the OS may
choose a broken font over one that actually works. Furthermore, it would
be the operating system that parses and checks the font, not your "less
than perfect run time" checker.
> Rather than placing the burden on OS and application developers,
Again, this is only applicable to operating system developers.
> wouldn't it be easier simply to certify fonts that meet your national
> standard - and have a requirement e.g that computers supplied to
> government departments, schools etc come pre-loaded only with certified
> Sinhala fonts (and an operating system & applications properly
> configured to use them)?
All these strategies need to executed in parallel to achieve an optimum
This archive was generated by hypermail 2.1.5 : Sun Sep 13 2009 - 11:54:30 CDT