1--- 2layout: default 3title: Layout Engine 4nav_order: 12 5has_children: true 6--- 7<!-- 8© 2020 and later: Unicode, Inc. and others. 9License & terms of use: http://www.unicode.org/copyright.html 10--> 11 12# Layout Engine 13{: .no_toc } 14 15## Contents 16{: .no_toc .text-delta } 17 181. TOC 19{:toc} 20 21--- 22 23## Line Layout Deprecation 24 25> :warning: ***The ICU Line LayoutEngine has been removed in ICU 58.*** 26> It had not had active development for some time, had many open bugs, 27> and had been deprecated in ICU 54. 28> 29> Users of ICU Layout are **strongly** encouraged to consider the HarfBuzz project 30> as a replacement for the ICU Layout Engine. An ICU team member responsible for 31> the Layout Engine is contributing fixes and features to HarfBuzz, and a drop in 32> wrapper is available to allow use of HarfBuzz as a direct replacement for the 33> ICU layout engine. 34> 35> HarfBuzz has its own active mailing lists, please use those for discussion of 36> HarfBuzz and its use as a replacement for the ICU layout engine. 37> See: [http://www.freedesktop.org/wiki/Software/HarfBuzz](http://www.freedesktop.org/wiki/Software/HarfBuzz) 38 39 40> :point_right: **Users of the "layoutex" ParagraphLayout library**: Please see information 41about how to build "layoutex" on the [Paragraph Layout](paragraph.md) page. 42 43 44## Overview 45 46> :warning: **See the deletion/deprecation notice, above.** 47 48The Latin script, which is the most commonly used script among software 49developers, is also the least complex script to display especially when it is 50used to write English. Using the Latin script, characters can be displayed from 51left to right in the order that they are stored in memory. Some scripts require 52rendering behavior that is more complicated than the Latin script. We refer to 53these scripts as "complex scripts" and to text written in these scripts as 54"complex text." Examples of complex scripts are the Indic scripts (for example, 55Devanagari, Tamil, Telugu, and Gujarati), Thai, and Arabic. 56 57These complex scripts exhibit complications that are not found in the Latin 58script. The following lists the main complications in complex text: 59 60The ICU LayoutEngine is designed to handle these complications through a simple, 61uniform client interface. Clients supply Unicode code points in reading or 62"logical" order, and the LayoutEngine provides a list of what to display, 63indicates the correct order, and supplies the positioning information. 64 65Because the ICU LayoutEngine is platform independent and text rendering is 66inherently platform dependent, the LayoutEngine cannot directly display text. 67Instead, it uses an abstract base class to access font files. This base class 68models a TrueType font at a particular point size and device resolution. The 69TrueType fonts have the following characteristics: 70 711. A font is a collection of images, called glyphs. Each glyph in the font is 72 referred to by a 16-bit glyph id. 73 742. There is a mapping from Unicode code points to glyph ids. There may be 75 glyphs in the font for which there is no mapping. 76 773. The font contains data tables referred to by 4 byte tags. (e.g. `GSUB`, 78 `cmap`). These tables can be read into memory for processing. 79 804. There is a method to get the width of a glyph. 81 825. There is a method to get the position of a control point from a glyph. 83 84Since many of the contextual forms, ligatures, and split characters needed to 85display complex text do not have Unicode code points, they can only be referred 86to by their glyph indices. Because of this, the LayoutEngine's output is a list 87of glyph indices. This means that the output must be displayed using an 88interface where the characters are specified by glyph indices rather than code 89points. 90 91A concrete instance of this base class must be written for each target platform. 92For a simple example which uses the standard C library to access a TrueType 93font, look at the PortableFontInstance class in 94[icu/source/test/letest](https://github.com/unicode-org/icu/tree/master/icu4c/source/test/letest) 95. 96 97The ICU LayoutEngine supports complex text in the following ways: 98 991. If the font contains OpenType® tables, the LayoutEngine uses those tables. 100 1012. If the font contains Apple Advanced Typography (AAT) tables, the 102 LayoutEngine uses those tables. 103 1043. For Arabic and Hebrew text, if OpenType tables are not present, the 105 LayoutEngine uses Unicode presentation forms. 106 1074. For Thai text, the LayoutEngine uses either the Microsoft or Apple Thai 108 forms. 109 110OpenType processing requires script-specific processing to be done before the 111tables are used. The ICU LayoutEngine performs this processing for Arabic, 112Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telegu, Kannada, and 113Malayalam text. 114 115The AAT processing in the LayoutEngine is relatively basic as it only applies 116the default features in left-to-right text. This processing has been tested for 117Devanagari text. Since AAT processing is not script-specific, it might not work 118for other scripts. 119 120## Programming with the LayoutEngine 121 122**See deprecation notice, above.** 123 124The ICU LayoutEngine is designed to process a run of text which is in a single 125font. It is written in a single direction (left-to-right or right-to-left), and 126is written in a single script. Clients can use ICU's 127[Bidi](../transforms/bidi.md) processing to determine the direction of the text 128and use the ScriptRun class in 129[icu/source/extra/scrptrun](https://github.com/unicode-org/icu/tree/master/icu4c/source/extra/scrptrun) 130to find a run of text in the same script. Since the representation of font 131information is application specific, ICU cannot help clients find these runs of 132text. 133 134Once the text has been broken into pieces that the LayoutEngine can handle, call 135the LayoutEngineFactory method to create an instance of the LayoutEngine class 136that is specific to the text. The following demonstrates a call to the 137LayoutEngineFactory: 138 139```c 140LEFontInstace *font = <the text's font>; 141UScriptCode script = <the text's script>; 142LEErrorCode error = LE_NO_ERROR; 143LayoutEngine *engine; 144engine = LayoutEngine::layoutEngineFactory(font, 145script, 1460, // language - ignored 147error); 148The following example shows how to use the LayoutEngine to process the text: 149LEUnicode text[] = <the text to process>; 150le_int32 offset = <the starting offset of the text to process>; 151le_int32 count = <the number of code points to process>; 152le_int32 max = <the total number of characters in text>; 153le_bool rtl = <true if the text is right-to-left, false otherwise>; 154float x, y = <starting x, y position of the text>; 155le_int32 glyphCount; 156glyphCount = engine->layoutChars(text, offset, count, max, rtl, 157x, y, error); 158``` 159 160This previous example computes three arrays: an array of glyph indices in 161display order, an array of x, y position pairs for each glyph, and an array that 162maps each output glyph back to the input text array. Use the following get 163methods to copy these arrays: 164 165```c 166LEGlyphID *glyphs = new LEGlyphID[glyphCount]; 167le_int32 *indices = new le_int32[glyphCount]; 168float *positions = new float[(glyphCount * 2) + 2]; 169engine->getGlyphs(glyphs, error); 170engine->getCharIndices(indices, error); 171engine->getGlyphPositions(positions, error); 172``` 173 174> :point_right: **Note** The positions array contains (glyphCount * 2) + 2 entries. This is because 175> there is an x and a y position for each glyph. The extra two positions hold the 176> x, y position of the end of the text run. 177 178Once users have the glyph indices and positions, they can use the 179platform-specific code to draw the glyphs. For example, on Windows 2000, users 180can call `ExtTextOut` with the `ETO_GLYPH_INDEX` option to draw the glyphs and on 181Linux, users can call `TT_Load_Glyph` to get the bitmap for each glyph. However, 182users must draw the bitmaps themselves. 183 184> :point_right: **Note:** The ICU LayoutEngine was developed separately from the rest of ICU and uses 185> different coding conventions and basic types. To use the LayoutEngine with ICU 186> coding conventions, users can use the ICULayoutEngine class, which is a thin 187> wrapper around the LayoutEngine class that incorporates ICU conventions and 188> basic types. 189 190For a more detailed example of how to call the LayoutEngine, look at 191[icu/source/test/letest/letest.cpp](https://github.com/unicode-org/icu/tree/master/icu4c/source/test/letest/letest.cpp) 192. This is a simple test used to verify that the LayoutEngine is working 193properly. It does not do any complex text rendering. 194 195For more information, see [ICU](http://icu-project.org/) , the [OpenType 196Specification](http://www.microsoft.com/typography/tt/tt.htm) , and the 197[TrueType Font File 198Specification](http://developer.apple.com/fonts/TTRefMan/RM06/Chap6.html) . 199 200> :warning: **Note:** See deprecation notice, above. 201