Better Unicode support in Reports and PDF generation

By default, both GDI+ anti-aliased drawing and PDF file generation using our libraries did lack of font-fallback implementation.

If some of the characters in a string are not supported in a requested font, they were drawn as square symbols on the GDI+ canvas or the PDF content.

The font-fallback mechanism implemented will use a third-party font (Arial Unicode MS by default, which is installed with Microsoft Office), for any glyph that are missing when rendering the content. Of course, for PDF generation, you are able to embed the font within the generated file (this is by the way mandatory for PDF/A-1 format).

Both of these new features are handled by the SQlite3Pages unit, i.e. for report anti-aliased drawing preview and PDF generation.

By the way, the TGDIPages class itself (the one used for report generation from code) now handles by default Unicode text, even with Delphi versions prior to 2009 (via the SynUnicode string type, which maps WideString before Delphi 2009, then UnicodeString starting with Delphi 2009). Does make sense with such a font-fallback mechanism.

The following modifications have been committed:

New TPdfDocument.UseFontFallBack property (enabled by default) and associated FontFallBackName property (set to 'Arial Unicode MS' by default), used to define if the PDF document will handle "font fallback" for characters not existing in the current font: it will avoid rendering block/square symbols instead of the correct characters (e.g. for Chinese text);
New TGDIPlusFull.ForceUseDrawString property for properly handling font fall-back if needed when drawing text (disabled by default), and corresponding parameter in DrawEmfGdip() function;
Now implements font fall-back in internal Anti-Aliaised drawing of TGdiPages, if the new ForceInternalAntiAliasedFontFallBack property is set to TRUE.

In fact, the EMF to EMF+ conversion routine included in GDI+ 1.1 is not able to implement font-fallback (and text underlining, by the way).
Our Delphi-based conversion code sounds definitively better than the original! That is the reason why our internal code is enabled by default, instead of GDI+ 1.1 GdipConvertToEmfPlus API call.

I think it is perhaps now time for a 1.17 release of our mORMot units, as a bug-fix version.

Comments are welcome on our forum!

Synopse Open Source

Better Unicode support in Reports and PDF generation