I have added Imago font (including bold, italic and those both with those names: boolta, med and medlta) to Info.plist, but now I'm totally stuck with several tutorials.
I'm using storyboard mode.
Could someboby tell me what codes I have to write and where to get these font to work?
been having a lot of issues with fonts myself recently and there are a few things I suggest checking: -
1/ Always use .ttf format
2/ Make sure your font is included in 'Copy Bundle Resources' in your project 'Build Phases'
3/ Custom fonts should be defined in the array in your '[appname]-Info.plist' like you said above, it's under the heading 'Fonts provided by application'
4/ Make sure that you are using the correct font name as it is usually different to the filename. To get a list of available font names use the below code. Just using finders 'Get Info' is not always reliable: -
for (NSString* family in [UIFont familyNames]){
for (NSString* name in [UIFont fontNamesForFamilyName: family]){
NSLog(#"font=%#", name);
}
}
Then use the font name outputted in your log
5/ If that STILL doesn't work, it may mean your font encoding is a little messed up. I had this recently with a .ttf font, the app just couldn't see it so I stuffed the file into this online converter and whatever the issue was disappeared, magic!
Related
I'm using blogdown to create my website. Now I found this problem:
ggplots embedded in .Rmarkdown files doesn't appear. When I rename the file to .Rmd the graphic is okay. But I need to use .Rmarkdown because I want to use the beauty syntax highlighting and other features only available in .Rmarkdown files.
When I print the fig.path with
knitr::opts_chunk$get('fig.path')
I see the difference:
In .Rmd
"2020-06-17-rmd_files/figure-html/"
In .Rmarkdown
"/post/2020-06-17-rmarkdown_files/figure-html/"
But I don't see why the paths are changed.
How do I solve this?
I found a solution (at https://discourse.gohugo.io/t/raw-html-getting-omitted-in-0-60-0/22032):
After adding
[markup.goldmark.renderer]
unsafe= true
in the config.toml the plots appear.
I am migrating Spreadsheet gear of my application from 6.0.3.190 to
7.4.1.104.I am getting my issues with Color property.Can any one help me in this.Now I am using using Color = System.Drawing.Color; and also ToSGColor().This became very hectic to do in all places where ever we use color.I expect we should have some shortcut to do this.Can any one suggest me How can i get all functionalities with few changes only.I am also getting exceptions to c onvert IColorFormat.LineColor to system.drawing.Color.
Note the "Breaking Changes" page in the SpreadsheetGear 2012 documentation, which lists this particular change:
In order to support WPF and Silverlight, the core API has been
separated from the GDI+ and Windows Forms APIs and therefore uses the
new SpreadsheetGear.Color type rather than
SpreadsheetGear.Drawing.Color. SpreadsheetGear.Drawing.Color has been
moved to SpreadsheetGear2012.Drawing.dll. See
SpreadsheetGear.Drawing.Color for an example which uses the implicit
and static converters to convert between SpreadsheetGear.Color,
SpreadsheetGear.Drawing.Color and System.Drawing.Color.
SpreadsheetGear.Colors and SpreadsheetGear.SystemColors provide
helpful predefined colors to replace the use of predefined colors in
System.Drawing.Color.
So you'll need to ensure than any place where you were previously using System.Drawing colors now use SpreadsheetGear.Drawing colors, including API like IColorFormat.LineColor.
There aren't really any "migration" tools to automatically convert such instances to the new API. So you'll need to resolve these errors for each code file. Doing a Find/Replace keyword search for "System.Drawing" and "SpreadsheetGear.Drawing" could possibly speed up the process, though this would depend on what using statements you have added to each code file.
So I am having consistency issues with a certain set of unicode characeters. The characters within the buttons under the reply section, and at various parts of the page show up as squares: http://bit.ly/zlhgEI
When I copy them into google i can navigate to a wikipedia page describing that character. So it seems like it is a rendering issue. Or perhaps that platform is just missing characters? I don't know.
Where it works: Firefox (I think on any platform), Chrome on windows7 and ubuntu maybe osX
Where it is broken: Chrome on XP, iphone4 and droid incredible
Does anyone know a way to ensure this character set will get added. I already tried adding to utf-8 meta tag, which seems to do nothing. What can I do?
Thanks!
This is primarily a font problem. The buttons contain Syriac letters, which are not present in most fonts. The CSS setting is font-family: Helvetica,Arial,sans-serif, but Helvetica and Arial do not contain Syriac letters, so browsers will first try the font to which they map the generic name sans-serif. It most probably does not contain Syriac letters either, so browsers will either give up and e.g. show a square or (more properly) scan through the fonts available on the system. So indirectly this is a browser issue too.
The odds are that the vast majority of users will not see the Syriac letters unless you use an embedded font for them. For suitable fonts, you could check
http://www.wazu.jp/gallery/Fonts_Syriac.html
where many download links don’t work, but try
http://www.bethmardutho.org/index.php/resources/fonts.html
You could also write a CSS rule with fonts that contain Syriac letters, e.g.
font-family: Estrangelo Edessa, TITUS Cyberbit Basic, Sun-ExtA, Code2000, unifont. But most people don’t have any of them in their computers, so consider adding the downloadable font of your choice into the list, once you’ve selected and installed one.
The character encoding is not a problem. The data is UTF-8 encoded and declared as UTF-8 in HTTP-headers, so meta tags don’t affect encoding issues (as long as the page is viewed online).
The buttons look really odd (each occupying the full width of the window) on IE 9, but this seems to be unrelated to the problem at hand, and it’s a Quirks Mode issue and can be fixed by adding <!doctype html> at the start.
This could be an example of mojibake. There's probably not a ton you can do about it -- I believe it depends on the fonts available and the range of encodings they support.
I'm setting a Button's content to an Image. It looks something like this:
<Button>
<Image Source="pack://application:,,,/NavigationImages/nav_up_left.png" />
</Button>
In my project I have a subfolder named NavigationImages and within that folder is the image file nav_up_left.png.
When I view the Designer the image appears, however during runtime I get an IOException error saying it cannot locate the resource.
The Build Action is set to Resource.
Actually, this worked fine in one project. But when I copied it over the another project it fails. This seems like an incredibly simple problem, but I find myself stumped and ready to start pulling out hair. #_#
Your thoughts and suggestions will be much appreciated!
Whelp, I figured it out...kinda.
I copied that xaml code from one project where the output type is Windows Application, to another project where the output type is Class Library.
I didn't think of it at the time, but apparently when the output type is a Class Library the pack URI needs to change.
So instead of "pack://application:,,,/NavigationImages/nav_up_left.png" I changed it to "/ProjectName;component/NavigationImages/nav_up_left.png" and now it's working just fine.
I'm not 100% clear why this is works and not the former. I've read through the MSDN documentation on pack URIs in WPF but perhaps I misinterpreted something.
I'll leave this answer unchecked in the event someone can give me a good explanation why what I previously had doesn't work in a project with output type Class Library.
I'm probably missing something really simple. #_#
I just struggled with this same problem for quite a while, and I think that part of what was going wrong in the original was the missing word "component". I, for instance, had
myBitmapImage.UriSource = new Uri(#"pack://application:,,,/MyApp;images/mona2.jpg");
but should have had
... = new Uri(#"pack://application:,,,/MyApp;component/images/mona2.jpg");
The word "component" is not part of the pathname, despite its appearance -- it's a string literal that has to be there. Why? Someone thought it'd be a good idea, I guess.
And for those struggling with another part of the thing, what about "MyApp"? That's the name of the Assembly. Right-click on your project name, select "Properties...", and under the "Application" tab you'll see the "Assembly name:" field.
If you don't feel like searching for that (or worry that it might change, breaking your code), you can do this:
String appUri = #"pack://application:,,,/" +
System.Reflection.Assembly.GetEntryAssembly().GetName().Name + ";";
String path = appUri + "component/images/mona2.jpg";
myBitmapImage.UriSource = new Uri(path);
Not very pretty code, I admit -- it can clearly be shortened -- but it'll gets you where you need to go, I hope. Remember to set the "Build" property on your image file to "Resource"!
Just to shine a light on what was happening in your situation. The second pack uri. The one that worked. Is meant for resources located in an assembly other than the host application. By the sounds of it, the host application was loading this resource from the Class Library in question?
You can see the differences in the pack uri schemes here:
MSDN Pack URI Scheme
The uri changes slightly when referencing a resource from the main assembly, and referencing one from another assembly.
Also, the pack://application:,,, includes what is referred to as the "authority", to omit it would basically make it a relative path, both are valid in most cases where the application authority is assumed.
EDIT: basically because /Subfolder/Resource.xaml(.jpg etc.) and /Assembly;component/Resource.xaml are very similar, the latter tells the parser/loader that it's looking in a referenced assembly, not in the main application's assembly. (I imagine this helps speed up the search).
One other solution to getting this right:
Once your image Build Action is set to 'Resource' and you have rebuilt, navigate to the properties of your <Image /> object. The properties window will provide a ... file resource browser, whereupon selecting your image the Source="..." attribute of your <Image /> will be correctly filled in.
I am mucking about with WPF glyphs and documents and have run into a null reference exception in the .Net 4 framework.
I extract and save true-type fonts to disk as .ttf files, then try to create Glyphs based on the fonts. The first time I save a font to disk and instantiate a GlyphTypeface based on the font after creating a GlyphTypeface from another font in the same folder I get a null reference exception.
Say I have fonts A and B. B has not been saved to disk (A may or may not have been saved to disk; that doesn't seem to matter):
1) save B to disk in the same folder as A,
2) create GlyphTypeface using font A,
3) create GlyphTypeface using font B = exception.
Null reference exception at:
at MS.Internal.FontCache.FontFaceLayoutInfo.IntMap.TryGetValue(Int32 key, UInt16& value)
at MS.Internal.FontCache.FontFaceLayoutInfo..ctor(Font font)
at System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations)
at System.Windows.Media.GlyphTypeface..ctor(Uri typefaceSource)
If I restart my app and run it again (with font B already on disk), step 3 doesn't throw an exception.
The code to save a font to disk is simply writing a section from a binary stream and letting go of the file:
if (!File.Exists(filename))
{
using (FileStream fs = File.Create(filename, length))
{
fs.Write(m_data, m_index, length);
fs.Close();
}
}
Any ideas? I don't want to have to put every font in its own folder...
Thanks for your time.
This bug has been driving me nuts but I think I have a better understanding of what is going on now.
For testing I used the following XAML:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Glyphs
FontUri="C:\Users\Public\Desktop\A.ttf"
FontRenderingEmSize="100"
Fill="Black"
UnicodeString="Test"/>
</Page>
Using the XamlPadX application which runs on the .NET 2 runtime I could reliably render the XAML no matter where I placed the font.
Using the Kaxaml application which runs on the .NET 4 runtime the XAML would often fail to render depending on where I placed the font in the file system. By moving the font file around and renaming I tried to discover a pattern in what was allowed. However, it was very hard to see a pattern.
For instance storing the font in the path below would render the glyphs:
C:\Users\Public\Desktop\A.ttf - OK
Renaming it from A.ttf to B.ttf would throw the exception:
C:\Users\Public\Desktop\B.ttf - throws exception
Changing the extension would also throw the exception:
C:\Users\Public\Desktop\A.odttf - throws exception
Renaming parts of the path would sometimes wreak havoc but I was unable to see any pattern. Initially I used the temp path and getting exceptions lead me to this question and the answer about not using that path. However, later I have actually been able to use that path as long as the name of the file is A.ttf and not B.ttf so avoiding the temp path is not a sure fix.
At some point during my tests using my own WPF application the B.ttf file name suddenly started working. However, I had to restart the Kaxaml application before it would accept the B.ttf file name. Also, at that point the A.odttf file name was still throwing exceptions.
My suggestion is to use an application like Kaxaml or to create a small WPF application to test which font file names are acceptable and then use them. However, I fear that the nature of this bug is such that a "good" font file name may turn "bad" at a later point in time. Only time will show.
I ended up using the workaround of saving each font to its own folder (using the font name for the folder name). The exception went away, so I guess we can chalk this up to a bug in .Net.
I (and a co-worker) finally found what our particular problem was: do not save the font files to %TEMP%. For some reason, having the fonts saved to some other folder makes it work (for us), and saving it to anywhere inside %TEMP% makes it break.
According to XamlToys Doesn't work on framework 4.0???, the problem is in the extension of the file for partial fonts.
When I renamed the .ofttf files I save to .ttf, it all works again. Haven't got the foggiest idea of why that is though. Seems to be new in .NET 4.0.
My workaround was to simply replace the < Glyphs > with equavalent < TextBlock >s. The couple of pixels difference in layout was not a problem in my case.
Like you noted was the case for you, in my case also it was not a problem in .Net 3.5, but appeared in .Net 4.0.