I am trying to decrease font size for printing but unable to do this I have used this for small font size
val FONT_SMALL = byteArrayOf(0x1B, 0x21, 0x001)
But I want decrease more font size
It depends on the vendor and model of printer you are using.
For example, for EPSON, specifying Font C with the following command will result in a smaller font.
But whether it is supported or not depends on the printer model.
ESC M
In response to comment:
This is a command that changes the printer font for subsequent prints.
After sending this command, if you send the character string data you want to print, it will be printed with the changed font size.
Related
How to print strings on Apex3 using printer command language or SDK?
I created a library for android application to print Bitmap images on mobile thermal printers:
Apex3, 3nStar, PR3, Bixolon, Sewoo LK P30 using appropriate SDKs.
It works fine but pretty slow, every ticket of 30 cm length takes 20-40 secs to print (it depends on type of printer).
For 3nStar and Apex3 I started to do improvements to speed up a printing.
For 3nStar I developed a class which prints a header logo and formatted text with spanish characters.
(different alignments and different fonts for different parts of a ticket)
so, the ticket looks very similar as Bitmap image but a printing time is only 6 secs.
Now I have to do the same but with Apex3. And here I got stuck.
How I do it on 3nStar for strings:
I send in outputStream bytes which are commands for printer what to do.
outputStream.write(some_bytes)
First command always is
{0x1b, 0x74, 40} //Esc t ( -- [ISO8859-15 (Latin9)]
to print spanish characters.
Then, in a loop, for n strings:
I choose a font
{0x1B, 0x21, 0x00}//Esc ! 0 -- 0 is normal, 8 is bold etc.
where changing last byte I print different fonts: normal, bold, two height, two width and combined fonts.
Next I choose an alignment
{0x1b, 0x61, 48} //Esc a 48 for left, 49 for center, 50 for right
Then I convert a string in bytes using ISO_8859_1 to print spanish characters and also write in outputStream.
outputStream.write(messageString.getBytes(StandardCharsets.ISO_8859_1))
And last byte to send is
{0x0a} // Move on next line
And the above approach doesn't work with Apex3, also I failed using
http://www.old.adtech.pl/upload/Extech_Printer_Command_Language%20Rev_H_05062009.pdf
even though on page 1 of that book is written that is fit for Apex3.
I think I miss something, I start to see how to do it using some SDK feature of Android_SDK_ESC_V1.01.17.01PRO.jar
but I would prefer to do that using direct writing of bytes.
Answers I found from this
manual
Shortly differences with the approach that I described for 3nStar are:
1)Before printing set a char set
ESC F 1 //Esc t - for 3nStar
2)Set a font for text, for example
ESC K 1 3 CR //ESC F 1 - for 3nStar
3)Send a line of text with alignment
For 3nStar I can use an alignment command before sending a text, like
ESC 1 49 //Centering
But for Apex3 I have to know a line length which depends on type of font, also a length of printing string,
then I get
freeSpace = (lineLength - printingString)
and set spaces at the begining of a line (right alignment),
at the end (left alignment) or devide them (centering).
So, for both types of printers I use the same logic which differs only in 3 places.
It is simplified explanation as a real code includes several classes with hundreds lines of code.
I've seen numerous questions/answers showing how to get temperature information from an Android device - using this approach:
int zoneNumber = 0; // Usually 0 or 1
String temperatureFileLocation = "sys/devices/virtual/thermal/thermal_zone" + zoneNumber + "/temp";
File temperatureFile = new File(temperatureFileLocation);
scanner = new Scanner(temperatureFile);
double temperatureC = scanner.nextFloat(); // Degrees C
...
scanner.close(); // finally
I wasn't really sure what each zone is for (i.e., in which part of the device the sensor is located) but I just discovered that there is also a file that describes the type of each zone - for example:
String zoneTypeFileLocation = "sys/devices/virtual/thermal/thermal_zone" + zoneNumber + "/type"; // NB - that's "/type" not "/temp" !
Now, when using Scanner to read in what type each zone is, I get values back such as this:
mtktswmt
mtktscpu
mtktspmic
mtktspa
mtktsabb
mtktsbattery
tsen_max
sec-fuelguage
Can anyone explain what locations/components all these zone names are actually referring to?
(Ideally, I would like to obtain the temperature of the device's NFC hardware.)
I guess that's the Hardware thermal sensors of the mobile. They usually give the temperature of the given zones when the mobile is working or even when you perform some benchmarks results.
like
mtktswmt is Wifi Chip temperature zone.
mtktscpu is cpu temperature zone.
mtktspmic is Multi IO and Regulator Chip temperature zone.
mtktspa is Thermal sensor MD1
mtktsabb is processor temperature zone.
mtktsbattery is the battery temperature zone.
tsen_max is the maximum temperature sensor capacity(I dont know for sure).
sec-fuelguage is the fuel gauge chip.
the mtkt prefix is just the name of the maker. In this case it is Mediatek
That's pretty hardcore hardware stuff. These are actually used by the makers of the android mobile phone(I guess). Even the above mentioned data is searched from google android open source project where the values were found in kernal drivers. Hence it's pretty hardcore hardware to play with it.
For using the Hardware Properties that actually gives you your desired results try HardwarePropertiesManager.
I hope it Helps.
I am using tess-two (Android port of Tesseract OCR engine). I am OCR'ing bills and receipts. I am using OpenCV 3.0 to preprocess the image. I have successfully made a bill into a binary image along with adaptive thresholding.
Original image:
Binary threshold of original:
Tesseract output.
PH:26051246/26145398
TIN=276302417620
CQSH/BILL
NO 009762 0 m 0 09-07-2015
DESCRIPTION on mm mu
_.__________
m 3.990 75.18 zoo-00
_____\
CASH 300-00
m: YOU----UISIT 9691!!
w TIN:276302417620
-\ c1 09:27:58 we no. 0
At present I have trained 3 dot-matrix fonts and two Merchant copy fonts. I have turned off the dictionary and added user-words for all five fonts. They are commonly used terms in Bills and Receipts. Strangely these changes don't seem to make any difference in the output.
I resized the image so that the font size is at least 12 pt. How do I improve the accuracy further? Can anyone specify a font or should I retrain the fonts.
I've designed a label with Label Vista (free Zebra software) and I went watching at the generated CPCL code, I noticed:
_TTF -23 0 0 400 0 0 0 0 2 34 [Arial] 117 16 Test TTF string
T Ari06pt.cpf 0 118 45 Test Uploaded font string
I've uploaded to the printer the Ari06pt.cpf generated font.
Then I've tried to print from Label Vista and all went OK! IT WORKS!
After that I've passed the code to my android application (JAVA with Zebra SDK) and I've tried to print, but in this case only the
"T Ari06pt.cpf 0 118 45 Test Uploaded font string\r\n"
works right.... the first line (_TTF) is NOT WORKING anymore (white line was printed)...
Some solution?
According to CPCL manual:
_TTF -23 0 0 400 0 0 0 0 2 34 [Arial] 117 16 Test TTF string
is not a CPCL command. However, LabelVista creates for some reason (??) this command using resident TrueType fonts of your desktop OS and converts it silently in printing time to a CPCL "T" command like that:
T Ari06pt.cpf 0 117 16 Test TTF string
So I think that you should check LabelVista output if it contains commands other than CPCL. You can also try ZebraDesigner editor.
I have worked with Zebra MZ320 and QL420+ and they accept only prescaled fonts (*.cpf files) in their memory. So try to convert a TrueType font to a prescaled font. You can convert it using LabelVista or Zebra Font Downloader and then upload it to your printer. You can follow this Zebra font convertion guide.
I have written a program to decode a CDMA 3GPP2 point-to-point SMS message. I tested it on a couple CDMA PDU hex strings I found on the internet, and it works perfectly. However, when I try to implement it on all incoming text messages on the Android platform, it always fails.
I took a look at the incoming PDU, and it doesn't seem to follow the same pattern I have been used to seeing. Can anyone explain what format this PDU is in, or what I am missing to correctly decode this PDU? Is there additional header or fields I am not taking into account?
Example PDU pulled from a incoming text message on my phone:
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
All of the CDMA pdus I found and tested my parser on look more like:
00000210020207028CE95DCC65800601FC08150003168D3001061024183060800306101004044847
Carrier: Verizon
Phone: Samsung Galaxy S Fascinate running Android 2.3.3
See the javadoc from $SDK/sources/android-16/com/android/internal/telephony/cdma/SmsMessage:
/**
* Creates byte array (pseudo pdu) from SMS object.
* Note: Do not call this method more than once per object!
*/
...so it's not following any particular CDMA standard. You can decode it however; so in fine ASCII art:-
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
--------messageType --digitMode --------bearerReply ------------------------------------------------------bearer data
--------teleService --ton --------------------src --replySeqNo --messageID --msts --userdata
--------serviceCategory --errorClass --len --XX--len --len
--numberMode --causeCode ------ ------------2012/06/24 20:56:11
--npi --------bearerDataLength ----------------------userdata
--len
Note that I think you made a cut/paste error in your message - the 00 byte marked 'XX' I think shouldn't be there - luckily it's easy to spot the date and work backwards. So this is a message from 6789101674 with userdata:
104C2CF9F3F5EBD73E7000, the first five bits of which show that it's 7-bit encoded (0x02). Having shifted the remainder of the userdata 5 bits to the left, we're left with:
09859f3e7ebd7ae7ce00
--len(septets) 9 septets == 63 bits, so we expect 8 bytes of body
----------------7bit-body
So your 7bit-body decoded is "Bggguuugg".