Smart Forms中文字体重叠排查：SSFCTRLOP-LANGU与31字符压缩

简介：这份文档面向使用 SAP Smart forms 进行报表开发与打印调试的 ABAP 顾问和运维人员，聚焦中文内容在英文登录环境下打印预览时字体重叠、越界后与后续内容交杂这一高频问题，属于实操排错型技术资料。压缩包共 1 个 doc 文件，约 28KB，内容以问题现象描述、成因分析、关键代码片段和 SAP Notes 对照为主，篇幅精炼便于随查随用。资源已积累 1088 人学习下载，说明该问题在多语言 Unicode 系统中较为普遍。文中给出了具体定位思路：通过 Debug 表单对应的 FM，检查 Function Module SSFRT_SET_LANGUAGES 中的赋值逻辑，理解 %header-langu 由 control_parameters-langu 与 sy-langu 决定的规则，并给出手动设置 control_parameters-langu = 1 后再传参的修正方式；同时整理了 Note 808326、908442 关于 Unicode 打印预览重叠与字符间距异常的说明，以及 Note 1007575 针对超过 31 字符亚洲文本被压缩的处理，读者可据此快速判断问题成因、核对系统补丁状态并完成修复验证。

1. 一个没赋值的语言位，让 Smart Forms 中文字体重叠拖了半年

接手一套 ECC6.4 的打印优化时，最扎手的不是性能，是几张中文单据在英文登录环境下打印预览时，中文糊成一坨，落纸后重叠的部分还会展开，跟后面的金额、数量字段搅在一起。中文登录环境下同一张表单却规规矩矩按预留宽度换行。我一开始铁了心认为是系统补丁问题，翻出 Note 808326、Note 908442 一对，发现系统早就打过了。真正的原因藏在 Smart Forms 生成的 Function Module 里：有个control_parameters-langu从头到尾没人赋值。这套环境在跨境业务、多语言单据、集团统一模板的团队里很常见，装不好或者配不对，单据打出来没法入账，财务直接退单，运维只能一遍遍重打。这篇记录写给正在被 Smart Forms 中文字体重叠折腾的同行，从环境前提一路讲到改完怎么验证。

2. 环境先列清：ECC6.4 上跟中文打印有关的三个前提

动手改代码之前，得先把环境前提摆清楚。很多人一上来就搜 Note，搜到就打，打完发现没变化，然后开始怀疑系统、怀疑打印机、怀疑字体，唯独不怀疑自己传进去的参数。这套打印链路上其实只有三个变量在起作用：登录语言、SSFCTRLOP控制结构里的语言字段、以及系统补丁基线。三者不核对清楚就改代码，等于闭着眼睛调参。

2.1 登录语言 'E' 和 '1' 影响的远不止界面文字

中文系统的内部语言代码是单字符'1'，英文是'E'，这两个值在系统里对应的就是sy-langu。如果要在用户主数据里切换，走 SU01 进用户 → 参数页签，参数 ID 填SPRAS，值填1或E，下次登录生效。我一般会建两个测试用户，一个SPRAS = 1一个SPRAS = E，其余权限完全一致，这样每次改完能立刻做对照，不用反复改自己的登录语言。

关键点在于：sy-langu不只是界面语言，它还会被打印链路当成"默认输出语言版本"来用。Smart Forms 在运行时如果拿不到明确的打印语言，就会退回到sy-langu。英文登录环境下，如果系统里找不到对应的英文版表单，它会把中文版表单当英文版处理，中转中文数据时宽度计算用的是另一套字体度量，于是字符宽度算窄了，文字就叠在一起。

对照表大致长这样：

表格第三行就是本文后半段要落到代码里的目标状态。注意第二行的"回退"行为不是 bug，是设计如此，所以不要指望靠打补丁让它消失。

还有一个容易忽略的坑：在英文登录环境下打开 Smart Forms 编辑器修改中文文本，保存之后中文描述可能在英文环境打印时全部变成乱码。这个成因我没有完全挖透，但血泪经验是——中文表单就在中文环境里编辑和激活，别图省事在E环境下改，改完再切回去测，很容易把自己带沟里。

2.2 SSFCTRLOP 里那几个决定命运的字段

SSFCTRLOP是 Smart Forms 的打印控制结构，调用生成的 Function Module 时作为CONTROL_PARAMETERS传进去。它的字段不多，但每一个都会影响输出结果，值得单独列一遍：

LANGU是核心，也是本文要改的那个字段。NO_DIALOG和PREVIEW在测试阶段特别有用：前者能让你在后台任务里跑出结果而不卡在对话框，后者能让你不真打纸就看清排版。实际排查里我通常把PREVIEW和GETOTF都打开，一边看预览一边把 OTF 抓到内表里比对字符间距。

另外有个内部变量%header，类型同样是SSFCTRLOP，这是生成的 Function Module 内部的表头控制结构。真正决定"这张表单按哪个语言版本渲染"的，是%header-langu。很多人在外层把control_parameters-langu设了，结果还是重叠，就是因为没确认这个值最终有没有落到%header-langu上。

2.3 补丁基线核对：808326、908442、1007575 三个 Note 分别管什么

网上搜"字体重叠"，基本都会指向两个 Note。我把它们和后来遇到的第三个一起列清楚，避免混为一谈：

核对是否已实施，直接走事务码 SNOTE，在 Note 浏览器里输入编号查询，状态会显示是否已实施。我这套 ECC6.4 上 808326 和 908442 都已实施，所以当预览仍然重叠时，说明问题不在补丁层面，必须往下钻到程序里。这个判断很关键——如果没有先做这一步核对，很可能在打补丁上白耗一两天，最后还是要回到代码。

3. 定位并修改：从 SSFRT_SET_LANGUAGES 的入参下手

基线核对完，确认补丁不是瓶颈，接下来就是 Debug。目标是回答一个问题：%header-langu到底被赋成了什么。这一步不要急着改代码，先看清楚现状，否则很容易改了一个地方、另一个地方又把它盖回去。

3.1 在生成的 Function Module 里找到那段被忽略的赋值

Smart Forms 保存激活后会生成一个 Function Module，名字形如/1BCDWB/SF00000123。拿名字有两条路：事务码 SMARTFORMS 进去后看"环境 → 功能模块名称"，或者直接在 SE37 里按SF00000*搜。打开后往下翻，通常 350 行以后，能看到这样一段：

" 这一段由 Smart Forms 生成器写入，负责决定表单的渲染语言 call function 'SSFRT_SET_LANGUAGES' exporting i_control_parameters = control_parameters " 外层传进来的打印控制参数 i_masterlanguage = '1' " 主语言，固定为中文 i_thrulang = ' ' " 直达语言，空表示不指定 i_install_lang = ' ' " 安装语言，空表示不指定 importing o_languages = %languages. " 系统实际可用的语言集合 %header-langu = %languages-langu1. " 关键：最终生效的打印语言

这段代码的逻辑说明：SSFRT_SET_LANGUAGES会根据你传进去的控制参数和系统里已安装的语言，算出一组可用语言，装进%languages。然后取%languages-langu1赋给%header-langu，这个值就是"这张表单按哪个语言版本渲染"的最终答案。

参数说明，逐个对照：i_control_parameters是最关键的输入，它就是外层传进来的control_parameters；i_masterlanguage是主语言，写死'1'；i_thrulang和i_install_lang留空即可，除非你的系统有多语言直达需求。真正决定结果的是第一个参数里的langu字段。

而这个 Function Module 对langu的取值逻辑，本质上就一句话：control_parameters是初始值就用sy-langu，非初始值就用control_parameters-langu。我 Debug 进去时，control_parameters-langu是空的，于是%header-langu直接等于sy-langu。英文登录环境下就是'E'，系统找不到英文版表单，把中文版当英文版渲染，中文字符宽度算错，重叠就这么来的。

3.2 在调用侧给 control_parameters-langu 赋值

知道根因之后改法很直接：在调用生成的 Function Module 之前，把control_parameters-langu显式赋成'1'。注意是改调用方，不是改生成器写出来的那段代码。

data: control_parameters type ssfctrlop, ls_output type ssfcrescl, lv_fm type rs38l_fnam, lv_formname type tdsfname value 'ZSF_INVOICE_CN'. " 1) 用表单名换出生成的 Function Module 名 call function 'SSF_FUNCTION_MODULE_NAME' exporting formname = lv_formname importing fm_name = lv_fm exceptions no_form = 1 no_function_module = 2 others = 3. " 2) 关键一步：把打印语言版本固定为中文，绕开 sy-langu 回退 control_parameters-langu = '1'. control_parameters-preview = 'X'. " 测试阶段走预览，不真打纸 control_parameters-no_dialog = 'X'. " 后台跑的时候不弹框 control_parameters-getotf = 'X'. " 需要比对字符间距时把 OTF 拿回来 " 3) 带着控制参数调用表单对应的 FM call function lv_fm exporting control_parameters = control_parameters importing output_options = ls_output exceptions formatting_error = 1 internal_error = 2 send_error = 3 user_canceled = 4 others = 5. if sy-subrc <> 0. " 打印失败时把返回码打出来，别静默吞掉 message id sy-msgid type sy-msgty number sy-msgno with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. endif.

代码逻辑说明：第一步只是把表单名翻译成 Function Module 名，不涉及打印；第二步才是重点，langu = '1'在这里赋值后，Function Module 内部判断control_parameters非初始，就不会再退回sy-langu；第三步执行真正的渲染。三个'X'是测试期配置，上线前把preview去掉，no_dialog按业务场景决定。

参数说明：lv_formname换成你自己的表单名；ls_output是返回结构，里面能拿到 OTF 表和任务输出信息；异常里的formatting_error多半是模板里字段绑定有问题，send_error才是输出设备层面的问题，两者别混。

改完这个之后，我那几张单据在英文环境下的重叠问题就消失了，预览和落纸都跟着正常。

3.3 直接改生成 FM 的做法与它的代价

有人图快，直接在生成的 Function Module 里把%header-langu硬赋成'1'，一行搞定，测试立刻通过。这个做法我试过，也确实管用，但代价很大：Smart Forms 只要在 SMARTFORMS 里重新激活一次，生成器就会重写整个 Function Module，你手改的那行被覆盖得干干净净。我当时改完忘了这茬，两周后业务改了个文本元素，重新激活，问题原地复活，排查时间又得重来一遍。

常见做法是只在调用侧改，生成器产出的一切当只读资产。如果确实需要在生成代码里插逻辑，可以考虑用隐式增强点，但 Smart Forms 生成的 FM 对增强点的支持并不友好，稳妥的路子还是外层传参。

顺带一提，改完之后别只测自己那一个入口。同一个表单可能被多个程序调用，比如前台手工触发、后台批量作业、接口服务各一套，逐个搜SSF_FUNCTION_MODULE_NAME的调用点，确认都补上了langu，否则就会出现"手工打正常、夜里跑批错位"这种玄学现象。

3.4 SAPscript 的对应改法：OPEN_FORM 里的 language

同一套系统里往往既有 Smart Forms 也有 SAPscript，后者也会遇到重叠。SAPscript 走的是OPEN_FORM，对应参数叫language，逻辑和SSFCTRLOP-LANGU一致：不传就吃sy-langu，传了就按你给的版本走。

call function 'OPEN_FORM' exporting form = 'ZSCRIPT_INVOICE' " SAPscript 表单名 language = '1' " 与 SSFCTRLOP-LANGU 等价，固定中文版本 device = 'PRINTER' " 输出设备 exceptions canceled = 1 device = 2 form = 3 options = 4 unclosed = 5 others = 6.

language这个参数在不少老代码里是空的，因为开发环境基本都是中文登录，测不出来，一旦切到英文登录环境的用户手上就爆。排查 SAPscript 时，第一件事就是在这个调用里把language补上，成本极低，收益直接。参数含义上，form是表单名，device是设备，language单字符，和 Smart Forms 那套完全对齐，改一处就能两头一致。

4. 31 字符压缩：另一个必须打 Note 1007575 的坑

语言问题解决之后，我按惯例做了一轮长文本回归，结果又翻车：文本超过一定长度时不再重叠，而是整个压缩在一起，字间距变得极窄，肉眼几乎糊成一团。这个问题和重叠不是同一个根因，但在同一批单据上经常一起暴露，值得单拎出来说。

4.1 复现这个边界：为什么偏偏是 31 个字符

复现方式很机械：造三条测试数据，长度分别是 30、31、32 个中文字符，全部塞进同一个表格单元格，走预览。30 和 31 正常，32 开始压缩——说明这是一个硬边界，不是渲染随机抖动。查到 Note 1007575，症状描述里写得很明确：表格行空间足够显示内容，但文本超过 31 字符时被系统压缩。

为什么是 31，从 Note 的描述看，这是内部缓冲或字段长度计算的一个固定界限，不是按可视宽度动态算的。所以不要试图通过调整输出设备、换字体、改窗口宽度的方式绕过它，那都是在错误的方向上花时间。判断是否命中这个坑，最快的办法是固定数据长度做二分：先造 40 字符看是否压缩，再往下降到 31/32 卡边界，一次就能确认。

我当时的处理是申请打上这个 Note。打之前有几点要注意：先用 SNOTE 查这个 Note 的前置条件，看是否依赖其他 Note 或特定支持包级别；再看对象冲突，SNOTE 会自动比对系统里现有对象的版本，冲突时不要硬覆盖，用调整功能逐段合。整个流程走 DEV → QAS → PRD，别在生产上直接动。

4.2 打完 Note 之后必须重测的几件事

打完 Note 不等于结束，我一般会强制重测四件事。第一，31/32 边界重跑一遍，确认压缩消失、且 31 字符以内没有出现新的换行异常。第二，超长文本（比如 80 字符以上）的换行位置是否合理，有没有出现半截字被切到下一行。第三，中文、英文、数字混排的单元格，因为这三类字符宽度不同，最容易在边界上出问题。第四，真实打印一张，别只看预览。

这里有个我踩过的坑：Note 解决的是"超过 31 字符被压缩"，但如果你的模板里单元格宽度本身就不够，超长文本仍然会溢出到相邻列，看起来像"又压缩了"，其实是模板层面的布局问题。区分方法很简单，把文本砍到 20 字符再预览，如果位置正常，那就是模板宽度问题，回去调窗口和表格列宽，别再怀疑 Note。

5. 避坑与排查：五条踩过的记录

这一节全是我自己踩出来的，按"现象 → 原因 → 解决"记，遇到类似症状可以直接对号入座。

第一条：Note 打了，预览照样重叠。现象是 SNOTE 里 808326 和 908442 都显示已实施，但英文环境下中文依旧叠在一起。原因是这两个 Note 修的是系统级渲染，管不到"你传了什么语言版本进去"。解决是 Debug 进生成的 FM，在SSFRT_SET_LANGUAGES调用之后看%header-langu的值，如果是'E'，就回到调用侧补control_parameters-langu = '1'。这一步比翻 Note 高效得多。

第二条：改完测好了，过几天又复发。现象是明明改过、也验证过，业务反馈问题重现。原因是直接改了生成的 Function Module，业务改文本元素后重新激活表单，生成器把整个 FM 重写，手改内容被覆盖。解决是所有改动只落在调用侧，生成器产物视为只读；已经改过生成 FM 的，去 SMARTFORMS 里重新激活一次把这个坏习惯清掉，再按调用侧方案补。

第三条：英文环境编辑表单，中文变乱码。现象是在E登录环境下打开 Smart Forms 改中文描述，保存激活后英文环境打印出来是乱码。原因是在非中文语言环境下编辑和保存中文文本，编码处理上出了问题，具体成因我到现在也没完全挖透。解决是中文表单只在'1'环境下编辑激活；如果已经乱了，回到中文环境逐个文本节点重敲一遍，别指望改个参数自动恢复。

第四条：预览正常，落纸错位。现象是打印预览里排版漂亮，真打出来文字跑到框外或者跟下一行交杂。原因是预览通道和实际输出设备的可用宽度、字体度量不完全一致。解决是测试阶段必须真机出纸，至少打一张 A4 和一张针式纸（如果业务在用）；同时在SSFCTRLOP里显式指定DEVICE，别让它走系统默认，默认设备在多人共用环境下经常被改得面目全非。

第五条：Note 1007575 打完了，长文本还是挤在一起。现象是超过 31 字符的文本仍然压缩。原因是模板单元格宽度不足，或者是数据本身带了不可见字符导致长度计算异常。解决是先砍到 20 字符测布局，布局正常就说明是宽度问题，回去调表格列宽和窗口；布局仍异常就用GETOTF把 OTF 抓出来看实际字符流，确认有没有混进特殊字符。

6. 验证跑通：四组预览对照和一次断点

改完之后我不看"能不能打出来"，只看四组对照能不能全部对上。这套验证方法后来成了我交付任何打印类需求的固定动作，因为它能把"某个人某台机器上正常"和"真的没问题"区分开。

四组都过，才算这一轮收工。任何一组不过，就按第 5 章的排查顺序往下走，不要跳步。

除了对照，我还会做一次断点确认，因为预览结果有时候会骗人。在调用生成的 Function Module 之前打一个外部断点，看control_parameters-langu是不是'1'；再在 FM 里SSFRT_SET_LANGUAGES调用之后打一个，看%header-langu是不是也变成了'1'。两个值对上了，链路才算真的通。如果第一个是'1'第二个还是'E'，说明有别的地方在中途覆盖，往上追调用栈。

需要批量回归的话，可以写个小报表把四组数据一次跑完，避免手工切用户切到崩溃：

report zsf_print_check. parameters: p_form type tdsfname default 'ZSF_INVOICE_CN', p_lang type ssfctrlop-langu default 'E'. " 手动指定语言版本 data: ls_ctrl type ssfctrlop, ls_out type ssfcrescl, lv_fm type rs38l_fnam, lv_text type string. " 造一条 32 字符的中文测试数据，卡 Note 1007575 的边界 lv_text = '中文打印边界测试数据中文打印边界测试数据中文打印边界测试数据中文打'. call function 'SSF_FUNCTION_MODULE_NAME' exporting formname = p_form importing fm_name = lv_fm. ls_ctrl-langu = p_lang. " 关键：由参数控制，方便切 E / 1 对照 ls_ctrl-preview = 'X'. ls_ctrl-no_dialog = 'X'. ls_ctrl-getotf = 'X'. call function lv_fm exporting control_parameters = ls_ctrl importing output_options = ls_out exceptions others = 1. " OTF 表行数可以粗略反映换行情况，配合预览一起看 write: / 'OTF lines:', lines( ls_out-otf ).

这个报表的价值在于把"切登录用户"变成"切参数"，一次登录就能跑完 A、B 两组，p_lang分别填'1'和'E'各跑一次，比对 OTF 行数和预览排版。lines( ls_out-otf )只是个粗指标，行数一致不代表排版一致，最终还是得看预览。

从那以后，我每次上线 Smart Forms 相关的改动，都强制走一遍"两个登录语言 + 31/32 字符边界 + 真机出纸"这套四组验证再交付，不管改动看起来多小。踩过的坑记在本子上，比记在脑子里靠谱。希望帮到你。

本文还有配套的精品资源，点击获取