I have made an applications which has specific font (handwriting.ttf), it works absolutely fine in application but when I email the text written in this font through my application - the font becomes gibrish on receivers end (the reason is that receiver does not have this perticular font in his computer)
I have seen another application that sends text via email using custom font.
This gives me confidence that functionality like this works - but I dont kow how?
When you say gibberish, do you mean that the user is seeing the copy, but with the alignment and other graphical elements getting screwed up, or that you literally see something entirely incomprehensible. I would have expected your font tag to have a series of fonts and that the email would have fallen back to one of the more standard fonts if the attempt to use the custom font failed. Please update your original question with (a) the code that you're using to create your email body, as well as (b) a screen snapshot of how it's rendered in the email client.
Two immediate suggestions:
If you know of other apps that are sending email with a custom font (which I'm surprised by, but I'll take your word for it), have one of them send you an email and then view the source of that email and see what it's putting in the email's html and examine how it's doing it;
Most emails I get that are employing specialized fonts are also incorporating all sorts of graphical elements and it's sending the email as an image (which you can either embed in-line in the html-based email using base64, or put on some server and link to the <img> there), frequently with a text rendition, too. You can use Quartz 2D to create those images that you then embed in your email. Clearly this won't work in all situations, but using images for the body of the email, or PDFs (which you can also generate from the app) for attachments seems to be more common.
Personally, I'd shy away from embedding custom fonts in the html body of the email because you're subject to the vagaries of how the user's email client renders custom fonts, if at all. Plus you'd want to do some exhaustive testing, examining the email in different email clients (as #meccan's commented link had done). If the look and feel of the resulting email are critical and highly stylized, and if the content of the email is relatively short, I'd lean towards option 2.
Related
Gmail actions seem like a really cool feature, but their placement at the far right of the subject line means I invariably miss them, even when I know they exist (i.e. for a MailChimp confirmation email).
It would make a lot more sense to me to place these buttons inside the email, as part of the regular content. Is this supported by the current API? Or are there any plans to support it in the future?
There are plans to show more interactive cards like the ones currently used for flight reservations, but for the moment actions will only be shown on the subject line.
There are no plans for the API to add buttons inside the email as part of the content, as the content is HTML defined by the sender and HTML already supports buttons.
I'm trying to move my app to use UIActivityViewController, rather than UIActionSheet, so that I get the fancy graphical sharing buttons rather than the textual buttons. (My app is targeted at iOS 6 only.)
After trying to work with it for a couple nights, it seems either I am totally misunderstanding how to use it, or the current implementation by Apple is terrible:
You can't specify a different message for different services. If I want something that will work across: Mail, Facebook, Messages AND Twitter, it's going to need to be 140 characters max, to work on Twitter. Is there a way to set custom content for each type of activity?
There appears to be no way to set a subject line or recipient for Mail messages. I've read the docs, they make it sound like this might be possible with an NSURL that uses the mailto: protocol, but in my tests, those URLs just get shoved into the message body. Is there actually a way to set the subject line and optionally, the recipients?
If I want to work around these shortcomings, and do my own custom activities by subclassing UIActivity, I have to use a custom image/icon. Therefore, I can't mimic the Mail activity with Apple's official icon, and e.g. implement my own custom activity backend that actually lets me set the subject line, recipients, custom body, etc. Am I wrong, is there a way to use Apple's service icons, but have a chance to customize the behavior? (The only callback I see is one that runs AFTER the activity has been completed, right?)
I hope I'm wrong!
Is there a way to set custom content for each type of activity?
Yes, I guess you should subclass UIActivityItemProvider and override method –activityViewController:itemForActivityType: with your logic (e.g. trim string to 140 chars for Twitter).
Then pass an instance of this class to -[UIActivityViewController initWithActivityItems:applicationActivities:].
Is there actually a way to set the subject line and optionally, the recipients?
You are right, the mailto scheme should be able to set these fields. If it is not working, I consider this as bug. (Didn't try this myself, but I will give it a check.)
Is there a way to use Apple's service icons, but have a chance to customize the behavior?
I think you can't do this. (Unless you want to hack those system activities.)
You are better off using a custom component that behaves like UIAcitvityController as it is quite limited, as you noted.
This is one example: https://github.com/hjnilsson/REActivityViewController , I just forked it from https://github.com/romaonthego/REActivityViewController to allow you to set the email subject field.
I am searching for a way to take the current text written in a text box and transfer that to a list, and after the list is full, send that list to an e-mail.
To make better sense of this, I'll explain. I help out at a youth ministry where the kids are required to check-in at the door. Instead of writing names down on paper, I have been tasked with designing an app so they can just type the name on an iPad. Once the kid hits "Submit" button, I would like their first and last name (different text boxes, but could conjoin if easier to code) to be added to a never-ending rtf file or something of the sorts. This rtf file would then be e-mailed to me so I could keep an online roster.
I have all the buttons and fields in place, I just cannot figure out how to code the submit button to handle the function of placing the current text from the linked boxes in a separate file. If it can't be rtf, I don't really care. Just wanting something I can e-mail back to my Mac to save time. If anyone knows how to do this, or somehow finds a site that I missed during my continued scouring of the Internet, please let me know your solutions.
Blessings,
Kyle Baity
You can have an NSMutableArray to which you add new name strings as they are submitted, you can then make this into a string list using componentsSeparatedByString:. This allows you to sort and count the names easily if you want to add more features later on.
It's not clear how you want the email to be sent, but MFMailComposeViewController would be a good start, using your list string as the message body.
I have a blogging application. Once a blog-post is created by a user, it will be sent as an email to some of user's friends. I want a functionality where the friends will just reply to the email and the content of the email will go as comments for that particular blog-post.
One way to do this is to do something similar to what http://ohlife.com does. It basically creates a unique ID per user per day, has the reply-to attribute of the email set to post+{unique_id}#ohlife.com and probably parses this field to know which user is the email for, when it gets received. But it really has only 1 email address which is post#ohlife.com. The part after the "+" get's ignored by email servers. This also is applicable to gmail.
What I wanted to know, is whether this property is for particular email servers or is it universal? If it is not universal, is there is email server independent way of implementing this? I would not want this to be based on the email subject, as it's the trivial solution I know of.
it is depending on your mail server and how it is configured.. (although it is quite a standard) - for example in postfix:
recipient_delimiter = +
you could set it to anything you like .. i once configured it to be a dot so i can use it all over the web.. http://www.postfix.org/postconf.5.html#recipient_delimiter
but you could simply make it configurable in your application as well..
Besides using the email subject or address, one other easy way to accomplish this would be to just stick an identifier number at the bottom of the outgoing email's body. It would then come back to you in the quoted part of the response message. This is much less obtrusive than putting stuff in the subject or address, and if you're using HTML messages you can even make the code invisible.
I'm currently coding all of the account management functionality for my site, and have already implemented the account activation and password reset systems by e-mail. The e-mails each contain a link to a servlet (with the appropriate parameters attached to the end), which does all the processing. Tests for the systems have gone well, however I have one question.
If the link's text is the same as its address, is there any reason to include traditional manual activation/password reset page (a page with a form where the request parameters in the activation or reset link would be entered in to the appropriate fields)? If the link doesn't work in the e-mail, the user can always copy and paste it. Is there any particular reason why sites still have seperate pages dedicated to these actions? And should I allow it?
You never know for certain the kind of transformations your email will undergo before being displayed to the person that will eventually use your reset facility. Combined with clueless users this may pose a problem.
An example: Since reset/activation links can be quite long they may be partially wrapped onto a new line after a transformation from HTML to plain text. Inevitably this will someday happen to a user that does not know how to deal with that situation.
Therefore it might prudent to provide the backup method of just entering the code in a text field which on submit performs the GET that was intended in the first place.
You are of course free to decide that your site does not need the business of said type of user and skip implementation of the manual method!