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
c7482bc29044 Replace FindCmap with ParseCMAP
include/vcl/fontcharmap.hxx | 6 +
vcl/inc/impfontcharmap.hxx | 1 +
vcl/inc/salgdi.hxx | 4 -
vcl/inc/sft.hxx | 19 +-
vcl/source/font/fontcharmap.cxx | 3 +
vcl/source/fontsubset/sft.cxx | 385 ++--------------------------------------
vcl/source/gdi/salgdilayout.cxx | 8 -
7 files changed, 24 insertions(+), 402 deletions(-)