TexDiff compares two .tex files by showing the differences in different colors. It is really helpful for tracking the changes during the process of thesis revision. Here is the instruction of installation and usage.
Step 1: Download and Unzip
(1). Download latest wdiff from the link below:
http://robmar.net/TexDiff/wdiff-0.5g.tar.gz
(2). Unzip: tar -zxvf wdiff-0.5g.tar.gz
Step 2: Compilation
(1). cd wdiff-0.5g
(2). ./configure
(3). make
(4). sudo make install
Step 3:
Copy the script texdiff to /usr/local/bin/ (Download texdiff from the link: http://robmar.net/TexDiff/texdiff)
Step 4: Usage
texdiff sample.tex sample-old.tex sample-diff.tex
Step 5: Make pdf file out of sample-diff.tex
REF: http://robmar.net/TexDiff
Thursday, July 22, 2010
Tuesday, July 6, 2010
BlackBerry: Email Bug from RIM
I found this interesting bug BB has for versions before 4.6 and here it is:
There are two possible options in the menu list to delete the address in email address fields. One is "delete field" and the other one is "clear field". "clear field" does not always show up in the menu list depending on how's the address like. If the address is only selectable as ONE whole content instead of as text (which is able to be deleted character by character), the option of "clear field" won't show up.
The bug happens when users 'delete' the address using 'clear field', what RIM does is, the address won't show in the field, however when the email is sent, the address got clear-fielded is still an address to which the email sent. This bug only happens with "Reply" functions. (RIM's bug!)
Why it is not noticeable is because that when users type in the addresses, most of the cases, the addresses shown are selectable only as ONE content. I believe RIM has some secret internal method does that, which is not revealed to 3rd party developers.
There are two possible options in the menu list to delete the address in email address fields. One is "delete field" and the other one is "clear field". "clear field" does not always show up in the menu list depending on how's the address like. If the address is only selectable as ONE whole content instead of as text (which is able to be deleted character by character), the option of "clear field" won't show up.
The bug happens when users 'delete' the address using 'clear field', what RIM does is, the address won't show in the field, however when the email is sent, the address got clear-fielded is still an address to which the email sent. This bug only happens with "Reply" functions. (RIM's bug!)
Why it is not noticeable is because that when users type in the addresses, most of the cases, the addresses shown are selectable only as ONE content. I believe RIM has some secret internal method does that, which is not revealed to 3rd party developers.
Saturday, July 3, 2010
Email Structure in BlackBerry
This post will show you the structure of BlackBerry emails.
1. API: Mulipart->BodyPart
First, let's take a look at the Email API under net.rim.blackberry.api.mail.Multipart and et.rim.blackberry.api.mail.BodyPart
These two classes provide the components which consist the emails. An email is a multipart containing multiple bodyparts. It is a tree structure. Each bodypart can contain multipart as well. Therefore if you want to retrieve the information of an email, you need to do it recursively. See reference [1].
The key subclasses of BodyPart are TextBodyPart, MimeBodyPart and SupportedAttachmentBodyPart. The not so convenient part is that the method of "setContentType(String value)" in Class BodyPart is currently not supported, which means although the 3rd party apps can add bodypart to an email, it cannot sign the specific type to a bodypart (for example, 'text/html' content-type), which constraints the 3rd party apps abilities to control the emails.
[TextBodyPart]
BodyPart with 'text/plain' content-type. This class is used when creating a multipart message that includes a text/plain part.
[MimeBodyPart]
This Class represents a MIME body part.
MIME Definition:
The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters. This effectively limits Internet email to messages which, when transmitted, include only the characters used for the English language. MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs.
[SupportedAttachmentBodyPart]
Represents an attachment part that has a corresponding viewer on the handheld, including registered third-party viewers.
2. Relation with Class net.rim.blackberry.api.mail.Message
In Class Message, there is a method setContent(Object o). Object o can only be String or Multipart. Therefore, the connection between Message and Multipart is: Message.setContent(Multipart).
3. Notes:
(1). MimeBodyPart does not support signing any content (Method: setContent(Object o)). Therefore, to construct emails, TextBodyPart and SupportedAttachmentBodyPart should be used.
(2). UnsupportedAttachmentBodyPart is not publicly instantiatable.
3. References:
(1). Retrieve Email Information:
http://rim.lithium.com/t5/Java-Development/Access-HTML-email-messages/ta-p/444941
(2). Attach HTML File to Emails:
http://supportforums.blackberry.com/t5/Java-Development/Create-an-attachment/ta-p/445025
1. API: Mulipart->BodyPart
First, let's take a look at the Email API under net.rim.blackberry.api.mail.Multipart and et.rim.blackberry.api.mail.BodyPart
These two classes provide the components which consist the emails. An email is a multipart containing multiple bodyparts. It is a tree structure. Each bodypart can contain multipart as well. Therefore if you want to retrieve the information of an email, you need to do it recursively. See reference [1].
The key subclasses of BodyPart are TextBodyPart, MimeBodyPart and SupportedAttachmentBodyPart. The not so convenient part is that the method of "setContentType(String value)" in Class BodyPart is currently not supported, which means although the 3rd party apps can add bodypart to an email, it cannot sign the specific type to a bodypart (for example, 'text/html' content-type), which constraints the 3rd party apps abilities to control the emails.
[TextBodyPart]
BodyPart with 'text/plain' content-type. This class is used when creating a multipart message that includes a text/plain part.
[MimeBodyPart]
This Class represents a MIME body part.
MIME Definition:
The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters. This effectively limits Internet email to messages which, when transmitted, include only the characters used for the English language. MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs.
[SupportedAttachmentBodyPart]
Represents an attachment part that has a corresponding viewer on the handheld, including registered third-party viewers.
2. Relation with Class net.rim.blackberry.api.mail.Message
In Class Message, there is a method setContent(Object o). Object o can only be String or Multipart. Therefore, the connection between Message and Multipart is: Message.setContent(Multipart).
3. Notes:
(1). MimeBodyPart does not support signing any content (Method: setContent(Object o)). Therefore, to construct emails, TextBodyPart and SupportedAttachmentBodyPart should be used.
(2). UnsupportedAttachmentBodyPart is not publicly instantiatable.
3. References:
(1). Retrieve Email Information:
http://rim.lithium.com/t5/Java-Development/Access-HTML-email-messages/ta-p/444941
(2). Attach HTML File to Emails:
http://supportforums.blackberry.com/t5/Java-Development/Create-an-attachment/ta-p/445025
Subscribe to:
Posts (Atom)