Just another quick example of colouring Arabic glyphs, showing that you can selectively colour glyph sub-paths.
Category Archives: Arabic
Fun with XeTeX: Colouring Arabic glyphs
Pre-processing Arabic text
Just a quick example of colouring Arabic glyphs via the XeTeX engine (XeLaTeX) using a pre-processor written in C (via FreeType and libotf). The glyph paths were obtained via FreeType and written out as TeX files that used XeTeX (i.e., xdvipdfmx) specials (\special{pdf: content...}) to draw the glyphs, taking care to close paths when FreeType’s FT_Outline_Decompose(...) function emits a moveto. It is a relatively straightforward exercise to extend this to fully-shaped Arabic using a (home-grown) context-analysis/shaping engine. I’ll post some examples and code.
Example: Importing a Cairo PDF into XeTeX
A quick example…
Just a quick example of importing the Cairo graphics clock into the latest XeTeX engine (using XeLaTeX). Crop marks were added using a raw \special{pdf: bop …} command.
Creating a clock with Arabic digits using the Cairo graphics library
Cairo graphics
Cairo is an excellent graphics library, albeit a little tricky to build on Windows. After successfully compiling it as a static library (.lib) I wanted to explore using it to create PDFs containing Arabic. Cairo is a graphics engine, not a text layout engine, so with complex scripts like Arabic you need to take care of the shaping and text placement yourself. Naturally, this is pretty fiddly but it’s certainly quite possible. So, here are a couple of clocks as examples – note that the positioning of the numbers is not quite perfect so I have a little tweaking to do on that. Additionally, the resulting PDF imports nicely into the latest XeTeX engine. For the digits I used the font ScheherazadeRegOT, available from SIL.
Glyph chart for ScheherazadeRegOT
I’m in the middle of writing the first of a new series of articles on using the libotf C library to typeset fully vowelled Arabic. I hope to get the first article finished in the next week or two. In the meantime, here’s a glyph chart for the free OpenType Arabic typeface called Scheherazade, produced by, and available for download from, SIL International. Many thanks to them for providing this typeface, together with the Microsoft VOLT project files (contained in the developer package).
One way to compile GNU Fribidi as a static library (.lib) using Visual Studio
Introduction and caveat reader
Yesterday I spent about half an hour seeing if I could get GNU Fribidi C library (version 0.19.2) to build as a static library (.lib) under Windows, using Visual Studio. Well, I cheated a bit and used my MinGW/MSYS install (which I use to build LuaTeX) in order to create the config.h header. However, it built OK so I thought I’d share what I did; but do please be aware that I’ve not yet fully tested the .lib I built so use these notes with care. I merely provide them as a starting point.
config.h
If you’ve ever used MinGW/MSYS or Linux build tools you’ll know that config.h is a header file created through the standard Linux-based build process. In essence, config.h sets a number of #defines based on your MinGW/MSYS build environment: you need to transfer the resulting config.h to include it within your Visual Studio project. However, the point to note is that the config.h generated by the MinGW/MSYS build process may create #defines which “switch on” certain headers etc that are “not available” to your Visual Studio setup. What I do is comment out a few of the config.h #defines to get a set that works. This is a bit kludgy, but to date it has usually worked out for me. If you don’t have MinGW/MSYS installed, you can download the config.h I generated and tweaked. Again, I make no guarantees it’ll work for you.
An important Preprocessor Definition
Within the Preprocessor Definitions options of your Visual Studio project you need to add one called HAVE_CONFIG_H which basically enables the use of config.h.
Two minor changes to the source code
Because I’m building a static library (.lib) I made two tiny edits to the source code. Again, there are better ways to do this properly. The change is to the definition of FRIBIDI_ENTRY. Within common.h and fribidi-common.h there are tests for WIN32 which end up setting:
#define FRIBIDI_ENTRY __declspec(dllexport)
For example, in common.h
...
#if (defined(WIN32)) || (defined(_WIN32_WCE))
#define FRIBIDI_ENTRY __declspec(dllexport)
#endif /* WIN32 */
...
I edited this to
#if (defined(WIN32)) || (defined(_WIN32_WCE))
#define FRIBIDI_ENTRY
#endif /* WIN32 */
i.e., remove the __declspec(dllexport). Similarly in fribidi-common.h.
One more setting
Within fribidi-config.h I ensured that the FRIBIDI_CHARSETS was set to 1:
#define FRIBIDI_CHARSETS 1
And finally
You simply need to create a new static library project and make sure that all the relevant include paths are set correctly and then try the edits and settings suggested above to see if they work for you. Here is a screenshot of my project showing the C code files I added to the project. The C files are included in the …\charset and …\lib folders of the C source distribution.
With the above steps the library built with just 2 level 4 compiler warnings (that is, after I had included the _CRT_SECURE_NO_WARNINGS directive to disable deprecation). I hope these notes are useful, but do please note that I have not thoroughly tested the resulting .lib file so please be sure that you perform your own due diligence.