I have some special characters in my French content. When i see the characters in XAML code, i can see the proper text in visual studio. But while running, the text is not getting rendered properly.
For example: <TextBlock xml:lang="fr-CA" Foreground="Black" Text="Bay Nº doit contenir uniquement caractères alphabétiques ou numériques"/>
In the given text, the underscore which we can see after N and below o is missing while running on the page.
Has anyone faced this issue/does anyone have any idea on resolving this issue?
So I think what you're running into is an issue between ordinal and numero in which case a workaround would be to just implement the Numero unicode hex directly as the character set instead of translating a single ordinal.
Numero hex : №
Shown as example which should render as desired both in designer and at runtime;
Hope this helps, cheers!
Related
I´m developing an app in xamarin and I have the next scenario.
I have a label with maxLines = 3, for some long words in german or french the line break doesn't separate the words syllabels correctly, for example the correct separation of the word "Bezirksschornsteinfegermeister" is "Bezirkss–chorn–ste–in–fegermeis–ter" but in the app is showing like this
It should be Bezirksschorn(First Line) steinfegermeister(Second Line)
This is my code
<Label
Margin="24,0,24,14"
FontSize="18"
HorizontalTextAlignment="Center"
LineBreakMode="TailTruncation"
MaxLines="3"
Text="Bezirksschornsteinfegermeister"
VerticalTextAlignment="End" />
The line break for long words works fine for english words but not for german or french words. There is any library that make a correct line break separation for german and french?
If you go through the options for LineBreakMode in the official docs as below:
HeadTruncation – truncates the head of the text, showing the end.
CharacterWrap – wraps text onto a new line at a character boundary.
MiddleTruncation – displays the beginning and end of the text, with the middle replace by an ellipsis.
NoWrap – does not wrap text, displaying only as much text as can fit
on one line.
TailTruncation – shows the beginning of the text, truncating the end.
WordWrap – wraps text at the word boundary.
Obviously,we can't divide a long string into separate words.You may need add spacing or other characters to separate words.
This isn't a Xamarin issue, if you are testing on Android then German language is not supported, only English, check this issue. Not sure about the iOS.
I am working on someone's strange code and it is changing emoji characters to strange values.
This is what I wrote:
It changed into:
Can someone let me know what could be happening?
Go to Edit->Emoji and Symbols in Xcode.Type the name of symbol you want to use(in your case heart).Copy it.Then paste it the way you want. Eg:_mylabel.text=#"♥︎";
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 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.