Icon Font causes Compatibility Mode in IE8 - unicode

I'm having a problem where icon fonts are causing IE8 to go into Compatibility Mode. And correspondingly, if IE8 is forced into Edge mode (eg. via <meta http-equiv="X-UA-Compatible" content="IE=edge" />) then IE will crash.
Specifically, I have a custom icon font that I'm using, and it's currently mapped to the unicode Private Use Area of the Basic Multilingual Plane. The font starts at \f000 and goes up to around \f360.
I found a couple articles that suggest that assigning to the unicode Private Use Area is the problem:
http://adactio.com/journal/6555/
http://www.clockwork.net/blog/2013/10/08/657/how_to_avoid_forced_compatibility_mode_in_ie8_and_keep_your_custom_fonts
Things that I've tried to fix it:
Re-mapping the range to \e000 - \e360
(Glyphicons uses the \exxx range)
Re-mapping the range to \0000 - \0360
(includes the Latin range, Linguistic scripts, and Other European Scripts)
Neither of these solutions works though, IE8 continues to crash and/or go into compatibility mode. I haven't yet tried limiting the font to strictly the Basic Latin range because I have too many glyphs to fit in the 127 available spots.
I've also been able to get both FontAwesome and Glyphicons to crash IE8, also it seems to happen less frequently than with my font. Most of the time the initial page load will work, and then hitting refresh will cause the problem.
Anyone have any other ideas on what I can do?
PS: I'm not concerned about other IE8 CSS #font-face issues, like those discussed here IE8 CSS #font-face fonts only working for :before content on over and sometimes on refresh/hard refresh. I've already applied the techniques there to solve those issues.

Long story short, there are two ways to solve this:
assign to the Basic Latin Range : U+0020 to U+007F
assign to the Low Surrogates Range : U+DC00 to U+DFFF
I found this through unit testing various ranges with my custom icon font using a grunt-webfont build process.
I didn't exhaustively test every range, but I found these two to work, and to be sufficient.
Notes: The Basic Latin Range starts from U+0020 not U+0000.
The Low Surrogates Range has a larger address space, and so is preferrable if you have a lot of glyphs. It also has the advantage of rendering square boxes if the glyph fails to load, as opposed to assorted Latin characters as the Basic Latin Range does.

Related

Unity - Displaying Burmese (Zwagyi) text

We're currently developing a game in Unity (2019.4.28f1). This game is played internationally. We'd like to add support for languages other than common Latin written languages. Currently, we're trying to implement support for Burmese, but aren't making much progress.
Finding fonts to display Burmese isn't a big issue. As you can see in the image below, we manage to display all characters that are supposed to be displayed.
However, the big problem here is that the displayed order of symbols isn't the same as what it's supposed to be (see image below for the desired result).
We've tried several fonts that use either Unicode or Zwagyi encoding, but none of them seem to display characters in the correct order. Currently, we're using a padauk font from here, which is supposedly Unicode encoded. Then, within Unity, we applied to following settings to that font:
So, if one of you knows more about this and can share some information with me, that would be much appreciated!
Thanks.
We've already found a solution for this! Before setting the text of the text component convert the Unicode codes to Zwagyi and it'll display the text in the correct order!
All the credits go to this guy who put in the effort to make a tool for these use cases!
Of course, you still need a (Unicode) font that supports these (Burmese) symbols.
Example:
Text textComponent = GetComponent<Text>();
textComponent.text = mmfont.Net.Converter.Uni2ZG(yourUnicodeText);

How to build a font generator in iOS Swift and allowing pasting to clipboard

I'm now building a listview to display fonts from the UIFonts framework. However, for using UIPasteboard.general.string, the fonts are not copied to the clipboard and only the plain text is transferred.
I've tried including the MobileCoreServices framework and use kUTTypeRTF to implement it. But there is no detailed documentation on it.
May I know how can I build a custom font list and allowing the text be selected and pasted with its font styling onto the other applications (like Notes or Facebook post), just like the font generator hosted online?
I'm now working on the two following UIFonts, but I'm not able to keep its formatting while pasting from the clipboard.
let fonts: [String] = ["BodoniSvtyTwoOSITCTT-Book", "ChalkboardSE-Regular"]
You cannot copy-paste text with a font on your iPhone.
FancyLetters also cannot do this. It just shows you characters that look like they are printed.
For example, the letter "A" has variations: "𝓐", "𝒜", "𝔾". But this is not font-altered text, StackOverflow does not allow it either. These are characters from Unicode table. They are the same characters as "A" or "B", except that without special modifiers the keyboard will not print them for you, e.g. SHIFTOPTIONK = ïŁż.
Any font is superimposed over Unicode characters.
I recommend you to read an excellent article Emoji under the hood. It's about how emoji are drawn on devices, but it also explains a lot about the construction of characters and how they are rendered on different devices.
Or font generator also cannot do this. It just shows you characters that look like they are printed

What emoji plugin should I use: HTML or Image?

I have two plugins to choose from. It will be used on a forum type script. I like the idea of HTML emojis (i.e. 😃 😃), however, each device is going to show their own styles and some devices (ipads as an example) do not render some HTML emojis.
With image emojis (i.e. <img class="emojis" src="/img/smiling_face.png">) there will be uniformity across all devices and browsers.
I am still not sure what to choose. If it was up to you, what would you use for your forum?

Prevent Emoji Characters from Showing

I use a few special uniode chars in my app, but since iOS 5 these have been replaced with emoji characters. How can I force the unicode characters to be displayed and not the emoji characters? Thanks
This is an old question but it plagued me a lot recently until I found the answer.
Just add '\U0000FE0E' after the character that we want to prevent from becoming an emoji.
For example:
#"▶" // should be written as:
#"▶\U0000FE0E"
Using the escaped unicode works as well:
#"\u25B6" // should be written as:
#"\u25B6\U0000FE0E"
We need to use Unicode variants to prevent certain characters from becoming emoji.
Here is the article that solved my problem.
Just to add to BFerer's helpful answer, I found this works similarly in Swift:
"▶\u{0000FE0E}"
There's a few mentions of this issue on Apple's private devforums (which you have access to if you're a registered member of the iOS developer program).
It sounds like the potential solution would be to explicitly set the font for whatever you're trying to display.
Use "Hiragino Mincho ProN" for the font. It worked for me, but unfortunately I had to change the insets to make things look correct. I had to add an inset to the top to place things as they were before the iOS update.
All the credit goes to Kevin Ballard who answered my post in the following discussion -
Unicode characters being drawn differently in iOS5

how to use custom font in html pages for UIWebView?

I am having the "Futura.ttf" font file.
I am displaying a HTML page in the UIWebView, but my requirement is that i want to use the custom font in my css file.
so is there any way that i can use the custom font in my css file ???
All suggestions are welcomed.
Thanks.
It is possible to load custom fonts into your UIWebView in iOS3.2 and above. Add the font to your bundle (see here) then just reference the font in your UIWebView's stylesheet like you would any other font:
<style type='text/css'>font { font-family: DroidSerif; } </style>
You have Cufon and sIFR as your options.
Typeface.js is a pure JavaScript Replacement
Cufon is a pure JavaScript Replacement
sIFR is Flash and Java font implementation,
FLIR JavaScript and PHP implementation
Some Comparisons
http://thatguynamedandy.com/blog/text-replacement-comparison
http://thinkclay.com/technology/cufon-sifr-flir
http://aaronwinborn.com/blogs/aaron/cufĂłn-alternative-sifr-image-replacement
Below is taken from this question Worth reading the whole thread, has greatdetails.
Typeface.js
Advantages:
User doesn’t have to have Flash
plugin installed on their browser
Easier to create with just a few
lines of Javascript
For page loading it just needs to
load the Javascript
Disadvantages:
Text is not selectable because it
outputs it like an image. I looked at
some examples, right clicked on a
word and had to view as an image.
Every single word had this behaviour.
Big thumbs down.
Usage for body copy will slow down
loading time, so it is recommended to
use only for headlines.
Cannot be read by screen readers
Visual looks blurry
Not all browser compliant and still
has a lot of development left to be
done
sIFR
Advantages:
Can be read by screen readers as a
normal headline because it is a
behaviour layer on top of the markup
and styling.
Text is selectable
SEO friendly
Displays text as is like any other
web font. Crisp and not blurry!
Has addons like jQuery sIFR Plugin!
Disadvantages:
Requires Javascript to be enabled
Flash plugin must be installed in the
browser
Need Adobe Flash Studio to create it
BUT there is a pretty nifty sIFR
generator that creates the file for
you!
For page loading, it has to request
for Flash, Javascript and CSS files
attached to it, which can potentially
get bogged down if you are using sIFR
in too many places.
Cannot display on an iPhone. Yet

CufĂłn (similar to Typeface.js)
Enter CufĂłn, the Javascript-based font replacement solution which makes heavy use of canvas and VML. This offers a great alternative to other solutions out there - no Flash or images required.
There are some issues with using CufĂłn on a live site, the most notable being the inability to highlight and copy/paste text, which is really the biggest issue for your site's users.
Combine that with the EULA issues, which prevent you from being able to legally embed fonts in Javascript files for most fonts on the market today.
The other issue is knowing what fonts can be used with CufĂłn. For sIFR, most fonts are fair game, since the font is embedded in a Flash movie, which is typically an approved usage by most font foundries for most fonts. With CufĂłn, the Javascript files used for the font can be easily "stolen" and either used on another website or reverse engineered.