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
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
starting with Delphi 2009). Does make sense with such
a font-fallback mechanism.
The following modifications have been committed:
TPdfDocument.UseFontFallBackproperty (enabled by default) and associated
FontFallBackNameproperty (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);
TGDIPlusFull.ForceUseDrawStringproperty for properly handling font fall-back if needed when drawing text (disabled by default), and corresponding parameter in
- 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!