Re: [indic] Re: Lack of Complex script rendering support on Android

Well, it's true that Google could be more incentive when licencing
Androif to OEM manufacturers and mobile network vendors, so that they
have to support internationalization, at least as downloadable and
installable addon modules, because they are part of the standard
version.

OEM manufacturers of smartphones and tablets should not be allowed to
disable this support or block their installation, and users should not
have to root their device and loose the manufacturer warranty and
support at the same time for what should be an appoved extension (or
upgrade for users of older versions of Android).

I can understand that some older smartphones won't have enough
internal storage (for the rendering engine, but fonts may still be
found and installed on external SD storage) or CPU capabilities to
support all Android versions and that manufacturers may also want to
exhibit longer battery life.

But if there's no technological barrier, this should remain a choice
for users. And it would also help a lot the developers of Android apps
to get a more uniform support of the platform.

And even if OEM manufacturers, device resellers, and mobile networks
still want to feature some preinstalled components, this should remain
possible without modifying the core firmware. Users should know
clearly, before buying the device, how it is upgradable and which
levels of upgrades it supports., even if the device also includes
proprietary components (that could be still protected using signed
device drivers recognized by the standard firmware using a sort of
Plug'n-Play system comparable to desktop OS'es.

And even if some devices contain OEM application bundles, all apps in
this bundle should be dis-enabled by the Application & Services config
menu, or replacable by an downloaded version.

This is also needed to allow correcting security issues (harneed by
some malicious application, given that too many applications are
requesting too many privileges without really explaining why they need
it, even if this causes unexpected costs, for example when those apps,
not only free apps, are repeatedly downloading ads and reporting user
data to a remote server when the user does not even use the device and
the screen is locked, using custom "services"...); theses issues are
occuring in the many integrated components and libraries that are
linked in the kernel or in the Java/DalvikVM engine or with specific
integrated devices or in standard applications like the Android
Internet browser and the configuration menu, or in the security
manager built in the VM engine, or in the networking stacks.

Most of these issues are found and updated daily on the Internet for
Linux users, but Android firmwares are often late by years (or will
never receive any update due to total absence of support by the
manufacturer or reseller in less than 6 months after the end of sales)

Time to reform the Android Market and the Android development kit and
developers licencing rules ?

2011/11/5 Mahesh T. Pai <paivakil_at_gmail.com>:
> In continuation of my earlier post; and not to contradict what you
> say.
>
> John Hudson said on Fri, Nov 04, 2011 at 04:11:03PM -0400,:
>
>  > PUA isn't necessary, and a font technology that handles elements of
>  > complex script shaping by referencing PUAs isn't fundamentally any
>  > different from one that uses glyph names or another identifier and
>  > leaves the glyph unencoded.
>
> And if things were so simple, is Google such a dunderheaded
> organisation to ignore 3 score issues, plenty of complaints in the
> user community and more than 30% of Android's user base?
>
> That said, I do not think it is fear of OpenType IP that is keeping
> Google from implementing Indic support in Android.
>
> But of course, I fail to understand several things. ;-D
>
> --
> Mahesh T. Pai   ||
> Learn from the mistakes of others.
> You won't live long enough to make all of them yourself.
>
>
Received on Sat Nov 05 2011 - 11:03:19 CDT