0

THE PROBLEM

I wish to develop a small desktop publishing application for the Urdu language. This is a right to left language but the typography can be very complex.

At its simplist one can use a Unicode font and this is the approach used by the BBC here: http://www.bbc.co.uk/urdu

However, the Unicode approach is essentially forcing all letters to firmly sit on a common baseline and have the same letter-height. The text looks more like arabic and this is acceptable for say business documents, but the beauty of Urdu is in its free form calligraphic style. An example of which can be seen here:

http://upload.wikimedia.org/wikipedia/commons/9/94/Urdu_couplet.svg

I wish to write an Urdu font rendering engine that gives a lot of control for rendering Unicode Urdu text in the calligraphic style. Creating a separate font file (assuming the circa 18,000 combinations of letter glyphs would fit in it) would not quite address the problem. For example, I would like to increase the "kerning" (letter spacing) and this would need to fluidly extend the lines connecting the letters while retaining a smooth curve.

THE QUESTION

My initial approach was to only target Windows and use C++ and MFC. But these are very old technologies and although may stil solve the problem I wanted to ask what would be a more modern approach. The following are options I have explored:

  • As font rendering is a low level activity, presumably C#/WPF would not be appropriate
  • I would like to avoid just targetting Windows and so perhaps C++/Qt might be an option
  • Given the cloud computing trends the ideal would be to deploy this through the browser but I assume it would be impossible to get a consistent experience. Then again, I havent properly explored GDI and DirectWrite
  • Perhaps something can be leveraged from DirectX / OpenGL gaming
Tyler Durden
  • 303
  • 5
  • 12

1 Answers1

0

What is your goal? A font rendering engine for desktop/mobile applications, or for the web? You can, of course, develop both, there's no problem with that. If you architect the code well, you can have three parts: the core engine, the desktop platform interface, and the web platform interface. The former would be written in both C++ and javascript, and those could be almost 1:1 reimplementations, perhaps the js machine generated from a subset of C++. The platform interfaces would be written in C++ and javascript, respectively.

The most you care for in the platform interface is the API used to render (stroke) the fonts. Qt's GUI module provides a QPainterPath that would work well for this. Cairo is another library that would work well. The benefit of Qt is that it gives you a lot of other cross-platform goodies. The application using your renderer doesn't have to be Qt-based at all, you can in fact statically link Qt's core and gui modules to your library, making it completely transparent.

WPF is "like" Qt Quick 2, and MFC is "like" Qt Widgets - simply a solution to a different problem. You're not designing a user interface, just a rendering library. You need 2D path stroking and geometry support, not a user interface framework. Qt's modularity is a good asset for you: only use the modules you need.

Using JavaScript you'd be drawing on an HTML5 canvas element of some sort. All of the font-specific things have to be implemented from scratch. HTML5 doesn't let you plug-in a font rendering engine, you'll be simply drawing pictures and having to handle copy-paste etc. Since you have to go to all that trouble, there's no point in dabbling with DirectWrite, since you'll have to implement it all from scratch. Of course it's up to you to decide how much of the font decoding is done server-side vs. client side. The server side can use Qt - it's a reasonably capable platform for server development. If you've been using credit cards, it's highly likely that some of your transactions went through a backend coded in Qt :)

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • [1/4] The three component architecture appears very sensible. To break the project down into manageable pieces, I was thinking perhaps to prototype using the lower levels of DirectWrite (the Script Processor, Font Rasterizer and Glyph-Rendering) to basically map a unicode string to a calligraphic representation. DirectWrite appears, from the marketing, to be very capable but the disadvantage is the tie-in to Windows. – Tyler Durden Jul 01 '14 at 14:00
  • [2/4] Firstly, what I am struggling to understand at the moment is how the Javascript engine will link to the font rendering. I feel I'm missing a "piece" between client side Javascript and the rendering engine almost as if I need to go through the respective Windows/Linux/Mac font display systems. – Tyler Durden Jul 01 '14 at 14:01
  • [3/4] Secondly, the goal started with building a very small desktop publishing application to wrap around the font rendering engine so that people can typeset on a blank canvas and export out into vectors for "proper" applications like Indesign. But now, I feel like I want everyone to benefit and allow such typesetting through the browser. – Tyler Durden Jul 01 '14 at 14:01
  • [4/4] Overall, I think I need to spend a few months learning about font rendering internals and play with DirectWrite to get that learning. After which I should know enough to then proceed with Qt? – Tyler Durden Jul 01 '14 at 14:16