I'm having trouble with special characters (like â é ü) when using a custom font in my app.
For some reason, it's replacing the accented characters with seemingly random characters. I'm trying to set a UILabel's text to the word Château but both this:
myLabel.text = [NSString stringWithFormat:#"Château"];
and (
myLabel.text = [NSString stringWithFormat:#"Ch\u00E1teau"];
are setting the label text to Ch,teau. This is only happening when using the custom font, when I log the result in the console the correct character shows up. I've tried setting a different string encoding. These characters so exist within the font (if i type the same word in TextEdit, MS Word, etc it shows up fine), I've also validated and inspected the font in FontBook. It's an .OTF font.
Any ideas what's happening?
Not all font sets have all characters. Open the charactermap in windows load your custom font and see if it exists. It could be that the author of the font has in advertantly placed it at the wrong code.
Try:
[NSString stringWithFormat:#"Ch\u00E1teau"]
Note the forward slash was changed to a backslash.
PS: verified in real program.
Related
How to solve this for pdfbox with boxable.
I am getting in table.draw as
No glyph for U+000D in font Helvetica
What to do.I am building table with boxable
That error tells you that your strings you use to fill the tables contain CR (carriage return) characters.
Do not use control characters (like CR, LF, TAB, ...) in those string as your software stack does not interpret them to mean something like a line break; instead it tries to interpret it as a glyph in the font which it fails doing.
If you need to break lines in boxable tables, try using <p> or <br> instead. According to their README, they support
HTML tags in cell content (not all! <p>,<i>,<b>,<br>,<ul>,<ol>,<li>)
I met some problems when trying to make a PDF in French, for my project. It doesn't show special character like é , ò, ê.... (their code are for instance ê or ó)
So, thanks to this link I tried to include my own font but it gives this kind of messages:
PDF error: This font cannot be embedded in the PDF document. If you would like to
use it anyway, you must pass Zend_Pdf_Font::EMBED_SUPPRESS_EMBED_EXCEPTION in the
$options parameter of the font constructor
Do you have any idea to solve it? Thanks.
You can use default font. Just use encoding UTF-8 every time you draw a text.
$pdf = new Zend_Pdf();
$page = new Zend_Pdf_Page(Zend_Pdf_Page::SIZE_A4);
$page->drawText("Bonjour Hélène!", 705, 550,'UTF-8');
I'm using the following to define an NSString containing the Tab character:
#define TAB #"\t"
I'm writing a longer NSString to a file using writeToFile:atomically:encoding:error, using encoding: NSUTF8StringEncoding. This longer NSString contains TAB characters.
When I open the resulting file in TextEdit, I see a character that looks like a Japanese glyph in the place of the TAB character. Here is a screen shot of a line that is intended to have two tab characters, but which has these odd characters instead:
odd characters http://www.market-research-services.com/starpowermedia/for_distribution/tab-char-anomaly.png
What is the correct way to #define an NSString that will contain a TAB character to be written to a file of NSUTF8StringEncoding?
Thanks in advance to all for any info.
I recently discovered an issue with IE10. We have a web page that displays English text beside a translation in Japanese. Some of the Japanese characters display as squares. In the view source page all characters are correctly rendered. The database also has the characters correctly rendered. The unusual part is that when I block the characters with the cursor they convert to the correct characters.
IE10 I believe has a bug.
Anyone having similar issue or know of a fix? Checked all language settings, regional settings, browser font settings and many other tests. Nothing corrects this issue.
This issue was related to a dual byte character which some fonts and windows applications will support.
Some older fonts may use a two hex character representation to present a single character. Some fonts support this and some do not.
In this case the characters at issue were the following…..
ジ
シ and ゙
The latter two which I think are special characters that combined are intended to represent ジ.
The Unicode Standard from the Unicode ISO web site table defines them like so…..
Decimal Character HEX Name
12472 ジ 30B8 KATAKANA LETTER ZI
12471 シ 30B7 KATAKANA LETTER SI
12441 っ゙ 3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK (combined with small tu (っ))
So some fonts use 12471 + 12441 to make 12472. This is what I found. But the actual string has 12471 + 12441 and not 12472 or the hex: 0x30B7, 0x3099 and not 0x30B8.
Any time a font being used does not support this binding, a box is displayed. The challenge is that it may be as simple as someone creating a birthday card using a non-compliant UTF8 font that could cause a PC to not allow the character to display correctly.
i have some truetype fonts and a programm takes these fonts so that a user can select a font he like to put some symbols around. The programm save these information (which font name und character code) in a file. (I dont have the source of this programm)
Now i have to reed these file into another programm (vb.net) and get the character from the character code. And here comes the problem.
If i'll try chr(144) i'll get an empty char back ... but in the font which the user has selected befor, the character, which display a symbol, exists with the character ç.
Have i to load the font on runtime or what i have to?
I have tried already CharW(144) but with the same result: I'll get an empty char but i need to get the ç
Kind regards
Nico
According to the Extended Latin-1 code chart, ç is U+00E8 (232 in decimal) so I suggest you try ChrW(232).
The value returned by Chr depends on the current thread's default encoding (and I seem to remember it's possible to provoke some odd results) - I would try to avoid it if possible. If you know the encoding you need to use, then use it explicitly with Encoding.GetString etc. Otherwise, stick to Unicode values wherever possible.