从FFmpeg中文字幕问题谈Linux字体管理与合规实践

在处理开发提出ffmpeg加载的中文字幕无法换行问题过程中深入了解Linux系统字体部署、配置以及字体的合规实践

事情起因

FFmpeg 是一个完整的跨平台音视频解决方案，用于记录、转换和流式处理音视频。它是目前最强大的音视频处理开源软件之一，被广泛应用于视频网站、播放器、编码器等多种场景中。开发同学有个项目需要使用FFmpeg处理字幕，使用FFmpeg添加中文字发现无法识别中文，如下图所示：

应该是系统没有中文字体导致的，查看镜像系统字体目录，果然没有中文相关字体。

从另外一台有中文字体的开发机把中文字体SimSun.ttf复制进镜像中。

FFmpeg可以识别中文字幕文件，但是发现一个问题，中文字幕长文本无自动换行，出现文字溢出，如下图。

问题排查

修改参数和升级版本

问了下Deepseek返回可能是FFmpeg设置字幕参数问题，按推荐修改添加WrapStyle=1,Alignment=10后字幕上调但还是有溢出，修改参数失败。

开通同学反馈在自己电脑上使用FFmepg处理完的中文字幕是可以换行的，先排查FFmpeg版本问题。开发同学使用的ffmpeg是7.1.1，中文字幕可以换行。

服务镜像这边是4.2.10，版本差距有些大。

从网上下载FFmpeg静态构建版本，有两个地方可以下载。

• https://johnvansickle.com/ffmpeg 由个人开发者 ​John Van Sickle​ 维护，提供手动构建的版本。
• https://github.com/BtbN/FFmpeg-Builds/releases 由 ​BtbN团队​ 在GitHub上维护，通过自动化构建工具（如GitHub Actions）生成。

服务镜像中使用FFmpeg新静态构建版本后还是不行，应该不是版本的问题，从FFmpeg日志进行排查。

升级FFmpeg依赖

既然修改参数和升级版本都不生效，查看FFmpeg的输出日志，有一段报错如下：

出现 ​**libass wasn't built with ASS_FEATURE_WRAP_UNICODE support**​ 错误，表明当前使用的 libass 库未启用 Unicode 自动换行功能。此功能对中文、日文等无空格分隔语言的自动换行至关重要。

查看ffmpeg 发现开启libass，检查发现当前安装的 libass 不支持 ASS_FEATURE_WRAP_UNICODE

需要解决libass开启支持ASS_FEATURE_WRAP_UNICODE，升级一下基础镜像版本，使用alpine:latest，单独编译libass开启ASS_FEATURE_WRAP_UNICODE，如下所示：

#单独编辑libass
git clone https://github.com/libass/libass.git 
apk add --no-cache libunibreak-dev #当检测到 libunibreak 时自动启用ASS_FEATURE_WRAP_UNICODE功能

./autogen.sh
./configure --prefix=/usr/local
make -j$(nproc)
make install

FFmpeg静态构建版本使用的libass并未启用ASS_FEATURE_WRAP_UNICODE，还需要再编译一下FFmpeg，具体编译命令如下。

#单独编译FFmpeg
git clone https://github.com/FFmpeg/FFmpeg.git 
apk add --no-cache x264-dev (crf需要)
apk add --no-cache lame-dev （提取mp3音频需要）

make distclean
git clean -xdf 


./configure --prefix=/usr/local --enable-gpl --enable-libx264 --enable-libass --enable-static --disable-shared --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" --disable-x86asm --enable-libmp3lame

make -j$(nproc)
make install

打包新镜像后运行，libass这里没有报错了，

中文字幕溢出问题也得到解决。

字体管理

业务逻辑上译文和原文一起烧录，解决完中文字幕换行问题后需要解决字体显示和版权问题（字体不能随便用，有版权限制），使用UI给的Google Noto Sans字体。这里涉及到字体管理以及使用实践，简单说一下。

字体部署相关

系统分类	安装位置	目录结构
Linux	1.系统字体位置：/usr/share/fonts 2.用户字体位置：用户名/.local/share/fonts或用户名/.fonts
Mac	1.系统字体:/Library/Fonts 2.用户字体:/System/Library/Fonts
Windows	字体位置：C:\Windows\Fonts

阿里云轻量级应用使用的字体如下，使用fc-match命令可以查看匹配选择语言适配的字体，字体文件的后缀是ttf。

补充一个知识点，lang=zh或en代表语种名称代码，zh表示中文，en表示英语。可以参考语种代码。

常见语言的ISO 代码如下表：

ISO639-1 Code	ISO639-2 Code	中文名	英文名
ar	ara	阿拉伯语	Arabic
ko	kor	朝鲜语	Korean
de	deu	德语	German
ru	rus	俄语	Russian
fr	fra	法语	French
zh	zho	汉语	Chinese
la	lat	拉丁语	Latin
pt	por	葡萄牙语	Portuguese
ja	jpn	日语	Japanese
es	spa	西班牙语	Spainese
en	eng	英语	English
it	ita	意大利语	Italian
hi	hin	印地语	Hindi
yi	yid	意第绪语	Yiddish

Linux系统的字体管理遵循分类存储原则，字体目录有/usr/share/fonts/ 与 /usr/share/X11/fonts/，区别如下：

以下是常见子目录及其字体类型说明：

注：实际目录结构可能因发行版不同有所差异，可通过 FontConfig 工具集 fc-list查看字体扫描路径,fc-list -v 详细列出系统字体信息的命令，其输出包含字体的元数据、路径、渲染参数等关键信息。

生效新字体

在镜像中新建/usr/share/fonts/custom/，将Google Noto Sans字体复制进去，使用fc-cache -fv 强制刷新字体缓存

fc-match -s :lang=en | grep Noto默认是第一个匹配到的Regular字体。

产品想调整成Medium字体，这种情况下需要在字体配置目录/etc/fonts/conf.d/下新增配置文件

我们新增99-custom-en.conf、99-custom-ja.conf、99-custom-zh.conf，配置语法参考：Font configuration、fonts.conf 中文手册，这里使用Deepseek快速生成配置。

#99-custom-zh.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <!-- 匹配中文字体 -->
  <match target="pattern">
    <test qual="any" name="lang"><string>zh</string></test>
    <test name="family"><string>sans-serif</string></test>
    <!-- 设置首选字体 -->
    <edit name="family" mode="prepend">
      <string>Noto Sans SC Medium</string>
    </edit>
  </match>
</fontconfig>


#99-custom-en.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <!-- 强制英文环境使用 Noto Sans SC -->
  <match target="pattern">
    <test name="lang"><string>en</string></test>
    <test name="family"><string>sans-serif</string></test>
    <edit name="family" mode="prepend" binding="strong">
      <string>Noto Sans SC Medium</string>
    </edit>
  </match>  <!-- 全局默认家族覆盖 -->
  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>Noto Sans SC Medium</family>
      <family>Noto Sans</family>  <!-- 备选字体 -->
    </prefer>
  </alias>
</fontconfig>

#99-custom-ja.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <!-- 强制日文环境使用 Noto Sans JP -->
  <match target="pattern">
    <test name="lang" compare="contains"><string>ja</string></test>
    <test name="family"><string>sans-serif</string></test>
    <edit name="family" mode="prepend" binding="strong">
      <string>Noto Sans JP Medium</string>
    </edit>
  </match>
</fontconfig>

然后再使用fc-cache -fv 强制刷新字体缓存，查看en、zh、jp、ko字体都是Mediumg格式的。

使用新镜像运行字幕烧录，新字体生效完成。

字体合规

用字体之前需要查看字体是否存在版权，比如下面这个被告字体侵权的案例：一字值万金？字体公司被指过度维权，

为了避免使用开源字体侵权，一方面可以自己设计字体（究竟怎样用字体，才不会侵权），另一方面需要查看开源字体的协议分类。

多数情况下，字体的应用方式通常包括平面印刷或者嵌入在软件项目中。通常来讲，在与字体开源相关的场合，可以使用Apahce2.0或者BSD协议进行授权，同时也有专门用于字体开源的许可证，如OFL许可证。例如，谷歌网站字体的许可协议属性，一部分是以APACHE2.0的，而另一部分是OFL的。OFL协议的全称是SIL Open Font License，是基于字体设计和语言软件工程方面的相关实践经验而专门为字体及其相关软件而设立的开源许可证，

协议	核心差异	典型场景
​OFL​	专为字体设计，允许商业使用但禁止单独售卖，强调保留名称规则	Google Fonts、思源黑体
​SIL OFL​	与 SIL OFL 功能相同，但 SIL OFL 是旧版本（如 V1.0），V1.1 为当前主流版本	旧版学术字体项目
​Apache 2.0​	允许代码与字体混合分发，但需遵守代码协议（如保留版权声明）	开源软件中的嵌入式字体
​GPL​	强制衍生作品开源，与 OFL 不兼容	需完全开源的软件项目

法律风险与规避建议​

1. 1.常见风险​
   • •​名称冲突​：修改字体后误用保留名称（如将 “Source Han Sans” 改名为 “MyFont” 仍需声明关联）。
   • •​协议混淆​：将 OFL 字体与 GPL 代码混合时，需明确字体部分独立授权。
2. 2.​合规建议​
   • •​文档声明​：在项目文档中单独列出字体授权信息（如 NOTICE.txt）。
   • •​元数据检查​：使用工具（如 fontforge）验证字体元数据是否包含保留名称。
   • •​版本控制​：若修改字体，建议发布为新版本（如 “NotoSans-Modified”）。

Google Fonts​ 提供全球开源字体库，包含 ​Comfortaa​ 的详细参数（如字重、字符覆盖范围）和在线预览功能。访问地址：fonts.google.com。还有fontsquirrel.com、ziyouziti.com等资源平台。

像阿里云轻量级应用系统用的字体是Comfortaa，Comfortaa以Open Font License协议发布（文件压缩包中已提供授权协议），可以免费用于个人及商业用途。

写在最后

现在人工智能和大数据技术的应用（LLM+StableDiffusion）使得字体设计更加高效和个性化。例如，阿里巴巴推出的“智能字体生成”技术，可以根据用户需求自动生成符合要求的字体样式。随着版权意识的增强，越来越多的企业和个人开始重视字体的合法使用。政府也在加强版权保护力度，推动市场健康发展。

动态字体生成系统架构

多媒体应用开发需要同时关注应用层配置与系统级资源管理，使用字体从系统配置和OFL协议入手，建设企业自己的FontBase平台，确保生成的字体符合SIL、 OFL等协议，构建从字体生成到企业级管理的完整技术栈。