Tuesday, July 29, 2014

Apex Listener prints # instead of national characters

On many sites around world, in last moths you might find that people are having problems when printing PDF in Apex (in mine case 4.2.5.00.08) through Apex listener (in mine example 2.0.5.287.04.27). Problem is that national characters are not printed properly and instead of then "#" signs are shown. This has nothing with any bad Windows setup (have tried some example on BI Publisher with same Apex and Windows...and all works like a charm) so the problem is in fop part of Apex listener which render Helvetica font in wrong code page.
Here is small example of one IR with only one column that shown in content all Croatian national characters:
When you print PDF (Download as PDF) then you get a PDF file like this one. Problem is more than obvious.
Regardless there are some instructions which said that proper "fop.xml" should be edited with some content, this approach didn't work in mine example.

The Solution

On my Windows PC, I have for example the Arial font that contains the Croatian characters. Solution is a little bit more complex and described in next steps.
  1. Open file \apex\core\reports3.sql (this contains the 'generic XSL-FO definition' that should be modified)
  2. Save that file it under new name reports3_new.sql (preserve original for any kind of problem later)
  3. find the part with "#BODY_FONT_FAMILY#" and replace with "Arial" Here is small example for body definition. Original part
       <xsl:attribute-set name="body-font">
          <xsl:attribute name="height">12.0pt</xsl:attribute>
          <xsl:attribute name="font-family">#BODY_FONT_FAMILY#</xsl:attribute>
          <xsl:attribute name="white-space-collapse">false</xsl:attribute>
          <xsl:attribute name="font-size">#BODY_FONT_SIZE#pt</xsl:attribute>
          <xsl:attribute name="font-weight">#BODY_FONT_WEIGHT#</xsl:attribute>
       </xsl:attribute-set>
    
    change to:
       <xsl:attribute-set name="body-font">
          <xsl:attribute name="height">12.0pt</xsl:attribute>
          <xsl:attribute name="font-family">Arial</xsl:attribute>
          <xsl:attribute name="white-space-collapse">false</xsl:attribute>
          <xsl:attribute name="font-size">#BODY_FONT_SIZE#pt</xsl:attribute>
          <xsl:attribute name="font-weight">#BODY_FONT_WEIGHT#</xsl:attribute>
       </xsl:attribute-set>
    
    This will set use of Arial font for all parts (header, body or footer) in reports. If you need some other setup, change with font you like in part you need.
  4. start SQLplus and connect as APEX_040200 user (or add APEX_040200 in previously edited package specification and connect any privileged user)
  5. Now recompile the changed file of step 2
  6. Recompile package & package body APEX_040200.wwv_render_report3
  7. In defaults.xml add entry which points to new "fop.xml" file. In mine case this is:
    c:\oracle\product\apex_listener\fop.xml
    
    Keep in minda that directory short names should avoid any other unknown problem.
  8. In fop.xml, on mentioned location, place next content:
    <fop version="1.0" encoding="UTF-8">
    <renderers>
     <renderer mime="application/pdf">
       <fonts>
         <!-- Arial  -->
         <font kerning="yes" embed-url="c:\windows\fonts\arial.ttf">
           <font-triplet name="Arial" style="normal" weight="normal" />
           <font-triplet name="ArialMT" style="normal" weight="normal" />
         </font>
       </fonts>
     </renderer>
    </renderers>
    
    where "C:\windows" is the location of installed windows.
  9. Restart the APEX Listener
Now when you generate PDF with same content (as shown on picture) problem is succesfully solved.

The End

As I was informed, this workaround should be fully implemented in next Apex 5.0 when such a workaround should not be necessary.
Hope this helps someone.

Cheers!

3 comments:

  1. marvelous. exactly the same problem and this is real solution.
    god bless you!

    ReplyDelete
  2. I found out after upgrading, that Apex 4.2.6.03 has fixed this issue-

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete