简介针对 SAP Smart Forms 在英文登录环境下中文内容显示重叠的实战排错文档面向需要处理报表打印异常、Unicode 打印预览问题的 SAP 开发与运维人员。文档从现象切入说明登录语言为 E 时中文业务数据在打印预览中被挤压重叠、超长字符与相邻内容交杂的成因并给出在 Smart Forms 对应 FM 中为 control_parameters-langu 赋值 1 再传参的修复思路同时梳理 FM SSFRT_SET_LANGUAGES 的赋值逻辑以及 Note 808326、908442、1007575 与 Unicode 打印预览异常、亚洲字符超过 31 字符被压缩等情况的对应关系。压缩包内共 1 个 doc 文件约 28KB篇幅短小但排查链路完整可作为语言版本类打印问题的速查参考。已有 1088 人学习下载适合初具 ABAP 基础、希望快速定位此类异常的技术人员。1. 中文字体重叠不是字体的问题是语言版本没有锁定在英文环境login language 为 E下预览一张带中文的 Smart Forms中文挤成一团黑块超出预留宽度的部分上了纸又突然展开和后面的字段缠在一起——这是 SMART 中文字体重叠最常见的现场。多数人的第一反应是字体、编码、Unicode 渲染的锅SPAD 里的字符集翻了个遍问题照旧。真正的开关藏在生成的功能模块里打印时到底取哪个语言版本的表单由%header-langu决定而它的值从control_parameters的初值状态推出来十有八九直接退化成sy-langu。这篇写给正在英文环境下做中文报表打印、被预览和上纸效果不一致折腾过的 ABAP 从业者。从现象拆解到SSFRT_SET_LANGUAGES的赋值链再到调用方的改法和补丁核对一条线走完最后把几个真踩过的坑摊开讲。2. %header-langu 的取值链重叠是从哪一行开始算错的2.1 预览挤成一团、上纸又散开其实是同一根链条上的两个表现先把现象描述准确因为不同的现象指向不同的排查方向。在 E 环境下打开一张已经做好的中文 Smart Forms业务数据...取出来的字段里含中文时打印预览里中文是重叠渲染的如果字符长度超过窗口预留的宽度预览里仍然挤在同一行。但真正打印到纸上重叠的部分会散开与后面窗口的内容交杂在一起——看起来像是排版被撑爆了实际上上纸时用的行宽是另一套。而在中文环境login language 为 1里打印同一张表单中文不会重叠超出预留宽度会自动换行该缩进缩进该截断截断。同一份表单、同一份数据、同一个打印设备唯一变量就是登录语言。这个对照非常值钱它直接排除了字体文件缺失、打印机驱动、纸张尺寸这类外部因素把问题锁死在表单取到的语言版本上。道理不复杂。中文版表单在设计时窗口宽度、段落缩进、换行策略是按中文字符的宽度算的系统在 E 环境下拿到这张表单时如果按单字节字符的宽度去估算可用行宽算出来的可用空间比实际需要的大于是把本该换行的中文全部塞进同一行。预览阶段按这套错误宽度计算就有了重叠上纸阶段打印机驱动按自己的字宽再渲染一次就变成散开交错。提示遇到这类问题先做语言环境对照实验。切一个 login language 为 1 的会话打印同样内容如果表现正常就别再往字体和驱动上查了。2.2 SSFRT_SET_LANGUAGES 的初值判断藏着两个陷阱定位到这一步下一步是去表单生成的 FM 里看语言是怎么定下来的。Smart Forms 激活后会生成一个功能模块名字形如/1BCDWB/SF00xxxxxx在这个 FM 里往下翻一般 350 行以后能见到这样一段 生成代码片段决定本次打印用哪个语言版本的表单 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.%header-langu就是开关它决定系统去取哪个语言版本的表单布局。而这个值的来源是SSFRT_SET_LANGUAGES内部对o_languages-langu1的赋值逻辑可以概括成一句话control_parameters is initial ? sy-langu : control_parameters-langu看清楚了这里有两个容易翻车的点。第一个是control_parameters用的是整结构判断IS INITIAL不是单看langu字段。ABAP 里对结构体做IS INITIAL是逐字段比较全部为初值才返回真。只要调用方给这个结构任何一个字段赋了值——比如device、copies、no_dialog——整个结构就不再是初值系统转头去取control_parameters-langu而这个字段恰好是空的于是%header-langu变成空值。空值往下走取表单版本的逻辑就退化成默认行为重叠问题照样出现。第二个是sy-langu的取值。E 环境登录sy-langu就是E。系统据此认为你要一份 E 版表单。可现实是绝大多数中文项目里根本没有单独做 E 版表单中文版就是唯一版本。系统找不到 E 版又不报错而是借用中文版内容、套上 E 版的处理规则重叠就在这一步埋下了。把这两个变量和它们的典型取值摆在一起看链条就清楚了变量来源典型取值对结果的影响control_parameters调用方传入常为 initial或部分字段有值决定走向哪条分支sy-langu当前会话登录语言E 或 1初值分支下直接决定语言版本%languages-langu1SSFRT_SET_LANGUAGES返回由上面两者推出赋给%header-langu%header-langu生成代码中的控制变量最终语言版本标识决定取哪套表单布局注意control_parameters的类型是SSFCTRLOP。赋值前先确认字段名LANGU是其中一个字段类型对应SY-LANGU的域内部长度一个字符。2.3 没有对应语言版本时系统会默认借用中文版这里需要把借用这个动作讲透否则容易误判。系统在确定%header-langu之后会按这个语言标识去找表单的文本资源和布局资源。找不到对应语言的版本时惯常的处理是回退——用现有版本的内容顶上但处理规则仍按请求的语言走。这就解释了为什么中文的内容在 E 环境下能被打印出来只是排版乱了内容没丢规则错了。这也解释了另一个新手常问的现象在英文环境里编辑 Smart Forms中文描述先变成一堆问号或者乱码。因为编辑期的文本存储也依赖语言标识在 E 环境下录入的中文文本被当作非当前语言的字符处理。常见做法是切到中文环境再编辑表单文本编辑完再切回去别在 E 环境里硬敲中文描述。至于乱码的确切成因我手上没有能复现到字符集层面的证据就不硬编解释了只把它当成一条操作习惯中文内容在中文环境里录入。想快速判断自己的表单是不是踩在这条链上有个不走弯路的方法在 FM 里SSFRT_SET_LANGUAGES调用之后打断点跑一次打印看control_parameters是不是初值、%header-langu拿到的是什么。这一个断点能省掉半天翻 Notes 的时间。3. 把 langu 固定在调用方三处代码改法与验证手段3.1 找到表单生成的 FM定位那段 call function第一步是拿到 FM 名字。不要凭记忆猜走事务码SMARTFORMS打开目标表单菜单里找环境 → 功能模块 → 显示系统会直接跳到这个表单对应的生成 FM。或者用SE37输入前缀/1BCDWB/SF加模糊搜索一次能列出系统里所有表单生成的模块按创建时间排一下也能找到。名字里的编号没有规律可循别照抄示例里的占位。进去以后用CtrlF搜SSFRT_SET_LANGUAGES一次命中上下文一般就是前面贴的那二十来行。这里要看的只有三件事i_masterlanguage传的是什么、control_parameters在调用前有没有被赋值、%header-langu赋给了谁。顺带说一句这个 FM 是系统生成的。在SMARTFORMS里重新激活一次表单整个 FM 会被重新生成覆盖。所以在这个 FM 里改代码是白改下次激活全部丢失。这一点和不少人的直觉相反——看到代码里少了一行赋值就顺手补上测试通过了过两天改个窗口宽度重新激活问题原地复活人直接懵。3.2 在调用方赋值而不是改生成代码正确的改法在调用方在CALL FUNCTION之前把control_parameters-langu显式赋成中文语言标识然后整个结构传进去。这样生成代码里的IS INITIAL判定必然为假走control_parameters-langu分支拿到你指定的值%header-langu才有确定的结果。 调用方打印前把语言版本固定成中文 DATA: ls_ctrl TYPE ssfctrlop, ls_output TYPE ssfcrescl. ls_ctrl-langu 1. 关键中文语言标识显式赋值别依赖默认 ls_ctrl-device PRINTER. 输出设备 ls_ctrl-no_dialog X. 后台静默打印需要弹对话框时去掉这一行 ls_ctrl-preview . 需要预览时才置 X CALL FUNCTION /1BCDWB/SF00xxxxxx 占位实际名字以 SMARTFORMS 环境菜单显示为准 EXPORTING control_parameters ls_ctrl 整结构传入非初值且 LANGU 有值 user_settings IMPORTING job_output_info ls_output EXCEPTIONS formatting_error 1 internal_error 2 send_error 3 user_canceled 4 OTHERS 5. IF sy-subrc 0. 按错误码分别落日志别用一个通用消息糊过去 ENDIF.几个参数的实际影响langu是这次修复的核心写1比写裸数字1更稳虽然隐式转换也能过但类型对应关系在代码审查时一眼能看懂device决定输出到打印机还是屏幕no_dialog X在后台作业里必须加否则会卡在对话框上preview只在需要预览时置X正式打印时关掉能省一次渲染。job_output_info拿回来的是输出信息结构做归档或者二次分发时用得上。如果一张表单会被多个程序调用别在每个程序里各写一遍赋值包一个小函数把这几个字段的默认值兜住调用方只传业务参数。这样以后改语言策略只动一处不会漏掉某个调用点——漏掉的那个往往就是上线后第一个被投诉的。3.3 用断点和 spool 双重复核改完之后不能只看预览。预览走的是屏幕渲染路径正式打印走的是输出控制路径两者对行宽的处理不完全一致3.2 里那个预览正常上纸错位的坑就是这么来的。第一层复核用断点。在生成 FM 里%header-langu赋值那一行打断点跑一次打印检查三件事control_parameters不再是初值、%header-langu等于1、%languages-langu1有正常返回。三个条件缺一个说明赋值没传到位别急着往下测。第二层复核看 spool。正式打印一次用SP01打开输出请求进预览、查看内容重点检查三处超出预留宽度的中文有没有按预期换行、字段之间有没有交杂、末尾有没有被截断。再对照一下打印出来的纸质件确认纸面和 spool 预览一致。第三层是回归。把调用这个表单的所有入口都跑一遍——前台单独打印、批量打印、后台作业。前台正常后台出问题通常是no_dialog没设对单条正常批量出问题通常是循环里control_parameters结构被复用没清空前一条的语言值串到了后一条。提示SSFCTRLOP结构在循环里重复使用时记得每次进循环先CLEAR再赋值。结构复用导致字段串值这类问题出现概率比想象中高。4. 超过 31 字符被压缩Note 1007575 与补丁核对法4.1 为什么偏偏卡在 31 个字符语言版本锁死之后预览里的重叠消失了但另一类现象开始露头某一行表格单元格里内容只要超过一定长度就被压缩在一起字距挤得明显不正常长度短的时候完全正常。这个阈值很好测从 31 个字符开始往上试32、33 都一样被压。这个现象指向另一个独立的原因。两个 Notes 已经打过不等于全部打完808326和908442解决的是 Unicode 系统下打印预览的文本格式化和亚洲文本重叠问题和 31 字符压缩并不是同一个补丁。压缩这一类问题对应的是1007575症状描述很直接在 Unicode 系统里显示亚洲 Smart Forms 时一行表格明明有足够空间显示内容但系统会把超过 31 个字符的文本压缩。这个明明有空间却压的描述和现场完全对得上值得先按它去核对。从机制上讲亚洲字符在渲染时按双倍宽度计算占位而单元格可用宽度是按字符个数换算出来的。两套计量方式不一致时超过某个整数阈值之后系统选择把内容压缩塞进同一行而不是换行或截断。31 这个数字跟字符宽度换算的取整方式有关不必深究到小数点记住触发条件就够了。4.2 打补丁前先核对已有 Note 的代码状态这里有个真实的坑看到两个相关 Note 就以为已经解决了结果根本没打全。核对顺序建议按下面这张表走别跳步。核对项怎么查判断标准Note 808326 是否已应用系统里查 Note 应用状态或对比修正说明里的代码行对应代码行已存在且版本一致Note 908442 是否已应用同上同上Note 1007575 是否已应用同上同上系统版本与 Note 适用版本查 Note 的适用组件与版本区间落在区间内才可打打补丁后的传输请求确认修正代码已进传输队列生产环境同步到位前三个是技术层面的后两个才是最容易出事的。经常出现的场景是开发机打上了测试机忘了传生产机是三个月前的镜像。查的时候一定要查出问题的那个环境而不是记忆里我上次打过了的那台机器。修正说明里的代码要逐行对照不是看到函数名对上了就算打完——同一段逻辑在不同版本里可能已经改写过。注意打 Note 前先确认适用的组件版本区间。版本不匹配硬打轻则无效重则引入新的渲染问题排查成本比原问题还高。4.3 补完后的两轮回归补丁打完之后要跑两轮缺一不可。第一轮测边界长度。准备一组测试数据中文长度分别取 28、30、31、32、35、40、60 个字符全部走同一个单元格检查 31 及以下是否正常渲染、32 以上是否不再压缩、超长部分是否按预期换行或截断。边界值附近最容易出问题别只测一个很长的字符串就收工。第二轮测组合场景。语言版本锁定和 31 字符压缩是两件独立的事任何一个没解决都会让另一个的表现被掩盖。组合起来至少覆盖四种E 环境下带中文的中长文本、E 环境下带中文的超长文本、中文环境下的同样两组。四组全过才算这两件事都收干净了。顺带把 SAPscript 的对照也记一下。SAPscript 走的是OPEN_FORM它自己带language参数作用和 Smart Forms 里的control_parameters-langu是一回事——都是限制表单的语言版本。项目里如果两种表单并存改的时候要一起改只改一边另一边照样在 E 环境下出问题而且因为现象相同很容易被当成没修好。5. 避坑清单五条从预览到上纸的翻车记录5.1 三条赋值相关的坑现象一改了生成 FM 里的代码测试通过一周后问题复现。原因是在SMARTFORMS里重新激活表单时生成 FM 被整体重新生成手改的代码全部被覆盖control_parameters-langu的赋值又回到了没有的状态。 解决办法是把赋值挪到调用方生成 FM 只读不改。如果确实需要在生成代码层面观察用断点别用改代码的方式验证。现象二调用方明明赋了langu%header-langu还是不对。原因常见于三种赋值写在CALL FUNCTION之后顺序错了赋值赋给了另一个局部结构传参时用的还是原来的空结构结构在循环里复用CLEAR漏了前一条的值串到了后一条。 解决办法是每次调用前重新构造control_parameters赋值紧挨着CALL FUNCTION写中间不插其他逻辑。代码审查时专门看这一段这是最容易出低级错的地方。现象三只给control_parameters赋了device没赋langu觉得结构不是空的就行。原因是没意识到IS INITIAL是整结构判断。结构非空只说明不走sy-langu分支走的是control_parameters-langu分支而那个字段是空的结果比初值分支还糟。 解决办法是把langu当成必填项和device一样对待缺了就不允许往下走。写个小校验为空直接抛异常比事后查半天强。5.2 两条补丁与测试相关的坑现象四两个相关的 Note 都打过了压缩问题一点没改善。原因是这两个 Note 解决的是 Unicode 打印预览的文本格式化和亚洲文本重叠和 31 字符压缩不是同一个问题。压缩对应的是另一个 Note症状描述里明确写了超过 31 个字符被压缩。 解决办法是按症状描述去匹配 Note而不是按看起来相关去挑。匹配到之后逐行核对修正说明里的代码确认在当前系统版本上确实生效而不是只看状态标记。现象五预览看着完全正常打印出来还是交错。原因是预览和正式打印走的是两条渲染路径预览通过不代表输出控制路径也通过。测试只在屏幕上看了预览没走SP01看 spool也没看纸质件。 解决办法是固定三段验证断点确认%header-langu、SP01看 spool 内容、纸质件对照。三段都过才算过缺一段都可能在客户端现场翻车。6. 上线前固定走一遍把语言版本检查做成动作折腾完这几轮我给自己定了个规矩凡是带中文的 Smart Forms上线前必须走一遍固定动作不凭记忆不靠上次好像没问题。具体就四步。第一步在调用方确认control_parameters-langu有显式赋值且赋值位置在CALL FUNCTION之前结构在循环里每次重建。第二步在生成 FM 里%header-langu赋值那一行打断点跑一次确认拿到的是1而不是空、不是E。第三步SP01打开输出请求看内容重点看超过 31 个字符的中文有没有被压缩、有没有和相邻字段交杂。第四步切到 E 环境和中文环境各打一次两个环境的输出结果做对比。这套动作可以整理成一张表贴在项目文档里谁接手谁照着走环节检查点不通过的典型表现调用方代码langu是否显式赋值、位置是否在调用前预览重叠%header-langu为空或 E生成 FM 断点%header-langu实际取值取到E或空spool 内容31 字符以上中文是否被压、是否交错字距异常、字段粘连双环境对照E 与 1 两次输出是否一致两种环境结果不同还有个习惯值得养把语言版本和长度阈值这两件事分开验证。我见过太多人把两个问题混在一起测改完语言以为压缩也好了结果上线才发现只解决了一半回头再走一遍流程时间成本翻倍。测试数据里专门准备一组 30 到 35 字符的中文串卡在阈值上下一眼就能看出来补丁到底生效没有。那次事故之后我每接一张新的中文表单都会先把langu那一行写死再谈排版。看起来是多余的一行代码省下的是打印室里反复试纸的那一下午。希望帮到你。本文还有配套的精品资源点击获取
简介针对 SAP Smart Forms 在英文登录环境下中文内容显示重叠的实战排错文档面向需要处理报表打印异常、Unicode 打印预览问题的 SAP 开发与运维人员。文档从现象切入说明登录语言为 E 时中文业务数据在打印预览中被挤压重叠、超长字符与相邻内容交杂的成因并给出在 Smart Forms 对应 FM 中为 control_parameters-langu 赋值 1 再传参的修复思路同时梳理 FM SSFRT_SET_LANGUAGES 的赋值逻辑以及 Note 808326、908442、1007575 与 Unicode 打印预览异常、亚洲字符超过 31 字符被压缩等情况的对应关系。压缩包内共 1 个 doc 文件约 28KB篇幅短小但排查链路完整可作为语言版本类打印问题的速查参考。已有 1088 人学习下载适合初具 ABAP 基础、希望快速定位此类异常的技术人员。1. 中文字体重叠不是字体的问题是语言版本没有锁定在英文环境login language 为 E下预览一张带中文的 Smart Forms中文挤成一团黑块超出预留宽度的部分上了纸又突然展开和后面的字段缠在一起——这是 SMART 中文字体重叠最常见的现场。多数人的第一反应是字体、编码、Unicode 渲染的锅SPAD 里的字符集翻了个遍问题照旧。真正的开关藏在生成的功能模块里打印时到底取哪个语言版本的表单由%header-langu决定而它的值从control_parameters的初值状态推出来十有八九直接退化成sy-langu。这篇写给正在英文环境下做中文报表打印、被预览和上纸效果不一致折腾过的 ABAP 从业者。从现象拆解到SSFRT_SET_LANGUAGES的赋值链再到调用方的改法和补丁核对一条线走完最后把几个真踩过的坑摊开讲。2. %header-langu 的取值链重叠是从哪一行开始算错的2.1 预览挤成一团、上纸又散开其实是同一根链条上的两个表现先把现象描述准确因为不同的现象指向不同的排查方向。在 E 环境下打开一张已经做好的中文 Smart Forms业务数据...取出来的字段里含中文时打印预览里中文是重叠渲染的如果字符长度超过窗口预留的宽度预览里仍然挤在同一行。但真正打印到纸上重叠的部分会散开与后面窗口的内容交杂在一起——看起来像是排版被撑爆了实际上上纸时用的行宽是另一套。而在中文环境login language 为 1里打印同一张表单中文不会重叠超出预留宽度会自动换行该缩进缩进该截断截断。同一份表单、同一份数据、同一个打印设备唯一变量就是登录语言。这个对照非常值钱它直接排除了字体文件缺失、打印机驱动、纸张尺寸这类外部因素把问题锁死在表单取到的语言版本上。道理不复杂。中文版表单在设计时窗口宽度、段落缩进、换行策略是按中文字符的宽度算的系统在 E 环境下拿到这张表单时如果按单字节字符的宽度去估算可用行宽算出来的可用空间比实际需要的大于是把本该换行的中文全部塞进同一行。预览阶段按这套错误宽度计算就有了重叠上纸阶段打印机驱动按自己的字宽再渲染一次就变成散开交错。提示遇到这类问题先做语言环境对照实验。切一个 login language 为 1 的会话打印同样内容如果表现正常就别再往字体和驱动上查了。2.2 SSFRT_SET_LANGUAGES 的初值判断藏着两个陷阱定位到这一步下一步是去表单生成的 FM 里看语言是怎么定下来的。Smart Forms 激活后会生成一个功能模块名字形如/1BCDWB/SF00xxxxxx在这个 FM 里往下翻一般 350 行以后能见到这样一段 生成代码片段决定本次打印用哪个语言版本的表单 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.%header-langu就是开关它决定系统去取哪个语言版本的表单布局。而这个值的来源是SSFRT_SET_LANGUAGES内部对o_languages-langu1的赋值逻辑可以概括成一句话control_parameters is initial ? sy-langu : control_parameters-langu看清楚了这里有两个容易翻车的点。第一个是control_parameters用的是整结构判断IS INITIAL不是单看langu字段。ABAP 里对结构体做IS INITIAL是逐字段比较全部为初值才返回真。只要调用方给这个结构任何一个字段赋了值——比如device、copies、no_dialog——整个结构就不再是初值系统转头去取control_parameters-langu而这个字段恰好是空的于是%header-langu变成空值。空值往下走取表单版本的逻辑就退化成默认行为重叠问题照样出现。第二个是sy-langu的取值。E 环境登录sy-langu就是E。系统据此认为你要一份 E 版表单。可现实是绝大多数中文项目里根本没有单独做 E 版表单中文版就是唯一版本。系统找不到 E 版又不报错而是借用中文版内容、套上 E 版的处理规则重叠就在这一步埋下了。把这两个变量和它们的典型取值摆在一起看链条就清楚了变量来源典型取值对结果的影响control_parameters调用方传入常为 initial或部分字段有值决定走向哪条分支sy-langu当前会话登录语言E 或 1初值分支下直接决定语言版本%languages-langu1SSFRT_SET_LANGUAGES返回由上面两者推出赋给%header-langu%header-langu生成代码中的控制变量最终语言版本标识决定取哪套表单布局注意control_parameters的类型是SSFCTRLOP。赋值前先确认字段名LANGU是其中一个字段类型对应SY-LANGU的域内部长度一个字符。2.3 没有对应语言版本时系统会默认借用中文版这里需要把借用这个动作讲透否则容易误判。系统在确定%header-langu之后会按这个语言标识去找表单的文本资源和布局资源。找不到对应语言的版本时惯常的处理是回退——用现有版本的内容顶上但处理规则仍按请求的语言走。这就解释了为什么中文的内容在 E 环境下能被打印出来只是排版乱了内容没丢规则错了。这也解释了另一个新手常问的现象在英文环境里编辑 Smart Forms中文描述先变成一堆问号或者乱码。因为编辑期的文本存储也依赖语言标识在 E 环境下录入的中文文本被当作非当前语言的字符处理。常见做法是切到中文环境再编辑表单文本编辑完再切回去别在 E 环境里硬敲中文描述。至于乱码的确切成因我手上没有能复现到字符集层面的证据就不硬编解释了只把它当成一条操作习惯中文内容在中文环境里录入。想快速判断自己的表单是不是踩在这条链上有个不走弯路的方法在 FM 里SSFRT_SET_LANGUAGES调用之后打断点跑一次打印看control_parameters是不是初值、%header-langu拿到的是什么。这一个断点能省掉半天翻 Notes 的时间。3. 把 langu 固定在调用方三处代码改法与验证手段3.1 找到表单生成的 FM定位那段 call function第一步是拿到 FM 名字。不要凭记忆猜走事务码SMARTFORMS打开目标表单菜单里找环境 → 功能模块 → 显示系统会直接跳到这个表单对应的生成 FM。或者用SE37输入前缀/1BCDWB/SF加模糊搜索一次能列出系统里所有表单生成的模块按创建时间排一下也能找到。名字里的编号没有规律可循别照抄示例里的占位。进去以后用CtrlF搜SSFRT_SET_LANGUAGES一次命中上下文一般就是前面贴的那二十来行。这里要看的只有三件事i_masterlanguage传的是什么、control_parameters在调用前有没有被赋值、%header-langu赋给了谁。顺带说一句这个 FM 是系统生成的。在SMARTFORMS里重新激活一次表单整个 FM 会被重新生成覆盖。所以在这个 FM 里改代码是白改下次激活全部丢失。这一点和不少人的直觉相反——看到代码里少了一行赋值就顺手补上测试通过了过两天改个窗口宽度重新激活问题原地复活人直接懵。3.2 在调用方赋值而不是改生成代码正确的改法在调用方在CALL FUNCTION之前把control_parameters-langu显式赋成中文语言标识然后整个结构传进去。这样生成代码里的IS INITIAL判定必然为假走control_parameters-langu分支拿到你指定的值%header-langu才有确定的结果。 调用方打印前把语言版本固定成中文 DATA: ls_ctrl TYPE ssfctrlop, ls_output TYPE ssfcrescl. ls_ctrl-langu 1. 关键中文语言标识显式赋值别依赖默认 ls_ctrl-device PRINTER. 输出设备 ls_ctrl-no_dialog X. 后台静默打印需要弹对话框时去掉这一行 ls_ctrl-preview . 需要预览时才置 X CALL FUNCTION /1BCDWB/SF00xxxxxx 占位实际名字以 SMARTFORMS 环境菜单显示为准 EXPORTING control_parameters ls_ctrl 整结构传入非初值且 LANGU 有值 user_settings IMPORTING job_output_info ls_output EXCEPTIONS formatting_error 1 internal_error 2 send_error 3 user_canceled 4 OTHERS 5. IF sy-subrc 0. 按错误码分别落日志别用一个通用消息糊过去 ENDIF.几个参数的实际影响langu是这次修复的核心写1比写裸数字1更稳虽然隐式转换也能过但类型对应关系在代码审查时一眼能看懂device决定输出到打印机还是屏幕no_dialog X在后台作业里必须加否则会卡在对话框上preview只在需要预览时置X正式打印时关掉能省一次渲染。job_output_info拿回来的是输出信息结构做归档或者二次分发时用得上。如果一张表单会被多个程序调用别在每个程序里各写一遍赋值包一个小函数把这几个字段的默认值兜住调用方只传业务参数。这样以后改语言策略只动一处不会漏掉某个调用点——漏掉的那个往往就是上线后第一个被投诉的。3.3 用断点和 spool 双重复核改完之后不能只看预览。预览走的是屏幕渲染路径正式打印走的是输出控制路径两者对行宽的处理不完全一致3.2 里那个预览正常上纸错位的坑就是这么来的。第一层复核用断点。在生成 FM 里%header-langu赋值那一行打断点跑一次打印检查三件事control_parameters不再是初值、%header-langu等于1、%languages-langu1有正常返回。三个条件缺一个说明赋值没传到位别急着往下测。第二层复核看 spool。正式打印一次用SP01打开输出请求进预览、查看内容重点检查三处超出预留宽度的中文有没有按预期换行、字段之间有没有交杂、末尾有没有被截断。再对照一下打印出来的纸质件确认纸面和 spool 预览一致。第三层是回归。把调用这个表单的所有入口都跑一遍——前台单独打印、批量打印、后台作业。前台正常后台出问题通常是no_dialog没设对单条正常批量出问题通常是循环里control_parameters结构被复用没清空前一条的语言值串到了后一条。提示SSFCTRLOP结构在循环里重复使用时记得每次进循环先CLEAR再赋值。结构复用导致字段串值这类问题出现概率比想象中高。4. 超过 31 字符被压缩Note 1007575 与补丁核对法4.1 为什么偏偏卡在 31 个字符语言版本锁死之后预览里的重叠消失了但另一类现象开始露头某一行表格单元格里内容只要超过一定长度就被压缩在一起字距挤得明显不正常长度短的时候完全正常。这个阈值很好测从 31 个字符开始往上试32、33 都一样被压。这个现象指向另一个独立的原因。两个 Notes 已经打过不等于全部打完808326和908442解决的是 Unicode 系统下打印预览的文本格式化和亚洲文本重叠问题和 31 字符压缩并不是同一个补丁。压缩这一类问题对应的是1007575症状描述很直接在 Unicode 系统里显示亚洲 Smart Forms 时一行表格明明有足够空间显示内容但系统会把超过 31 个字符的文本压缩。这个明明有空间却压的描述和现场完全对得上值得先按它去核对。从机制上讲亚洲字符在渲染时按双倍宽度计算占位而单元格可用宽度是按字符个数换算出来的。两套计量方式不一致时超过某个整数阈值之后系统选择把内容压缩塞进同一行而不是换行或截断。31 这个数字跟字符宽度换算的取整方式有关不必深究到小数点记住触发条件就够了。4.2 打补丁前先核对已有 Note 的代码状态这里有个真实的坑看到两个相关 Note 就以为已经解决了结果根本没打全。核对顺序建议按下面这张表走别跳步。核对项怎么查判断标准Note 808326 是否已应用系统里查 Note 应用状态或对比修正说明里的代码行对应代码行已存在且版本一致Note 908442 是否已应用同上同上Note 1007575 是否已应用同上同上系统版本与 Note 适用版本查 Note 的适用组件与版本区间落在区间内才可打打补丁后的传输请求确认修正代码已进传输队列生产环境同步到位前三个是技术层面的后两个才是最容易出事的。经常出现的场景是开发机打上了测试机忘了传生产机是三个月前的镜像。查的时候一定要查出问题的那个环境而不是记忆里我上次打过了的那台机器。修正说明里的代码要逐行对照不是看到函数名对上了就算打完——同一段逻辑在不同版本里可能已经改写过。注意打 Note 前先确认适用的组件版本区间。版本不匹配硬打轻则无效重则引入新的渲染问题排查成本比原问题还高。4.3 补完后的两轮回归补丁打完之后要跑两轮缺一不可。第一轮测边界长度。准备一组测试数据中文长度分别取 28、30、31、32、35、40、60 个字符全部走同一个单元格检查 31 及以下是否正常渲染、32 以上是否不再压缩、超长部分是否按预期换行或截断。边界值附近最容易出问题别只测一个很长的字符串就收工。第二轮测组合场景。语言版本锁定和 31 字符压缩是两件独立的事任何一个没解决都会让另一个的表现被掩盖。组合起来至少覆盖四种E 环境下带中文的中长文本、E 环境下带中文的超长文本、中文环境下的同样两组。四组全过才算这两件事都收干净了。顺带把 SAPscript 的对照也记一下。SAPscript 走的是OPEN_FORM它自己带language参数作用和 Smart Forms 里的control_parameters-langu是一回事——都是限制表单的语言版本。项目里如果两种表单并存改的时候要一起改只改一边另一边照样在 E 环境下出问题而且因为现象相同很容易被当成没修好。5. 避坑清单五条从预览到上纸的翻车记录5.1 三条赋值相关的坑现象一改了生成 FM 里的代码测试通过一周后问题复现。原因是在SMARTFORMS里重新激活表单时生成 FM 被整体重新生成手改的代码全部被覆盖control_parameters-langu的赋值又回到了没有的状态。 解决办法是把赋值挪到调用方生成 FM 只读不改。如果确实需要在生成代码层面观察用断点别用改代码的方式验证。现象二调用方明明赋了langu%header-langu还是不对。原因常见于三种赋值写在CALL FUNCTION之后顺序错了赋值赋给了另一个局部结构传参时用的还是原来的空结构结构在循环里复用CLEAR漏了前一条的值串到了后一条。 解决办法是每次调用前重新构造control_parameters赋值紧挨着CALL FUNCTION写中间不插其他逻辑。代码审查时专门看这一段这是最容易出低级错的地方。现象三只给control_parameters赋了device没赋langu觉得结构不是空的就行。原因是没意识到IS INITIAL是整结构判断。结构非空只说明不走sy-langu分支走的是control_parameters-langu分支而那个字段是空的结果比初值分支还糟。 解决办法是把langu当成必填项和device一样对待缺了就不允许往下走。写个小校验为空直接抛异常比事后查半天强。5.2 两条补丁与测试相关的坑现象四两个相关的 Note 都打过了压缩问题一点没改善。原因是这两个 Note 解决的是 Unicode 打印预览的文本格式化和亚洲文本重叠和 31 字符压缩不是同一个问题。压缩对应的是另一个 Note症状描述里明确写了超过 31 个字符被压缩。 解决办法是按症状描述去匹配 Note而不是按看起来相关去挑。匹配到之后逐行核对修正说明里的代码确认在当前系统版本上确实生效而不是只看状态标记。现象五预览看着完全正常打印出来还是交错。原因是预览和正式打印走的是两条渲染路径预览通过不代表输出控制路径也通过。测试只在屏幕上看了预览没走SP01看 spool也没看纸质件。 解决办法是固定三段验证断点确认%header-langu、SP01看 spool 内容、纸质件对照。三段都过才算过缺一段都可能在客户端现场翻车。6. 上线前固定走一遍把语言版本检查做成动作折腾完这几轮我给自己定了个规矩凡是带中文的 Smart Forms上线前必须走一遍固定动作不凭记忆不靠上次好像没问题。具体就四步。第一步在调用方确认control_parameters-langu有显式赋值且赋值位置在CALL FUNCTION之前结构在循环里每次重建。第二步在生成 FM 里%header-langu赋值那一行打断点跑一次确认拿到的是1而不是空、不是E。第三步SP01打开输出请求看内容重点看超过 31 个字符的中文有没有被压缩、有没有和相邻字段交杂。第四步切到 E 环境和中文环境各打一次两个环境的输出结果做对比。这套动作可以整理成一张表贴在项目文档里谁接手谁照着走环节检查点不通过的典型表现调用方代码langu是否显式赋值、位置是否在调用前预览重叠%header-langu为空或 E生成 FM 断点%header-langu实际取值取到E或空spool 内容31 字符以上中文是否被压、是否交错字距异常、字段粘连双环境对照E 与 1 两次输出是否一致两种环境结果不同还有个习惯值得养把语言版本和长度阈值这两件事分开验证。我见过太多人把两个问题混在一起测改完语言以为压缩也好了结果上线才发现只解决了一半回头再走一遍流程时间成本翻倍。测试数据里专门准备一组 30 到 35 字符的中文串卡在阈值上下一眼就能看出来补丁到底生效没有。那次事故之后我每接一张新的中文表单都会先把langu那一行写死再谈排版。看起来是多余的一行代码省下的是打印室里反复试纸的那一下午。希望帮到你。本文还有配套的精品资源点击获取
