Re: [android-coretech] Re: Request for creation of Project for Open Font Manager

[David Turner]

Hello,

+cc android-contrib, +bcc android-coretech

I have moved this discussion to the android-contrib mailing list, this is is more appropriate than android-coretech.

For the record, android-contrib was created recently to hold discussions about platform contributions.

We initally intended android-platform to do that, but this list was poorly named and has now low signal-to-noise ratio.

I thus invite you to join the group asap.

I'll answer your specific questions in a later answer in android-contrib only.

Thanks a lot, sorry for the annoyance.

- David

On Mon, Jun 14, 2010 at 6:41 AM, Bitstream Inc <bitsa...@gmail.com> wrote:

Hi David
Thank you for the reply and the comments. Yes this seems to be a very
logical path and we are already working on the same. Please find some
of my comments inlined below. This seems to be more exciting now :)
Regards
Lokesh

On Jun 5, 1:46 am, David Turner <di...@android.com> wrote:
> Thanks for the clarifications,
>
> I think it's clear that such an interface could be useful, however, a few  remarks:

Lokesh>> Thanks. This is a great start. :)

>
> - I'm not sure that external/ is the best location for something like that.  It would probably be part of frameworks/base/ instead, so a new module doesn't seem   necessary.

Lokesh>> Yes this is great.

>
> - I would suggest using something a bit more descriptive than "ofm", tiny acronyms  tend to become very cryptic in a large codebase like Android :-)

Lokesh>> Can we use "fontengine"  ? with this be fine ?

>
> - Also "Open Font Manager" is a slightly misleading name, since this feature  is to manage font engines, not font data; and even "Open" leads to believe that  this  would not be Android-specific (like I originally thought, but you're proposing
>   something that depends on Skia, so...). Please correct me if I'm wrong.

Lokesh>> Yes this is correct. Its a font engine manager or font
plugins manager.

> - The Android team is currently investigating alternatives to Skia, and tying the  font manager to this library would severely limit our choices in the future.

Lokesh>> I agree, separating this from the Skia will make the solution
scalable to any graphic library.

>
>   In other words, an abstraction layer will need to be provided, one that is as simple as possible.

Lokesh>> Yes, for now may be we can provide very simple layer using
typecast and then can enhance it to skia free. Will this be a nice
idea ?

>
> I would thus suggest an alternative plan to get this accepted:
>
> 1. Write a specification document for this project, detailing the boundaries of what you want to support, proposed architectural choices, and submit it there for discussion.

Lokesh>> We are working on it. Will try to submit by this week.

>
> 2. Submit patches to framework/base/ that implement the interface that has been approved. For example, put your external headers under include/fontengines/ and the implementation under libs/fontengines/. At a minimum you would need a "wrapper" around FreeType.

Lokesh>> Yes sure. Shld the name be fontengine instead :) or
fontframework ?

>
> 3. Also submit patches to external/skia to use this.

Lokesh>> Yes, we may submit this along with 2.

>
> The more important part is to get an API that doesn't depend on Skia at all but still provides sufficient features that a typical SkFontScaler requires/provides.

Lokesh>> We are on it :), thanks for the guidance, this is very
helpful.
>
> hope this helps
>
> - David

>
> On Thu, Jun 3, 2010 at 8:00 AM, Bitstream Inc <bitsandr...@gmail.com> wrote:
> > Hi David
> > Thanks for the reply. Please find my comments inlined below.
>
> > > Is there any documentation about the Open Font Manager project anywhere ?
> > > I could not find anything through a search engine.
>
> > Lokesh>> It will be made public soon as soon as the access to this
> > project is granted. I am trying to explain the same in brief below.
>
> > Anyone will be able to add the font engine to Android if the following
> > steps are followed, which are very easy as compared to now.
>
> > 1/ Inherit and implement a class based on OFMInst (Open Font Manager
> > Instance), whose definition is below:
>
> > class OFMInst
> > {
> > public:
> >        virtual void init() = 0;
> >        virtual SkScalerContext* createScalerContext(const SkDescriptor*
> > desc) = 0;
> >        virtual int getNameAndStyle(SkStream* stream, SkString* name,
> > SkTypeface::Style* style) = 0;
> >        virtual ~OFMInst(){}
> > };/* end method OFMInst */
>
> > Just four methods !! For example the implementation of FreeType will
> > be contributed (minor changes as compared to current implementation of
> > SkFontHost_FreeType.cpp).
>
> > 2/ Once done, add the following static function to the implementation,
> > which will help the OTFManager to load the OFMInst class handle from
> > dll:
>
> > extern "C"
> > {
> >        /*Start of C code*/
> >        OFMInst* getFontDriverInstance()
> >        {
> >                /* Sample code below, simple return the OFMInst instance */
> >                ofmInst = new OFMInstImpl; /* implementation of
> > OTFInst */
> >                ofmInst->init();
> >                return (OFMInst*)ofmInst;
> >        }/* getFontInstance() */
>
> > }/* end extern "C" */
>
> > 3/ Place the DLL at "/system/fonts/ofm"
>
> > Thats all. The OpenFontManager will pick all the font plugins and will
> > route the font to the capable plugin. This also adds a great
> > functionality to Android, add any font formats easily, with different
> > plugins.
>
> > > Can you describe what you plan to implement through this?. As far as I
> > understand,
> > > a font engine provider can already provide a FreeType-compatible API on
> > top of their
> > > own engine and their client use it through a local manifest that redirect
> > external/freetype.
>
> > Lokesh>> This is true but this is not easy to do, and less scalable
> > (may be performance also drops). More over at one time only one engine
> > can be active. With this easy approach, one can add many font plugins
> > at a time. And with very much ease. FreeType will be there by default
> > after this approach too. This also provides the way to support
> > proprietary font engine drivers since this will done at DLL level.
> > This approach is much easier to follow and has been backbone of other
> > mobile environments where multiple font format compatibility is needed
> > to meet localization efficiently.
>
> > >> Do you plan to add another abstraction layer to talk to the font engine
> > ?
> > Lokesh>> Its a new module or layer which can enable multiple font
> > engines at a time :), including FreeType at no performance hit.
>
> > > What other issues, not directly related to the font engine, do you want
> > to  support ?
> > Lokesh>> Some of these are mentioned above, trying to assimilate the
> > positives (which are not in Android right now) the same below:
> > 1. Easy integration of any third party engine
> > 2. Allowing more than one font engine active at a time.
> > 3. Allowing multiple engines to support multiple formats.
> > 4. Access on DLL level to font engine in case of proprietary font
> > formats.
> > 5. Another level of modularity in Android for Font Engine support.
>
> > Please note that Bitstream will try to propose the sample
> > implementation of the OpenFontManager and the sample implementation of
> > OFMInst based on FreeType. There is no performance degradation.
> > Please let us know in case of further queries.
>
> > Regards
> > Lokesh
>
> > > On Tue, May 25, 2010 at 5:02 AM, Bitstream Inc <bitsandr...@gmail.com
> > >wrote:
>
> > On May 28, 5:12 am, David Turner <di...@android.com> wrote:
> > > Is there any documentation about the Open Font Manager project anywhere ?
> > > I could not find anything through a search engine.
>
> > > Can you describe what you plan to implement through this?. As far as I
> > > understand,
> > > a font engine provider can already provide a FreeType-compatible API on
> > top
> > > of their
> > > own engine and their client use it through a local manifest that redirect
> > > external/freetype.
>
> > > Do you plan to add another abstraction layer to talk to the font engine ?
>
> > > What other issues, not directly related to the font engine, do you want
> > to
> > > support ?
>
> > > On Tue, May 25, 2010 at 5:02 AM, Bitstream Inc <bitsandr...@gmail.com
> > >wrote:
>
> > > > Hi,
> > > > Any update on this. I request to please add this project so that we
> > > > can begin proposing the changes for very configurable font rendering
> > > > engine system in Android.
> > > > Regards,
> > > > Lokesh
>
> > > > On May 5, 7:18 pm, Bitstream Inc <bitsandr...@gmail.com> wrote:
> > > > > Hi,
> > > > > On Behalf of Bitstream Inc, I request to please create a directory/
> > > > > project for Open Font Manager. The path can be external/ofm.
> > > > > This new approach proposed by Bitstream Inc will allow to plugin any
> > > > > font engine apart from/or with FreeType.
> > > > > This will be very much valuable for the OEMs who may need the
> > > > > different engine than/with freetype or a set of engines to support
> > the
> > > > > localization issues or new font formats.
> > > > > This new proposal also enables Android to support more than one font
> > > > > engine dynamically at runtime. This is very common in BREW and
> > > > > Symbian, and Bitstream Inc wishes to add the same functionality to
> > > > > Android. It is also possible to achieve more rendering performance
> > > > > with very much customized or well tuned engines for a particular
> > > > > hardware.
> > > > > Regards,
> > > > > Lokesh
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "android-coretech" group.
> > > > > To post to this group, send email to
> > android-...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
> > > > android-corete...@googlegroups.com<android-coretech%2Bunsu...@googlegroups.com>

> > <android-coretech%2Bunsu...@googlegroups.com<android-coretech%252Buns...@googlegroups.com>

>
> > > > .
> > > > > For more options, visit this group athttp://
> > > > groups.google.com/group/android-coretech?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "android-coretech" group.
> > > > To post to this group, send email to android-...@googlegroups.com
> > .
> > > > To unsubscribe from this group, send email to
> > > > android-corete...@googlegroups.com<android-coretech%2Bunsu...@googlegroups.com>

> > <android-coretech%2Bunsu...@googlegroups.com<android-coretech%252Buns...@googlegroups.com>

>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/android-coretech?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-coretech" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-corete...@googlegroups.com<android-coretech%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-coretech?hl=en.

--
You received this message because you are subscribed to the Google Groups "android-coretech" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-corete...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-coretech?hl=en.

[Bitstream Inc]

Hi David
Please suggest in case of any modifications or changes needed. Once the document is reviewed we can submit the patches for the same.
Regards
Lokesh

[David Turner]

Sorry for being late, I'm a bit busy.

Anyway, the current specification you provided still relies on Skia (even in a sort of "optional interface" sort of way),
and this is not desirable, as I already explained.

I would really prefer that you come with a proper abstraction for the features provided by the font engine that would stand on its own.

I know it's not trivial, but the Skia interface is too funky to be depended on, and its ABI is absolutely not frozen, which is another

problem for long-term support for font engine binaries.

[Bitstream Inc]

Hi David
Please find the new proposal document at
http://bitstream.com/open/android/FontEngineManagerProposal.pdf
We have been working on the implementation too and thats coming very
nice. I think what you suggested was best and scalable :)
Now none of the modules of FontEngineManager depend on Skia or any
third party code and its like very base utility of Android on which
any Graphic Engine can work, and we can add more apis easily if needed
in future.
Thank you again for the great suggestion. Please let us know your
comments on the document. Once this is through we can submit the code
for review.
Regards
Lokesh
** We have posted the same at android-coretech

On Jul 2, 1:20 am, David Turner <di...@android.com> wrote:
> Sorry for being late, I'm a bit busy.
>
> Anyway, the current specification you provided still relies on Skia (even in
> a sort of "optional interface" sort of way),
> and this is not desirable, as I already explained.
>
> I would really prefer that you come with a proper abstraction for the
> features provided by the font engine that would stand on its own.
> I know it's not trivial, but the Skia interface is too funky to be depended
> on, and its ABI is absolutely not frozen, which is another
> problem for long-term support for font engine binaries.
>

> On Wed, Jun 30, 2010 at 9:56 PM, Bitstream Inc <bitsandr...@gmail.com>wrote:
>
> > Hi David
> > Please suggest in case of any modifications or changes needed. Once the
> > document is reviewed we can submit the patches for the same.
> > Regards
> > Lokesh
>
> > On Mon, Jun 14, 2010 at 10:55 PM, David Turner <di...@android.com> wrote:
>
> >> Hello,
>
> >> +cc android-contrib, +bcc android-coretech
>
> >> I have moved this discussion to the android-contrib mailing list, this is
> >> is more appropriate than android-coretech.
>
> >> For the record, android-contrib was created recently to hold discussions
> >> about platform contributions.
> >> We initally intended android-platform to do that, but this list was poorly
> >> named and has now low signal-to-noise ratio.
> >> I thus invite you to join the group asap.
>
> >> I'll answer your specific questions in a later answer in android-contrib
> >> only.
>
> >> Thanks a lot, sorry for the annoyance.
>
> >> - David
>

> ...
>
> read more »

[Bitstream Inc]

Hi David
Please suggest. The implementation is near to ready. We can submit
that too soon.
Regards
Lokesh

On Jul 27, 7:41 pm, Bitstream Inc <bitsandr...@gmail.com> wrote:
> Hi David

> Please find the new proposal document athttp://bitstream.com/open/android/FontEngineManagerProposal.pdf

> ...
>
> read more »

[Gaurav]

Hi David,

Please suggest in case any modifications or changes are needed in the
new proposal document for Font Engine Manager Proposal. The link for
this document has been shared by Lokesh in his earlier post.

Regards,
Gaurav Jain
Bitstream India

> ...
>
> read more »

[David Turner]

Hello,

sorry, I was on vacation for three weeks, and I had some important catch-up to do.

I just read the document, and the general plan sounds good. I have only minor observations at this point:

- I would recommend using "FontEngine" instead of "FontDriver", since it's a better description of the object instance it models.

- The way engines are selected based on the content of the font file is not specified here. This is going to be one very important part of the puzzle. Preferably, we would like to avoid having to add a system setting to make the user (or the application) select the font engine. We should also avoid over-engineered solutions like xml-based config file with a custom DSL language baked in, just saying.

It's also important to avoid scanning too many files, too often, be it scanning for font engine libraries in the system, or the font files themselves. I hope this is being considered when doing the engine selection. We certainly don't want to run each engine's load function just to determine which font format the file is in. We may want to provide a small method (e.g. isFileSupported()) that could do _very_ quick checks from a given stream.

- One important thing about this is that the font engine libraries will be loaded in all UI processes. For security reasons, we cannot accept third-party engines to be downloaded from Market or other sources, since this opens doors to all kinds of nastiness. It'd be nice if the design doc, and more importantly the source comments, make this *very* explicit. E.g. the loader should ensure that the font engine libraries are decidedly in the system partition (e.g. under /system/lib/fontengines/, for example).

- It's not certain that libutils is the right place to implement the FEM. libutils is used both on the host and the device (many of the Android tools link against it), we may find something else instead, but it's not a really high priority.

Thanks a lot, I think I'm ready to look at the sources, so please fire away on gerrit :-)

- David

[Bitstream Inc]

Hi David,
Thank you for your reply :), hope you had a nice vacation time. Please
find my comments below.
Regards,
Lokesh

Director, Research & Development,
Bitstream Inc.

On Sep 2, 1:44 am, David Turner <di...@android.com> wrote:
> Hello,
>
> sorry, I was on vacation for three weeks, and I had some important catch-up
> to do.
>
> I just read the document, and the general plan sounds good. I have only
> minor observations at this point:
>
> - I would recommend using "FontEngine" instead of "FontDriver", since it's a
> better description of the object instance it models.

Lokesh>> Yes done, sorry we missed this in the document.

>
> - The way engines are selected based on the content of the font file is not
> specified here. This is going to be one very important part of the puzzle.
> Preferably, we would like to avoid having to add a system setting to make
> the user (or the application) select the font engine. We should also avoid
> over-engineered solutions like xml-based config file with a custom DSL
> language baked in, just saying.

Lokesh>> yes definitely, we need to make this very transparent for the
user/application. The way we thought of is through the API
createFontScalerContext of FontEngineManager which in turn calls the
same method on FontEngine. If the font format is supported then the
context is created else NULL is returned. Also some more explanation
is below:

1. FontEngineManager::createFontScalerContext() : The API creates and
return font scaler instance. Font Engine list is traversed and a
request for font scaler is perform against a font engine. The API
return immediately if the font scaler successfully created ; a request
for font scaler creation is made to next font driver in the list
otherwise.

2. FontEngineManager::getFontEngine() and
FontEngine::createFontScalerContext() : If the user wants to creates
the font scaler from a specific FontEngine; say "freetype"; then user
can perform the following :

i) User need to perform getFontEngine("freetype"). This will return
the instance of FontEngine if "freetype" is supported; NULL otherwise.
ii) User need to call createFontScalerContext() on the returned
FontEngine instance.

Please suggest. How does this sound ?

>
> It's also important to avoid scanning too many files, too often, be it
> scanning for font engine libraries in the system, or the font files
> themselves. I hope this is being considered when doing the engine selection.
> We certainly don't want to run each engine's load function just to determine
> which font format the file is in. We may want to provide a small method
> (e.g. isFileSupported()) that could do _very_ quick checks from a given
> stream.

Lokesh>> Yes very true, we have incorporated the same. The new
signature of classes will be like below:

// Font Engine Interface; each plugin will provide its implementation
class FontEngine
{
public:
...

/* Given system path to font file; return if the font format
supported.
*
* If isLoad is set to true then; font file will be loaded i.e.
sfnt and scaler will be created to determine the font file support.
* If isLoad is set to false then; the font file extension will be
checked against the font format list; a static list of the engine
supported formats; of the Font Engine.
*/
virtual bool isFileSupported(const char path[], bool isLoad) = 0;

/* Given a font file stream; return if the font format supported.
*
* Font file will be loaded i.e. font object (sfnt) will be
created to determine the font file support.
*/
virtual bool isFileSupported(const void* buffer, const uint32_t
bufferLength) = 0;

...
};

class FontEngineManager
{
public:
...

/* Given system path to font file; return if the font format
supported.
*
* If isLoad is set to true then; font file will be loaded i.e.
sfnt and scaler will be created to determine the font file support.
* If isLoad is set to false then; the font file extension will be
checked against the font format list; a static list of the engine
supported formats; of the Font Engine.
*/
bool isFileSupported(const char path[], bool isLoad);

/* Given a font file stream; return if the font format supported.
*
* Font file will be loaded; i.e. font object (sfnt) will be
created to determine the font file support.
*/
virtual bool isFileSupported(const void* buffer, const uint32_t
bufferLength) = 0;

...
};/* end class FontEngineManager */

>
> - One important thing about this is that the font engine libraries will be
> loaded in all UI processes. For security reasons, we cannot accept
> third-party engines to be downloaded from Market or other sources, since
> this opens doors to all kinds of nastiness. It'd be nice if the design doc,
> and more importantly the source comments, make this *very* explicit. E.g.
> the loader should ensure that the font engine libraries are decidedly in the
> system partition (e.g. under /system/lib/fontengines/, for example).

Lokesh>> Great idea. We are doing the same in document and in the
source also. We will post the new document by today for your review.

>
> - It's not certain that libutils is the right place to implement the FEM.
> libutils is used both on the host and the device (many of the Android tools
> link against it), we may find something else instead, but it's not a really
> high priority.

Lokesh>> Okay, for review process may be we can keep this folder and
then we can change as per your preference.

>
> Thanks a lot, I think I'm ready to look at the sources, so please fire away
> on gerrit :-)

Lokesh>> Thank to you for your guidance and great support. I think the
new revised framework is much better and is in great shape. We will be
submitting the code by this wednesday.

>
> - David

> ...
>
> read more »

[Bitstream Inc]

Hi David,
While my last message is not live, hope will be done soon by
moderator :)
Here is the link for new document: http://bitstream.com/open/android/FontEngineManagerProposal.pdf
. Please let us know in case of any comments. We have change the
proposed API name from isFileSupported to isFontSupported, since font
can be loaded through buffer also.
We will also need your help to create a folder for FreeType
implementation for the FontEngine. Will it be possible to create
external/fontengines/freetype for the same ?
Can we assume frameworks/base/include/utils and frameworks/base/libs/
utils path for implementation of FontEngineManager ?
Please suggest,
Regards
Lokesh

Director, R&D
Bitstream Inc.

> ...
>
> read more »

[Gaurav]

Hi Shawn,

We are ready to submit the patches for Font Engine Manager and
FreeType based plugin implementation for review. Can we have following
directory created in the Android source tree so that we can submit the
source code.
external/fontengines/freetype

David is agreed with the proposal document and now ready to review the
source code. Please find below the discussion thread for your
reference :
http://groups.google.com/group/android-contrib/browse_thread/thread/c29869f0601b2dcd

Link for Font Engine Manager proposal document:
http://bitstream.com/open/android/FontEngineManagerProposal.pdf


Regards,
Gaurav Jain
Bitstream Inc.

> ...
>
> read more »

[Bitstream Inc]

Hi David,
The code has been fixed and submitted for review at:

https://review.source.android.com/#change,20070
and
https://review.source.android.com/#change,20071

Please suggest if any changes are needed or any comments.
Regards
Lokesh

---------- Forwarded message ----------
From: Gaurav
Date: Sep 21 2010, 5:37 pm
Subject: Request for creation of Project for Open Font Manager
To: Android Contributors

Hi Shawn,

We are ready to submit the patches for Font Engine Manager and
FreeType based plugin implementation for review. Can we have following
directory created in the Android source tree so that we can submit the
source code.
        external/fontengines/freetype

David is agreed with the proposal document and now ready to review the
source code. Please find below the discussion thread for your
reference :http://groups.google.com/group/android-contrib/

browse_thread/thread/c...

> Director, R&D
> Bitstream Inc.

> > Hello,

> > - David

> > > > > > >> Hello,

> > > > > > >> +cc android-contrib, +bcc android-coretech

> > > > > > >> - David

> > > > > > >>> > I

...

read more

[Bitstream Inc]

Hi David
Has been a while regarding the project. The code has been submitted on
Jan 18, 2011 with all comments fixed. Please help. A review from you
would be of a great help.
Regards
Lokesh

On Jan 18, 8:03 pm, Bitstream Inc <bitsandr...@gmail.com> wrote:
> Hi David,

> The code has been fixed and submitted for review at:
>
> https://review.source.android.com/#change,20070

> andhttps://review.source.android.com/#change,20071

> > > > this document has been shared byLokeshin his earlier post.

> ...
>
> read more »

[Bitstream Inc]

Hi David
Please help regarding the same. We need your help to get the font engine framework to Android. We have been getting many OEM requests for the same as there are legacy and proprietary font formats also which OEMs will be making use of. Plus this addition opens the way to support any advanced rendering engine to Android.
Lokesh
Director, R&D, Bitstream

[David Turner]

Hello guys,

On Mon, May 30, 2011 at 10:45 AM, Bitstream Inc <bitsa...@gmail.com> wrote:

Hi David

Please help regarding the same. We need your help to get the font engine framework to Android. We have been getting many OEM requests for the same as there are legacy and proprietary font formats also which OEMs will be making use of. Plus this addition opens the way to support any advanced rendering engine to Android.

I'm really sorry, I've been very busy. I'll try to review your patch early next week. Ping me again if I havent' done it by Wednesday.

Regards

- Digit

[Bitstream Inc]

Hi David,
Please suggest, we realize that you must be very busy. This feature can be useful for many OEMs and localized versions of the android devices. Please suggest if any changes are needed in the code.
Regards,
Lokesh
Director, R&D, Bitstream

[Bitstream Inc]

Hi David,
Please suggest, we realize that you must be very busy. This feature
can be useful for many OEMs and localized versions of the android

devices. Please suggest if any changes are needed in the code.

Regards,
Lokesh
Director, R&D, Bitstream

On Jun 9, 12:59 pm, David Turner <di...@android.com> wrote:
> Hello guys,
>

> On Mon, May 30, 2011 at 10:45 AM, Bitstream Inc <bitsandr...@gmail.com>wrote:
>
> > Hi David

> > Please help regarding the same. We need your help to get the font engine
> > framework to Android. We have been getting many OEM requests for the same as
> > there are legacy and proprietary font formats also which OEMs will be making
> > use of. Plus this addition opens the way to support any advanced rendering
> > engine to Android.
>
> I'm really sorry, I've been very busy. I'll try to review your patch early
> next week. Ping me again if I havent' done it by Wednesday.
>
> Regards
>
> - Digit
>
>
>
>
>
>
>
> > Lokesh
> > Director, R&D, Bitstream
>

> ...
>
> read more »

[Bitstream Inc]

Hi David
Thanks for the reply.

Here are links to the latest patches which we had checked-in to the
git repository in regards to your comments for earlier patches (which
were: https://review.source.android.com/#/c/18717/ and
https://review.source.android.com/#/c/18718/):


Font Engine Manager:
https://review.source.android.com/#change,20070


FreeType plugin based to Font Engine Manager:
https://review.source.android.com/#change,20071


The above latest patches were checked in on Dec 28, 2010.
Please help and suggest,

Regards,
Lokesh
Director, R&D, Bitstream

> ...
>
> read more »

[Bitstream Inc]

Hi Romain Guy and David,
Please help. The code has been checked in and also updated to the
latest release. Requesting you to please review the code and provide
your valuable comments. It will be great to have this module to
android main release soon.
Regards,
Lokesh
Director, R&D
Bitstream

On Mar 3, 4:11 pm, Bitstream Inc <bitsandr...@gmail.com> wrote:
> Hi David

> Has been a while regarding the project. The code has been submitted on Jan
> 18, 2011 with all comments fixed. Please help. A review from you would be of
> a great help.
> Regards
> Lokesh
>

> ...
>
> read more »