Unicode Font Arabic

[Keith Cogswell]

heyeveryone,

so far as i know 600-6FF, 750-77Fis the UniCode hex range of arabic

and i am facing an issue, no matter what kind of font i download and use in the Asset Font Creator, the generated atlas is always missing these characters.

so, can anyone help me, and recommend a bunch of fonts that actually contain this set? so i can write in arabic in TextMeshPro.

(if anyone knows of fonts that contain both arabic and english, it would be really great too).

sorry if this is in the wrong place by the way.

thanks for your response, apparently it is exactly as you said. simply the fonts that i was attempting to use, were not supporting arabic (despite being in the category of arabic fonts but oh well, i guess i needed to simply, try more fonts).

so apparently This One worked for me and managed to generate a Texture. so thanks for pushing me to search better and to try out different fonts.

On Windows or OSX, the included font viewers use glyph substitution where missing glyphs are shown but actually come from a different font which is very misleading. I suggest getting an external tool like Font Creator from High Logic, FontForge or BMfont, etc that will allow you to see the true content of the font file.

hey folks

just been messing around with same issue

added tip if it is any help also on using arabic fix from asset store to connect letters, turns out the full range on unicode page is needed for all the glyphs, so pretty much : 0600-06FF,0750-077F,08A0-08FF,FB50-FDFF,FE70-FEFF

tested with amiri font that can be found on google fonts and a 2k X 2k atlas size indeed

Thanks for replying, However, I have tried using the arabic fonts also. But using them, I am not even able to print the normal text. I am using arabic unicode fonts with pdf encoding as Unicode with Horizontal Writing. Could you please suggest some other solution?

Unfortunately, I believe this is a fundamental incompatibility within

matplotlib. matplotlib uses a very simple algorithm for layout out a

line of characters which assumes ltr order and all kinds of other things.

That said, there is something you could try. Matplotlib has a "usetex"

mode which will do all text rendering using LaTeX. Assuming you can get

LaTeX to handle Arabic correctly, you can set the following in your

.matplotlibrc file:

You'll need to install the LaTeX Unicode extension "ucs" (Ubuntu

probably has packages for that.) If you need to load any LaTeX packages

to get arabic support, you can tell matplotlib about them in your

matplotlibrc like so:

If Arabic-encoded-as-Unicode doesn't work, you could try setting

"text.latex.unicode" to False, and then typing your Arabic strings using

one of the other Arabic encodings that LaTeX understands.

Having an issue with Arabic font support using matplotlib. When using

the correct font, Arabic characters are displayed, but are not joined

together

properly; and they are also not in the correct order (the font rendered is

ltr, but Arabic is a rtl language). Is this an issue with the render I

am using, or some incompatibility within matplotlib? Sample source code

used (please note, your email client should support utf8 to display the

code correctly).

I have been trying to follow your tips regarding matplotlib and arabic support.

Is it related to my installation ? (Ubuntu with package

texlive-latex-recommended)

I asked here : Latex Unicode : missing .def for arabic ?

Here's the thing to keep in mind: matplotlib's built-in text layout algorithm is completely English-centric. It assumes all text is left to right and doesn't deal with any of Unicode's complications like combining characters etc. We really should be using a proper text layout engine like Pango or ICU TextLayout that has all these things worked out. matplotlib in general avoids (L)GPL'd libraries for core functionality so Pango is probably out. And ICU TextLayout doesn't appear to have Python bindings, adding another speed bump to its use. I think it needs a highly-motivated developer to take it on. Unfortunately, I think many of us are in the head-in-the-sand about internationalization United States...

So the trick here for matplotlib (ignoring the LaTeX/XeTeX issues for now), is to avoid its built-in text layout. The Agg, Pdf and Ps backends are basically forced to use it by the nature of the format and implementations. The Cairo backend could do it if we used pangocairo, but at the moment we use Cairo's "toy" text API which doesn't have all the Pango goodness. It turns out that (basically by accident) the SVG backend *does* work, if you set "svg.embed_char_paths" to False. In that mode, it outputs "real" SVG text as strings that appear (to my non-Arabic-reading eyes) to be interpreted correctly r-to-l in Inkscape. Note, however, that matplotlib will get the length of the text wrong, so the text is slightly off-center. But it's a start.

Now, on to the LaTeX-based solution. I'm a bit out of my element here and only suggesting things that I might try next. No guarantees of working at all. I haven't spent much time with matplotlib's usetex code.

A couple of things may stand in the way -- xetex, with the --no-pdf option, outputs "xdv" (extended dvi), rather than "dvi". matplotlib inserts LaTeX text by converting dvi to png or ps (with dvipng or dvips respectively). I don't know how backward-compatible xdv is as a format and whether that's a show stopper.

Are there perhaps some latex packages you could load using the

text.latex.preamble rc setting? This setting is officially unsupported, but

it would be much easier than adding an option to use the xetex executable

(which would probably not be officially supported by mpl).

I'd like to see a Cairo expert take on the task of upgrading our Cairo backend to use Pango. That would make this a little cleaner and theoretically fix the text alignment problem with your method (i.e. the titles are not exactly centered since its width is based on a naive rendering of the text). I have no concept of how much work that would be. Though it's also possible that that would just run up against other assumptions that matplotlib makes about text.

3a8082e126