libreoffice卡顿的又一个解决办法。

[zrqlx126]

事实上这个问题从libreoffice一开始出生就存在这样的情况。尤其是在wirter中制作表格时，当涉及的表格异常复杂，卡顿的现象就会非常明显。这些年的版本已经作出了很大的改进，但是问题依然存在。网络上给除了各种各样的设置来解决libreoffice卡顿的问题，但是效果十分有限。
从网络上和各种实验来看，问题可能出现在字体的渲染上，众所周知的是libreoffice字体渲染过程并不采用linux系统的字体渲染方式，单独另行一套，而libreoffice这套渲染方式，在一些字体的渲染上就会出现卡顿缓慢的问题，比较明显的一个例子就是中易宋体字，在有些版本的libreoffice中是无法识别出来新宋体的。
所以根据实验的结果，网络上就有人直接删除中文本地语言包的方法，解决卡顿问题，简单粗暴。但是针对中文母语的我们，没有中文本地语言包是很难进行办公的。所有又有人提出更简单的方法，就是不使用一些与libreoffice不兼容的字体，而使用开源的思源字体，但是这种方法与我们办公时的初衷有不一样。简单的办法是如果真的要使用其他字体，可以在编辑时使用字体替换的方法，将不太兼容的字体替换为开源的思源字体，不让libreoffice对不兼容的字体进行渲染，避免卡顿。编辑完成后，再禁用字体替换，恢复原设定的字体。

这个里给出原文：针对Libreoffice卡顿奇慢的怪病，这里有一味特效药

本人尝试以后效果立竿见影，希望libreoffice尽快尝试修复此问题。

[百草谷居士]

不怎么用writer，倒是在使用impress时发现特别卡，特别是处理impress中的表格时。
是不是也是和这个问题有关？
平时使用 方正兰亭黑，方正新书宋，方正楷体，西文字体一般使用 Dejavu Sans Mono。

[大宝]

libreoffice 版面还原度很差，而且不符合国人，至少是不符合我的编辑习惯，所以坚决使用永中，WPS备选

[yq-ysy]

两年前就已经公布过方法（可能因为帖子的标题没改，就被忽视了）：
【已解决】 LibreOffice 6.1 writer 保存缓慢，总是提示“正在重新制作文档……”的问题。
viewtopic.php?f=35&t=488835

然后我也己经把正确的解决方法写进了《LibreOffice 6.2 Writer 文档写作指南》，在（第214页的“字体”这一小节中）
【下载】《LibreOffice 6.2 Writer 文档写作指南》（22章477页）
viewtopic.php?f=35&t=489410

之前很多朋友遇到的Libreffice文档变得十分卡顿、缓慢的问题，多半是因为在“段落样式”对话框的“字体”标签页里，在“亚洲文字字体”中错误地选择了非中文的字体，虽然也能显示中文，但由于Libreffice总是尝试着为中文汉字寻找合适的替代字体，所以就造成了Libreffice变得十分卡顿和缓慢，只要在“亚洲文字字体”中改选回正确的中文字体，文档的速度就会变快、恢复正常了。

[Ping-Wu]

平时使用 方正兰亭黑，方正新书宋，方正楷体，西文字体一般使用 Dejavu Sans Mono。

一般我们在帮忙解答有关 LibreOffice（英文版）的问题时，第一件事总是先问 “微软的字体装了没有？” 打中文字，最保险的方法就是使用 Noto Serif/Sans CJK。用 mono 字体打英文字外国人看了会觉得很奇怪，其实 Noto Serif/Sans CJK 里的英文字自动会转成 variable kerning，不会比其它西方字体差（即中西文可以指定为同一字体）。

目前 LibreOffice 幕后机构 Open Document Foundation 的政策主要是支持（自动）付费的（大型）使用者，每年的捐款约100万欧元。这样做，除了让开发工作能持续下去外，最大的好处就是有一个固定的目标，建立一个坚强的基础。因为如果这些机构可以放心使用了，以后推广的事就容易了。我知道台湾有一些公司积极的在支持 LibreOffice，但还是极少数。

十多年前，我在参与 OpenSolaris 开发的时候，我们曾经与中国智慧财产权律师协会一些领导讨论，计划在北京中国政法大学设立一个 OpenOffice 的小型实验室。很可惜这个计划因为 Sun Microsystems 倒闭了而作罢（没有了 Sun，就没有人，也没有钱）。要实质推动 LibreOffice，必须积极吸收法商人员来参与。

另外，从 7.0 版起，LibreOffice 开始引进 Vulkan GPU 驱动器，这对图像包括中文字体的处理应该会有很大的帮助。不过如我在另帖提到的，我们的机器这几年来已经都全部换成AMD/Radeon了，不知道在 Intel/Nvidia机器里的效果如何？

LibreOffice 还有一个最大的弱点，即无法运用 OpenCL （amdgpu 开发成功以前，Linux 系统连个像样的显卡驱动都没有，那来的显卡加速？）。AMD 已进行一项计划要把这个缺口补起来，没有人知道到底进展如何。不过AMD 的开源 amdgpu 开始成熟也是最近这一两年的事，应该不必再等太久了吧！

[百草谷居士]

平时使用 方正兰亭黑，方正新书宋，方正楷体，西文字体一般使用 Dejavu Sans Mono。
作为一名老会计，平时并不需要写英文，更多的是数字。等宽字体让数字更清晰易认，在表格中，等宽字体使数字看起来更整齐。

如果字体设置，能够把英文和数字区分开来更好。

另：喜欢那种数字0里带点的字体，这样很容易和字母oO区分开。

[Ping-Wu]

在 LibreOffice 里使用 ibus-rime 时，按 shift + space 就可以把字体换成 ｍｏｎｏ　ｓｐａｃｅ，每一个数字占的空间跟中文字一样宽。在做中文表格时有时候很管用。

0123456789

shift + space

０１２３４５６７８９

另外，Ubuntu Monospace Regular 字型数字0里就有带点，与英文字母O不同，如附图：

在Calc表格里使用 Ubuntu Monospace 的确有它的好处，学到了新东东！

[zrqlx126]

两年前就已经公布过方法（可能因为帖子的标题没改，就被忽视了）：
【已解决】 LibreOffice 6.1 writer 保存缓慢，总是提示“正在重新制作文档……”的问题。
viewtopic.php?f=35&t=488835

然后我也己经把正确的解决方法写进了《LibreOffice 6.2 Writer 文档写作指南》，在（第214页的“字体”这一小节中）
【下载】《LibreOffice 6.2 Writer 文档写作指南》（22章477页）
viewtopic.php?f=35&t=489410

之前很多朋友遇到的Libreffice文档变得十分卡顿、缓慢的问题，多半是因为在“段落样式”对话框的“字体”标签页里，在“亚洲文字字体”中错误地选择了非中文的字体，虽然也能显示中文，但由于Libreffice总是尝试着为中文汉字寻找合适的替代字体，所以就造成了Libreffice变得十分卡顿和缓慢，只要在“亚洲文字字体”中改选回正确的中文字体，文档的速度就会变快、恢复正常了。

Libreffice文档变得十分卡顿、缓慢的解决办法.png

班主，按照您的方法，重新设定后。经过测试，问题依旧。然后我使用如下方法进行了解决。（测试文档为.odt复杂表格文档）
首先，正确选择“西文字体字体”家族和“亚洲文字字体”家族。
再次，使用fc-match查看家族字体的匹配，确保字体首先匹配中文字体。
最后，关闭“切换格式化标记”的显示。

在测试中，发现即便进行了前两项操作，如果打开了“切换格式化标记”，那么卡顿依然。但是一旦关闭“切换格式化标记”，就非常流畅了。
不知道算不算bug

[yq-ysy]

如果打开了“切换格式化标记”，那么卡顿依然。但是一旦关闭“切换格式化标记”，就非常流畅了。
不知道算不算bug

通常一般是使用旧版的 Ubuntu 和 Libreoffice 才会出现卡顿的现像，
因为旧版的 Linux 系统和软件对中文的支持度不够完善，很多默认的设置都只适用于英文版。
以前，不同的 Linux 发行版指定的默认中文字体五花八门，Libreoffice 无所适从，就容易出现卡顿的现像。

自从谷歌开源中文字体发布后，这情况得到了大大改善。
现在基本上所有的 Linux 发行版都使用谷歌开源的中文字体作为汉语默认字体，
这几年来，我在 Ubuntu 上用 Libreoffice 再也没卡过。

我的系统是 UbuntuStudio 20.10，桌面环境是KDE 5.74.0，用 Libreoffice 7.0.3.1 测试，
92万汉字的文章，几秒就打开了（机械硬盘，慢了点哈），滚动编辑也很顺，不卡。
“切换格式化标记”只是用来隐藏显示”段落符、换行符“之类的，也没影响。

不知道你的操作系统环境是什么样的。
但你可以这样测试，在虚拟机上全新安装一个Ubuntu系统，运行Libreoffice看看卡不卡？
比较一下虚拟机上的系统，和你现在用的系统，各种中文相关的设置有什么不同？
也许就能发现问题。
——我比较懒的，就直接用全新的系统了，哈哈，舒心。

[zrqlx126]

如果打开了“切换格式化标记”，那么卡顿依然。但是一旦关闭“切换格式化标记”，就非常流畅了。
不知道算不算bug

通常一般是使用旧版的 Ubuntu 和 Libreoffice 才会出现卡顿的现像，
因为旧版的 Linux 系统和软件对中文的支持度不够完善，很多默认的设置都只适用于英文版。
以前，不同的 Linux 发行版指定的默认中文字体五花八门，Libreoffice 无所适从，就容易出现卡顿的现像。

自从谷歌开源中文字体发布后，这情况得到了大大改善。
现在基本上所有的 Linux 发行版都使用谷歌开源的中文字体作为汉语默认字体，
这几年来，我在 Ubuntu 上用 Libreoffice 再也没卡过。

我的系统是 UbuntuStudio 20.10，桌面环境是KDE 5.74.0，用 Libreoffice 7.0.3.1 测试，
92万汉字的文章，几秒就打开了（机械硬盘，慢了点哈），滚动编辑也很顺，不卡。
“切换格式化标记”只是用来隐藏显示”段落符、换行符“之类的，也没影响。

不知道你的操作系统环境是什么样的。
但你可以这样测试，在虚拟机上全新安装一个Ubuntu系统，运行Libreoffice看看卡不卡？
比较一下虚拟机上的系统，和你现在用的系统，各种中文相关的设置有什么不同？
也许就能发现问题。
——我比较懒的，就直接用全新的系统了，哈哈，舒心。

包含较多纯文字的odt文档，经过测试也没有太大问题。问题出现在包含表格的odt文档中，使用鼠标上下滚动。在浏览到包含表格的页面时，能够明显感觉到卡顿。在编辑复杂表格时卡顿十分严重，反应迟缓，甚至崩溃。
我同时在x11显示后端和xwayland显示后端进行了测试，为了确定问题，还在windows 10 下载新最的7.1.0版本进行了测试。测试结果均表明，取消“切换格式化标记”后，运行明显流畅。
测试环境为ubuntu21.04每日构建版。使用liveusb登陆测试，可以排除系统环境和libreoffice版本影响。文档为包含复杂的odt表格文档（由于保密原因无法上传）。
环境截图如下：

[yq-ysy]

如果打开了“切换格式化标记”，那么卡顿依然。但是一旦关闭“切换格式化标记”，就非常流畅了。
不知道算不算bug

通常一般是使用旧版的 Ubuntu 和 Libreoffice 才会出现卡顿的现像，
因为旧版的 Linux 系统和软件对中文的支持度不够完善，很多默认的设置都只适用于英文版。
以前，不同的 Linux 发行版指定的默认中文字体五花八门，Libreoffice 无所适从，就容易出现卡顿的现像。

自从谷歌开源中文字体发布后，这情况得到了大大改善。
现在基本上所有的 Linux 发行版都使用谷歌开源的中文字体作为汉语默认字体，
这几年来，我在 Ubuntu 上用 Libreoffice 再也没卡过。

我的系统是 UbuntuStudio 20.10，桌面环境是KDE 5.74.0，用 Libreoffice 7.0.3.1 测试，
92万汉字的文章，几秒就打开了（机械硬盘，慢了点哈），滚动编辑也很顺，不卡。
“切换格式化标记”只是用来隐藏显示”段落符、换行符“之类的，也没影响。

不知道你的操作系统环境是什么样的。
但你可以这样测试，在虚拟机上全新安装一个Ubuntu系统，运行Libreoffice看看卡不卡？
比较一下虚拟机上的系统，和你现在用的系统，各种中文相关的设置有什么不同？
也许就能发现问题。
——我比较懒的，就直接用全新的系统了，哈哈，舒心。

包含较多纯文字的odt文档，经过测试也没有太大问题。问题出现在包含表格的odt文档中，使用鼠标上下滚动。在浏览到包含表格的页面时，能够明显感觉到卡顿。在编辑复杂表格时卡顿十分严重，反应迟缓，甚至崩溃。
我同时在x11显示后端和xwayland显示后端进行了测试，为了确定问题，还在windows 10 下载新最的7.1.0版本进行了测试。测试结果均表明，取消“切换格式化标记”后，运行明显流畅。
测试环境为ubuntu21.04每日构建版。使用liveusb登陆测试，可以排除系统环境和libreoffice版本影响。文档为包含复杂的odt表格文档（由于保密原因无法上传）。
环境截图如下：
2021-02-26 14-07-11屏幕截图.png

我打开我翻译的《LibreOffice 6.2 Writer 文档写作指南》，里面也有很多表格，也不卡呀！

可能是因为 Liveusb 的中文环境不完整（虽然它能显示中文），
默认安装包并不附带完整的中文字体，只带有少数简单字体，
安装的过程中，根据用户选择的不同国别和语言，才另外下载相应的字体和语言环境包。

一般 Ubuntu 在安装完成后，设置‘语言/输入法’时，会提示”中文环境包不完整“，
然后会有一个下载安装中文环境包的过程。
在windows 10 下，你需要手动设置 Libreoffice Writer 的默认中文字体，以及在”段落样式“里也指定正确的中文字体。
甚至在”表格样式“里也要指定正确的中文字体，就不卡了。

普通大多数人还不会、更不习惯使用”样式“来编辑文档，几百上千字的文章，随便打几个空格，几个Tab键，就算作是排版好了。
但如果是一个”文字工作者“，要编写几个章节的长篇报告或长篇书籍，就必须掌握”样式“这个基本技能。

[zrqlx126]

我打开我翻译的《LibreOffice 6.2 Writer 文档写作指南》，里面也有很多表格，也不卡呀！

可能是因为 Liveusb 的中文环境不完整（虽然它能显示中文），
默认安装包并不附带完整的中文字体，只带有少数简单字体，
安装的过程中，根据用户选择的不同国别和语言，才另外下载相应的字体和语言环境包。

一般 Ubuntu 在安装完成后，设置‘语言/输入法’时，会提示”中文环境包不完整“，
然后会有一个下载安装中文环境包的过程。
在windows 10 下，你需要手动设置 Libreoffice Writer 的默认中文字体，以及在”段落样式“里也指定正确的中文字体。
甚至在”表格样式“里也要指定正确的中文字体，就不卡了。

普通大多数人还不会、更不习惯使用”样式“来编辑文档，几百上千字的文章，随便打几个空格，几个Tab键，就算作是排版好了。
但如果是一个”文字工作者“，要编写几个章节的长篇报告或长篇书籍，就必须掌握”样式“这个基本技能。

我使用的liveusb是从每日构建的源中自行打包而来的，可以肯定中文语言环境完整，中文字体完整，软件包未经修改变更等，此问题影响可以排除。
我的使用的测试文档就是使用样式来排版的，从测试中百思不得其解。后来，想起来该文档是从我制作的一个模板建立的，而该模板使用的是很老版本的window版libreoffice创建的，问题可能出现在这里。
有兴趣的可以看看这个测试文档（该文档已经删除涉密内容，该文档可在相关政务公开网站上查询）。

[yq-ysy]

我打开我翻译的《LibreOffice 6.2 Writer 文档写作指南》，里面也有很多表格，也不卡呀！

可能是因为 Liveusb 的中文环境不完整（虽然它能显示中文），
默认安装包并不附带完整的中文字体，只带有少数简单字体，
安装的过程中，根据用户选择的不同国别和语言，才另外下载相应的字体和语言环境包。

一般 Ubuntu 在安装完成后，设置‘语言/输入法’时，会提示”中文环境包不完整“，
然后会有一个下载安装中文环境包的过程。
在windows 10 下，你需要手动设置 Libreoffice Writer 的默认中文字体，以及在”段落样式“里也指定正确的中文字体。
甚至在”表格样式“里也要指定正确的中文字体，就不卡了。

普通大多数人还不会、更不习惯使用”样式“来编辑文档，几百上千字的文章，随便打几个空格，几个Tab键，就算作是排版好了。
但如果是一个”文字工作者“，要编写几个章节的长篇报告或长篇书籍，就必须掌握”样式“这个基本技能。

我使用的liveusb是从每日构建的源中自行打包而来的，可以肯定中文语言环境完整，中文字体完整，软件包未经修改变更等，此问题影响可以排除。
我的使用的测试文档就是使用样式来排版的，从测试中百思不得其解。后来，想起来该文档是从我制作的一个模板建立的，而该模板使用的是很老版本的window版libreoffice创建的，问题可能出现在这里。
有兴趣的可以看看这个测试文档（该文档已经删除涉密内容，该文档可在相关政务公开网站上查询）。

在我的机子上，打开这文档很顺溜，一点不卡。
注意到，在 Writer里显示使用字体是 CESI宋体-GB18030 ，样式里也是指定了使用 CESI 字体。
在字体设置里是用“斜体字”显示这个字体的名称，就是因为我的系统没有这个字体。
Liveusb 会自带 CESI 字体吗？不可能吧。
以前就是因为这个原因才卡的，没有对应的字体，就在系统里找其它字体来替代，就拖慢系统了。
但现在我也不卡，一也许是因为文档不大，处理起来快。二也许是因为我是安装后的系统，中文包很完整，替换顺利。

[zrqlx126]

在我的机子上，打开这文档很顺溜，一点不卡。
注意到，在 Writer里显示使用字体是 CESI宋体-GB18030 ，样式里也是指定了使用 CESI 字体。
在字体设置里是用“斜体字”显示这个字体的名称，就是因为我的系统没有这个字体。
Liveusb 会自带 CESI 字体吗？不可能吧。
以前就是因为这个原因才卡的，没有对应的字体，就在系统里找其它字体来替代，就拖慢系统了。
但现在我也不卡，一也许是因为文档不大，处理起来快。二也许是因为我是安装后的系统，中文包很完整，替换顺利。

liveusb使用的是我自行从源中打包的镜像，中文环境是完整的。

cesi字体是我从其他软件包中提取的 。测试时，完整安装了cesi字体。
打开“切换格式化标记的显示”，编辑表格卡顿。关闭“切换格式化标记的显示”，编辑表格流畅。

根据您的提示，问题可能出在两个方面。一是该文档为老版本windows创建的文档，格式上存在问题。二是该文档使用了错误的字体家族，而未被发现，造成字体渲染缓慢，进而卡顿。

[Kiev]

我看到 LibO 7.3 的发行说明里面说这个版本有一条 commit 就专门解决这种卡顿问题，现在 7.3 RC2 都出来了，大家试试。