Adobe Reader 安装程序体积历年变化
最新更新：2025-08-26 04:33:40
截至本文撰写时，适用于 Windows 11 的最新版 Adobe Reader 25.x.y.z 64 位安装程序体积达 687,230,424 字节。安装完成后，程序包含“AI”（理所当然）、自动更新程序、遍布各处的_Acrobat在线服务_广告，以及“新”与“旧”两种图形界面。
作为对比，SumatraPDF-3.5.2安装程序仅为8,246,744字节。它不含“AI”组件，无自动更新程序（虽可检查新版本——我认为这毫无必要，毕竟理智的用户本就会通过scoop安装），更没有“云存储”广告。
下图展示了Adobe Reader安装程序多年来体积的增长趋势。在可行的情况下，均采用64位版本安装程序进行对比。
次日更新：
Hacker News最佳评论：“这图表简直像犯罪现场”
好吧，这里是线性图表，以及生成两张图表的原始数据源此处。所有数据点标签均为版本号。
Adobe Reader是我在全新设备上绝不安装的首款应用。
它运行迟缓卡顿，暗藏诸多恶意设计与烦人弹窗，以各种方式践踏用户权益，还将基础编辑功能锁在订阅服务后。
这简直是垃圾软件中的垃圾之最，和MS Word(在Mac上越发臃肿)同属一类。
编辑：为明确表意在“垃圾”后补上“软件”二字。
> 烦人的弹窗
弹窗难道有不烦人的时候吗？:)
最近对此深有感触，我实在想不出弹窗在何种情境下是真正不可避免且恰当的选择。至少从用户角度看是这样(开发者视角嘛，这既是偷懒捷径，又是抓人眼球的“好方法”…虽然抓不住注意力)。
我有个Illustrator插件，提供多种定期保存文件的辅助选项。我设置的是每十五分钟弹出一次礼貌提醒。
有时它会抢占Illustrator操作焦点，确实略显烦人，但正是这种设计才真正有用——我_希望_它能打断当前操作，迫使我思考是否该保存文件，若未完成则立即保存。
或许这依然令人不快，但这是我明知会烦人却主动要求的烦扰。
看看如今开发者如何称呼“吐司”通知：他们深知“弹窗”一词带有负面意味，却达成共识用新名词替代，而非彻底杜绝弹窗机制。
《主题医院》(一款90年代的搞笑游戏)的提示设计很酷，看左下角图标弹出的效果：https://youtu.be/26O35BOTVSI?t=693
部分提示若未点击会自动消失，可能是问题已解决(例如等得不耐烦的病人离开)，且用户可自由选择处理顺序。
> 弹窗难道不总是烦人吗？ 🙂
在macOS的Finder中按空格键“预览”文件基本算“不烦人的弹窗”，毕竟这是用户主动需要的操作 🙂
或许当用户反复尝试不可行的操作却未能理解更微妙的UI提示时？此时弹窗恰好介入解释操作失败的缘由，反而能缓解挫败感？
>> 我实在想不出弹窗是真正不可避免且恰当选择的场景
双重验证请求的弹窗呢？弹窗提示推送通知总比自己找认证应用强吧。
“确定要关闭146个标签页？”
这正是多余弹窗的典型案例。只需提供明显的撤销操作即可。
> Adobe Reader是我在全新设备上首拒安装的应用。
说得好。让我想起那首歌词类似“当你的手机不再响铃，那必定是我”的歌。
我常听一档恶作剧电话节目，主持人惯用桥段就是给二手商品卖家打电话，明确告知对方自己毫无购买意愿。
“人们总爱解释为何不买那些他们压根没打算买的东西”
— 科技吐槽YouTube频道
有链接吗？
现在不确定能否找到具体包含这类通话的剧集，但搜索“美国电话失败者”或“扫雪车秀”(都是同一位主持人)能找到大量Craigslist相关通话。
这里有个类似桥段，他假扮AT&T客服告知对方无法接听来电：
https://www.youtube.com/watch?v=s1sxF6vN3Ho
这挺有意思。英国也曾有过类似的“电话劫持者”组织。
不过Adobe Reader(或Acrobat Reader)仍是PDF文档的行业标准。
我曾遇到这样的情况：用OnlyOffice创建的PDF在Chrome中显示正常，但嵌入的字体在Acrobat中无法识别或正确渲染。
我保留Acrobat安装仅用于验证自创PDF文件的完整性。
我怀念Acrobat的打印对话框。没错，就是那个打印对话框。我不得不安装整个臃肿的软件包，只为获取那个对话框。
为什么？PDF文件往往是“打印优先”文档。有时我需要打印它们。有时打印机需要些许调整才能输出完美效果。Acrobat的打印对话框具备即时完成此操作的能力，毫不费力。其他软件则完全做不到。如果SumatraPDF能具备同等功能，而不是把所有内容都扔进那个糟糕透顶的Win95时代系统默认打印对话框，我想我永远都不会用其他软件了。
它居然还能成为行业标准，这实在令人难以置信。在我用过的现代PDF阅读器中，它的表单填写功能(在现有PDF上填写表单)绝对是最糟糕的。即便是付费版本也相当糟糕。
上份工作中我不得不安装Adobe Reader，因为需要处理的联邦及州政府官方PDF文件仅能在该软件中正确显示。若用Chrome等其他程序打开，只会出现单页提示要求使用Adobe Reader。
>用其他软件(如Chrome)打开时，只会显示一张提示“请用Adobe Reader打开”的空白页。
所以他们故意让非Reader的文档无法正常显示？
PDF存在多种标准。文档设计者可通过支持不同标准实现差异化显示效果。Acrobat(至少曾经)是唯一真正兼容所有标准的软件。
完全正确。我最近用macOS预览程序处理国外PDF地图：旋转图层并叠加英文注释。保存后在预览程序中正常显示，但用iOS原生PDF阅读器打开时旋转失效导致注释无法辨识。而Acrobat Reader for iOS能正确显示。
可见仅看二进制文件大小毫无意义。Acrobat虽臃肿，但其底层代码显然足够健壮，能处理其他阅读器无法应对的边缘场景。
虽然我也持相同看法，但仍会安装它——因为总会收到只有Acrobat能处理的PDF文件。
所有替代方案都存在缺陷，尤其在商务场景中，人们总会发挥创意挖掘PDF的特殊功能。
我使用Adobe Reader/Acrobat的唯一用途就是将PDF转换为文本。真的仅此而已，而且仅因为某些PDF文件的转换效果远胜于pdftotext。
若在Mac系统上，何必安装Adobe Reader？虽然专业用户可能需要那5%的特殊功能，但预览程序已能满足我所有需求(包括签名标注、真实信息遮盖、合并PDF等)，且速度快、功能齐全且完全免费。
不是给高级用户用的，是给政府机构用的 🙂
我保留官方Adobe Reader是因为这是签署政府文件的唯一途径。
它简直像病毒，我不得不手动清除更新守护进程和垃圾邮件守护进程之类的东西。
顺便说下，文章说它现在有“AI”功能了。那我的纳税申报表会被发到哪里去？
我用预览程序处理签名标注、合并PDF、删除页面等操作，但有时会破坏可填写PDF——字段对齐失准，某些数学函数无法使用。
许多经典PDF功能至今仍未被替代阅读器实现。工作中我必须使用Reader来调用可点击的元数据弹窗，这是其他阅读器无法支持的。
Adobe支持的两大功能在其他阅读器中并不常见。首先，我使用的原理图捕获应用生成的PDF文件中，每个元件的元数据可通过点击查看。原理图上显示“R179, 100欧姆, 0.125W”，点击后会显示零件编号及BOM中的其他数据。其他阅读器均无法呈现此类数据。由于该PDF作为“不可篡改”的图纸副本导入客户关系管理系统，无需打开Cadence软件即可获取全部信息极为便利。我认为这涉及某种极易被利用的PDF JavaScript扩展功能，或许正是其他厂商未支持此功能的原因(也解释了为何Adobe产品常受CVE漏洞困扰)。
其次，我们利用Adobe的批注功能标记已发布图纸或其他文档的变更。随后我和质量保证人员在PDF上签名，文件要么直接发往生产车间实施，要么交由文档负责人整合到新版本中。其他阅读器要么无法以相同方式使用批注功能，要么无法尊重批注和签名应有的只读属性。
我发现许多表单在预览中无法正常工作。不确定是Acrobat专属功能缺失，还是苹果刻意未在预览中支持。但某些表单在Mac预览中填写后会严重变形，这种情况我一眼就能辨认出来。
> 合并多个PDF文件
能否实现将PDF A的第2-3页与PDF B的第7-23页拼接？多年前在macOS上操作时记得这非常麻烦。记得最后用了云服务/网站处理，毕竟文件完全不涉及机密。
难道不能直接拖拽文件在预览窗口间移动吗？
你可以直接拖动缩略图。
据我所知，这种方法唯一的缺点是会生成新的PDF文件(渲染到新的PDF上下文中)。某些情况下可能存在损耗(如果存在预览程序不支持的功能被“丢弃”)，且生成的PDF文件可能比原始文件更大。
哇，逐页拼接？我之前不知道这个方法，下次用Mac拼接PDF时试试看吧 🙂
我常用的工具是pdftk。
详见https://www.pdflabs.com/docs/pdftk-cli-examples/
我通常首选qpdf处理PDF：
对于已安装LaTeX的用户：使用LaTeX实现此功能相当简单。
> 使用LaTeX实现此功能相当简单。
不查参数/语法的情况下，如何实现“将PDF A的第2-3页与PDF B的第7-23页合并”？
若需多次命令行调用，且需在终端历史记录中记忆/查找，同时长度不足80字符——我不敢说这算简单 🙂
pdfjam [1] 底层使用 LaTeX 包，它包含在 TeX Live 发行版中，并作为 LaTeX 包的封装工具。基于此，我认为你的示例应为：
坦白说我查了资料才弄明白，不过只花了三分钟(读我文件里就有这个示例)。
[1] https://github.com/pdfjam/pdfjam
有时Mac用户需要与非Mac用户沟通，使用相同的PDF阅读器软件很有帮助——这样就能确保发送的文件与对方所见完全一致。
预览工具尚可，比Adobe Reader强。但PDF Expert在各方面都堪称卓越，相比Adobe Acrobat和预览工具都有显著提升。他们居然不推出PC版，实在太奇怪了。
喜欢预览功能，但它无法兼容所有PDF格式。我仍需经常切换到Acrobat使用。
说得对，谁会选择Adobe Reader而非Mac自带的预览功能？尽管预览功能本身存在局限性。
预览功能哪里差劲？唯一想到的是缺少涉及JavaScript的高级PDF功能(对某些人而言这反而是优势)。
三年前起，每次用预览打开PDF都会莫名缩放失准，左右滑动时文档会抖动……(并非故意左右滑动，而是上下滑动时会触发)。我总得先缩小显示才能让文档正确适配屏幕，此时左右滑动功能才会失效。
在预览中查看的PDF文件中，约每15个就有1个在首页出现类似“损坏JPEG”的伪影。(通常是旧书杂志的扫描件。)页面会出现对角线排列的绿色方块阶梯状图案，每个方块我推测是8×8尺寸的离散余弦变换(DCT)单元，贯穿整个页面，同时伴有疑似缺失的颜色通道。但同一PDF在Firefox中打开则显示正常(说明pdfjs渲染正确)。此问题已存在多年，似乎与MacOS自身的PDF渲染机制有关(因此简单切换应用程序很难解决)。我完全不明白这是怎么回事，甚至想不出合适的描述来搜索这个问题的解决方案…
希望能看到示例PDF文件(我想将其发送给苹果公司的PDF/ImageIO团队)。
在Windows XP时代，我曾深爱福昕阅读器。它能直接打开PDF文档，毫无麻烦。
安装Adobe Reader前可通过Windows版自定义向导[1]移除广告及在线功能，其中设有“禁用升级销售”[2]选项。macOS系统可能也有对应版本[3]。此外，直接在系统注册表/首选项中设置相应的“FeatureLockDown”选项也可能有效[4]。
[1]: https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/in…
[2]: https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/on…
[3]: https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuid…
[4]: https://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/W…
或者我安装一个替代方案，这样就不必执行此操作。
此刻我已不再信任大型程序。有人推荐用Lens管理K8集群，那应用安装包竟有600MB，若我没记错在Mac上安装后体积翻倍。桌面软件真是越来越离谱了。而Blender下载包才300MB。倒不是说我追求过度优化的软件。但2GB的k8控制台本身就让人对开发者失去信任。
移动端也好不到哪里去。刚查了iPhone上几个应用：Instagram、TikTok、Duolingo各自占用约500MB。而这些应用使用一段时间后，缓存内容往往会膨胀到数GB。
几天前我清空了Snapchat缓存——明明很少用，它竟占用了我手机5GB空间。
就在一周前，我通过Lens工具报告了Debian软件包中37MB的冗余空间https://forums.k8slens.dev/t/debian-package-stores-lima-twic…
官方承诺会修复这个问题。
不妨看看k9s：https://k9scli.io/
我实在怀念octant。它曾是款卓越的工具，堪称80/20法则的典范应用。
如今我认真地说，主要用kubectl。试过k9s但实在用不习惯…
注：y轴采用对数刻度。图表显示当前Adobe阅读器比Sumatra大83倍。
确实。考虑到图表旨在展示相对尺寸差异，对数刻度似乎是个糟糕的选择。
对技术受众而言，这可能是较优选项；但面向大众传播时效果欠佳。
若采用纯线性图表，Adobe PDF安装程序和公司前15年的发展轨迹将完全被压扁成一条直线
参考版本：线性纵轴图表 https://imgur.com/a/A2D1puk
就本文论述目的而言，此图表比对数坐标图更能有效阐明观点。我认为采用此类图表会是更优选择。
谢谢！
但在非对数图表中几乎无法看出SumatraPDF的增长轨迹。2000年前的Adobe Reader同样如此。
就本文传达的核心观点而言，我认为2000年前Adobe的具体市场份额或SumatraPDF的精确规模完全无关紧要。
线性图表能_瞬间_传递以下信息：
或许是我愚钝，起初竟未察觉图表采用对数纵轴。意识到后，我不得不花时间解析图表才能理解其含义(我极少接触对数图表)。解析后我唯一的收获是“哇，当苏门答腊几乎原地踏步时，Adobe却暴涨了”——这与线性图瞬间传递的信息如出一辙。
对我而言，最关键的直观信息就是：苏门答腊体量相对平稳，而Adobe增长曲线近乎垂直。若需精确数值，我自会深入探究。
我认为这恰恰是采用对数刻度的论据。你所说的结论其实并不准确。
Adobe的体量几乎始终呈指数级增长，2010年代中期增速略有提升。SumatraPDF初期同样如此，但十年后成功趋于平稳。
关键在于相对体积变化。90年代中期从约2.5MB增至5MB的增幅在当时相当显著。就用户体验影响而言，这至少与25-30年后从300MB增至600MB同样重要，甚至更为关键。
>关键在于相对体积变化.
这正是我们观点分歧之处。相对体积变化对我毫无意义，我关注的是最终安装包的绝对大小。
Adobe庞大且持续膨胀，Sumatra精简且始终轻量。
我不同意，支持qualeed的观点。我认为容量翻倍本身意义不大，关键在于：为何要翻倍？新增了什么我真正需要的功能？直觉告诉我毫无价值，因此这种做法本不该被接受——只是如今已是行业常态。软件发行商几乎都默认带宽无限且高速，根本不在意用户实际消耗。
90年代这种跳跃会让我白白浪费调制解调器时间。那天我额外多花了30-60分钟才能下载其他东西(如果我记得没错的话)。如今，多下载300MB只需不到一分钟，我还能轻松同时处理其他任务。
试想1998年出现50MB的跳跃——那绝对是令人瞠目的瞬间。再想象2025年的50MB跳跃，我们几乎不会察觉。
说Adobe的疯狂增长始于六年前，不过是指出指数曲线中的拐点罢了。其实从1.0版本起，它的增长曲线就基本如此。而SumatraPDF也曾长期保持同样的指数级增长。
若只看绝对数值，300MB的增量无关紧要，那为何不把Y轴扩展到1TB，把所有数据都压在底部？
感谢！这张图比文章里的清晰多了。两款软件的相对体积一目了然，而对数刻度在这方面简直糟糕透顶。
若要凸显Adobe Reader如何臃肿膨胀，同时对比Sumatra的空间利用效率，这种呈现方式才真正切题。
这才是最具代表性的展示。
作为技术受众，对数刻度对我毫无意义。因此我甚至不认同它对技术受众是好选择。或许对习惯阅读对数刻度的人有效，但这类人群绝非多数——毕竟这种图表实在罕见。
我最初看图表时误将版本号当作兆字节大小，因为这样解读的数据与曲线呈近似线性关系。“25.1 MB？”我自言自语道，"咦，我本以为会大得多，但…或许是某种超压缩技术？但还是感觉太小了。不过这篇文章可能是在夸Adobe控制得当。"
随后想到Sumatra安装包3.几MB的体积倒也合理，毕竟是高压缩安装程序。
唉，有些体积实在离谱。我至今记得Zoom某次更新直接翻倍——他们居然在安装包里塞了_第二个完整网页浏览器_。
2005年收购Macromedia后，Adobe将Flash整合到Acrobat及Acrobat Reader等多款产品中。这使得PDF文件能嵌入Flash(SWF)内容，导致安装程序体积和复杂度增加。随着Adobe在2020年代初正式终止Flash Player支持，Flash功能最终被移除。
Adobe还在Acrobat中嵌入了JavaScript引擎，以支持表单验证和自动化等交互式PDF功能。多年来，Flash和JavaScript都带来了显著的安全风险。
尽管Flash已不再受支持，但Acrobat Reader仍包含JavaScript功能，这依然是潜在的攻击面。相比之下，轻量级PDF阅读器如Sumatra不支持JavaScript或Flash，提供了更小巧、更安全的运行环境。
我总觉得嵌入JavaScript这件事带着某种讽刺意味。
PostScript技术本身很出色，拥有强大的渲染引擎。但问题在于PostScript过于强大——作为图灵完备语言，其脚本输出难以直接作为文档使用。于是Adobe沿用相同渲染引擎，剔除图灵完备特性，添加大量结构化设计，最终诞生了PDF格式。讽刺的是…他们随后竟以(厌恶地吐唾沫)JavaScript的形式，将那些棘手的图灵完备特性重新塞了回来。天啊，如果他们真需要在文档里嵌入脚本语言(这点尚有争议)，大可直接把PostScript放回去。
题外话：有没有好用的平滑滚动PDF阅读器(至少Windows平台)，能提供一定程度的视图自定义？(比如双页并排显示，最好支持深色模式和隐藏工具栏的全屏纵向浏览。)
据我所知，Adobe阅读器(？记不清确切名称)是唯一具备此功能的Adobe产品，虽然我弄到过旧版exe，可惜它已被停产。
最接近的似乎是Xodo PDF，功能几乎齐全，但弹窗实在太多。
或许试试Sumatra PDF？
它真能实现这些视图模式？上次试用时感觉界面相当…简陋/粗糙。有点像Arch Linux的感觉——我不是怀疑它做不到，但不查阅文档恐怕难以操作(无意冒犯Arch或Sumatra！)
Sumatra支持带封面页或无封面页的并排显示，但无法实现无边框界面，深色主题也略显丑陋。
这确实是相当成熟的程序，只是开发者选择以牺牲其他功能为代价，极致追求“轻量”和“快速”。
或许Okular能通过调整实现这种效果
谢谢，我记得以前试过，再试试看
买台Mac用预览程序吧
(我没投反对票)我真心想买Mac，只要能在上面轻松运行自己的操作系统，且维修成本合理(我愿意为优质产品支付高价)。
…大概这就是我买框架(13)的原因吧哈哈
这下子被愤怒的黑客们疯狂点踩了。用对工具完成任务有什么不对吗？在另一个帖子里，我还建议发帖者卖掉Mac换台PC呢。
> 有没有好用的平滑滚动PDF阅读器(至少Windows平台)
看来提问者这次是在找Windows软件。无论如何，“买台Mac(…)”作为“需要更好PDF阅读器”的解决方案听起来有点不合理。
仅供参考：我认为若Mac更适合这位评论者，他早该换机了。对某些人而言，苹果设备在细节处理和用户体验上的提升，并不值得为同等配置的PC多花$$$。其他顾虑想必你也清楚。
> 正常人都会通过scoop安装
这种认知缺失实在令人震惊。
除此之外帖子写得不错。图表很棒。
我对Windows生态不太熟悉，但理解Scoop是类似Choco或NuGet的包管理器对吧？它会被认为臃肿吗？谢谢
这种认知缺失在于：绝大多数Windows用户根本不知道Scoop(甚至可能没用过任何包管理器)，尤其不会用它安装GUI应用——但这并不意味着他们“不正常”。
就算有人用包管理器，也多半是Choco。我读这篇文章前连Scoop都没听说过。
choco需要管理员权限，像我这样的企业员工并不总能获得。
而scoop始终以普通用户身份运行。
scoop很可靠，它始终局限于用户配置文件内运行，不像某些其他包管理器那样。
winget难道不该尊重软件包源的初衷吗？
这种态度让我反感，更可悲的是它污染了整篇文章。不理解组织和个人需求各异，是多么狭隘的观点。不承认winget或chocolatey的存在，甚至暗示使用它们(或天哪，官网)是疯狂行为，简直荒谬至极。
最糟的是浏览器如今在表单填写和签名功能上已更胜一筹，而Adobe垃圾软件却试图借此推销付费服务
确实。具体何时改进我不确定，但Chrome表现出色。
记得一年前尝试时它根本做不到，或者说做得糟糕透顶。
我04或05年转投Mac阵营。预览程序的PDF处理能力立刻让我惊艳，从此告别Adobe Reader。
它依然臃肿不堪倒不意外，但真没想到体积竟逼近整张CD容量。
简直荒谬。
这消息让我震惊。最近我买了台旧PC笔记本在车间用，运行一些Mac无法运行的发动机诊断软件和设备控制程序。当然首要需求是PDF阅读工具，我选择了Reader——想着Adobe的工具应该最靠谱。结果安装后突然冒出McAfee弹窗？天知道它还捆绑了什么东西。简直糟透了。我满身油污地翻阅维修手册时，AI弹窗和广告总在眼前晃悠。他妈的。
或许该试试文章提到的Sumatra。我之前用Mac自带的预览程序，实在没精力研究什么PDF阅读器。对Adobe非常失望。
所有浏览器都能很好地打开PDF文件，有时甚至比Acrobat更好。只需Chrome、Firefox、Edge等浏览器即可。
我通常需要查看数千页的手册，快速搜索和导航至关重要，而且需要良好的图表缩放功能。我甚至没尝试过用浏览器，因为机器性能有限，我以为会太慢。但我会试试看…
我频繁遇到这个问题，因此尝试将所有PDF页面先渲染为png图像，再用程序一次性加载所有图像到屏幕上。
优点是速度极快，由于所有图像已预先加载，完全没有加载延迟。
缺点是内存消耗极其惊人。一本500页的手册可能占用8-10GB内存。此外还无法实现文本高亮或Ctrl+F搜索功能。
但即便如此“勉强可用”的方案，也凸显了PDF阅读器的缺陷——尤其当遇到那些保留完整图像却OCR效果极差甚至完全未识别的扫描文档时。在Chrome中阅读PDF时，跳转文档位置的加载耗时极长(每页数秒)。既然如此，为何不直接采用图像文件格式？
我发现Sumatra在PDF兼容性方面最多只能算凑合。确实经常出现PDF无法加载或显示为空白页的情况，上周就遇到过。但即便如此它仍是我的默认选择。
完全同感。最近要给一台Windows 7笔记本部署摩托罗拉软件和文档，去下载最新版Reader可执行文件时——
看到Windows 7版居然提供600MB+的安装包时简直震惊，最后我自己转用SumatraPDF了。
8MB比600MB强太多了，尤其在只有1GB内存的笔记本上。
我用的是Adobe Acrobat付费版。但应用里铺天盖地的弹窗简直令人抓狂，根本无法工作。尤其现在他们还在软件里推送“AI”功能广告(这还是个付费插件)。
我唯一感受到的差异是显示速度；但阅读技术性强内容时这并不重要。若需快速浏览大量页面，Adobe Reader反而更快。
比什么更快？
比基于浏览器的PDF显示更快；不过我尚未与muPDF或Zathura进行过直接对比测试。
当前最佳的免费桌面PDF阅读器/编辑器是什么(不限操作系统)？
在Windows上我用了十多年的PDF-XChange，但好奇是否有更优替代方案出现。
我总在预览器和Skim之间切换：简单操作和编辑用预览器，深度阅读(比如需要同时查看PDF文件两个部分的大型文档)则用Skim。
有趣的是图表采用对数刻度，使得增长幅度看起来远不如实际显著。反观许多股票图表却用线性刻度，反而夸大了波动幅度。我认为应该反过来才合理。
哪些工具能填写带JavaScript的PDF表单？
Acrobat在我们公司所有系统上都崩溃了。打开几秒就崩溃。无论卸载多少次或尝试其他方法都无法修复。垃圾软件。
对数刻度让你忽略了问题的严重性。
真想看看这张图用线性刻度展示的效果！
与此同时…
> apt show zathura | grep Size
Installed-Size: 1,018 kB Download-Size: 224 kB
我用xpdf或evince。从未遇到它们无法处理的PDF。不过我的需求很简单。
目前最爱的PDF阅读器。功能虽有限，但比我试过的任何软件都快。
Mupdf搜索大型PDF的速度快得多。不过自从切换到wayland/sway后，我也开始用zathura——因为它支持剪切粘贴。Mupdf虽是X应用，我仍用它搜索大PDF。另有此插件但未深入测试：https://github.com/pwmt/zathura-pdf-mupdf。在xorg环境下Mupdf支持剪贴功能。
这并非公平比较，因为实际渲染内容需要大量依赖项。仅zathura-pdf-mupdf在我的系统就占24M。
偶尔更新三星应用时，发现更新包竟达110M。
在5G覆盖的国家这不算什么，但当我在偏远地区度假时，才意识到我们有多么习以为常。
为什么数据点的标签与比例尺不匹配？
看起来像图表犯罪现场
对数刻度让这张图有资格角逐https://www.reddit.com/r/dataisugly/
对数刻度有什么问题？我认为这恰恰是合理运用——毕竟安装程序体积随时间呈指数级增长。
因为趋势线乍看呈线性，未能直观展现绝对尺寸差异。更何况对数坐标图相当罕见，多数人甚至不会察觉其特殊性，从而产生误解
你看到的应该是软件版本号。不过确实容易混淆
数据点的标签是版本号。
明白了，这样说有道理。
未作说明，而数据可视化的核心理念本应是清晰传达信息。当出现数字时，其代表的含义及单位都应标注。在此情境下看到数字，我自然会认为它指代显示的数值。
X轴也略有偏差，理想情况下应绘制发布日期并采用标准时间轴。
添加标题也很必要，或许可以考虑制作数据表格。
抱歉我有点暴躁，但那些给负分的人，要么把表达说清楚，要么学点规范，要么别发布图表。你甚至可以让AI帮你清理代码以符合规范。软技能对工程师很重要。你需要用清晰有力的语言和数据可视化来阐释工作内容。否则就该自诩“我是天才工程师，你们自己琢磨我意思，我才懒得顾及你们眼睛是否刺痛”。天哪。
https://www.datavizstyleguide.com/
https://www.amazon.com/Better-Data-Visualizations-Scholars-R…
https://guides.library.jhu.edu/datavisualization/scientific
https://github.com/rougier/scientific-visualization-book
>软技能对工程师很重要。
个人而言，我对大小写和标点使用有点吹毛求疵。我想每个人都有自己执着的小癖好。
对数y轴确实是比较两个线性量的合理选择
在对数轴上看起来近乎直线难道不意味着指数关系而非线性关系吗？
该量(文件大小)属于线性量
何谓线性量？
我猜想它仅在一个维度上增长
查阅资料后发现：物理学或涉及长度的维度中存在线性量。例如围栏越长，其长度量就越大——因其遵循1:1比例关系。
除此之外还存在线性关系，如每小时工作收入。工作时长越长，收入越高。忽略加班费的情况下，这仍是1:1比例关系
我不认为图表涉及线性关系，因为文件大小并非逐年等比例增长。时间推移与文件体积增大之间并无必然联系。且文件大小不属于线性量，因其不涉及长度维度。
何谓线性量化？
编辑：我迟到了…
现在把每GB存储成本和平均网速加进图表吧。
还有应用加载时间和页面渲染时间。天啊，这张图或许能概括所有问题。