I've created a webapp that uses SVG to allow the user to create an image. Because I want the user to be able to export that image as a PNG, I've embedded a number of fonts directly into the SVG as Base64 encodes (I converted the fonts using FontSquirrel). Everything works just fine under OSX (where I am developing) on all major browsers.
I have limited ability to test Windows machines, but one of my beta test users is having a problem where certain characters render incorrectly under Windows (Firefox or Chrome that we've tested so far). So far, it appears to affect the letter 'g' and the number '8'. Here's what they look like:
I'm pretty stumped... not seeing anything about this on SO or other sights about embedding fonts as Base64. Do I need to set up my encode on font squirrel differently to accommodate Windows or something?
Update: Thanks to Mike for the testing environment link. I took a look at this and it appears to have been an issue with the encoding of my font. It was present on all versions of Windows (7, 8, and 10) and browser combos. After some frustration I redid the font squirrel encode (which I had tried previously) and suddenly everything worked. I don't know, but if someone finds this, I guess re-encode.
Related
I have an application for iOS and macOS. These apps are using Cloudit to share information between (Core data). I am storing NSAttributedString created on one platform (for example iOS) in core data attribute, which is defined as Transformable type of attribute so core data uses (I assume) default NSCoder to code/decode NSAttributedString data.
Now my macOS app can read data from iCloud including this NSAttributedString and view/edit them. But this NSAttributedString looks completely different on macOS (and vice versa)
Not only size (which I understand, because default size on iOS and macOS is different - so I need to adjust size) but I lost my formatting (bold, italic, etc.).
So it seems like font attributes for UIFont and NSFont are not compatible, am I right? I am using standard fonts - for example on iOS UIFont.preferredFont(forTextStyle: .body)
Maybe I have to store NSAttributedString as something else (for example convert it to RTF/HTML data and share them that way) in iCloud and during reading convert RTF/HTML again into NSAttributedString. I am not asking how to do that (I know it) but I am asking if I have to do that to have NSAttributedString compatible (at least from formatting point of view) on all used platforms.
I cannot find anything regarding this on web (maybe I searching with wrong keywords). Does anybody have experience with sharing NSAttributedString between platforms (iOS, macOS)?.
Are there are any recommendations for that?
Thanks for advice/help in advance.
Solution
Finally I found the solution. The problem is that UIFont.preferredFont(forTextStyle: .body) returns a font that is not recognized on macOS platform. Therefore macOS instead of using this unknown fonts used Times New Roman for plain, bold and italic variants and this is the reason why I lost some formatting information on the way from iOS to macOS application.
Solution is simple. Instead of using standard font returned by
UIFont.preferredFont(forTextStyle: .body)
it's better to use font that is available on both platforms (for example Arial). No need to convert NSAttributedString into RTF/HTML and back.
I would like to make a change to an open source Android app which uses the Bravura font implementing the Standard Music Font Layout (SMuFL) fonts. I am developing on Linux.
The app displays musical notes with things like
<string name="notef_c5"> == ==</string>
which is displayed like
I now need to change things and I would like to see what I am going to do, rather than semi-randomly changing the Unicode numbers and see what happens. So I installed the font on my Linux desktop from github, by simply copying the SVG that the app is using into my global font directory and that did not work (fc-cache said /usr/share/fonts/svg/Bravura: caching, new cache contents: 0 fonts, 0 dirs). The same procedure for the OTF did work. This could be a problem down the line, since the app is using slightly modified version of the SVG, so any hint on that could help, but it's secondary regarding the question.
In fact I want to use "something" to display the font, and I tried many things, including Charmap and FontManager (which is almost the same as FontViewer). Charmap is the worst, displaying basically every single font installed on the machine even if I select just the Bravura (why is that???!) -- FontManager does the same (???!) -- FontViewer is almost passable, in that (when the "Characters" tab is selected) it display empty squares for the characters not defined in Bravura. Therefore with lots of careful scrolling it displays the "actual things" I am looking for, but it does not show their unicode values, and it's an extenuating search of few actual characters in a huge ocean of empty squares. So it's a no go anyway.
Is it possible that the best solution is just to blindly type Unicode values as described in the docs and see what happens? I know, if I were running Windows or Mac I could use Dorico SE but more generally there must be a better way of using Unicode in Linux, perhaps built for other purposes?
If you’re looking for specific symbols in the SMuFL specification, the full list of glyphs is available on the SMuFL website. (Note that the fonts themselves know nothing about music typesetting, they are simply collections of shapes to be used by a typesetting program. Even the simple example you provided is a composite of several carefully scaled and positioned glyphs, and simply changing the character codes may or may not work as intended.)
If you’re looking for ways to input Unicode characters on Linux, see the many suggestions provided here: How to type special characters in Linux?
I'm using MS Office 2016 One note on windows 10.
On my PC, when I put box-drawing characters as like this : ┴┻┷┸┸┵┶┹┺┐┐┘├┬┬┤┴┼┣┳┼ on OneNote 2016 on Windows 10 those will be shown as ⍰⍰⍰⍰⍰⍰⍰⍰⍰┐┐┘⍰⍰⍰⍰⍰⍰⍰⍰⍰. Some of these seem like a missing glyph, but some of those are displayed properly, I've changed fonts but I still get the same result. I've also tested it on different office 2016's products but this only occurred on OneNote 2016.
Any possible solutions?
The reason why this doesn't work has nothing to do with the fonts as you've found. OneNote simply doesn't support unicode as has been reported here and the same issue, but more generally can be found also in this article.
As the following excerpt about the Windows 10 Edition(but should mostly apply to other versions as well) explains, a font fallback system is used for most applications to help them display characters not in a font.
All Windows 10 editions include fonts that provide broad language support, and the Windows platform includes font fallback mechanisms designed to ensure that text in any language always displays with legible glyphs rather than boxes. But some apps may take direct dependencies on particular fonts for displaying certain Unicode characters and do not utilize the font fallback mechanisms provided by Windows 10 systems"
(emphasis mine)
However this explanation neglects how Windows actually uses fonts and why a font fallback is necessary. The way that most applications in Windows handle text is:
Find the font it wants. Depending on the application it might look for a font file that comes bundled with it, or looks for the font in the Windows Font Directory if it's a commonly used font.
Displays the characters the chosen font supports. This contains characters to display, but not all of them, as there are 137,174 Unicode Characters and designing a single font for all of them is impossible because a font file simply can't contain that many characters.
However there are font families that are attempting to do this such as Google Noto.
Uses "font fallbacks" if the application uses them to display unsupported unicode. Windows knows that no font file can support all Unicode Characters so it has a system that inserts fonts for different languages and sections of Unicode.
Older applications such as OneNote may support sections or languages of this in a more manual way, but ultimately doesn't use the font fallback system, and so doesn't support all Unicode Characters. Which leads to the next step
Windows displays the "not defined" glyph this usually has the appearance of a rectangular box as you've seen, this can be "overridden" in a font, and depending on the OS or even application may appear as a black question mark.
The reason why OneNote has so many of these font issues is because it is a legacy program. In fact, the version you have stated you use, OneNote 2016 is being Sunsetted and as such will not be getting any more updates, so there is likely no fix for this beyond using a different application.
Disclaimer: I am not an expert nor will I pretend to be, I hope that this represents an accurate explanation, but cannot guarantee it. I may turn this into a community wiki later, but I plan to research this topic more to verify it.
How to enable users to type Unicode characters in a web application? More specific, my users need to type the Dutch IJ and ij (Unicode: IJ and ij).
So I read Wikipedia and related sources, to find out it is perfectly fine to type those characters in Microsoft Word and Wordpad using ALT codes 0306 and 0307. In notepad however I get 2 and 3 instead. I was thinking this had something to do with simple notepad not being able to cope with multibyte encodings. But even Firefox 58 and Internet Explorer show 2 and 3 instead of the Unicode characters, when the webpage has Unicode enabled and <html lang="nl"> set. The page is rendered with the "Arial MS Unicode" font just like Word, to be sure that as much as possible Unicode characters are displayed correctly. My test machine runs Windows 8.1 with Internet Explorer set to Dutch, with also a Dutch version of Firefox.
So now users copy and paste from Word and Wordpad to their browsers which is pretty cumbersome. And obviously this method does not work on most computers (laptops, mobile phones) nowadays, because they don't have a numeric pad on their keyboard.
Others have similar issues. There is even a pragmatic tool to work around the problem.
It appears that typing ALT codes with a leading 0 has worked in the past on Windows XP and 2003, but setting a registry value for this to work on all clients is not an acceptable solution.
Isn't there a common solution to this human to browser barrier? Some JS API perhaps?
I am developing a Chrome Packaged app that has a webview in it. The problem is that I cannot type any sort of accented character (such as é, ç, ê) in a text input that is inside the webview. When I try to type é, for instance, I only get e in the text field. Strangely I can copy and paste accented characters into the webview text field without a problem.
Text inputs that are outside the webview work ok. This issue only seems to happen when running the packaged app on Mac OSX (It works fine on Windows). Other official sample apps that use webviews also have the same issue.
I have already checked if UTF-8 is being used by both the app and the webview itself, and it is.
Any idea of what might be happening?
Like lazyboy commented, this has been fixed since Chrome 34. It was actually a bug in previous versions of Chrome.