I'm trying to get the file corresponding to a given system font, e.g: In my system I have the font "Algerian" with the corresponding file "C:\Windows\Fonts\ALGER.TTF", and the font Batang, with the file "C:\Windows\Fonts\batang.ttc".
I've seen a couple of posts saying that I can do this by iterating the fonts folder and extracting the font name from the file header (as explained here: http://www.codeguru.com/cpp/g-m/gdi/fonthandlinganddetection/article.php/c3659/), but this seems inefficient and a bit complicated.
Is there a better way to do it? or do I have to iterate the whole directory?
Thanks
In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts you got the list of font with their filename
Related
Currently I'm finishing my very first iPhone application with MonoTouch. Localization through the "*.lproj" folders works as expected.
Having an UIWebView that displays some user guidelines, I'm populating this one with the LoadHtmlString() method. (I.e. no internet connection is required).
Since the text is a bit longer, I do not want it to be placed inside the "Localizable.strings" file but being swapped out to a completely separate file (as I'm doing it for Windows .NET applications, too):
In the above screenshot, I would have one "help.html" file inside each language folder and call the LoadHtmlString method to read from the appropriate file in a way that would be similar to NSBundle.MainBundle.LocalizedString.
My question:
Is it possible to have per-language files and access them from within a MonoTouch application?
Follow-up to Dimitris' solution
Based on Dimitris' solution, I solved it by this code:
var localizedHtmlFile = NSBundle.MainBundle.PathForResource("help", "html");
var text = File.ReadAllText(localizedHtmlFile);
helpTextView.LoadHtmlString (text, null);
Yes, of course it is possible. You can get the path of the localized file like this:
string localizedHtmlFile = NSBundle.MainBundle.PathForResource("help", "html");
You can use the PathForResource method for various different types of resources (PDFs, images, etc.). The first parameter is the file name and the second one is its extension. Check the other overload of the PathForResource method for more options.
Is there the way to create iTextSharp font using additional info (such as gdiCharSet etc) from System.Drawing.Font object?
Short answer: Yes.
Long answer: Each attribute is a bit different, but all that information can be expressed within PDF in general, and iText[Sharp] in specific.
You can specify a font's encoding when you create it, but you must do so in a way iText understands. Specifically, encoding values are strings within iText[Sharp]. BaseFont has a number of public static string members that list many of the available encodings, including several code pages that will map nicely to some of the GdiCharSet values. Others, not so much.
I generally suggest using "Identity-H" and subsetting your fonts (which happens automagically with Identity-H, you can't avoid it, which is a Good Thing) unless you need to keep the file size to a bare minimum. There are several single-byte encodings, the most common of which is "WinAnsiEncoding", BaseFont.WINANSI (the default IIRC). The string can also be the name of a "CMap" (such as Identity-H).
CMaps are generally language specific, and encoding specific. UTF & Japanese, or Big5 (a Chinese encoding as I recall), or what have you. Identity-H (and Identity-V) are font specific instead. They simply map values in the content stream to glyph indexes in the font (which can vary wildly from one font to the next, or between versions of a given font: that's why you're required to embed subsets of Identity-* fonts).
In PDF (and therefore iText[Sharp]), "bold" and "italic" are part of the font's identity, not a property. "Arial-Bold", "Arial-Italic", etc.
Strikeout and underline are decorations added after the fact (though I believe iText will let you set a flag at the font level for such things in com.itextpdf.text.Font's constructor).
iText won't give you direct access to the height, though a font's "descriptor" will let you define it.
The point size isn't a property either, you set it and the font (and color, default black) before you draw some text.
I hooked into the question located at "Replace image in word doc using OpenXML". I noticed that there are several ImagePartType types. Is there any easy "built in" way to determine which type a specific image should be other than going by it's extension? The ImagePartType enum is also used in PowerPoint as is alot of the WordProcessingML structures.,
For instance,
ImagePartType.Bmp on image1.bmp
ImagePartType.Emf on image1.emf
ImagePartType.Gif on image1.gif
ImagePartType.Icon on image1.ico
ImagePartType.Jpeg on image1.jpeg or image1.jpg
ImagePartType.Pcx on image1.pcx
ImagePartType.Png on image1.png
ImagePartType.Tiff on image1.tiff or image1.tif
ImagePartType.Wmf on image1.wmf
There is not - because you can have filename.png which is actually a bmp file and it all works fine. The only way to know for sure is to read the actual bitmap file and see what format it is in.
You can do this either by loading it into an Image class, or just read the first couple of bytes and look for the signature of each of the formats.
I'm doing this:
private void LoadSoundFile()
{
if (openFileDialog1.ShowDialog() == DialogResult.OK)
{
if (openFileDialog1.FileName.EndsWith(".mp3"))
{
txtFileName.Text = openFileDialog1.FileName;
}
else
{
MessageBox.Show("Currently Musicality only supports MP3 files.", "Unsupported file chosen.");
}
}
}
Is there a better way of checking file types or am I doing it the right way?
Having the .mp3 extension doesn't mean it is an mp3, but not having it is an (acceptable) indication that it isn't.
At some point you will call some API to play the file, and it will fail. When it does, you know it's not a playable file. So make sure you handle that with some decent UI too.
Your question seems to ask if the right way to check if a file is MP3 is to look at the end of the filename. As others have said, the answer to that is no. Matt Warren's post can help you if you want to look into the file to see if it is actually mp3 format.
But your comment on Eran Betzalel's answer makes me wonder if you are asking generally whether the right way to check a file extension is to use String.EndsWith().
One thing to notice is that EndsWith(string) is case-sensitive, so the results of:
EndsWith("mp3")
EndsWith("Mp3")
EndsWith("MP3")
and
EndsWith("mP3")
don't all give the same answer. A better test might be:
if (Path.GetExtension(openFileDialog1.FileName).ToLower() == "mp3")
if all you care about is the file extension and not the file contents.
If you actually want to analyse the file (to check if it really is a .mp3) you'll need to look at the specification so you parse it correctly. Here is a good place to start and there is some more info here. This article on the CodeProject goes even further and extracts ID3 tags as well as the header.
This will be better than just checking that the extension is ".mp3", but it's a lot of extra work so it has to be worthwhile.
It really depends on the nature of your program. I think that if you are not developing a security related application, then you can use the simple extension check.
No, because file extension is simply an indicator, it is not a reliable guide to what the file is or contains.
I can name i music file as mySong.zzz and it will still play in Winamp. When you load it you should sample the start of the file to see if it really is an mp3.
You can also set a filter on your open file dialog so that it only allows the user to select mp3 files:
openFileDialog1.Filter = "mp3|*.mp3|All Files|*.*";
I guess the proper way to actually check if it's an MP3 file (this requires that the file be opened) is to look for "magic numbers", sequences of bytes within the binary data that always occur. In this case, you can use the ID3 tag's magic number: ID3v1 tags are stored in the last 128 bytes of the file starting with the bytes "TAG" (hexadecimal "544147"), while ID3v2 tags are stored at the beginning of the file, so the first 3 bytes of the file are "ID3" (hexadecimal "494433"). I don't know if the MP3 frames themselves have simple magic numbers like this. Obviously, this method requires the file to be opened, which could make a scan of a large number of files slower.
If you want to be sure, load the file with this lib http://sourceforge.net/projects/id3dotnet/ it will fail with an exception if not an mp3. Simply create an Id3.Net.Mp3File with filename or stream in constructor an see if it throws an exception
I'm working with ITextSharp for a project and am looking for a reasonable way to get a string list of different fonts it has available for use.
I thought maybe I could just use reflection and loop over a class of available fonts, but there does not seem to be an easy way to do this. What I really want to do is provide a drop down of available/supported fonts for my users to select from Does anyone have any thoughts on how I might accomplish this?
This webpage has a great reference for how to work with the 14 embedded fonts in iTextSharp, as well as how to embed and use any fonts of your choosing.
To get the list of fonts included in iTextSharp:
Dim myCol As ICollection
//Returns the list of all font families included in iTextSharp.
myCol = iTextSharp.text.FontFactory.RegisteredFamilies
//Returns the list of all fonts included in iTextSharp.
myCol = iTextSharp.text.FontFactory.RegisteredFonts
An example of a font family is Helvetica. An example of a font is Helvetica-Bold or Helvetica-Italic.
First call FontFactory.RegisterDirectories(); to get all fonts on the system registered.
Then call FontFactory.RegisteredFonts; to get all the fonts.