ICU Placement Mechanism

Question

I am trying to use ICU to build complex scripts. It has an example in the layout engine user guide (http://userguide.icu-project.org/layoutengine). It sounds pretty simple, but when I started testing it in the sample code, I was stuck in creating a LEFontInstance .

It has nothing to cater for specific types of fonts (ttf / otf, etc.). They gave an example of the definition and use of the ttf font in the PortableFontInstance file in letest.cpp . What I am collecting from all this information is that if we want, for example, to select a specific font by name, we must write a new class inherited from LEFontInstance and implement the font selection ourselves.

This is rather unpleasant for me, since I think that well-known font formats and the use of system font tables should be included in this library, otherwise I, as a user, must implement all the functionality for reading and selecting fonts. After that, the layout engine can process glyphs.

Should I use ICUs to build complex scripts (since the SDK and apple windows provide extensive font support in the system font table)?
What are the efforts associated with using the ICU layout engine? (I see that I will have to handle all font formats myself.)

Is there anything else I'm missing here?

Answer 1

I'm going to add an updated answer here, which we (ICUs) now recommend using HarfBuzz instead of the ICU linking mechanism. There is a bridge that allows you to use the ICU API against HB, but you should use HarfBuzz, not the ICU.

Answer 2

You should learn the D-Type Font Engine font and the D-type text extension that internally uses ICU LayoutEngine. See http://d-type.com/page/text_layout

They say:

However, LayoutEngine ICU itself does not provide an interface for accessing the necessary layout tables in font files. Depending on the method of accessing the fonts, this interface must be written by the client (developer). In other words, the developer is responsible for opening, closing and managing the actual fonts (for example, from a file or memory), accessing and, if necessary, caching their layout tables and providing these tables to ICU LayoutEngine upon request. Previously, this was the only way for software developers to use ICU LayoutEngine in conjunction with the Dont Type Font Engine.

With the expansion of the D-type text format, fortunately, this is no longer necessary. The D-type text layout extension performs all font-specific tasks and interacts with ICU LayoutEngine. Software developers can now use one simple extension to display all supported complex scripts without having to write their own font access interfaces. The D-type text layout extension is a Dont Type Font Engine extension that allows you to easily visualize complex scripts, hiding from the developer all the complexity associated with this process and the need to interact directly with ICU LayoutEngine.

Answer 3

It would be helpful to advise why you recommend using HarfBuzz instead of the ICU Layout Engine. HarfBuzz is still a very new library (it has not even reached version 1.0), there is practically no documentation for it, and its reliability, stability and security are still unknown and not well tested. Is it that you just decided to refuse / abandon the ICU layout mechanism before HarfBuzz reaches maturity? If so, that sounds a bit unprofessional. I know that the ICU Layout Engine was not originally designed with security in mind and has many incomplete and unpolished parts (not to mention that no significant new features have been updated for many years), but it’s certainly more mature. than HarfBuzz. I think you should support your recommendation with strong technical arguments and / or test data explaining why people should switch to HarfBuzz now . This is even more important when the recommendation comes from the ICU. Yes, HarfBuzz will certainly make ICU LayoutEngine obsolete in the future, but then again, why are your existing ICU Layout Engine users switching to the new library at the moment?