iOS / Safari output PNG speed opt

[zxkmm]

Description / 描述

• 之前我自己的中等程度文档耗时~45s
• 现在~8s
• 没有发现明显问题

Type of change / 变更类型

• Bug fix
  缺陷修复
• Refactoring
  代码重构
• New feature
  新功能
• Text updates or new language additions
  修改文案或增加新语言

Checklist / 检查清单

• I have performed a self-review of my own code
  我对自己的代码进行了自我审查
• I have full rights to the submitted code and agree to license it under this project's AGPL-3.0 license
  我拥有所提交代码的完整权利，并同意其以本项目的 AGPL-3.0 许可证授权
• PR is submitted to the dev branch and has no merge conflicts
  PR 提交到 dev 分支，并且没有合并冲突*

[zxkmm]

如果为了稳妥起见希望除了Safari iOS之外用老的库的话可以随时告诉我

[88250]

帮忙试试这个如何 https://github.com/zumerlab/snapdom

[zxkmm]

可以的。同时我想知道你们对于两种分叉方案的看法：

• 直接替换，然后尽量做回归测试（但是没有回归测试的测试用例），但是之后可能又要重新开始修问题
• 稳妥起见，原来的库不变，只有safari/ios用新库（不管是你挑的这个还是我挑的），这样的话无论如何都是提升（因为ios的45秒基本上等于不能用）

[TCOTC]

帮忙试试这个如何 https://github.com/zumerlab/snapdom

不知道现在怎么样，去年测试的时候是完全不可用的，当时的测试插件 https://github.com/TCOTC/captures

[zxkmm]

然后这个大方向定了以后我们可以多测几个库看哪个更合适

[TCOTC]

我个人是希望有个更好的库可以直接替换掉现在这个，支持更现代的 CSS 特性

[88250]

@Vanessa219

[zxkmm]

我个人是希望有个更好的库可以直接替换掉现在这个，支持更现代的 CSS 特性

我不知道这些库的实现方法。理论上来说，支持更多CSS是不是意味着在比较落后的环境（火狐和webkit）支持能力较差？因为我感觉这些库是类似于做一个用跑的环境渲染+截图的功能，应该不太可能从头parse然后绘制图片？

如果基于这种考虑的话是不是还是求稳比新css重要？

[TCOTC]

比如以前的库不支持 color-mix 导致主题改颜色很麻烦

[zxkmm]

话说导出图片是要尽量遵循主题吗？我还以为我们注重可复现性

[TCOTC]

导出图片尽量跟编辑器里实际显示的效果一致

[Vanessa219]

plantuml 和代码块行号需要验证一下。或者用用户指南中的排版元素都验证一遍

[zxkmm]

plantuml 和代码块行号需要验证一下。或者用用户指南中的排版元素都验证一遍

你的意思是不用同时使用两个库了是不是？
上下文：#18022 (comment)

[zxkmm]

帮忙试试这个如何 zumerlab/snapdom

不知道现在怎么样，去年测试的时候是完全不可用的，当时的测试插件 TCOTC/captures

经过刚刚的测试，这个不可用。整个思源界面在safari上都加载不出来

[zxkmm]

plantuml 和代码块行号需要验证一下。或者用用户指南中的排版元素都验证一遍

• 经测试，plantuml 本身在safari上也渲染不出来。 (再次排查了一下，好像还跟互联网有关？？)
• 代码块行号确实不正常，序号是跨代码块从头叠加到尾部。请问能接受哪一项
  • 思源fork并改下这个库（对方是否愿意合并不确定，如果不愿意合并，思源就用自己的fork）
  • 修一下思源代码去兼容这个库
  • iOS safari导出图片时候用这个库，别的设备维持原样，导出时候ios不显示代码块的行号（即使用户在设置中选择显示）
  • 把这个放到go后端渲染（有现成的库可以再试一试）

我刚才问了AI，js上能拿得出手的lib我们这下子都尝试的差不多了。我其实建议 “iOS safari导出图片时候用这个库，别的设备维持原样，导出时候ios不显示代码块的行号（即使用户在设置中选择显示）” 选项，我感觉这种程度的瑕疵比45s要好很多

[Vanessa219]

目前比较下来，哪一个库更合适？麻烦给一个详细对比。

[zxkmm]

目前对比下来的折中方案是safari based使用我这个新的库（有些许css问题但是基本达到能用的程度，45s vs 8s）；其他维持使用原库

[zxkmm]

@Vanessa219 @TCOTC @88250
经过细致对比，且再次尝试了好几个新的库，结论如下：
本次变更引入的新库存在两个问题：

• 超长文档（整个用户指南）导出失败，导出的图片是空文件。但是现在用的库导出来的图片也不可读（很模糊）
• 代码块行号显示存在问题（跨代码块之后行号会继续往下数）
  经仔细对比没有发现其他问题。

鉴于目前Safari和iOS图片导出几乎无法使用，我认为有总比没有好，可以两个库一起用，这个库专门服务于iOS/Safari

[Vanessa219]

以上两个问题可以用目前的修改 dom 方式规避么？

[zxkmm]

• 第一个问题不太清楚怎么发生的。
• 第二个问题我估计可以看看怎么patch一下库，或者看看能不能改改思源的实现。

[zxkmm]

请问“目前的修改 dom 方式”的代码大概在什么地方，我看一看能不能追加点东西解决代码块行号的问题

[Vanessa219]

行号可能是上次换导出图片的库的时候移除了。目前有的都在这个方法里面了

siyuan/app/src/protyle/export/util.ts

Line 28 in 44b87de

export const exportImage = (id: string) => {