ICU layout engine

Question

I am trying to use ICU for layout of complex scripts. It has an example in the layout engine user guide (http://userguide.icu-project.org/layoutengine). It seems like it is quite simple, but when I started to test it in an example code, I got stuck at the LEFontInstance creation.

It does not have anything to cater specific font types (ttf/otf etc). They have given an example of defining and using a ttf font in PortableFontInstance in letest.cpp file. What I gather from all this information is that if we want to select a particular font by name for example, we have to write a new class, inherited from LEFontInstance and implement selection of font ourselves.

This is quite frustrating for me, as I think the well known font formats and use of system font tables should be incorporated in such a library, otherwise me as a user has to implement all the functionality of font reading and selection. The layout engine can handle the glyphs after that.

Is it worth to use ICU for layout of complex scripts (as SDKs windows and apple provide ample support for fonts in system font table) ?
What is the effort involved if I use ICU layout engine? (I can see that I will have to handle all font formats myself.)

Is there anything else that I am missing here?

Answer 1

It would be good to disclose why you recommend using HarfBuzz instead of ICU Layout Engine. HarfBuzz is still a very new library (has not even reached version 1.0), there is virtually no documentation for it and its reliability, stability and security are still unknown and not well tested. Is it the case that you have simply decided to abandon/deprecate ICU Layout Engine before HarfBuzz has reached maturity? If so, that sounds a bit unprofessional. I know that ICU Layout Engine was not initially designed with security in mind and has lots of unfinished and unpolished parts (not to mention that has not been updated with any significant new features in years) but is certainly more mature than HarfBuzz. I think you should back up your recommendation with some solid technical arguments and/or test data explaining why people should switch to HarfBuzz now. This is even more the case when the recommendation comes from ICU. Yes, HarfBuzz will quite certainly make ICU LayoutEngine obsolete in the future, but, again, why should your existing ICU Layout Engine users switch to a new library at this point in time?

Answer 2

I'm going to add an updated answer here, that we (ICU) now recommend using HarfBuzz instead of ICU's layout engine. There's a bridge that lets you use ICU APIs against HB still, but you should use HarfBuzz and not ICU.

Answer 3

You should look into D-Type Font Engine and D-Type Text Extension which internally uses ICU LayoutEngine. See http://d-type.com/page/text_layout

They say:

The ICU LayoutEngine itself, however, does not provide an interface to access the necessary layout tables in the font files. Depending on how the fonts are accessed, this interface must be written by the client (developer). In other words, the developer is responsible for opening, closing and managing the actual fonts (e.g. from file or memory), accessing and, optionally, caching their layout tables and supplying those tables to the ICU LayoutEngine when requested. In the past, this was the only way for software developers to use the ICU LayoutEngine in conjunction with D-Type Font Engine.

With D-Type Text Layout Extension, fortunately, this is no longer necessary. D-Type Text Layout Extension takes care of all the font specific tasks and interaction with the ICU LayoutEngine. Software developers can now use one simple extension to display all supported complex scripts without the need to write their own font access interfaces. D-Type Text Layout Extension is an extension of D-Type Font Engine that makes it possible to easily render complex scripts, hiding from the developer all the complexity associated with this process and the need to interface with the ICU LayoutEngine directly.