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.
Related
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.
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.
I am getting tons of Lint warning to change layout to better support RTL devices.
If I use drawableStart in XML, what will happen in the devices that came before this attribute was introduced? Will they silently convert it to drawableLeft or the app will break?
I have good experience with using unsupported themes which silently convert to supported theme if my theme is not supported (like usage of Holo theme explicitly). So I wonder if the same will happen with these attributes.
For example, a device with SDK 10 uses this app. Will it crash or not as drawableStart was not known at that time?
PS. I do not have a device with SDK 10 to test the real behaviour, just emulators. That is why I am reluctant to believe what emulator says.
According to this blogpost you should use both start and left.
I have tried to use only start/end on API 16 and the behaved exactly as you would expect -- start got mapped to left and end got mapped to right.
The original Terminus just does not appear available in PHPStorm.
I tried installing Terminus.ttf but this one has different sizing and literally broke the look and feel of the whole system (e.g., code in browser is not readable). Besides this Termius in PHPSotrm is not as accurate as the original one.
Is there any way to make the original Terminus work under PHPStorm?
I'm using Debian testing.
JVM supports only TTF and OTF fonts (OTF since 1.7), so you need a version of Terminus in the compatible format. Original one will not work.
I've made a TTF version of Terminus many years ago, but it's far from perfect. Probably there is a better one now somewhere.
It may help if you change the font name with a font editor so that it doesn't conflict with the original one (like TerminusTTF). Use the TTF font in the IDE and the original font in the system.
Also check this issue, it has some details in the latest comments how font appearance can be improved in Java applications on Linux.