Replace FindCmap with ParseCMAP

This introduces a potential performance regression, because
FindCmap works on the existing font tables and just sets up
a lookup function, while ParseCMAP creates some optimized,
in-memory lookup table, which needs a bit more work, but
is faster in its usage, I think. At least the initial usage
is faster the old way, as the CMAPs aren't decoded at all.

As you can see, the old code is just used on Windows and
MacOS / iOS. Deep in the bowels of the PrintFontManager, the
CMAP is also decoded using ParseCMAP...

So I'm not sure this potential regression really exists. Most
fonts will already have a decoded CMAP, so my guess is this
is actually faster in the end. No idea, how to measure.

Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

1 files changed, 6 insertions, 0 deletions

diff --git a/include/vcl/fontcharmap.hxx b/include/vcl/fontcharmap.hxx
index 2a4e1dd08ff1..f600c3e6849f 100644
--- a/include/vcl/fontcharmap.hxx
+++ b/include/vcl/fontcharmap.hxx
@@ -39,7 +39,11 @@ public:
         all codepoints in the Unicode BMP range, including surrogates.
      **/
     FontCharMap();
+
+    /** A new FontCharMap is created based on the CmapResult
+     */
     FontCharMap( const CmapResult& rCR );
+
     virtual ~FontCharMap() override;
 
     /** Get the default font character map
@@ -134,6 +138,8 @@ public:
 
     int                 GetGlyphIndex( sal_UCS4 ) const;
 
+    bool isSymbolic() const;
+
 private:
     ImplFontCharMapRef mpImplFontCharMap;