昨天在我电脑上有原图的 6 倍之大，移除倍数后是 2 倍。用你最新的代码是 3 倍，但是依旧存在问题，每次复制的都是当前尺寸的三倍，并不是实际大小的三倍。

这个代码没太深入研究，还麻烦再帮忙调试一下，谢谢。

emmm，核心想法不是为了相对实际大小设置的，而是相对目前显示大小设置的，因为canvas渲染的效果在相同像素下明显比思源中查看要好，所以需要调大截取的比例，保证两者的显示效果差不多。如果使用其他的图片查看器，比如直接使用window的照片，增加0.5的系数就很足够了。

不过移除后为什么是两倍大小？这个结论是怎么来的，能发来测试的pdf吗？

如果放太大的话，这种小图片就每次都需要用户去手动调整大小，很麻烦

不用实际的话，用户每次调整缩放后再次复制的就都不一样（尤其是选择自动缩放后），这样用户还是需要去手动调整成一样，感觉也很麻烦。

不知道是不是因为 scale 等于 2，这个 debugger 能看出问题么？不能的话我再私发 PDF 给你

那我明白了，这个scale获取的是全局或应用的缩放，也就是windows的这个设置：

v姐你应该用的是4k屏加全局2倍缩放，才会有这个scale。

但是，在思源或者说web应用中，canvas使用的是实际像素，应用中的图片使用的是被全局缩放影响过的放大像素。因此，虽然从canvas中截取的就是真实的图片大小，但是在思源中显示是会放大的。

如果要保证两者的目测大小一致，那应该取scale的倒数，这样会导致显示效果更加的模糊，在v姐你的设备上相当于原始图片放大4倍的清晰度，我认为这才是不可接受的。

因此，这虽然与用户的第一直觉不符，但是才是合理的做法。

另外，截取这么少的面积对于矩形标注来说才是少见的用法，大面积的框选才是更为常见的，为了这方面的用途，还是需要增加放大系数。

另外，使用显示的大小作为基准是很有必要的，因为pdf的大小和形式都是不确定的，有分屏的、纵向的、还有大小经过缩放的，我们没办法使用pdf上的参数确定这个图片截取到什么缩放才是合理清晰的，只能以用户在查看时使用的是什么缩放作为参考。

所以我的想法就是在用户目前查看的缩放等级上增加一个固定值，这样才能更好的以不变应万变。

我的是 Mac，应该没有进行过缩放。

是否可以把导出的图片的大小设置为实际大小下的像素值，这样不仅可以兼容中小图，还可以保持任何情况下复制后的图片大小。

我查了一下，mac的应该会有默认的缩放设置

v姐你可以使用手动截图看看，应该会发现截图的显示大小是你实际截取大小的2倍。

因此，这实际上是一个显示的问题，可以在初始化阶段先获取缩放系数，然后反向设置css即可。

我调整了一下，你看看这个效果是否可以？

依然模糊，这个真的是显示大小的问题。

这是我直接修改css的效果。

我换个电脑看看 ，感觉我这个还可以

但是清晰度下降真的很严重啊……明显是变大且模糊了。

而且v姐你不应该截取小区域进行测试吗？

我在 Window 上看并不模糊，大的2倍不到，大部分场景可以接受。你用的是 dev 最新的代码么？

完全不行，属于不可接受的等级。正如我之前说的，不可能从pdf中得知什么样的缩放最合适，比如我找了一个字比较小的pdf，那么公式已经完全看不清了。在图片中，我完全看不出是x还是2，还是‘’

依靠用户当前的缩放才是更加合理的

这应该属于比较特殊的情况，可以用 QQ 截图代替一下。

不能这么说，如果这个还需要使用其他的截图功能来代替，那这个功能还不如不改进呢，至少以前只是有边框，现在是完全用不了了。

而且，特殊情况也并不特殊，从我的图片版pdf里，一半都会出现这种情况。文本还能直接划选，那图片版该怎么办？

我提交这个pr是为了能根据需要获取高清的截图，痛点是之前总是有边框，截的图片不够清晰，但是这越改越难用……我是真的很难受。

这种例子是很多的。

v姐你也可以自己用这个pdf试试。
test.pdf

再来一个过大的
干燥技术在果蔬中的应用综述.pdf

好像也有道理，可能平常 pdf 用的比较少。

那v姐可以重新考虑一下这个吗？

嗯嗯，这个版本会改的，要晚一点，还在改其他的 issue。

设置为 1.5 倍，麻烦再帮忙看看是否可行？

v姐，你拿我发的两个测试文件测试一下不就知道了……固定缩放的适用面太小了。

能同时满足这两个文件的只能是动态缩放。

昨天已经改成动态的了

从实际情况来看，依然是固定的

是 Dev 分支的代码，在 600% 和 200% 下的情况

刚刚试了下，是我没刷新的原因……

画质什么没问题的话，这个 issue 就这样吧，今天要打包发布了。

在左右分屏的情况下，分栏的pdf图像略微模糊……v姐你要不还是用我这个提交 cc2cc04 吧，目前这个在小缩放的时候还是会有点模糊。

这个模式在不使用分栏的pdf的情况下是能接受了。

版本已经发布了。

按照用户缩放后的比例进行截图，左右分屏和不分屏的情况下如果缩放比一样，大小应该也是一样的。

版本已经发布了。

按照用户缩放后的比例进行截图，左右分屏和不分屏的情况下如果缩放比一样，大小应该也是一样的。

确实如此，只是我希望能适当提高放大系数，目前的放大获取方案不能良好保证任何缩放都能获取足够清晰的图片。

按乘法来的话，在缩放小、比较模糊的时候只能有限改善模糊，在缩放大的时候，又会获取到过大的图片。

所以我的想法是使用加法方案。

更精确的动态缩放系数也有，但是不如加法方案在效果可接受的情况下实现简单。

这个 PDF 看上去是不太清晰的，我们是否可以理解为用户在使用的时候如果不在乎清晰程度，最终也不会太在意截图的清晰程度。

如果要修改的话，是不是需要在这里根据缩放的大小来使用某个算法来使其最终截图不会过于太大而且清晰？

这个pdf是一个矢量化的pdf，实际上的分辨率是无限的。显示较不清晰只是受到分屏时屏幕大小的限制。

是否理解为用户在使用的时候如果不在乎清晰程度，最终也不会太在意截图的清晰程度。

我认为这一点是不太正确的，实际上用户自然是希望无限清晰的，只是受到了图片体积的制约。如果说用户最终选择了较为有限的清晰度，那也只是出于图片体积和图片清晰度的综合考量。

但无论如何，用户肯定是希望图片在查看的时候是清晰的，只是不要求无限放大也能保持清晰。因为思源图片总是相较于pdf中相同的像素放大显示，因此增加放大系数来获取截图是符合用户意愿的。

如果要修改的话，是不是需要在这里根据缩放的大小来使用某个算法来使其最终截图不会过于太大而且清晰？

因此，这里的说法只能有限的成立，正确的说法是需要根据缩放的大小，来使用某个算法来使其最终截图在清晰度可接受范围内、体积不会过大。

在我观察了各种算法的效果后，我觉得还是直接使用加法来增加放大系数比较简单且效果可接受，更强的算法是获取截取面积和屏幕面积，然后再使用非线性算法进行计算，但这个就比较麻烦一点。我pr的哪个原始版本直接修改getCaptureScale就行，在v姐你改成现在的代码后，我觉得是有点难以下手了。

如果v姐你觉得可以的话，我觉得可以到ld社区进行一下投票，来一个小规模的抽样调查。

搜索 1.5 这个，目前是写死的，修改为需要的算法应该就可以了。