探索LibreOffice 7.0

这篇由LWN订阅者和LWN.net订阅者带给您的文章使这篇文章-以及围绕它的一切-成为可能。如果您喜欢我们的内容，请购买订阅，并使下一组文章成为可能。

Document Foundation(TDF)宣布发布LibreOffice7.0。这一主要版本是从6.4.6版开始的重大升级，侧重于与Microsoft Office的互操作性、通用性能以及对OpenDocument Format(ODF)1.3版的支持。可以在发行说明中找到新功能和错误修复的完整列表。

当谈到最新的LibreOffice版本时，还必须谈到ODF，这是LibreOffice文档的默认格式。ODF 1.3版早在2019年12月就被批准为OASIS委员会的规范，它对LibreOffice现在可以利用的格式进行了几个改进。出于安全考虑，使用OpenPGP(PGP)的文档加密是一个受欢迎的补充。此外，虽然LibreOffice在以前的版本中通过SSL/TLS证书支持数字签名，但在LibreOffice7.0中，PGP密钥现在可以用来签署文档。该版本中有关ODF的说明阐明了LibreOffice版本之间的兼容性：

最新版本的LibreOffice使用"；ODF 1.3扩展&34；文件应该没有问题。唯一已知的例外是OpenPGP/GPG加密的ODF 1.3文档，它只能从LibreOffice 6.4.5开始导入。如果需要与旧的和不再维护的ODF使用者(如OpenOffice.org、Apache OpenOffice或LibreOffice3.x)兼容，并且不关心是否符合ODF标准，则ODF 1.2扩展版(兼容模式)仍然可用。

为了测试这些最新功能，我们使用了两个系统：Ubuntu20.04和MacOS10.15.5。在这个实验中，在Ubuntu机器上的LibreOffice Writer中创建了一个文档，然后在MacOS机器上打开该文档以验证密码。所有测试都使用我的LWN PGP密钥。

最初，通过PGP工作获得数字签名和加密最复杂的方面是导入密钥本身。LibreOffice依赖于它所谓的操作系统的证书管理器，每个系统都会带来独特的挑战。在这种情况下，从2018年开始，针对MacOS的LibreOffice(版本为6.0.2.1)存在一个突出的缺陷，这给事情带来了不必要的困难。在Ubuntu中，通过gpg导入我的密钥需要注销，海马才能访问它们(bug报告)。

使用LibreOffice7.0中可用的PGP密钥对文档进行签名或加密非常简单。将数字签名添加到文档需要从菜单中选择数字签名(调出文档的当前签名者列表)，然后单击签名文档添加另一个数字签名。对文档进行签名会自动保存该文档，任何进一步的修改都会使签名无效。有一个由我签名的ODT文档示例可供下载，下面是该文档的屏幕截图：

使用PGP加密ODT文档甚至更简单；在使用"；另存为时选中"；Encrypt with GPG Key"；框将弹出一个选择密钥的界面。试图在没有可用的私钥的情况下打开加密文档会导致LibreOffice奇怪地提示输入解密密码(人们可能希望不存在密码)；使用可用的私钥，文档会被透明地解密。

LibreOffice 7.0版本在与Microsoft Office软件套件的互操作性方面也有相当大的改进。对于Microsoft Word，LibreOffice现在支持保存为原生的2013/2016/2019年Microsoft Word MS-Docx格式，而不是以前仅限于2007兼容模式格式的限制。兼容模式从来都不是与Microsoft Word互操作的理想解决方案，正如Microsoft自己所承认的那样：此模式旨在确保不同版本Microsoft Office的用户可以继续协同工作，并且使用旧版本Office创建的文档在未来版本的Office中重新打开时看起来不会有任何不同。TDF进一步解释了这一举措：这主要使Word用户受益-由于可以应用Docx 1.0，因此文档可以使用更多功能并修复Word的错误。&。发行说明接着承认，这一变化对使用Microsoft Word 2010的用户产生了负面影响，并鼓励这些用户转向LibreOffice。

对于LibreOffice Calc，该版本中包含了许多改进。添加了两个用于生成非易失性(每个单元生成一次)随机数的新函数RAND.NV()和RANDBETWEEN.NV()。对于允许使用正则表达式的函数，Calc现在可以正确处理不区分大小写标志。有关此问题的说明表明，函数的默认区分大小写不会更改[...]。只有在正则表达式中的第一个(？-i)之后，敏感度才会改变。"；在另一项Microsoft Office兼容性改进中，现在支持将工作表名称超过31个字符的电子表格导出到Microsoft Excel。

用于自动执行任务的Python宏将不再能够使用CPython版本2.7；该项目已经专门升级到CPython版本3。这一更改可能会给某些宏带来问题；用户在升级LibreOffice时应该会解决Python2.7和3之间的脚本兼容性问题。

随着LibreOffice7.0的发布，社区期待7.1的发布。TDF的wiki提供了7.1的发行说明，随着新特性和错误修复的解决而更新。列出的两个值得注意的改进是LibreOffice Writer的试验性大纲模式和在LibreOffice绘图应用程序中向现有PDF文件添加可见签名的能力。Writer的大纲模式通过提供将当前标题中的所有文本折叠到下一个标题的方式，简化了文档大纲的制作。

有兴趣试用或升级到V7.0的读者可以下载Linux、MacOS和Windows平台的二进制文件。该项目还提供Flatpak、Snap和AppImage版本。要开始使用LibreOffice，可以获得该项目的大量文档。如公告中所述，TDF#34；不为用户提供任何技术支持，该项目的邮件列表和Ask LibreOffice网站上存在社区支持。

LibreOffice7.0版本的一个主要目标似乎是使其与Microsoft Office更兼容(作为Microsoft Office的替代品更可行)。随着微软将注意力转向在线服务(Microsoft365)，TDF似乎意识到，被迫为办公效率软件套件支付永恒的订阅费的想法对除了微软之外的任何人都不是理想的。毕竟，一些用户可能不想依赖完全在线的办公效率套件。TDF很可能希望吸引那些需要或希望在本地安装其生产力软件的用户。

对于那些寻找开源在线办公解决方案的用户，TDF还在同时使用LibreOffice online和离线版本。LibreOffice Online目前适合家庭用户，但TDF热衷于避免大规模部署不合适版本的情况。为了强调这一点，如果超过10个并发文档和/或超过20个并发连接处于活动状态，LibreOffice Online会显示显著的不受支持警告。

对于不熟悉项目细节的读者，LibreOffice主要是在Mozilla Public License v2下发布的。它的社区由广泛的公司和个人贡献者组成；7.0的公告指出：74%的提交来自咨询委员会中的公司雇用的开发人员，如Collabora、Red Hat和CIB，以及其他几个组织，26%来自个人志愿者。该项目定期宣布安全建议，并似乎迅速修复了严重的漏洞。

LibreOffice 7.0在许多关键方面都有重大改进，LibreOffice online很可能会继续成熟为可伸缩的解决方案。对于目前的6.4用户，该项目将继续支持几个月的后端修复。总而言之，由于TDF的努力，免费的Microsoft Office兼容替代方案(在线和离线)继续取得重大进展。

(登录以发表评论)。

TDF似乎意识到，被迫为办公效率软件套件支付永久订阅费的想法，除了微软(Microsoft)之外，对任何人都不是理想的想法。我拥有一家微软(MS Silver)级的公司。我是总经理，我还有另外两个合伙人和20多名员工。我并不反对因鞭打物品而获得报酬，但我确实有自己的标准。这个令人悲伤的老模因肯定是Word，而MS Word在这方面有点令人难过。每当LWN或EL REG上出现新版本的LO时，肯定会有更多的地方出现，而不是机器人…。呃...。员工们站出来为自己辩护。所有的软件都有错误，但是Lo能够渲染所有的.。所有的..。是的，操他妈的所有人……。我公司的文件。

至于作为一个令人印象深刻的例子，所附的截图讲述了非常不同的故事。人们可能会认为文本编辑器很擅长显示文本。然而，字距调整完全错误，看起来非常糟糕：-在"；示例中，"；p&34；和"；l&34；之间的空格太大-"；开源&34；中的破折号偏离中心，移到右侧-"；软件&34；在"；w&34；和"；a"；和"；a"；之间有奇怪的空白。太左，它与"；T&34；重叠，并且在文档中的"；i；-"；e"；之前留了太多的空间-在"；签名"；中的"；g"；也在"；签名"；的前面留了太多的空间，依此类推……。

为什么你认为不是因为1)错误的字体，2)错误的字体配置？

出色的观察力！我在Ubuntu20.04上安装的LibreOffice6.4.5.2中尝试了一下。同样的操作系统，同样的字体。这没有你指出的任何问题，所以要么是倒退了，要么是其他什么东西很时髦。但是，在我的示例中，文档"；中的*这个"；e"；似乎太右了，并且"；签名"；中的*这个"；g"；似乎也与7.0相反？

文本编辑器本身不进行字距调整，它使用字体中的字距调整信息。因此，很明显，您的字体或您的字体设置已损坏。任何系统对此都无能为力。

>；A"；文本编辑器本身不进行字距调整，它使用字体中的字距调整信息。不一定是真的。>；因此，很明显您的字体或字体设置已损坏。任何系统对此都无能为力。

在未来的LibreOffice中，我只希望看到一个新功能。它可以选择以全ASCII编码保存文档。除了一个例外，这个输出与文档的前一个版本在更改的数量上成比例地不同，这使得它“几乎”可以与Git互操作。唯一的例外是，每一行都以一个随机数字开头，该数字与读取文档时在相应行上看到的数字不同。Bug报告已经存档了十多年，要求修复这个问题。(第一个可能提到的是Subversion，而不是Git。)。他们甚至不需要更改格式--只需记住数字，然后写出相同的数字！有各种笨拙/不切实际的变通办法已经出版，针对这个错误，普通人是不能使用的。(顺便说一句，如果标点符号在文本格式的输出中产生一个换行符，这将有助于检查不同之处；但首先要做的是。)。

受您评论的启发，我在LibreOffice中编写了一个名为ToMarkdown的宏，它调用Pandoc并将文件写入.md文件。不过，我不知道为什么。

无论如何，然后我在工具栏中创建了一个调用此宏的按钮，所以现在保存文档后，我可以按下ToMarkdown按钮，我就会得到该文档的Pandoc减价版本。

它不能解决你的问题，但它相当可爱，因为现在我甚至只需点击一下就可以从我的文档中获得乳胶排版的PDF。

REM*Basic*Sub ToMarkdown inname=MID(ThisComponent.getLocation()，8)outname=MID(inname，1，Len(Inname)-4)&；"；.md"；params=inname&；&34；-o"；&；outname Shell("；/usr/bin/pandoc"；，6，params，true)MS。

是的，它并不优雅，你可以/应该用搜索来代替Len-4。让它在扩展名长于或短于3的情况下工作，但我没有费心。

为了完成上一篇文章，以获取PDF(带有开始部分)，我使用了以下宏：REM*Basic*Sub ToLatex inname=MID(ThisComponent.getLocation()，8)outname=MID(inname，1，Len(Inname)-4)&；"；.pdf"；params=inname&；&34；-o"；&；outname Shell(&#。/usr/bin/evince"；，1，outname，false)End Sub。

我还将其绑定到工具栏中的一个按钮上...

我希望他们能着手修复LibreOffice中的协作功能。它们在某些方面不如Microsoft Office提供的产品。*LibreOffice Writer中文档页边距注释保留的空间太少(宽度太小)，这是不可配置的。据我所知，不可能更改评论的默认字体，尽管很高兴您可以一次更改所有评论中的字体。此外，注释的布局是为了避免重叠，这在某些方面优于MS Word-但如果没有足够的空间，每个注释都会得到一个滚动条，而不是像MS Word那样，每个注释只显示一个摘要并在单击时展开，这对我来说更有用*LibreOffice Writer中合并不同版本文档的能力似乎比MS Word中的能力更有限，尽管在描述此功能的文档中可能会过于谨慎。我只需要使用MS Word版本，它工作得很好，可以选择将合并的文档存储在两个合并的文件中，也可以存储在新的文档中。

房间里的大象：GnuPG？在2020年？我想我们已经确定，这个模型对大多数用户来说根本站不住脚；太难了，无法正确使用。我曾希望讨论一下这个…。

虽然PGP在可用性和对普通用户的正确使用方面肯定有它的挑战，但它仍然是事实上被广泛使用的分散加密方法。我不知道它是否比S/MIME使用得更多，但是S/MIME也有一个基础设施方面的挑战，而且不一定更容易使用。ProtonMail构建在PGP之上，keybase.io也是如此。它们都试图使加密更加用户友好。但也就是说，除非您能验证签名者和签名，否则拥有加密或数字签名的文档不会给您带来任何好处。您需要某种可以验证的信任链，以及验证验证的方法。今天广泛使用的是PGP和S/MIME。S/MIME依赖于颁发用户证书的CA，这些证书可以根据该CA进行验证。PGP建立在信任网络模型之上，在该模型中，每个用户都需要确保他们收到的公钥已经过正确的验证。S/MIME概念与SSL/TLS服务所使用的概念有些类似，但获取S/MIME证书供您自己使用并非易事，在某些情况下可能会相当昂贵。PGP一直是免费的。可能会有人大喊，但是区块链！……。是的，AFAIK可能会提供一个更好的替代方案，但在普通用户用于签名、加密和验证文档或数据的应用程序中，AFAIK没有广泛可用的解决方案。要验证区块链实现是否足够安全并让用户真正使用它，还需要做相当多的工作。当它到来并得到密码专家的祝福，产品开始实施它时，情况可能会改变。在此之前，请使用目前可用的。我非常欢迎PGP加入LibreOffice。对于那些足够关心并正确使用它的人来说，这至少是一种效果很好的东西。

有很多FUD围绕PGP在线，但我不知道有什么严重的高调替代。密码基础是健全的，似乎可以抵御民族国家的攻击。一如既往，它主要是密钥管理，这是有点棘手，然而，在过去的5年里，在这方面已经有了巨大的进步，你现在就可以利用它！对于电子邮件，自动加密是用户友好的解决方案。为了信任，只需确保启用豆腐即可。对于密钥分发，请使用众所周知的Web密钥目录。当然，WoT和keyserver的经典模型仍然可用，并为需要它们的用户并行工作。

有很多备受瞩目的替代者！它只是没有万能的，因为GPG模式并没有那么有用。(请注意，这根本不是关于密码的，而是关于模型的可用性。)。要与集中的对象对话，请使用HTTPS。对于安全的消息传递，请使用Signal。要发送文件，请使用魔法虫洞。对于备份，应该使用Tarsnap，但如果您的数据太多，Tarsnap的成本会很高。

谢谢你提醒我还有其他选择。我不会说https真的是一种结束状态，似乎还有很多围绕边缘的调整仍在进行，比如1.3，esni，doh，quic。Signal=lib(Meg)olm在消息传递的案例中，100%同意，而我对魔术虫洞了解不多，将不得不对其进行研究。>；根本不是关于密码，它是关于模型的可用性是的，我以为我们实际上是在谈论可用性，但我把它加进去只是为了清楚为什么我认为可能会有很多人在网上推动避免GPG，但实际上并没有被打破。

从技术上讲，HTTPS可能没有完成，但这并不重要，因为：-用户实际上正在使用它。-网站管理员都是实实在在的

.