I have a program that basically creates a text report containing non-ASCII characters (Traditional Chinese, to be exact). The file opens up fine in text editors.
The main problem I'm having is printing this text report
If I print this file from notepad, the form feeds/page breaks
aren't recognized and the alignment goes haywire. Non-ASCII characters show fine.
If I use the command "type filename > \\machine\printer", the alignment works but all non-ASCII characters print as gibberish.
I've tried several variations of raw printing, setting system locale, changing code page, etc but can't get it to work.
Originally, the program was allowed to spool directly to printer (and it worked fine) but due to technology changes, direct spooling is forbidden. I can only work with the text-file as-is after it's been generated.
Does anyone have an idea how to work with this?
Found a way -basically using powershell and force the encoding to UTF-8 in Get-Content. Apparently cmd spooling will never be able to handle this...
Related
I load csv file of utf-8 encoding with cyrillic strings. After parsing in Flow interface - i see not cyrillic, but not readable symbols like "пїўпѕЂпѕ™пїђпѕ" How can i use utf-8 cyrillic strings in H2O?
This appears to be a bug in the Flow interface, but only in the setupParse command. If you continue through and do the import, the data gets imported correctly.
I've reported the bug, with test data and screenshots (taken in Firefox) here:
https://0xdata.atlassian.net/browse/PUBDEV-4640
So if you have additional information, or the bug is behaving differently for you, it'd be good to add it to that bug report.
check your csv file in text and binary presentation to find how Cyrillic text is encoded, if it is UTF-8 it should look like this:
Привет
for the word
Привет
I have used Jekyll tool to convert MarkDown file To HTML. It has been successfully converted to HTML. but the below following encoded punctuation characters has been added at the top of the HTML, due to the file encoded format is Encode in UTF-8.
"—-"
After changed the same markdown file to Encode in ANSI format in NotePad++[encoding option in menu bar]. The punctuation character not included in generated HTML.
In this we need to manually change the markdown file to ANSI for HTML generation 'Jekyll'.
Any solution for this?
 is the UTF-8 BOM so that's probably what you are seeing, assuming you are looking at it using CP1252; and — is something out of the General Punctuation block.
Proper diagnostics are not possible without an indication of which character encoding you are using instead of UTF-8 to view the file, and/or what exact bytes you have in the file, probably as a hex dump. The first few bytes (the BOM) would be EF BB BF. See also the character-encoding tag wiki for troubleshooting tips.
Quick googling indicates that Jekyll is highly allergic to UTF-8 BOM in its input, so it seems unlikely that it generates spurious BOM characters on output. I could speculate that the template file you are using has a BOM and that it is being faithfully included in the output, but I'm not really familiar enough with Jekyll to actually help troubleshoot any further.
Of course, as per the big ugly warnings all over the Jekyll site, I assume you have already made sure that your Markdown input doesn't have a BOM character. Many Windows editors are notorious for putting one in when you save as UTF-8; make sure you use "UTF-8 without a BOM" as the "Save As..." format -- and switch to an editor which offers this option if yours doesn't have it.
try using charset=utf-8
or
Check your content has any straight double quote (" ") or straight single quote (' ') and remove those
http://practicaltypography.com/straight-and-curly-quotes.html
This encoding format issue. make the markdown file in UTF-8 without BOM format.
This will remove the punctuation character in 'html' .
We have developed an in-house printing solution that allows users to manage their prints (audit/merge/review/send to multiple printers) etc... but we are having issues with the very end of the process - the final print.
Currently our solution stores documents (original & after merging) in PDFs. We need to be able to send these documents to a particular printer and have it in some cases (when the user has selected the option) print page 1 to tray 8 and the rest to tray 1. We can't split the PDFs and print them separately as they also have to be stapled by the printer as a single job.
Our idea was to convert the PDF files to PostScript files using ghostscript then insert PJL commands into the PostScript and then print this modified PostScript file using gsprint.
Unfortunately the combination of ghostscript, postscript, PJL and gsprint doesn't seem to be working. The PJL commands we try, which we CAN get to work within text files sent to the printer via the windows copy command, don't seem to have the same affect when put into the PostScript files and printed using gsprint.
Can anyone spot any hideous flaws in what we are doing to the PostScript or have any idea why the PostScript->PJL amends->gsprint workflow we have might not be working?
It's been very difficult to find examples online so it's very possible our placement of PJL commands is incorrect.
(//comments not in final file)
<ESC>%-12345X#PJL JOB<ESC>&l8H //start job printing first page
#PJL ENTER LANGUAGE = Postscript //to tray 8 (letterhead)
#PJL COMMENT CANPJL SET STAPLE=ONEUPLEFT //indicate the document should be stapled
%!PS-Adobe-3.0 //start of PostScript file proper
---
%%PageTrailer //end of first page
<ESC>%-12345X#PJL EOJ<ESC>%-12345X //end the first job
%%Page: 2
<ESC>%-12345X#PJL JOB<ESC>&l7H //start 2nd job to print remaining
--- //pages to tray 1 (plain)
---
%%EOF
<ESC>%-12345X#PJL EOJ<ESC>%-12345X //end 2nd job
We then take this modified PostScript and use gsprint as follows:
gsprint -noquery -ghostscript gswin32c -printer "printer" "C:\postscriptfile.ps"
This all print out to the default tray and unstapled, i.e. none of this works as expected.
I hope it's clear what we are trying to achieve. Any help would be greatly appreciated.
Thanks in advance.
PS: All our printers are Canon printers.
Edit:
After KenS's answer below it seems the logical workflow should instead be PDF->PCL->add PJL->send to printer with "copy"
Unfortunately we are still having issues with this, certain PJL commands seem to be ignored by our printers (the printers are definitely PCL printers).
If we take a 2 page PDF produced by Microsoft Word, convert it to PCL using ghostscript then edit that PCL file with Notepad++ add add the following:
<ESC>%-12345X#PJL JOB NAME = "My Print Job Name"<CR><LF>
#PJL SET DUPLEX = ON
#PJL SET OUTBIN = LOWER
#PJL ENTER LANGUAGE = PCL
...original PCL data...
<ESC>%-12345X#PJL EOJ<CR><LF>
<ESC>%-12345X
the document comes out of the lower output tray but not duplexed. But what is extra odd is that the printer seems to take much longer to print when DUPLEX = ON than the exact same job with DUPLEX = OFF and it sounds like it's doing something different internally.
Any ideas?
I think you misunderstand how gsprint operates. It takes an input file, renders it to a bitmap, draws that bitmap on an appropriate canvas, and then uses the Windows printing system to print that canvas on a printer. It does not have any control of the printer at all, as a result embedding anything which is expected to control the printer (as opposed to the rendering) will not have any effect.
In addition, PJL is asociated with HP PCL printers, not with PostScript printers. Whil;e your PJL may work on a PCL printer, because it treats each page as a separate job, it won't work at all on a PostScript printer, and may well cause it to give you an error, depending on whether the interpreter ignores PJL commands or not.
In order to control the printer, you will need to determine what kind of input the printer supports (PostScript or PCL), you then need to convert your PDF to that form, then insert appropriate control sequences. In the case of a PCL printer you might reasonably use PJL, for PostScript printers you should control this using the setpagdevice operator. Assuming you have a Windows .WPD or .PPD file for your printer, the relevant control sequences can be found there, or by printing a few test files and examining their contents.
In passing; you say that the commands you are using work when sending text files to the printer. This means the printer at least understands PJL and is almost certainly a PCL printer. You can't send text to a PostScript printer, it will generate an error, because PostScript is a programming language and you will have syntax errors with any random piece of text. You can however send text to a PCL printer which assumes that anything not starting with a 0x1B (escape) is just text to be printed.
So using Ghostscript to produce PCL output, inserting your PJL as you have above, and then sending the result directly to the printer should probably work. Of course identifying the end of each page might be more difficult in a PCL file.
We had similar issue this is how we did using ghost script and PJL
http://reddymails.blogspot.com/2014/07/how-to-print-documents-using-java-how.html
Also bfo.com has some commercial jars which do the same thing without ghost script and in a Pure java way. But you have to pay for it :)
Currently I am trying to set application name using
net.rim.blackberry.api.homescreen.HomeScreen.setName("これはある");
but it throws exception: IllegalArgumentException.
Can anyone provide the solution?
I am using Blackberry JDE 5.0.
This is probably a string encoding problem. Try
new String(new String("これはある").getBytes("UTF-16BE"), "UTF-16BE");
It's not pretty but I think that will work.
Here's a link to the Blackberry string spec: http://www.blackberry.com/developers/docs/5.0.0api/java/lang/String.html
By default it's ISO-8859-1 which does not include Japanese characters.
The problem you are facing is how to get a string represented in your source code into your application with the same characters. For latin characters, this is pretty straightforward, as we can just put the characters in quotes, and get a string, like "Hello world"
When you go to non-latin, like Japanese, it gets harder. You can still directly write Japanese in your source code, but you need to make sure your editor and your compiler agree on an encoding so that the characters can be interpreted correctly. The Java-SE compiler takes an argument "-encoding" which allows you to specify the encoding of your java source files.
Unfortunately, rapc, the BlackBerry compiler, does not offer an option to specify encoding, even though it is invoking javac itself. So rapc uses the platform default, which is utf-8 on Linux and OSX and iso-8859-1 on Windows.
The way around this problem is to use a feature of the Java language for parsing strings - unicode escaping. By entering the six character sequence "\u3053" in a string, the java compiler will parse that number as hexidecimal and use the corresponding unicode code point, solving problems with source file encoding.
So "Hello world" and "\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064" will result in the same strings appearing in your class files.
Because of this, Svetlin's answer from the comments is the right approach here:
net.rim.blackberry.api.homescreen.HomeScreen.setName("\u3053\u308C\u306F\u3042\u308B");
i'm having problem to deal with charset in ruby on rails app, specificially in my templates. Code that comes from my database, works fine, but codes like ç ~ that are located in my views are not working. I added the following codes to my code
I added a function like that, but that still not working i have ç ~ codes in my application.rhtml that are not working.
before_filter :configure_charsets
# Configuring charset to UTF-8 def configure_charsets
headers["Content-Type"] = "text/html; charset=UTF-8"
end
I added as well meta http-equiv html to utf-8 and a .htaccess parameter AddDefaultCharset UTF-8
That's still not working, any other tip?
Put this piece of code in your config (environment.rb)
Rails::Initializer.run do |config|
config.action_controller.default_charset = "iso-8859-1"
end
This will do it.
Also, remove the default charset line if any in layouts/application.html
Is the text editor you're using to put the special characters into the file (either source or views) treating those characters as UTF-8? For example, if you're using TextMate, you can deliberately save a file as UTF-8. If for some reason you used a different encoding earlier (a default, perhaps), those UTF-8 characters might be getting transcoded at the code editing stage, so even if the rendering process is using UTF-8 throughout, it'll still not work.
Further, if you're using something from a shell, like vi, or whatever, is your terminal set up to accept UTF-8 as default? If you had it set to ISO-8859-1 or whatever, you'd get the same issue.
Is your application.rhtml file written in the correct character set? Make sure it's UTF-8, and not ISO-8859-1.
So if the contents of your file are UTF-8, and the output is being interpreted as UTF-8, something in between is changing the data. Can give give us the the hex interpretation of the input bytes (anything non-ASCII will be at least two bytes in UTF-8) for one of your special characters, and the hex interpretation of the output byte or bytes? Perhaps we can figure out what the change is, and work back from there.