Suggestion on supporting unicode and Complex Text Layout

[bzhkl]

1. windows direct write:

   you can use IDWriteTextLayout::HitTestTextPosition IDWriteTextLayout::GetClusterMetrics IDWriteTextLayout::GetLineMetrics and so on ,
   if you want complete working example: take a look https://github.com/vczh-libraries/GacUI/blob/master/Source/GraphicsElement/WindowsDirect2D/GuiGraphicsLayoutProviderWindowsDirect2D.cpp

2. windows gdi:

   you can use ScriptGetFontProperties
   if you want complete working example: take a look https://github.com/vczh-libraries/GacUI/blob/master/Source/GraphicsElement/WindowsGDI/GuiGraphicsUniscribe.cpp

3. mac os :

   you can use NSTextStorage NSLayoutManager NSTextContainer
   if you want complete working example: take a look iGac/Mac/GraphicsElement/CoreGraphics/GuiGraphicsLayoutProviderCoreText.mm at master · vczh-libraries/iGac · GitHub

4. linux :

   use pango
   if you want complete working example: take a look XGac/X11Cairo/GraphicsElement/Renderers/GuiSolidLabelElementRenderer.cpp at master · vczh-libraries/XGac · GitHub

I can not get a big picture of the whole juce architecture， maybe someone help to implement on windows first or mac， and I can get start！

[ttg]

Here is a related thread of the current JUCE state:

Graphics drawText etc do not behave properly for RTL text

That's a really good summary of the problem! I did look into things like harfbuzz a couple of years ago, but they're just ridiculously huge - adding support for it would double or triple the size of most binaries that people build! But yes, adding some kind of i8ln layer would be the smart approach - so that it can use a simple back-end that only handles LTR text if you don't need anything beyond that, but being able to swap it out for a more capable back-end in apps where that's necessary. It…

(haven’t changed much and it does differs greatly between platforms).