I need to display a file that comes from a mac on a Windows machine.
The font name in the mac file is "Helvetica".
Windows does not have Helvetica but it has "Arial" which is the close. However, if I pass "Helvetica" to a WPF control the font family is ignored.
How can I get programmatically the closest font from "Helvetica" on Windows?
They are actually different fonts, though the difference is subtle. Talk to any obsessed graphic designer and he or she will probably start ranting about Arial's inferiority. Hell, they even made a movie out of it.
http://www.helveticafilm.com/
So that's why there's no "mapping". Because they're just plain different. You'll have to come up with your own way of choosing which font you want to use (that is, you'll have to detect what you have and then use what you get from the OS).
Some fonts contain an embedded PANOSE number, which classifies fonts visually and can be used to match similar fonts. It's what Windows' Fonts folder uses to list fonts by similarity. However, I'm not sure how widely supported it is.
Presumably, you'd need to know a particular Helvetica font's PANOSE number in order to find the near matches from the fonts you have installed.
See PANOSE on Wikipedia and MSDN Library page on Using PANOSE Numbers.
it may be possible to convert Helvetica into a windows something like transtype
you could then embed the font into your wpf app.
You may be on very sketchy ground in terms of licensing though!
There's a very good font stack generator over at codestyle.org, I've blogged about how to use it here http://devsigner.co.uk/creating-a-good-css-font-stack/
hope this helps!
There's some information about some Helvetica look-alikes here, maybe you could install these on your Windows machine. If you're worried about compatibility with other machines, you can't use this though, as it won't display the font on their machines (I believe it will default to some specific font, perhaps Arial or Times).
Related
I'm a font maker and I want to protect my web-fonts.
I know about the HTACCESS way to protect font files, but I found that there is another way to protect web-fonts: making the TTF font files intentionaly corrupted when you try to open them with Windows Font Viewer so they won't be installable, while the the same exact file will still work as webfont in the browser.
Here's a working example I have found (how they did it is the mystery):
http://fontface.co.il/fonts/demo_s.asp?id=131
As you can see, you are able to access the font files if they are cached in your browser, but when you download the TTF file and open it via "Windows Font Viewer" in order to install it, it will give you this error: "The requested file _____.ttf is not a valid font file".
You can test it yourself in your computer and you'll see that the web font will still work only with the TTF. (without including the woff / eot files in #font-face)
That's exactly what I want to do to my own fonts.
That way they would still work as web fonts, and will not work as desktop fonts, making it harder for untrained people to install them without a license.
However, I can't figure out how they did it.
Any ideas?
The OS has different requirements for what constitutes as a valid font than a web browser. A web browser is more lenient when the font misses certain pieces of data. The trick is to figure out how much you can "mangle" a font so that it's not installable, but still passes OTS and is usable in a browser.
On the webpage indicated as an example, the font is served in Embedded OpenType format.
Embedded OpenType (EOT) fonts are a compact form of OpenType fonts designed by Microsoft for use as embedded fonts on web pages. [...] These font files can be created from existing TrueType font files using Microsoft's Web Embedding Fonts Tool (WEFT), and other proprietary and open source software. [...] The font files are made small in size by use of subsetting (only including the needed characters), and by data compression (LZ compression, part of Agfa's MicroType Express). (Wikipedia)
I'm making program using Allegro5, but I'm not familiar with the library yet. I just want to know what is possible with this library.
I have to do 'color correction of image' (contrast, brightness, etc.) and I thought about:
-making buttons (like in normal windows program),
-scrollbars,
-file loader - I click on the button and I'm allowed to jump through directories on my hard drive and pick image file i want to edit in my program
-opening windows in allegro window (for the preview or something)
etc.
I want to use for that as much OOP as I can (i know, it's C). Is it possible to do all of that in C and Allegro5, or i need windows libraries and other stuff as well?
Thanks in advance for your replies. :)
Yes, you can do all of those things, but Allegro 5 is primarily designed for games and not GUI applications. It has support for native menus (5.1 series) and dialogs, but you're on your own regarding buttons, sliders, etc. (There are some third party GUI libraries available, but none of them would look like a native application.)
So if your program is basically a GUI application, then you're probably best off using something like Qt or GTK as your foundation, and only using a graphics library as needed.
I have come across a project where it is required to draw some 2D graphics on a form under Windows and to be able to perform the following tasks:
read image formats jpg, GIF, png, with transparency
monitor mouse and keyboard input to this form
draw simple 2D shapes, eg. line, ellipse, rectangle, pixel set/clear, polygons, ...
draw text with true font types and sizes and measure text sizes for different strings
written in C and can be integrated into Visual Studio 2008 C project
I've tried OpenCV but it lacks the transperency, font types, and GIF decoding and other things
I need your help please, It would be good if the library is easy to learn and use
thanks all
Sounds like a perfect job for SDL
And why not use the GDI built into Windows?
Traditional GDI documentation - http://msdn.microsoft.com/en-us/library/dd145203%28v=VS.85%29.aspx
Newer GDI+ documentation - http://msdn.microsoft.com/en-us/library/ms533798%28VS.85%29.aspx
Some more info added:
I guess I don't understand your requirements. Is cross platform support required? If yes, then use C and some of the cross platform libraries people have mentioned. If this is Windows only, then why not use the APIs that come with Windows?
Since your already using Visual Studio and you want ease of learning and development, why don't you use C# and the.NET libraries? In 2010, that is really the easiest way to build Windows only programs. Windows Forms will likely do everything you need. If you really must write in C and you are Windows only, then use GDI+ (or GDI if you need to support older versions of Windows). If you want to learn classic Windows C programming, go to the source - http://www.charlespetzold.com/pw5/.
As daddz said, you can use SDL for inputs, and image reading. In order to render your 2D primitives, OpenGL will do the work (be sure to create an OpenGL compatible window while calling SDL_CreateWindow). Concerning font rendering, it is not directly implemented in SDL but a couple of libraries can be used (see Survey Of OpenGL Font Technology).
I'm working on a multi-lingual WPF project that will be localized into many different languages. One issue we are currently having is localizing the tool tips on the minimise, maximise and close buttons. The tool tips seem to get localized when changing the OS language in Vista and Windows 7, however on XP SP3 the tool tips still appear in English even though the current OS language is set to Arabic (ar-SA) for example.
Are these tool tips controlled by the operating system or do they come from somewhere else like the .NET language pack?
UPDATE:
I forgot to add, applications such as Microsoft Word and Notepad appear with localized tool tips on the same XP machine that failed to display our application's tool tips in the desired language.
The language has been changed via the Keyboards and Languages panel in intl.cpl.
UPDATE AGAIN:
Installing the English version of the application on Arabic Vista also results in Arabic tool tips suggesting that the localization of these tool tips is done outside of the application. I have seen no trace of a .NET language pack on the Vista machine leading me to believe that with Vista, the tool tips are controlled by the OS. The question now is why aren't these tool tips being localized for the Arabic application being installed on Arabic XP SP3?
FURTHER UPDATE:
Today I went on the XP machine and created a new WPF application out of curiosity to see what it's tool tips came out like and discovered that they were localized to Arabic; meaning that the problem with the tool tips is within the application itself. The question now is, what possible ways are there of preventing these tool tips being localized? It was suggested today that it could be the setting of the windows xml lang, however I did not get the time to test this out and can hopefully try this tomorrow.
The tooltip texts come from the operating system and the language will depend on the language version of the operating system. If you for instance open the Windows Explorer, the menus of that application should appear in the same language as the tooltips for Minimize/Maximize buttons.
Note that changing regional settings in the Control Panel does not affect this.
The problem is our use of some 3rd party controls. These controls do some localization that works in Vista and Win 7 but falls back to some strings in an XML file on XP for some reason.
I'm building a .net application with windows forms. I'm pondering on the following problem: If I specify fonts in my application that are available only in Vista and Office 07, what will happen when the application tries to run in a machine without these ?
I suppose the system won't be able to fall back to a font of it's family, since they are initialized internally using strings (eg "Segoe UI").
What's the best practice to follow, such that I will still be able to specify fonts through the forms designer and not worry about things like this breaking ?
I think it's System.Drawing.SystemFonts.MessageBoxFont that gives Segoe UI, Tahoma, then MS Sans Serif depending on the OS. As long as your layout is fluid enough---WPF is good at this, but in Windows Forms it's much harder---then it'll work great. Regardless, it'd be worth using that setting then testing in VMs to see if it works.
Also rather unfortuantely the designer doesn't have support for setting the font like that, and it will reset things to hard-coded Segoe UI sometimes (if you're using Vista).
This kind of thing was actually one of the reasons I'm starting to move to WPF :).
Either check the OS and use Tahoma on XP and Segoe UI on Vista or let the user choose in an options dialog. Installing Segoe UI on XP seems to be considered not-done by most.
I agree with Brian Cline, if you can include them that would be best.
A great way to see what will happen with a clean OS is to start up a virtual machine on your system and install the program on it. Microsoft has a free virtual machine program called 'Microsoft Virtual PC'. Using this, you can load up any operating system within a virtual machine and test how your application will react in a 'clean' install environment. It will act the same as a regular computer and will only have the programs you install on it specifically. I use this for my winforms applications and it works great!
Let me know if this helps!
JFV
Either take Jasper's advice, or follow mine: Don't do it. Unless you're reskinning the whole app for some reason, just use the fonts already defined on the system. If you look like every other battleship gray (or mildly themed) app, except the fonts, it looks a little odd to users.
Either way, including the fonts is a EULA violation. Users can download the Office 2007 Compatibility Pack and get most of them, but the one notable exception will be (I believe) Segoe UI: This font is a Vista-only font.
If you do want to be different, then take Jasper's advice and detect XP vs Vista. If you're on XP, either use Tahoma or Trebuchet MS. If you're on Vista, go ahead and use the cool new fonts.
Check the EULA first in both Office and Vista to make sure the fonts aren't sacred, but you may be able to include those fonts in your installer package and have it install them.
Barring the ability to redistribute the fonts in your installer, you may have to check for the existence of said fonts first. If they are not there, have your app pick an alternative font from a static list of fallback choices.