I'm using Sabre/vobject (Documentation GitHub) using php to create vCard version 3.0.
As stated in the format of vCard
Content lines SHOULD be folded to a maximum width of 75 octets
The Sabre library handle it correctly and fold the lines in the right place. When adding the vCard to iPhone contacts app, all works as expected. On Android when the address is less than 75 bytes all works well, but once the address is longer and the content folds into multiple lines, the address doesn't appear on the contact. At least when using the default contact app on Pixel 3, Android 10.
If I change the vCard manually, and keep the whole address in one line of more than 75 bytes, not as expected by the format, then the contacts app is adding the address well.
Is it just a bug on the Android contacts app? I didn't find anything about this issue. Am I doing something wrong? Any solution?
The following vCard, doesn't add the address to the contact on Android
BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 3.4.5//EN
FN;CHARSET=utf-8:vCard test 3
N;CHARSET=utf-8:test 3;vCard;;;
ADR;TYPE=work;CHARSET=utf-8:;;336 Rue Saint-Honoré;Paris;Île-de-France;75
001;France
GEO:48.865928, 2.330285
EMAIL;TYPE=work;CHARSET=utf-8:abcdef#gmail.com
TEL;TYPE=mobile:+1 212 1234 5678
TEL;TYPE=landline:+1 977 1234 5678
TITLE;CHARSET=utf-8:CEO
END:VCARD
The following vCard add the address to the contact. Please note, the format is wrong the address line has more than 75 bytes.
BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 3.4.5//EN
FN;CHARSET=utf-8:vCard test 3
N;CHARSET=utf-8:test 3;vCard;;;
ADR;TYPE=work;CHARSET=utf-8:;;336 Rue Saint-Honoré;Paris;Île-de-France;75001;France
GEO:48.865928, 2.330285
EMAIL;TYPE=work;CHARSET=utf-8:abcdef#gmail.com
TEL;TYPE=mobile:+1 212 1234 5678
TEL;TYPE=landline:+1 977 1234 5678
TITLE;CHARSET=utf-8:CEO
END:VCARD
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 am trying to use Tesseract OCR on Android to read the state of a gas meter when you take a picture of it:
This is the output when I parse this image:
vb"
22% BK-G4T ||||||||I||||I|||ii\|||\
’ 64 2007
22?: 06.0"! 'm'lm Mm. 23212274 ,
v 2,0 dm’ 1
pmn 0_5 bar tm ~25°C v‘40"(1 I
1amp é 0_o1m’ sb15°cl :Sp 20°c l
'I ELSTEQ~I¢¢>>InstrogwnSs HB Z _ 18 _ 1013 . ‘
a, 069373593435- 3 I
i'23212214 Y _ w w V'
g
The idea is to extract the first 5 digits of the state of the gas meter ( 06937 on this image ).
My question is, is there a way to train Tesseract to only parse this part of the image? Absolute coordinates are not an option since every picture would be different. I am guessing the best logic would be something like: parse only white numbers on black background.
By changing the page segmentation mode (psm), tesseract 4.00.00 alpha is able to read the meter line characters correctly as 06937598-m3 apart from other characters.
The command used is:
tesseract meter.jpg output --psm 11 -l eng
--psm 11 means to recognize "Sparse text. Find as much text as possible in no particular order".
Here is the output file with showing all the ASCII control characters.
If --psm 11 works on other meter images, then you could just need to search -m3 at the end of the line to extract the who meter line characters. With that, you can get the first 5 digits right away.
Hope this help.
I used twitter4j to post tweet include image and text in android. My text has been truncate to less than 140. But I wonder why the server response over 140 characters exception.
Here is my try:
message = trimTweet(message); // guaranteed max length is less than 140
StatusUpdate status = new StatusUpdate(message);
if(bitmapUri != null){
status.setMedia(new File(getRealPathFromURI(getApplicationContext(), bitmapUri)));
}
twitter.updateStatus(status);
The server response:
10-23 19:18:00.842: E//NewsActivity.java:280(25288):
TwitterException{exceptionCode=[b2b52c28-11aaaacd], statusCode=403,
message=Status is over 140 characters., code=186, retryAfter=-1,
rateLimitStatus=null, version=3.0.4}
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:162)
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientWrapper.post(HttpClientWrapper.java:98)
From debug, I can see my tweet message less than 140 characters (sometime is 138 or 139). But when I try to send only 108 or 110 characters, it sent success. Then I wonder twitter4j add my image to tweet text. Is that right?
How can I send image and text with only 140 characters?
Finally I figured out my problem. When adding URL or image, Twitter limit characters down to 118. That 's sound stupid, I think. From this link: http://mediacause.org/10-nonprofit-twitter-tips-140-characters/
We all get tripped up by just how limiting 140 characters can be (it
sounds like a lot until you start typing). Add in a link or a photo,
and your character count for accompanying text is cut down to 118.
Keep this in mind when crafting tweets and include text that gets
straight to the point
Update: Thanks to #Aggressor, now twitter updated limit link depend on the URL that gets t.co wrapped.
The https steals away 23 characters(it was 21), so you have only 117 characters for text.
For non https url, you have 118 characters (wrapped url is 22).
Https:
Http:
I found from the twitter documentation that while Tweets are still limited to 140 characters, the character counting model has evolved over time. Tweets are UTF-8 string content and any UTF-8 character counts as a single character. Strings that are understood as links, such as "http://twitter.com", "twitter.com", "twitter.com/twitterapi" will be automatically converted to t.co. t.co links represent a variant character count (currently "22" for HTTP-based links and "23" for HTTPS-based links). See How Twitter wraps URLs with t.co for more information on how t.co plays a role in character counting. Counting Characters provides more details on character counting strategies.
Use GET help/configuration to programmatically keep track of t.co wrapping lengths. The fields "short_url_length" and "short_url_length_https" will indicate the current lengths.
I need to read MSISDN in android, but we must use .c to finish it.
I open a socket to send RIL_REQUEST_SIM_IO to ril. Here is the log.
D/RILC ( 106): [0004]> SIM_IO (cmd=0xB2,efid=0x6F40,path=3F007F10,1,4,30,(null),pin2=(null),aid=(null))
...
D/RILC ( 106): [0004]< SIM_IO {sw1=0x90,sw2=0x0,ffffffffffffffffffffffffffff0891684125205260f5ffffffffff}
Did I use the right parameters (P1 = 1, P2 = 4, P3 = 30)?
And how can I get the mobile phone number by response?
Thank you!☺
What is your confusion here? You wanted to know what you told the card? All this information is in ISO 7816-4 and a few other specs, but here's the details of what you did:
You sent a read record command to the SIM (0xB2)
You asked for the Path:
3F00 -> (MF)
7F10 -> (DF_TELECOMM)
6F40 -> (MSISDN)
You set parameters:
P1 (record) = 1 (record 1)
P2 (reference control) = 4 (this mean use record number set in P1)
P3 (Le meaning bytes to read) = 30 (bytes)
and you got back success (SW stands for status word, you got SW1/SW2 = 0x9000 which means success) and the data (0xffffffffffffffffffffffffffff0891684125205260f5ffffffffff)
Checkout E.164 on parsing your MSISDN.
the data (0xffffffffffffffffffffffffffff0891684125205260f5ffffffffff) yes it contains MSISDN
----08 = means the Length of dial no
----91 = means MSISDN Internatioal dial No
the rest (684125205260f5) value u nid to swap it side by side of each 1 byte. example 68 swap 86, 41 swap 14...so on then u will got the MSISDNnumber.
In case it helps some1 later on:
Encoding can be found on TS 51.011. File is called EF_MSISDN. Its identifier is 6F40.
MSISDN is preceded by its length, then the TON/NPI. It is also in a BCD inverted format
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".