This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When you say "unable", what does that actually mean? Read our FAQ entry TellTheDetails for the sort of things we need to know.
Also, I notice that you are reading data from a file and then printing it, and assuming that the printing is the problem. You might consider not jumping to that conclusion; I notice you didn't specify a charset in your code which reads from the file.
Joined: Apr 15, 2011
Thanks Paul, I meant to say i am unable to print Swedish Character, Swedish Character are getting printed like some garbage characters. I am reading text from the file and trying to print it, in the file Characters are displaying correctly but while printing issue is coming.
For byte print data where the doc flavor's MIME type does not include a charset parameter, the Java Print Service instance assumes the US-ASCII character set by default. This is in accordance with RFC 2046, which says the default character set is US-ASCII. Note that US-ASCII is a subset of UTF-8, so in the future this may be widened if a future RFC endorses UTF-8 as the default in a compatible manner.
Also note that this is different than the behaviour of the Java runtime when interpreting a stream of bytes as text data. That assumes the default encoding for the user's locale. Thus, when spooling a file in local encoding to a Java Print Service it is important to correctly specify the encoding. Developers working in the English locales should be particularly conscious of this, as their platform encoding corresponds to the default mime charset. By this coincidence that particular case may work without specifying the encoding of platform data.
Every instance of the Java virtual machine has a default character encoding determined during virtual-machine startup and typically depends upon the locale and charset being used by the underlying operating system. In a distributed environment there is no gurantee that two VM's share the same default encoding. Thus clients which want to stream platform encoded text data from the host platform to a Java Print Service instance must explicitly declare the charset and not rely on defaults.
The preferred form is the official IANA primary name for an encoding. Applications which stream text data should always specify the charset in the mime type, which necessitates obtaining the encoding of the host platform for data (eg files) stored in that platform's encoding. A CharSet which corresponds to this and is suitable for use in a mime-type for a DocFlavor can be obtained from DocFlavor.hostEncoding This may not always be the primary IANA name but is guaranteed to be understood by this VM. For common flavors, the pre-defined *HOST DocFlavors may be used.
See character encodings for more information on the character encodings supported on the Java platform.
Make sure you create the DocFlavor with the correct character set, for example:
Ravi Rai wrote:@Jasper - Thanks you, my file encoding is ANSI, i'll try to use different encodings in DocFlavor constructor and will update result.
ANSI? I don't know a character encoding named "ANSI". Maybe you mean Windows-1252? I see you've changed the code and you're using ASCII. Note that the ASCII character set does not include characters such as Ä, å and ö. So your text file is most likely not encoded in ASCII.
You need to find out what the actual character encoding of your file is.
Joined: Apr 15, 2011
I am using below code to generate to File, which later i am using for printing.
in this code i have used UTF-8 encoding.