SmartForms : Printing Non-English characters with SWIN output device?

I have a Japanese Text (entered in Unicode at So10) and I want to print it from my SmartForms application using SWIN device type.
I thought SWIN converted all the components into graphics before sending to printer. To my surprise, the Japanese text printed out as "########".
I even tried duplicate the SWIN output device to another output device and changed the character set to 4103 UTF-16LE Unicode / ISO/IEC 10646 but then the print process hang.
Anyone knows how to overcome the problem so that I can print Japanese with SWin output device?

I have a Japanese Text (entered in Unicode at So10) and I want to print it from my SmartForms application using SWIN device type.
I thought SWIN converted all the components into graphics before sending to printer. To my surprise, the Japanese text printed out as "########".
I even tried duplicate the SWIN output device to another output device and changed the character set to 4103 UTF-16LE Unicode / ISO/IEC 10646 but then the print process hang.
Anyone knows how to overcome the problem so that I can print Japanese with SWin output device?

Similar Messages

  • Encoding non english characters with utf 8 on jsp (Critical!!)

    I am inserting hebrew characters from JSP into oracle db and everything is fine until this point. But when I try to retrieve the information from the database, the characters are not displayed properly (I get some garbage characters). I am sure that the data stored in the database is correct, but not sure why there is a problem in displaying the data in the JSP.
    I came across a thread on TSS
    http://www.theserverside.com/discussions/thread.tss?thread_id=28944
    and followed the suggestions given there like having
    <%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
    <META http-equiv="Content-Type" content="text/html; charset=UTF-8">and also this
    <%
    //Some JDBC and sql statement query UTF-8 data and then ...
    String str = rs.getString("utf8_data");
    str = new String(str.getBytes("ISO-8859-1"),"UTF-8");
    %>
    <%= str %>Now, the data getting displayed is partly correct, I mean to say, some characters are still coming as squares.
    Any ideas will be of great help.

    even i doubt the database charset for this issue. But what I dont understand is how only certain hebrew characters are getting stored properly and why others are corrupted?
    Also, can anyone let me know how i can view the Non-English characters present in the database directly, as TOAD is not able to display them

  • Problem with the Non-English Characters

    Hello,
    I have been using Adobe Illustrator  but I have a huge problem with the non-english characters with Standart Fonts. With the Professional font's I have no problem with them. But when I'm using any standart font in font folio library I cannot type any "ğ-İ-ş". I can add those letters in fontlab with the glyphs (scedilla, idotaccent, gbreve). Most of the fonts have those letters already prepeared so I dont even have to redraw. But I can't add those glyph to every single font because I dont have that kind of time and patience. Is there any better solution for this? Or is there any font folio pack that all fonts are PRO.
    I'm looking forward for your answers
    Thanks.

    Joel wrote: I'm told that this is the exact difference between Adobe's Standard and Pro fonts — the Pro fonts have additional glyphs, including those necessary for extended Latin script.
    Exactly. The Pro fonts have at a minimum the Adobe Western 3 character set, which is essentially western European + Adobe CE.
    > Standard fonts just have the basic English character set, with maybe a bit of help for Spanish and French.
    A lot more than that!
    > You're doing Turkish, right? Adobe's coverage for Turkish in its fonts is not great - some of the Pro fonts have Turkish coverage, many do not.
    This is false. Every single Adobe Pro font supports Turkish.
    To be clear:
    All Adobe Standard fonts support the following languages: Afrikaans, Basque, Breton, Catalan, Danish, Dutch, English, Finnish, French, Gaelic, German, Icelandic, Indonesian, Irish, Italian, Norwegian, Portuguese, Sami, Spanish, Swahili and Swedish.
    Adobe Pro fonts support those languages, plus AT LEAST: Croatian, Czech, Estonian, Hungarian, Latvian, Lithuanian, Polish, Romanian, Serbian (Latin), Slovak, Slovenian and Turkish. Some Pro fonts have more language support than this, such as Greek and/or Cyrillic, and additional extended Latin.
    See: http://www.adobe.com/type/browser/info/charsets.html
    Cheers,
    T

  • Can't able to print Non English data properly in PDF Output

    Can't able to print non english data properly
    Example:
    I want to print the germen data (Währung),But it printing like this (Währung) in PDF out put
    What the changes i have to do to achive this
    Thanks&regards
    yamini

    Hi Yamini,
    I think this happens when you look at utf-8 in Windows wiith another character set. I've noticed that the XML file (and hence the PDF output) displays those characters when I preview reports on the BI desktop, but the output from the server is fine, so I don't worry about it.
    Tore.

  • [AS] Problem with non English characters in file path

    I wrote a script that exports a pdf file from ID, rasterizes it in PS, applies an action, saves it as another pdf file, and finally creates a Mail message, and attaches the file to it (the last part is written in AppleScript).
    The problem is that it doesn't work when the path to this file contains non English characters.
    This works:
    make new attachment with properties {file name:"/Volumes/Macintosh HD/BackUp Tetard/Test.pdf"}
    but this doesn't:
    make new attachment with properties {file name:"/Volumes/Macintosh HD/BackUp Têtard /Test.pdf"}
    I remember vaguely that I read somewhere that AppleScript can work with Unicode — in other words with such characters — starting from some version, don't remember which exactly, but it seems to me — Leopard.
    I am on Mac OS X 10.4.11 right now. Will updating solve this problem? Does anybody know any solution to this problem: a scripting addition, some hidden setting, etc.
    I made a little test: used a Russian character — ё and it works, but when I use — ê (Dutch) it doesn't. May it have something to do with the Region setting in International panel?
    Thanks in advance,
    Kasyan

    Kasyan, as of Leopard AppleScript treats all text as Unicode pre this you can specify 'as Unicode text'. Try a test with these.
    -- Leopard
    set x to POSIX path of (path to desktop)
    -- Pre Leopard
    set x to POSIX path of (path to desktop as Unicode text)
    -- Leopard
    set x to POSIX path of (choose file without invisibles)
    -- Pre Leopard
    set x to POSIX path of ((choose file without invisibles) as Unicode text)

  • Non English characters in BIP email

    Hi, my report contains Japanese characters, when I view the output in HTML format. It is displayed properly. But when I click on send button , enter email parameters like to, cc, bcc, subject , etc and send it, in the mail I receive, the japanese characters are not getting displayed properly. The same problem occurs for spanish and portugese texts-in general to all non english characters. I am using Oracle Business Intelligence Publisher Release 10.1.3.4. If someone has faced a similar issue, kindly help. Thanks in advance

    Suggestions
    1) Try with NLS_LANG as
    SWEDISH_SWEDEN.WE8DEC
    2) Make a paramform and enter via paramform (unencoded)
    (This is just for testing purpose)
    3) Change machine locale to swedish and try
    4) Which reports version is this ?
    Please see
    BUG 2713695 - NLS CHARACTERS FOR PARAMETERS CHANGE TO QUESTION MARKS WHEN PASSED ON URL BAR
    Get in touch with Support to see if this is the issue and if "yes" get a one-off patch.
    [    All Docs for all versions    ]
    http://otn.oracle.com/documentation/reports.html
    [     Publishing reports to web  - 10G  ]
    http://download.oracle.com/docs/html/B10314_01/toc.htm (html)
    http://download.oracle.com/docs/pdf/B10314_01.pdf (pdf)
    [   Building reports  - 10G ]
    http://download.oracle.com/docs/pdf/B10602_01.pdf (pdf)
    http://download.oracle.com/docs/html/B10602_01/toc.htm (html)
    [   Forms Reports Integration whitepaper  9i ]
    http://otn.oracle.com/products/forms/pdf/frm9isrw9i.pdf
    ---------------------------------------------------------------------------------

  • Odd number of non-english characters get broken in windows-chrome and ff

    I developed jnlp applet which prints out the user input.
    When I put odd number of non-english characters(eg: chinese), chrome and firefox browser prints out the last character as question mark.
    input : 가
    output : 가��
    I checked on java console that the character is correct.
    It must be bug in communication of applet to chrome browser.
    IE prints out correctly.
    I can resolve the issue by appending white space on applet and remove it on java script.
    Anyone has any clue on the issue?
    Codes are as follows.
    MainApplet.Java
    public class MainApplet extends JApplet implements JSInterface{//, Runnable {
         public int stringOut(String sData) {
              OutData = sData;
              return 0;
    js File
    function TSToolkitRealWrapper ()
         var OutData;
         var OutDataNum;
    var TSToolkit = new TSToolkitRealWrapper();
    var attributes = { id:'TSToolkitReal',code:'tradesign.pkitoolkit.applet.MainApplet', width:100, height:100} ;
    var parameters = {jnlp_href: getContextPath() + '/download/pkitoolkit.jnlp',
                         separate_jvm:true, classloader_cache:false} ;
    TSToolkitRealWrapper.prototype.stringOut=function(str)
              var      nRet = TSToolkitReal.stringOut(str)     ;
              this.OutData= TSToolkitReal.OutData;
              return      nRet;
    HTML
    <SCRIPT language=javascript>
    <!--
    function StringOut(form)
         var data = form.data.value;
         var nRet = 0;
         var base64Data;
         nRet = TSToolkit.stringOut(data);
         if (nRet > 0)
              alert(nRet + " : " + TSToolkit.GetErrorMessage());
         else
              form.data1.value = TSToolkit.OutData;
    -->
    </SCRIPT>
    Edited by: user13496918 on 2013. 3. 20 오후 7:29
    Edited by: user13496918 on 2013. 3. 20 오후 7:39
    Edited by: user13496918 on 2013. 3. 20 오후 9:17
    Edited by: user13496918 on 2013. 3. 20 오후 9:18

    I checked on java console that the character is correct.So it isn't a Java problem.
    It must be bug in communication of applet to chrome browser.So tell the people who make the Chrome browser.
    IE prints out correctly.That's a change. I've just spent nine days tracking down an IE applet problem and I'm not finished yet.
    Please omit the boldface next time. We can read. Boldface doesn't help; it makes it worse.

  • Non-english characters in sqlplus

    Friends,
    9.0.1,10.2.0.1
    CAn the non-english characters be displayed in sqlplus prompt?
    I have to print the data with some hindi charcaters like name from the report generated via proc.
    What is teh workaround for this?
    Thanks

    Hi,
    I have RH Linux 7.3.
    Here is my situation.
    I have some tables that have some columns.In these columns i need to store data in hindi.
    The database character set(nls_characterset) is US7ASCII.
    The datatypes of the columns is varchar2 type.
    The tables are accessed through Pro*c and the proc code generates the report.
    The data in these reports needs to be printed out and the corresponding data has to be in hindi.
    So i have to do two things
    1) On query the tables, the user should see hindi data along with english data.
    2) The printed report should also contain hindi data.
    Questions:
    1) If i change the charcater set by the command:
    alter database character set AL32UTF8;
    and OS locale to UTF-8
    Would these chnages solve the purpose?
    2) Or do i need to recreate the database with AL32UTF8 and exp/imp all the data?
    3)Any other advice/option?
    Thanks

  • Formula to show non english characters from clob in crystal report

    Hi
    I am using the database Oracle 11g with a field clob in one of the table that i want to show in the crystal report
    But the problem is when i put the clob field in crystal report it is outputting the results perfectly for English characters but not for the Arabic ones and returning the string like (¿¿¿¿ ¿¿¿¿ ¿¿¿ ¿¿¿¿ ¿¿¿¿ ¿¿¿ ¿ ¿¿¿¿¿ ¿¿¿)
    so is there any way to show the arabic (non english) characters perfectly on crystal report with clob field

    Hi Azeem,
    Make sure the arabic font should install in your system.
    Try this:
    Create a text field in your Crystal Report (a label).
    Place Arabic characters into that field (just by typing them into it on the report definition).
    Run the report. If they display correctly then its probably not Crystal, but rather would point to an issue in the data retrieval and supply to Crystal via your dataset (or whatever datasource you are using).
    If they don't display - then its definitely Crystal.

  • Predictive text non-English characters to be made ...

    I just filled an enhancement request on this feature, please vote for it HERE:
    Predictive text non-English characters to be made optional
    The story is: while using predictive text for non-English languages (Polish in my case) the dictionary words are grammar correct which include special characters like: ą,ę,ć,ś,ż,ź,ó,ł etc. For texting (SMS) operators count these as 3 characters making a message much longer than it looks. Therefore I can tell you no one uses these characters while texting and people use EN only characters instead a,e,c,s,z,o,l... which makes using the predictive text useless for eg Polish language.
    I'd like to have an option to switch using these non-en chars off for predicting text, which is grammatically not correct but in real life that's how people type.
    So basically if there's an option to disable lang specific characters I would be getting an example suggestion of 'Prosze' instead of grammatically correct 'Proszę'. 'Prosze' is a 6 character word, 'Proszę' is a 5+3=8 character word. Considering a single SMS message a 300 chars, than it really makes a difference.
    Simple solution would be to replace every char ą with a, ć with c, ó with o etc... in each word suggested for the ones who have this option enabled.

    HI,
    You can write a code in PAI of main screen. there by using loop at screen you can make that field editable or disabled.
    Code sample:
    loop at screen.
    ****condition for value check
    if screen-name = 'TEXT_EDIT_NAME'
    screen-output = 1.
    screen-input = 0.
    modify screen.
    endif.
    endloop.
    Hope this will help you.

  • Problem in converting Spool to PDF file, having non-English characters

    Hi All,
            I have problem in converting Spool to PDF format.
    Scenario : I have a spool which has non-English characters. I am using CONVERT_ABAPSPOOLJOB_2_PDF  FM to perform conversion. But my output is having junk values( ie # ) for non-English characters. Any pointers to solve this issue will be appreciated.
    I even tried with report RSTXPDFT4 , it also gives me the same junk characters.
    Regards,
    Navin.

    Hi All,
            I have problem in converting Spool to PDF format.
    Scenario : I have a spool which has non-English characters. I am using CONVERT_ABAPSPOOLJOB_2_PDF  FM to perform conversion. But my output is having junk values( ie # ) for non-English characters. Any pointers to solve this issue will be appreciated.
    I even tried with report RSTXPDFT4 , it also gives me the same junk characters.
    Regards,
    Navin.

  • Non-English characters not displaying correctly - Serious Issue

    My corporate email is on a Lotus Domino server with Lotus Traveler installed.
    I have set my PlayBook (with OS 2) up to syncronize with the corporate email trough Active Sync (see http://alturl.com/qh3nn), which works perfectly.
    I have however noticed that in some emails special non-english characters are displayed correctly but in some emails special non-english characters are displayed as a black diamond with a question mark inside.
    This is of course a serious issue as most non English speaking countries use some special characters.
    When trying to understand this problem how can I analyse the emails and see what character set is being used?
    And of course better; has someone solved this?

    I am having the same problem. Is there any update available?

  • Only VBA does not recognize non-English characters

    Hello guys,
    I have a new laptop with Windows 8.1 bought in the USA and I'm having a difficulties with Excel VBA (Office 365 University-64x bought in the Czech Republic - Central Europe). The VBA does not recognize non-English characters (particularly "ř" and
    "ů") which causes me problem when running some codes that I wrote earlier on my previous laptop (Windows 7, bought in the Czech Republic with the same Office). 
    The problem with non-English characters has occurred only in VBA so far, otherwise I can use these characters normally in Excel cells, Word... I tried to install both English and Czech version of the Office with no change, I also installed Czech proofreading
    tools and set everything to Czech in the Office. The location and language preferences in the Windows are also set up to Czech. And it is not a problem of a font. I also mentioned that when I tried to look up these characters, using Ctrl+F, it changes
    original ř to r after a search and again this is only an issue of the VBA.   
    Thank you very much for any help.
    Tom

    Hi Tom,
    VBA for Excel can only recognize ASCII code from 0 to 255, if you use other special characters like "ř" or "ů", it will returns 63(?) to you. To use this kind of characters, you have to utilize ChrW function to parse a decemal to the
    character.
    http://msdn.microsoft.com/en-us/library/ee177465.aspx
    for example, the hex code and dec code for these two characters are as below:
      Hex   Dec
    ř 159   345
    ů 016F  367
    So to get these two characters in VBA, you could code as below:
    ChrW(&H159) or ChrW(345)
    ChrW(&H16F) or ChrW(367)
    You can get the hex code of the character by searching in the system character map(in the Win8.1 start view, search "character map"), then convert the hex code to decimal code by yourself.
    Range("A1").Value = ChrW(&H159) & ChrW(&H16F)
    Range("A1").Value = ChrW(345) & ChrW(367)
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

  • VBA does not recognize non-English characters

    Hello guys,
    I have a new laptop with Windows 8.1 bought in the USA and I'm having a difficulties with Excel VBA (Office 365 University-64x bought in the Czech Republic - Central Europe). The VBA does not recognize non-English characters (particularly "ř" and
    "ů") which causes me problem when running some codes that I wrote earlier on my previous laptop (Windows 7, bought in the Czech Republic with the same Office). 
    The problem with non-English characters has occurred only in VBA so far, otherwise I can use these characters normally in Excel cells, Word... I tried to install both English and Czech version of the Office with no change, I also installed Czech proofreading
    tools and set everything to Czech in the Office. The location and language preferences in the Windows are also set up to Czech. And it is not a problem of a font. I also mentioned that when I tried to look up these characters, using Ctrl+F, it changes
    original ř to r after a search and again this is only an issue of the VBA.   
    Thank you very much for any help.
    Tom

    Hi Tom,
    I would suggest you post the question in the forum of
    Excel for Developers as your query is directly related to VBA. Here we mainly support Office client side issues:
    https://social.msdn.microsoft.com/Forums/office/en-US/home?forum=exceldev
    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.
    Regards,
    Ethan Hua
    TechNet Community Support
    It's recommended to download and install
    Configuration Analyzer Tool (OffCAT), which is developed by Microsoft Support teams. Once the tool is installed, you can run it at any time to scan for hundreds of known issues in Office
    programs.

  • Support issue for non-English characters (in html forms)

    Hi group!
    I just want to post an issue here and see if anyone else has the same problem. First off, Im running Windows XP MCE but the French version (not the english version). This may help find out where the problem really is.
    Second, I know a bit of html and such, and I'm referring to HTML Character entities for this thread, there's a quite complete list here for reference: http://www.faqs.org/docs/htmltut/characterentitiesfamsupp69.html
    I noticed that some, not all, non-English characters written in a textarea (which is, basically, a multi-lined input box) doesnt pass well or at all to the server when sending the form from Safari. Most of the time, the content of the text area is reduced to the beginning and ends where the first accentued character is met.
    The most used French accents (&eacute;, &agrave;) are usually well interpreted (but may, once in a while, produce that bug too) by safari, but &ocirc; and &icirc; doesnt do that well.
    Oddly, this bug doesnt happen all the time and doesnt "crash" in the same manner everytime.
    So I started a thread just to see if there's anyone else having issues with any non-english characters mostly in forms. Probably flash/shockwave does work, but I'm not sure- I have not tested yet.
    Acer Aspire 5044   Windows XP   Turion 1.8GHz, 1Gb SDRam, ATI 200M xpress

    Yes, it is a known issue. I also noticed that it sometimes works, but most of the time it does not. It will hopefully be solved in the future. According to http://www.apple.com/safari/download/ changes that will come include:
    # Support for International users
    # International text input methods
    # Advanced text (contextual forms, international scripts)
    Sony Vaio   Windows XP  

Maybe you are looking for