From: Chris Fynn (cfynn@gmx.net)
Date: Mon Sep 07 2009 - 12:35:13 CDT
Harshula
A limitation of this is that applications may use a different rendering
engine than that used by the windowing environment of the operating
system. 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.
For example MS Windows uses Uniscribe but Adobe applications use their
own rendering engine(s) - so a Sinhala font might work with Windows
Notepad but not with InDesign. For a publisher font working in the later
application may be far more important.
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
scenarios?
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
implemented - what happens when such standards are updated or changed?
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.
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?
Rather than placing the burden on OS and application 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)?
- Chris
Harshula wrote:
> Hi Doug,
>
> On Sun, 2009-09-06 at 13:09 -0600, Doug Ewell wrote:
>> "Harshula" <harshula at gmail dot com> wrote:
>>
>>> Taking these *realities* into account the operating system needs to
>>> have an *intelligent* way to determine if a particular font is
>>> sufficiently complete to be used for the UI. On some operating systems
>>> there is already a layer/mechanism that is responsible for doing
>>> exactly that.
>> Note that people are not necessarily saying it's a bad idea for an
>> operating system to do this type of runtime checking, if it can be done
>> efficiently and effectively. Users obviously want text in their
>> language to be displayed correctly.
>
> I agree. How do we get there? There's probably more than one approach
> that can be undertaken in parallel to achieve that goal.
>
>> Where you are running into resistance on this list is where you argue
>> that the checking MUST be done for compliance with a national standard,
>> and where your posts blur the distinction between (a) whether you feel
>> it is important for an OS to do the checking and (b) whether the
>> standard actually requires it.
>
> Firstly, I actually said "should", not "MUST": "Operating systems
> should, at a minimum, check that a Sinhala font meets these requirements
> before using it."
>
> Secondly, I have been requesting feedback on the wording of a possible
> amendment. Taking the feedback into account, the updated wording is:
>
> 'Operating systems shall, to the extent of their capabilities, only
> recognise Level 1 compliant fonts as Sinhala fonts.'
>
> The intent is that if the operating system already checks font
> compliance then it must adhere to Level 1 compliance for the aspects it
> can/does check. The other option is to change the "shall" to a "should".
> i.e. change it to a recommendation.
>
> What do you think?
>
> cya,
> #
>
>
This archive was generated by hypermail 2.1.5 : Mon Sep 07 2009 - 21:33:48 CDT