工作中，需要用ghostscript库将pdf文件中的非内嵌字体全部内嵌。先测试一下ghostscript直接处理
gswin64c.exe -o new.pdf -sDEVICE=pdfwrite bad.pdf
GPL Ghostscript 9.56.1 (2022-04-04)
Copyright (C) 2022 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Processing pages 1 through 3.
Page 1
Loading font KaiTi (or substitute) from %rom%Resource/Font/NimbusSans-Regular
Loading CIDFont KaiTi (or substitute) from C:/Windows/Fonts/simkai.ttf
Page 2
Page 3
这个源pdf中，有部分KaiTi字体没有内嵌。而Ghostscript因为内置字体没有楷体，用了NimbusSans来替代，从而导致转出来的pdf，有部分文字乱码。
为了让ghostscript可以使用Windows的自带字体文件，需要设置FONTPATH指向C:\Windows\Fonts，参考
https://stackoverflow.com/questions/73707930/why-is-ghostscript-replacing-embedded-fonts
gswin64c.exe -o new.pdf -sDEVICE=pdfwrite -sFONTPATH="C:\Windows\Fonts" -dNEWPDF=false bad.pdf
Processing pages 1 through 3.
Page 1
Scanning C:\Windows\Fonts for fonts... 461 files, 269 scanned, 244 new fonts.
Can't find (or can't open) font file %rom%Resource/Font/%rom%.
Can't find (or can't open) font file KaiTi.
Loading KaiTi font from C:\Windows\Fonts/simkai.ttf... 7509676 6105470 22306756 20455617 4 done.
Loading a TT font from C:/Windows/Fonts/simkai.ttf to emulate a CID font KaiTi ... Done.
Page 2
Loading a TT font from C:/Windows/Fonts/simkai.ttf to emulate a CID font KaiTi ... Done.
Can't find (or can't open) font file %rom%Resource/Font/%rom%.
Can't find (or can't open) font file KaiTi.
Loading KaiTi font from C:\Windows\Fonts/simkai.ttf... 9374496 6674894 23208168 21339269 4 done.
Page 3
如果不加 -dNEWPDF=false，虽然显示可以加载出C:\Windows\Fonts/simkai.ttf，但是转换出来的pdf还是有乱码。Ghostscript的作者解释到这是9.56.1的bug（实测10.00.0还是有bug，10.02.0就修复了）
https://stackoverflow.com/questions/72657607/how-to-use-fonts-from-window-fonts-folder-for-a-pdf-in-ghostscript
回到正题。在工作中，是调用ghostscript.dll来完成pdf文件处理的，按道理把命令行试验通过的参数全部传一遍进 gsapi_init_with_args 就完事了。
gs_argv[0] = "gs";
gs_argv[1] = "-o";
gs_argv[2] = "new.pdf";
gs_argv[3] = "-sDEVICE=pdfwrite";
gs_argv[4] = "-sFONTPATH=\"C:/Windows/Fonts\"";
gs_argv[5] = "-dNEWPDF=false";
gs_argv[6] = inputFile;
code = f_gsapi_init_with_args(gs_inst, 7, gs_argv);
但是，实际运行却不行
Processing pages 1 through 3.
Page 1
Scanning "C:/Windows/Fonts" for fonts... 0 files, 0 scanned, 0 new fonts.
Querying operating system for font files...
Substituting font Helvetica for KaiTi.
Loading NimbusSans-Regular font from %rom%Resource/Font/NimbusSans-Regular... 4916440 3557620 7087640 5585527 4 done.
Loading a TT font from C:/Windows/Fonts/simkai.ttf to emulate a CID font KaiTi ... Done.
Page 2
Loading a TT font from C:/Windows/Fonts/simkai.ttf to emulate a CID font KaiTi ... Done.
Substituting font Helvetica for KaiTi.
Page 3
从 C:/Windows/Fonts 目录中没有扫描出来字体文件！开始以为是调用 ghostscript.dll 流程不对，导致比gswin64c命令行少执行了些初始化操作。于是下载了ghostscript的源代码，认真看了 gswin64c 命令行的执行过程，位于 ghostscript-9.56.1\psi\dwmainc.c。我的程序是少调用了 psapi_set_arg_encoding、gsapi_set_stdio、gsapi_run_string等动作。但是把这些动作补全，依然是读取不到字库文件。继续搜索代码，发现 Scanning "C:/Windows/Fonts" for fonts 这行打印语句，是 Resource\Init\gs_fonts.ps 这个postscript脚本打印出来的，要想调试ps脚本比调试c代码难多了。调试了好一会的初始化c代码，也没有发现什么端倪。
后来又想到，要能够读取"C:/Windows/Fonts"目录中的字体文件，肯定需要给这个目录赋予读权限。dll层赋予目录权限的api是 gsapi_add_control_path，根据代码一层层跟踪，最后实际运行函数是 gs_add_control_path_len_flags()。在这里打了一个断点，观察传进来的 path 参数。这个函数被调用20来次之后，终于传进来 C:/Windows/Fonts 目录名。对于命令行 gswin64c.exe ，传过来的目录名是对的。但是对于我通过 gsapi_init_with_args 的调用，传过来的目录名变成了 "C:/Windows/Fonts"，前后多了双引号！（其实如果认真一点地对比命令行中的输出，应该也可以发现这个差异）
继续跟踪，可以发现，命令行中的 -sFONTPATH="C:\Windows\Fonts"，传到wmain函数时，argv中得到的已经是 -sFONTPATH=C:\Windows\Fonts，windows的命令行在解析命令行参数的时候，已经把双引号去掉了。但如果我们直接传 -sFONTPATH="C:\Windows\Fonts" 给gsapi_init_with_args，这个双引号原封保留带了过去，从而导致了postscript中看到的FONTPATH参数带了双引号
