Text rendering: Add full support for complex scripts layout (like devanagari, thai, etc.) #67452

New Issue

Bastien Montagne · 2019-07-22T16:11:10+02:00

Bastien Montagne commented

2019-07-22 16:11:10 +02:00

There has been a (low-level) stream of reports since years now, about users wanting to write in Blender in their own language, which requires complex script layout.

This is currently not possible in Blender, we only have a very basic/simple layout code. Some scripts (like Arabic one) can partially work around the situation by using (pasting) some kind of 'pre-processed' strings using pre-layed-out unicode points instead of the 'raw' ones, but this means people cannot directly type in Blender in those languages either. And this is not available for other scripts, like many from South-East Asia (India, Cambodia…).

Most obvious solution currently would seem to be to replace out current layout code with HarffBuzz, probably together with fribidi.

This is not a terrific amount of work, but likely not a very simple one either, and though most of it should be limited to the BLF area of the code, it could require some changes elsewhere too. First step would be to try a quick proof-of-concept, to see how well that could be going…

See also D1809: Complex Text Layout, an old patch adding support to complex scripts.

There has been a (low-level) stream of reports since years now, about users wanting to write in Blender in their own language, which requires [complex script layout](https://en.wikipedia.org/wiki/Complex_text_layout). This is currently not possible in Blender, we only have a very basic/simple layout code. Some scripts (like Arabic one) can partially work around the situation by using (pasting) some kind of 'pre-processed' strings using pre-layed-out unicode points instead of the 'raw' ones, but this means people cannot directly type in Blender in those languages either. And this is not available for other scripts, like many from South-East Asia (India, Cambodia…). Most obvious solution currently would seem to be to replace out current layout code with [HarffBuzz](http:*harfbuzz.org/), probably together with [fribidi](https:*github.com/fribidi/fribidi). This is not a terrific amount of work, but likely not a very simple one either, and though most of it should be limited to the BLF area of the code, it could require some changes elsewhere too. First step would be to try a quick proof-of-concept, to see how well that could be going… See also [D1809: Complex Text Layout](https://archive.blender.org/developer/D1809), an old patch adding support to complex scripts.

Bastien Montagne commented

2019-07-22 16:11:10 +02:00

Added subscriber: @mont29

blender-admin commented

2019-07-22 16:11:10 +02:00

#92619 was marked as duplicate of this issue

blender-admin commented

2019-07-22 16:11:10 +02:00

#44438 was marked as duplicate of this issue

blender-admin commented

2019-07-22 16:11:10 +02:00

#78765 was marked as duplicate of this issue

blender-admin commented

2019-07-22 16:11:10 +02:00

#79601 was marked as duplicate of this issue

blender-admin commented

2019-07-22 16:11:10 +02:00

#76586 was marked as duplicate of this issue

blender-admin commented

2019-07-22 16:11:10 +02:00

#72847 was marked as duplicate of this issue

Bastien Montagne commented

2019-07-22 16:18:03 +02:00

Added subscribers: @WilliamReynish, @brecht, @ideasman42, @pablovazquez

Bastien Montagne commented

2019-07-22 16:18:03 +02:00

I know that this is not a high-priority task, but still think we should consider it at some point. It would also be nice to be able to refer to it when closing related bug reports we keep getting (like lastest one, #67438 (Error Font)), and as a basis if someone volunteers to work on it. Might even make a nice GSoC project?

If the #user_interface project admins agree with it, this should be listed in #63726 (User Interface Module ).

I know that this is not a high-priority task, but still think we should consider it at some point. It would also be nice to be able to refer to it when closing related bug reports we keep getting (like lastest one, #67438 (Error Font)), and as a basis if someone volunteers to work on it. Might even make a nice GSoC project? If the #user_interface project admins agree with it, this should be listed in #63726 (User Interface Module ).

Harley Acheson commented

2019-07-22 16:20:52 +02:00

Added subscriber: @Harley

zdy commented

2019-07-22 16:31:12 +02:00

Added subscriber: @nge

zdy commented

2019-07-22 16:31:12 +02:00

Will Text object language support be possible?

Will **Text object** language support be possible?

Brecht Van Lommel commented

2019-07-22 16:33:57 +02:00

I'm fine with this being added on the UI module page.

Bastien Montagne commented

2019-07-22 16:40:09 +02:00

@nge what would be the point/usage for such a setting?

@brecht thx, will do then. :)

@nge what would be the point/usage for such a setting? @brecht thx, will do then. :)

Bastien Montagne changed title from ~~Text rendering: Add full support for complex scripts layout (like devanagri, thai, etc.)~~ to Text rendering: Add full support for complex scripts layout (like devanagari, thai, etc.)

2019-07-22 16:41:39 +02:00

Valentin commented

2019-07-29 16:48:45 +02:00

Added subscriber: @Poulpator

Brendon Murphy commented

2019-11-05 22:54:31 +01:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2019-11-05 22:54:31 +01:00

mentioning blender/blender-addons#62011 addon to write reversed text order

ìman Salmani commented

2020-01-02 09:47:48 +01:00

Added subscriber: @iman-salmani

Bastien Montagne commented

2020-01-14 12:19:42 +01:00

Added subscribers: @OKWhat, @JacquesLucke

Tae Lim Kook commented

2020-04-14 23:33:23 +02:00

Added subscriber: @kozet

Ankit Meel commented

2020-05-10 14:19:09 +02:00

Added subscribers: @waseeld, @Alaska

Bustamam Harun commented

2020-05-11 15:09:56 +02:00

Added subscriber: @glasscat

Bastien Montagne commented

2020-08-14 11:30:20 +02:00

Added subscribers: @artutava, @iss

Bastien Montagne commented

2020-10-14 16:12:22 +02:00

Added subscriber: @dharmateja

khader commented

2020-11-18 09:46:43 +01:00

Added subscriber: @khader-1

khader commented

2020-11-18 09:46:43 +01:00

Any updates regarding this task!
https://blender.community/c/rightclickselect/MGgbbc/

Any updates regarding this task! https://blender.community/c/rightclickselect/MGgbbc/

Bastien Montagne commented

2021-01-27 09:44:14 +01:00

Added subscribers: @ZhangYu, @raksa

(Deleted) commented

2021-07-27 00:06:18 +02:00

(Migrated from localhost:3001)

Added subscriber: @(Deleted)

Germano Cavalcante commented

2021-11-03 15:17:46 +01:00

Added subscribers: @MOOOLORD, @mano-wii

sayed Mohammad Ghaznavi commented

2021-12-05 17:54:43 +01:00

Added subscriber: @Ghaznavi7

sayed Mohammad Ghaznavi commented

2021-12-05 18:15:54 +01:00

This comment was removed by @Ghaznavi7

*This comment was removed by @Ghaznavi7*

sayed Mohammad Ghaznavi commented

2021-12-05 18:18:47 +01:00

pleeeeeaaaaaaaase someone do something about it.
isn't it possible to copy or inspirate from other open-source softwares that support it? such as Inkscape, GIMP, Scribus (version 1.5.x), LibreOffice, ect....
This is the ONLY reason that blender is not YET my primary software for video editing. if i can write arabic/persian text without preprocessing every single sentence with other tools.
It'll be AWESOME if this fixed.

pleeeeeaaaaaaaase someone do something about it. isn't it possible to copy or inspirate from other open-source softwares that support it? such as Inkscape, GIMP, Scribus (version 1.5.x), LibreOffice, ect.... This is the ONLY reason that blender is not YET my primary software for video editing. if i can write arabic/persian text without preprocessing every single sentence with other tools. It'll be AWESOME if this fixed.

Harley Acheson commented

2021-12-05 19:07:15 +01:00

This isn’t forgotten. Ideally this would be done by a developer who is fluent in a language that uses complex shaping and is also familiar with Blender source and the relevant libraries needed to do this.

This is also on my own very long “to do” list of text-related Blender changes, but it might take me a year or more to get to text direction and shaping depending on how many changes I can get accepted per release. For this issue this is mostly about getting our code into a position where we can output arrays of multiple glyphs rather than by code point as we are doing it now.

This isn’t forgotten. Ideally this would be done by a developer who is fluent in a language that uses complex shaping and is also familiar with Blender source and the relevant libraries needed to do this. This is also on my own very long “to do” list of text-related Blender changes, but it might take me a year or more to get to text direction and shaping depending on how many changes I can get accepted per release. For this issue this is mostly about getting our code into a position where we can output arrays of multiple glyphs rather than by code point as we are doing it now.

Eyad Ahmed commented

2022-01-26 15:12:32 +01:00

Added subscriber: @IyadAhmed

Eyad Ahmed commented

2022-01-26 15:12:32 +01:00

I just updated @ideasman42 's patch, builds good, still trying to make it work fully
https://developer.blender.org/D13921

I just updated @ideasman42 's patch, builds good, still trying to make it work fully https://developer.blender.org/D13921

Ayman Roshdy commented

2022-03-16 18:28:34 +01:00

Added subscriber: @Cybermoni

Ayman Roshdy commented

2022-03-16 18:28:34 +01:00

@Harley just came across this thread and wondering what is its status?

I used to work on ICU4C & ICU4J open source bidirectional engine for Arabic right to left and characters shaping back in the days, so thought to check if this would help in the Arabic issues in any way, it is a bit old but I think I still remember how this used to work with the Unicode bidi algorithm and start adding Arabic support to Blender, but will need someone to direct me on how to start

@Harley just came across this thread and wondering what is its status? I used to work on ICU4C & ICU4J open source bidirectional engine for Arabic right to left and characters shaping back in the days, so thought to check if this would help in the Arabic issues in any way, it is a bit old but I think I still remember how this used to work with the Unicode bidi algorithm and start adding Arabic support to Blender, but will need someone to direct me on how to start

Harley Acheson commented

2022-03-16 19:47:58 +01:00

@Cybermoni - just came across this thread and wondering what is its status?

The status is best described as "a few English speakers slowly trying to improve our international text handling".

This project as a whole has fairly complex needs and wants for text output, and only a few people familiar with (or interested in) this area of code, none of them native users of non-Latin scripts. I have a rough timeline for changes to our text output, that includes getting to bidirectional output and complex shaping here: https://developer.blender.org/T94030

The above is mostly me trying to clean up our text output code and simplify it before adding new features that I want (or need) to add before complex shaping. One notable prior step being D12622: BLF: Fallback Font Stack as that will free us from using our current monolithic metafonts. We want all language glyphs available to all users, regardless of output language selection but the way we currently do that makes it harder to add new languages and makes it more difficult for users to use their own fonts.

Another notable prerequisite is D13137: BLF: Implement FreeType Caching for fairly technical reasons. We require fast text output so we cache rendered glyphs. But we currently save these indexed by character code, while we will need fast access by glyph index once we do text shaping. It is easy enough to index our glyphs by glyph index, but then we lose quick lookups from charcode to glyph index. Rather than use the (slow) FT_Get_Char_Index all over I'd rather move to FreeType caching and use their FTC_CMapCache_Lookup. Using FreeType caching also fits well with the use of fallback fonts above, since fonts that are never used would not have to be ever fully loaded, or could be loaded and discarded when not needed.

Once our code is in nicer shape, is using a fallback font stack, and is using FreeType caching, it would be a nice time to handle bidirectional output and text shaping. And we could probably use some help at that time. At that time we'd basically be changing from our current "output ut8 strings, one charcode at a time" to converting runs of ut8 characters that use the same unicode block to arrays of charcodes that are optionally reordered (probably Fribidi) then converted to arrays of glpyh indexes and advances by Harfbuzz and then output.

I used to work on ICU4C & ICU4J open source bidirectional engine for Arabic right to left and characters shaping back in the days, so thought to check if this would help in the Arabic issues in any way...

Does ICU still include an implementation of the bidirectional algorithm and a text shaping engine? For some reason I thought it had these things things but then dropped them in favor or the use of fribidi and Harfbuzz. I could certainly be wrong. I ALSO want to add ICU anyway to our project for other internationalization issues like proper Unicode sorting.

Are there ways that you can see yourself getting involved and helping with this? There would be ways to help that could range from simple testing and feedback all the way to coding.

> @Cybermoni - just came across this thread and wondering what is its status? The status is best described as "a few English speakers slowly trying to improve our international text handling". This project as a whole has fairly complex needs and wants for text output, and only a few people familiar with (or interested in) this area of code, none of them native users of non-Latin scripts. I have a rough timeline for changes to our text output, that includes getting to bidirectional output and complex shaping here: https://developer.blender.org/T94030 The above is mostly me trying to clean up our text output code and simplify it before adding new features that I want (or need) to add before complex shaping. One notable prior step being [D12622: BLF: Fallback Font Stack](https://archive.blender.org/developer/D12622) as that will free us from using our current monolithic metafonts. We want all language glyphs available to all users, regardless of output language selection but the way we currently do that makes it harder to add new languages and makes it more difficult for users to use their own fonts. Another notable prerequisite is [D13137: BLF: Implement FreeType Caching](https://archive.blender.org/developer/D13137) for fairly technical reasons. We require fast text output so we cache rendered glyphs. But we currently save these indexed by character code, while we will need fast access by glyph index once we do text shaping. It is easy enough to index our glyphs by glyph index, but then we lose quick lookups from charcode to glyph index. Rather than use the (slow) FT_Get_Char_Index all over I'd rather move to FreeType caching and use their FTC_CMapCache_Lookup. Using FreeType caching also fits well with the use of fallback fonts above, since fonts that are never used would not have to be ever fully loaded, or could be loaded and discarded when not needed. Once our code is in nicer shape, is using a fallback font stack, and is using FreeType caching, it would be a nice time to handle bidirectional output and text shaping. And we could probably use some help at that time. At that time we'd basically be changing from our current "output ut8 strings, one charcode at a time" to converting runs of ut8 characters that use the same unicode block to arrays of charcodes that are optionally reordered (probably Fribidi) then converted to arrays of glpyh indexes and advances by Harfbuzz and then output. > I used to work on ICU4C & ICU4J open source bidirectional engine for Arabic right to left and characters shaping back in the days, so thought to check if this would help in the Arabic issues in any way... Does ICU still include an implementation of the bidirectional algorithm and a text shaping engine? For some reason I thought it had these things things but then dropped them in favor or the use of fribidi and Harfbuzz. I could certainly be wrong. I ALSO want to add ICU anyway to our project for other internationalization issues like proper Unicode sorting. Are there ways that you can see yourself getting involved and helping with this? There would be ways to help that could range from simple testing and feedback all the way to coding.

Ayman Roshdy commented

2022-03-16 20:33:25 +01:00

@Harley it seems you will have a very busy schedule ahead, good luck with that :)

ICU still has a full implementation of the bidirectional algorithm, back in the days I used to work in IBM Egypt and we had a project to participate in ICU with both the bidirectional algorithm plus the Arabic shaping engine that we used to have in IBM, I ported the shaping part myself inside the ICU4C code, in short ICU takes an array of characters (or a string) handles the Arabic RTL and the Shaping then returns the new string, which I believe matches your target, Arabic specifically can't be handled as one character at a time because the shape of each character differs based on the character that comes before it and the character that comes after it, plus of course a bit complex characters like the Lam + Alef combinations and what we call in Arabic Tashkeel that are mainly like small glyphs that should appear above or below the characters to handle the Arabic grammar in the correct way, I can say that all of this will be a bit of a science fiction for non-Arabic speaking developers!

Reference to the shaping engine HYG the code written in C ushape.cpp
It is nice that I found my name still kept in the file after all of these years - this dates back to 2000 - 2001 time frame :)

Anyway I'm willing to help by porting whatever code we need to support Arabic in Blender, and later in testing of course. One thing that I tried just now is that I opened "Blender -> File -> Open -> Blender File View", and tested to see what will happen for a folder name written in Arabic, and as expected it is not in RTL and no shaping, so if you can guide me to which file in Blender source code handles this then I can try testing with ICU4C and see how we can make the 'Blender File View' display Arabic in the correct way, once this test is complete I believe we can go ahead and start porting (or actually calling) the same code every where that reads/writes text

What do you think?

@Harley it seems you will have a very busy schedule ahead, good luck with that :) ICU still has a full implementation of the bidirectional algorithm, back in the days I used to work in IBM Egypt and we had a project to participate in ICU with both the bidirectional algorithm plus the Arabic shaping engine that we used to have in IBM, I ported the shaping part myself inside the ICU4C code, in short ICU takes an array of characters (or a string) handles the Arabic RTL and the Shaping then returns the new string, which I believe matches your target, Arabic specifically can't be handled as one character at a time because the shape of each character differs based on the character that comes before it and the character that comes after it, plus of course a bit complex characters like the Lam + Alef combinations and what we call in Arabic Tashkeel that are mainly like small glyphs that should appear above or below the characters to handle the Arabic grammar in the correct way, I can say that all of this will be a bit of a science fiction for non-Arabic speaking developers! Reference to the shaping engine HYG the code written in C [ushape.cpp ](https://gitlab.com/gitlab-org/build/omnibus-mirror/libicu/blob/61607c27732906d36c5bd4d23ecc092f89f53a2b/icu4c/source/common/ushape.cpp) It is nice that I found my name still kept in the file after all of these years - this dates back to 2000 - 2001 time frame :) Anyway I'm willing to help by porting whatever code we need to support Arabic in Blender, and later in testing of course. One thing that I tried just now is that I opened "Blender -> File -> Open -> Blender File View", and tested to see what will happen for a folder name written in Arabic, and as expected it is not in RTL and no shaping, so if you can guide me to which file in Blender source code handles this then I can try testing with ICU4C and see how we can make the 'Blender File View' display Arabic in the correct way, once this test is complete I believe we can go ahead and start porting (or actually calling) the same code every where that reads/writes text What do you think?

Harley Acheson commented

2022-03-16 21:20:30 +01:00

@Cybermoni - ICU still has a full implementation of the bidirectional algorithm...

Nice!

Shaping then returns the new string, which I believe matches your target, Arabic specifically can't be handled as one character at a time...

I have rudimentary knowledge of output ordering and shaping, but no direct experience in implementing either. I do know that Arabic characters differ depending on word position, so our current text output will need quite a bit of work to get there. We have had some demonstration patches that show complex shaping working in our codebase, but not in a way that works well...

Just for background, defining some terms. All of the Unicode characters have set 32-bit values that I will call "charcodes" here. Each font has a number of glyphs that are in an order that does not match charcodes. As in the glyph in one font with index 1 might be for charcode U+0020, the 60th glyph could be charcode U+0904 in some other font.

We currently start with a ut8 string, loop through each utf32 character at a time, treat each as a charcode. We look in our glpyh cache for it (by charcode), grab the glyph if there or make it if not. That cached glyph also contains the advance value so we then output the glyph and move by the advance. With some added complications to do with hinting and kerning.

Planned loop would instead go through our input ut8 string and group runs that are in the same default script. So a string containing English, Chinese, and then Arabic might turn into three separate runs. For each run we need to convert to an array of 32-bit charcodes, then give this to a bidirectional function to reorder as needed, based on detected script. Then this array is sent to a shaper like Harfbuzz which gives us back pairs of glyph indexes and advances. We then need to find our glyphs in our cache and output these and move with the advances.

That's my current understanding of the process anyway. I might have something wrong or have to alter my thoughts as I get there. But the endgame is having a user running Blender in Spanish yet being able to enter a text string containing a mixture of Japanese, Devanagari, and Arabic and have it not only display correctly but also select and edit correctly. And be able to convert the entire thing to curves to make 3D shapes from them too.

What do you think?

I think you might come in handy! You should probably start by getting the blender source compiling. There is good instructions for that here: https://wiki.blender.org/wiki/Building_Blender

Once are compiling a good start would be looking at some of my own patches to do with these things, https://developer.blender.org/T94030. Most of the meat of our text output that will be affected by text shaping are touched by those patches, mostly blf.c and blf_glyph.c

If you follow the link in my name you will find lots of ways to get in touch, with blender.chat being the most convenient. I am at UTC-8 though, so might not always be available, depending on your own location.

> @Cybermoni - ICU still has a full implementation of the bidirectional algorithm... Nice! > Shaping then returns the new string, which I believe matches your target, Arabic specifically can't be handled as one character at a time... I have rudimentary knowledge of output ordering and shaping, but no direct experience in implementing either. I do know that Arabic characters differ depending on word position, so our current text output will need quite a bit of work to get there. We have had some demonstration patches that show complex shaping working in our codebase, but not in a way that works well... Just for background, defining some terms. All of the Unicode characters have set 32-bit values that I will call "charcodes" here. Each font has a number of glyphs that are in an order that does not match charcodes. As in the glyph in one font with index 1 might be for charcode U+0020, the 60th glyph could be charcode U+0904 in some other font. We currently start with a ut8 string, loop through each utf32 character at a time, treat each as a charcode. We look in our glpyh cache for it (by charcode), grab the glyph if there or make it if not. That cached glyph also contains the advance value so we then output the glyph and move by the advance. With some added complications to do with hinting and kerning. Planned loop would instead go through our input ut8 string and group runs that are in the same default script. So a string containing English, Chinese, and then Arabic might turn into three separate runs. For each run we need to convert to an array of 32-bit charcodes, then give this to a bidirectional function to reorder as needed, based on detected script. Then this array is sent to a shaper like Harfbuzz which gives us back pairs of glyph indexes and advances. We then need to find our glyphs in our cache and output these and move with the advances. That's my current understanding of the process anyway. I might have something wrong or have to alter my thoughts as I get there. But the endgame is having a user running Blender in Spanish yet being able to enter a text string containing a mixture of Japanese, Devanagari, and Arabic and have it not only display correctly but also select and edit correctly. And be able to convert the entire thing to curves to make 3D shapes from them too. > What do you think? I think you might come in handy! You should probably start by getting the blender source compiling. There is good instructions for that here: https://wiki.blender.org/wiki/Building_Blender Once are compiling a good start would be looking at some of my own patches to do with these things, https://developer.blender.org/T94030. Most of the meat of our text output that will be affected by text shaping are touched by those patches, mostly `blf.c` and `blf_glyph.c` If you follow the link in my name you will find lots of ways to get in touch, with blender.chat being the most convenient. I am at UTC-8 though, so might not always be available, depending on your own location.

Ayman Roshdy commented

2022-03-16 21:57:57 +01:00

Seems like a good algorithm to handle text with different languages, and BTW if we are to go with ICU4C then we don't really need Harfbuzz as ICU comes with its own shaping engine

I will start by blender source compiling and having a build environment up and running, and I already downloaded the latest ICU4C and started to refresh my memory, will catch you on blender.chat later once I played a bit with the code, I am at UTC+2 but I don't have a problem connecting with you during my night which will probably be your morning to your noon, since I will be probably working on this at night anyway

Chat with you again soon
Have a nice day

Seems like a good algorithm to handle text with different languages, and BTW if we are to go with ICU4C then we don't really need Harfbuzz as ICU comes with its own shaping engine I will start by blender source compiling and having a build environment up and running, and I already downloaded the latest ICU4C and started to refresh my memory, will catch you on blender.chat later once I played a bit with the code, I am at UTC+2 but I don't have a problem connecting with you during my night which will probably be your morning to your noon, since I will be probably working on this at night anyway Chat with you again soon Have a nice day

Alaska commented

2022-03-16 22:10:26 +01:00

Removed subscriber: @Alaska

Harley Acheson commented

2022-03-16 22:34:59 +01:00

@Cybermoni - if we are to go with ICU4C then we don't really need Harfbuzz as ICU comes with its own shaping engine

I'm seeing that as being deprecated in ICU 54 and removed in version 58. Now at version 70.1

https://unicode-org.github.io/icu/userguide/layoutengine/

> @Cybermoni - if we are to go with ICU4C then we don't really need Harfbuzz as ICU comes with its own shaping engine I'm seeing that as being deprecated in ICU 54 and removed in version 58. Now at version 70.1 https://unicode-org.github.io/icu/userguide/layoutengine/

Ayman Roshdy commented

2022-03-17 00:23:39 +01:00

@Harley I didn't see this comment in version 58, I only downloaded the 70.1 version and searched for the code and found it there, anyway let's think about the shaping engine to use after I am more familiar with the code, working on this step now

Belal Sweileh commented

2022-05-02 14:36:34 +02:00

Added subscriber: @bsweileh

sayed Mohammad Ghaznavi commented

2022-06-15 22:18:34 +02:00

Whenever I want to write Persian text in a Left-to-Right software (e.g. unity or blender) I use this site: http://bobardo.com/reshaper/
in this site the algorithm and code for converting is based on JavaScript. its code is visible by inspecting. also this site works offline so you can download it and see it with an IDE. maybe that code may help with what you're doing by reverse engineering its algorithm for converting LTR to RTL... I don't know

Whenever I want to write Persian text in a Left-to-Right software (e.g. unity or blender) I use this site: http://bobardo.com/reshaper/ in this site the algorithm and code for converting is based on JavaScript. its code is visible by inspecting. also this site works offline so you can download it and see it with an IDE. maybe that code may help with what you're doing by reverse engineering its algorithm for converting LTR to RTL... I don't know

Bastien Montagne added this to the User Interface project 2023-02-09 15:34:10 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Text rendering: Add full support for complex scripts layout (like devanagari, thai, etc.) #67452