Can someone please let me know if it is possible to display a site in a language (other than English say Chinese) even if the user's system doesn't have that font (Chinese font)?
I've seen that in Google. Even if I have the font, still I can see the site in that language. But there are certain sites which can be read only if the font is installed.
In all the google sites google uses Unicode (UTF-8, UTF-16) fonts which are by default supported by most of the browsers
You can use unicode in your multi language site, This doesn't need any fonts to be installed
e.g. सुस्वागतम, 为鄂伦春哦么
Your question is far from being clear but I suspect that you are interested about CSS3 downloadabel fonts and specially about the fonts hosted by Google at http://www.google.com/webfonts
So if you want to maximize the visibility of Unicode text in your HTML application you must be sure that you serve UTF-8 encoded pages and that your CSS specifies a large set of fonts instead and always keep the fallback generic font last:
font-family: Arial, Helvetica, sans-serif;
In addition you may want to add a CSS3 downloadable font, but from my experience this is not going to help because most browsers will not be able to take advantage of it, especially the ones running on systems with "bad" fonts.
Mainly, you do not care so much, I work on internationalization field so I do have more than average fonts installed on my systems and I remember seeing boxes for some weird languages.
Now if you respect the above recommendations and still have some specific problems, please open a new question and we'll find a way to help you.
http://www.w3.org/TR/css3-fonts/
Section 4.3 shows that you can point to an external location for the font.
Related
I'd like to create a visually appealing select-dialog that shows FontAwesome-Icons and a word describing the symbol to select from various scales for statistical data.
So I'm using the FontAwesome-Fonts for the select-tag and the unicode-glyphs for the various symbols. That first part works nicely.
But the words I am using are also used in FonAwesome to form ligatures that can also be used to get the icons (I thought this was limited to the desktop-version, but as my example prooves, it also happens on the web). The FA-Site states that they are "...aren't comfortable considering ligatures for Web Fonts + CSS".
Please check out my fiddle here or the screenshot:
So, my questions are:
if it's not supposed to happen with Webfonts/CSS - is there anything that I am doing wrong using them? (Of course I have the desktop-fonts installed on my machine, I guess we won't know if users of the website will have them or not)
is there any way I can avoid the ligatures taking effect within the option-tag? (as you see in the sample, I am already using font-variant-ligatures: none; in the CSS)
I found a way to solve this by defining dedicated #font-faces with a different name. (My theory is that Chrome uses the local font I have installed and that it's ligatures override everything I do in CSS). That "special font-face" is sure not to be found locally...
If someone finds a better explanation or fix, I'll happily accept it.
I have a French website that is in LFR (Left to Right)
And the client is wanting to translate the site in hebrew thus transforming it to RTL (Right to Left). In all Hebrew Website the design is reversed
https://he.wikipedia.org/wiki/
https://www.google.co.il/
Is there a way to do this automatically ? Again I am not talking about the text direction. I want to flip it horizontally the design, like a mirror effect.
Your mileage may vary. Some web page generation tools support RTL with easy switch, while with others the WYSIWYG breaks completely when you specify <html dir="rtl">. Browser fragmentation may also be an issue: some browser simply don't support RTL bulleted lists correctly.
There are quite a few good tutorials on the Web; I would recommend https://hacks.mozilla.org/2015/09/building-rtl-aware-web-apps-and-websites-part-1/ and https://hacks.mozilla.org/2015/10/building-rtl-aware-web-apps-websites-part-2/. If you look up Google to search for more articles, please remember that this field is quickly changing, and some recipes of few years ago may be obsolete.
You may find the automation with css-flip or rtlcss useful.
Note that localization is generally not easy, and invariably requires a manual touch. You must understand the target culture very well to recognize tiny glitches that may look awful to the end-user. For example, on Hebrew Website you need different image for the "back" button. On Arabic sites, some numbers should be represented by indic digits, but other numbers are expected to use the usual digits.
Issues of first day of week, etc. are common for LTR localizations, too.
I have a keyboard app designed for Serbian language. My keys have labels based in Serbian cyrillic alphabet. My xml strings that are used for those labels are enclosed in <xliff:g></xliff:g> tags, but a certain provider on a certain type of a phone still translates these into a different language. Just in case, I also have my strings in language specific folders, but it still happens. Does anyone know if there is a way I could disable translating of all my strings any other way?
There are providers who can handle technical files translations,i.e. know what to translate in technical files. Also, some are available for you to manage the translations. OneSky is one of these platform and we also provide translation service.
See GIF of how placeholder validation works in OneSky
Disclaimer: I work in OneSky
I've been building a general-purpose, OpenType ".otf"/".ttf" file parsing library that must parse at least some of the more complex tables, such as the GPOS and GSUB table. I've been using various existing OpenType font files against the parser to flush the bugs. So far so good, although it is a non-trivial amount of work to support the spec in its entirety. Mostly because many of the OpenType font file's tables, sub-tables, and even lower-level data structures have multiple formats.
But any given font file makes use of only a subset of these myriad formats. I have found the spec often to be confusing, so it's hard to get the parsing code correct. Testing is essential.
So ... is there a font file, or collection of font files, available (free or for sale) that has been designed expressly not to be a working font but rather to exercise as many OpenType parsing code paths as possible?
I've scoured the web, looked at Adobe's FDK, etc., etc., but have come up empty.
I'm curious to know why you need to reimplement these :-). Feel free to contact me offline.
I suggest trying the following fonts:
IranNastaliq and other Nastaliq fonts,
Indic fonts, like the Lohit family for example,
Any script fonts you may find.
A good collection for mass testing would be googlefontdirectory:
https://code.google.com/p/googlefontdirectory/
I don't know any expressly designed for that purpose, but there's a bunch of OpenType fonts that might be useful for this at sourceforge, including Adobe's Source Sans Pro and Source Code Pro family that you'll probably already know and some arabic which might be interesting too.
You can find the font source files in Adobe's github.
I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.