Better Unicode support in Reports and PDF generation
By A.Bouchez on 2012, Tuesday July 10, 23:44 - Open Source libraries - Permalink
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.UseFontFallBackproperty (enabled by default) and associatedFontFallBackNameproperty (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.ForceUseDrawStringproperty for properly handling font fall-back if needed when drawing text (disabled by default), and corresponding parameter inDrawEmfGdip()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!