Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Jigang_Zhang张吉刚
Active Contributor
0 Kudos
6,677
Normally, there could be mess code issues for Chinese/Japanese/Korean characters, especially never been printed in those languages before. There're many articles that discussed this issue a lot.

Please check this for Printing problems, Smartforms/Sapscripts/ PDF conversion of spool containing Double byte characters, and the approach to solve the issues from Prashant Patil.


 

This article tips to deal with the error that specific Chinese/Japanese/Korean characters have been shown as square instead of mess code in adobe form printout.

  • No mess code for all the characters except some specific characters shown as a square;

  • Both Print preview and SP01 spool preview are perfectly fine;

  • Save as a PDF file and printing out physically is fine;

  • Smartforms&Scripts forms are fine for the same characters;

  • The device type 'PDFUC' has been used;

  • Arial Font been used for text;

  • SAP GUI770 has been used;

  • The printer can print those characters without issue for applications like Word.


It's not relevant to the driver program and the adobe forms itself for sure, after checking SAP printer setting/ physical printer setting/font family support/ related notes, etc., we find no clue at all until the Basis team provides the below approach:

1, Tick the check box of 'Use Font Substitution'


SAP GUI Options->Front-End Print->Configure Front-End Print->PDF options, the option 'Use Font Substitution' is default unselected.




2. Install Monotype Fonts for Printing download from SAP site



After implementing the above steps, all the characters are printed correctly in the Production system while 99% of characters are printed correctly in the Development system... still rare unique characters are displayed as a black dot instead of the previous Square!~ And surprisingly find out some characters were bold randomly!


Then try using solutions from Notes 1489570 (Set font mapping for PDF forms) which explains why it happens:
The display differs because different fonts are used in the form that was rendered by Adobe Document Services (ADS) than are used on your local PC where the Adobe LiveCycle Designer is.

If you display a form in the preview in the Adobe LiveCycle Designer, the system uses the fonts that are used in the form template.

If you use Adobe Document Services to generate the PDF form, they can
use fonts only that are either included in the PDF form or installed on the same server. To ensure that rendering leads to the same result (regardless of the platform), a default mapping is set for certain fonts. The fonts Times New Roman und Arial are affected by this. These fonts are replaced with the fonts Times or Helvetica for the PDF output. This font replacement is specified in the file xfa.xci that is on the server on which ADS run.

The issue is still there after creating the font mapping entry in the table FPFONTREPL. Please kindly let me know if any better approach can fix this display issue perfectly!

 

--------Update on 2022/07/28-----------------


Here is the whole story of what I've known after several days of testing:

Q1: The reason why those characters show differently when printout?


A1: Notes 1489570 (Set font mapping for PDF forms) explains this very clearly:


The display differs because different fonts are used in the form that was rendered by Adobe Document Services (ADS) than are used on your local PC where the Adobe LiveCycle Designer is.

If you display a form in the preview in the Adobe LiveCycle Designer, the system uses the fonts that are used in the form template.

If you use Adobe Document Services to generate the PDF form, they can
use fonts only that are either included in the PDF form or installed on the same server. To ensure that rendering leads to the same result (regardless of the platform), a default mapping is set for certain fonts. The fonts Times New Roman und Arial are affected by this. These fonts are replaced with the fonts Times or Helvetica for the PDF output. This font replacement is specified in the file xfa.xci that is on the server on which ADS run.

Q2: Why does Arial font have the lowest possibility of mess code before figuring out the perfect font?


A2: Notes 2367603 (Arial font missing in PDF output) explain this point:



  • Helvetica font was used in PDF generation instead of Arial font.

  • Arial font is a custom-specific font and is not a part of ADS standard installation.

  • Fonts used in PDF generation are different in Adobe LiveCycle Designer and ADS PDF output.


The root of this because:

  • Arial font is mapped to Helvetica in the default xfa.xci file.

  • Arial font is not installed on the ADS server.


And the default xfa.xci file has only considered font mapping for Arial font& Helvetica font.
           <fontInfo>
<embed>0</embed> <!-- 0|1 -->
<map>
<equate from="Arial_*_*" to="Helvetica_*_*"/>
<equate from="Times New Roman_*_*" to="Times_*_*"/>

<equateRange from='Arial_*_*' to='Helvetica_*_*' unicodeRange='U+000000-00007F'/> <!-- Basic Latin -->
<equateRange from='Arial_*_*' to='Helvetica_*_*' unicodeRange='U+000080-0000FF'/> <!-- Latin-1 Supplement -->
<equateRange from='Arial_*_*' to='Myriad Pro_*_*' unicodeRange='U+000100-00017F'/> ......

<equateRange from='Times New Roman_*_*' to='Times_*_*' unicodeRange='U+000000-00007F'/> <!-- Basic Latin -->
<equateRange from='Times New Roman_*_*' to='Times_*_*' unicodeRange='U+000080-0000FF'/> <!-- Latin-1 Supplement -->
<equateRange from='Times New Roman_*_*' to='Minion Pro_*_*' unicodeRange='U+000100-00017F'/> <!-- Latin Extended-A -->

......

<equate from="Adobe Gothic Std B_normal_normal" to="Adobe Gothic Std B_bold_normal" force="1"/>
<equate from="Adobe Fan Heiti Std B_normal_normal" to="Adobe Fan Heiti Std B_bold_normal" force="1"/>
</map>
<alwaysEmbed>OCR A Std</alwaysEmbed>
<alwaysEmbed>OCR B Std</alwaysEmbed>
<alwaysEmbed>MICR Std</alwaysEmbed>
</fontInfo>

This explains why there are so many various font types being used in the generated PDF file, and even shown as different fonts & sizes & bold types in the same line with exactly the same font setting.




  • KBA 2366689 - How to check fonts used in PDF generation


Q3: How to find the right Font type for your special characters?


A3:  To understand what's a Unicode range, please check this WIKI.


Unicode - Unicode Character Table (unicode-table.com) provides the listing of Unicode which maps the font replacement at xfa.xci file.


Copy the character which is not displayed correctly to this linkage, then it'll show the Unicode number for this character like below:


In my case, we can clearly saw its all details for these specific characters which belong to CJK Compatibility Forms.


Then check the mapping at the file which font's range covers this Unicode number or any related hits about this font family beside the mapping entry:


If not been covered, but it's very related, just try to replace the mentioned font from the mapping line. Good luck! 😄

Q: What if all the above-mentioned approaches failed?


A: If still not working, we have the ultimate solution which is mentioned in notes 1717189  ADS Font Trace.



  1. Activate font trace as per SAP Note 1717189.

  2. Generate PDF with additional information as per SAP KBA 2216427 or SAP Note 944221.

  3. Open trace.txt file from PDF attachment list (see SAP KBA 2216427).

  4. Scroll down to the relevant output form area. Ex.: PDF, PCL or ZPL.

  5. Use font log information and analyze the issue.


 

Maybe get the error at the font processing log like below:
"Character U+0030E2:モ is not found in font Helvetica_Bold_Normal, substituted from font Kozuka Gothic Pro-VI M_Normal_Normal."
Used font Helvetica doesn't contain character U+0030E2:モ and was substituted from font Kozuka Gothic Pro-VI.
Install font with this character on ADS server.

 

Finally, it's a tortured journey to investigate all of this, but full of expectations and surprises during print-out testing for those special characters I thought I'd known 100%. Now I have a brand-new understanding of how ADS processes PDF rendering and how complex could be to deal with all various characters for the languages in this world.

1 Comment
Labels in this area