ilcpm

> 好奇地问一下，为什么你要转成tiff? 从图像存储的角度而言，png以及完全够用了，毕竟你这个文件不需要什么真彩。 如果是打算做电子存档，GB/T 18894-2016已经允许使用PNG格式了。 > > 8.3.3 以文本、位图文件形成的文书、科技、专业类电子文件应按以下要求归档： a）电子公文正本、定稿、公文处理单应以版式文件格式，其他电子文件、电子文件组件可以版式文件、RTF、WPS、DOCX、JPG、TIF、PNG等通用格式归档； 这个文档里面的图形是SVG，但是文本层做了字体混淆复制出来全是乱码也没办法搜索，所以需要转换成普通图像然后进行OCR，对于这种纯黑白的页面，使用TIFF无损压缩存储纯黑白图像（每个像素只有0和1）是通常做法。这个文档我最后处理成900DPI的纯黑白TIFF，进行OCR并添加目录之后体积只有3.23M，审计PDF空间图像只有1.97M，甚至体积还缩小了不少。 我对具体的图像格式里的压缩算法什么的没有深入了解过，我也不清楚png如果存储纯黑白图像在参数正确的情况下是不是能达到同样的效果。我知道的是这样做是一种“最佳实践”，如果我没记错的话，不管什么位深度的png或者jpg喂给ABBYY做OCR之后，输出的时候都会被重编码，导致图像被有损压缩损失而失真，尤其如果参数设错图片被存成了jpg格式，后果我就不说了，感兴趣的话可以自己去试试看…… 至于为什么要转换成图像再来OCR而不是直接对SVG的PDF进行OCR，时间久了我记不清了，我猜应该是ABBYY不支持SVG，识别之后只能变成几十M的低质量有损压缩图像（那破软件不能详细调整输出PDF的图像参数，很难伺候）。 总之大方向上就是：如果喂给ABBYY做OCR，这种黑白的只有在TIFF的黑白模式下ABBYY才不会改动图像，保证输出文件的体积；否则的话要么损失质量变成jpg，体积几十M水平，要么保证质量变成png，体积几百M水平。如果我还是没记错的话，好像在某种参数下ABBYY会把图像处理成jp2格式，体积小质量也没有jpg那么差，但是jp2的解码太慢了，在很多PDF阅读器里面滚动速度极慢（虽然我这个900DPI的文档滚动起来也很慢……但那是为了视觉观感，如果是600DPI的话滚动就很流畅）。 另外附上我处理完成的PDF供参考（有点邀功的意思了……）。 [[GBT 1.1-2020][标准化工作导则 第1部分：标准化文件的结构和起草规则][OCR].pdf](https://github.com/wmjordan/PDFPatcher/files/13794197/GBT.1.1-2020.1.OCR.pdf)

in another word, `\mathop{\hat{xyz}}_{abc}` should works as `\hat{xyz}_{abc}` in inline mode, and works as `\underset{abc}{\hat{xyz}}` in display mode inline mode: $$\hat{xyz}_{abc}$$ display mode: $$\underset{abc}{\hat{xyz}}$$

now I am using `\operatorname*{\hat{xyz}}_{abc}` to get the correct result, so this problem is solved 

不老不老，这就是正式版win10的最新版，win10没出23Hx的版本 

另外GB2312应该不能用来代表中文的默认编码，根据我之前了解到的信息，2312所在的年代简体字标准都还没完全确定下来，比如“瞭望塔”的“瞭”字里面是没有收录的，那个时候写的是“了望”，下图是仿宋GB2312的所有“liao”的读音下的文字  从维基百科看，微软的2312似乎是个GBK的子集？所以正常在Windows里“瞭”这个字还是能打出来 https://zh.wikipedia.org/zh-cn/GB_2312#%E4%B8%A4%E7%A7%8D%E4%B8%8D%E5%90%8C%E7%9A%84GB/T_2312%E5%AE%9E%E7%8E%B0 然后中文现在最全的编码应该是GB18030，至于Windows默认用的到底是GBK还是18030具体没去深究

没有，我也毫无头绪😂群里还有人在quicker的安装界面出现这种问题的 我感觉，只是感觉，可能和Chrome内核，webview相关的东西关系很大 目前我用的是1.41.5，应该就是最近一两个月才出现的这个问题，触发的频率也不是很高，基本不影响使用 或许可以定位一下出现问题的最早版本？

 这是按照上面维基百科的提示，在Python里用2312编码“瞭”字的结果，确实2312是没有这个字，由此可以判断Windows下的2312是被微软用GBK扩增过的 在chcp 936的环境下是可以打出“瞭”的 --- 补充，Windows下，在VSC中选择编码GB2312保存，得到的文件实际上是CP936，也就是ANSI 在记事本中保存默认编码也是ANSI对应CP936 二者都不是GB 2312，也就是说，Windows上似乎没有提供直接的方案来以严格的GB 2312存储文本？ **所以就算要代表默认的Windows平台中文编码，也应该使用CP936而不是GB 2312** 关于CP936，详见下文

翻了半天总算翻出来了  

我查了一下，Windows的默认编码“CP936”既不是GB2312也不是GBK或者GB18030…… 只能说CP936≈GBK GBK中没有欧元符号“€”，Python里直接认为CP936=GBK，所以有了下面两个图（PowerShell 5、cmd、Python）   至于18030，让GPT举个例子随便一试就报错  

我的意思是说，装了PowerShell 7之后，虽然换成utf8就解决问题了 但是把动作分享给别人，或者安装别人的动作的时候，如果里面有PowerShell脚本，那就还是可能出现乱码，因为你没办法预知对方电脑的PowerShell版本…… PowerShell 5，默认把ps1当做ANSI看待，PowerShell 7默认当做UTF8对待 所以最好的方案就是对PowerShell脚本使用UTF8(BOM)编码，这样两个版本的PowerShell都不会有问题 对应的我认为quicker的改进方案就是增加UTF8(BOM)做为文件编码