如果你是仍在 linux 服务器上创建的，首先判断一下服务器有这个 ttf 以及确实被系统加载上了，其次判断一下生成软件确实能够加载到这个字体。前一段玩 java 的 itext ，好在是一个任何系统都不具备的字体。

6# 这个图上第二行的 TimesNewRoman 明显不是衬线字体，TNR 是一种衬线字体，所以第二行应该是调用了保护字体。然后中文方面，都是字体库缺少中文，都调用了保护字体

@aitaii 13# 完全不一样。
如果发生源是手机本体，那是高频电流产生的谐波杂音，产生空气振动的元器件不是发声单元——俗称“电流声”。
另外 GSM 时代还会让接近的音箱产生嘟嘟嘟的脉冲声，这是 GSM 的工作频段产生了电磁波杂波泄露干涉，使扬声器电路产生了电流振荡，并且把振荡转化成了声音，也就是嘟嘟嘟的声音。民航不让使用手机，其中一个因素就是这个，这个会干扰空地无线电对话，以及干扰 ILS 、VOR 、DME 等依靠模拟无线电进行定位的飞行活动，但是之后的数字蜂窝无线通信已经基本不会出现这个问题了，但是起降阶段仍然原则上关闭设备。

不知道 PDF 在哪里生成的，是 windows 环境还是 linux 环境。如果是 windows 平台创建的，对于 TimesNewRoman 这种字体，要么两平台的字库不一致，要么 TNR 具有强版权不得嵌入 PDF ，但总归表征更像字体并没有嵌入到 PDF 中，所以版权问题可能性较大；如果是 linux 平台创建，先检查字体库文件问题。

陈述一个事实，windows 7 开始，中易为微软更新了“仿宋”字体，而且更加强调版权，不得在非 Windows 系统中使用，所以 PDF 不会嵌入这个字体，结果就是很多用了这个字体的公文生成 PDF 后到其他平台上就全是以保护字体显示。

这些方块其实就是调用了保护字体渲染。

PDF 嵌入字体

对了，2#再补充一个 USB 网卡，完活，连 MAC 都对不出来，完活

你还是带一个 windows to go ，或者 linux LiveCD 吧，然后全流量走梯子

我记得网卡已经都有自动切换功能了。以前需要区分交叉线还是直通线。

超声波载波数字信号，原理就是无线数字通信，只不过从电磁波变成了声波，载波带有 UUID ，接收端接收到声波解码识别 UUID ，然后找服务器识别显示端的信息，通过 wifi 建立连接，回归到传统无线投屏套路，完活。需要双端在线。纯靠声波实现数据发送，声波表示太难了，高清无压缩信号都还得靠 60GHz 频段传输。

@noahhhh 2# 我的 X85J 就这熊样了。应该是 J 版开始换的，然后按照 OP 3#，H 版的开始更新了。

如我所猜，耗时点（效率瓶颈）产生在接收端的创建摘要过程，因为我觉得 A 端保存并摘要在整个流程中是一个异步的，不会影响。而可能 B 端接收是一个同步的事件，需要考虑摘要计算的影响。

那么我觉得你最好不要用 sftp 而是自己实现传输过程，在接收的时候，边接收边计算，甚至采用楼内建议，分片外加并行。如果是结构化的数据文件，分片比较 easy 吧。

发送端在保存的时候即创建摘要，再次读取传输的时候直接传送摘要。
接收端在接收的时候即创建摘要，之后两者匹配。

场景描述不详细，还需要 OP 补充。

遇到过一个失去浏览器窗口焦点就暂停的

多么希望家里的玻璃能运行这段代码

https://zh.wikipedia.org/wiki/USB USB 机械电子标准一览表
除非你说的不是 TYPE-B

我现在就用着一根 A-C 连接着 U2720QM ，A 头接台式机 USB-A ，C 头接显示器 TYPE-C ，然后鼠标键盘接显示器。回复中的“部分”写错了，应该是不分。你看说明书，https://dl.dell.com/content/manual12122772-dell-u2723qe-monitor-%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97.pdf?language=zh-cn 第 13 页 8 号接口。

@stardew 18# 5 口就是 DP AlternativeMode 的一线通，带着视频信号呢，还可能切换到 4-Lane 提供更高的带宽，4k10bit60Hz 需要 4-Lane

@Highlights 20# 那根线部分上下，A 头接台式机，C 头接 8 口，就可以了。你说的方头，就是 type B ，已经换成 type-c

大哥，不看说明书么，这机器就没有 B ，给你 A-B 干啥。看我的那篇文章，接 8 口，A-C 就是你期望的 A-B 。5 口是一线通接笔记本的。

@duke807 感觉在 v4 上，光猫充当了 NAT ，就光猫的性能，堪忧。还是桥接给下游设备，然后做 NAT 吧