I'm trying to find a way to make dingbats appear exactly the same in Firefox, Chrome, Safari and IE.
I noticed that the Dingbats appear the same in IE/Chrome/Safari, HOWEVER - in Firefox - they look "thinner".
For example - try to visit the following page:
http://en.wikipedia.org/wiki/Dingbat
You'll notice that when viewing that page in Firefox - the characters look different in comparison to Chrome/IE.
Does anybody know why and how can I cause Firefox to display the characters EXACTLY like they appear in Chrome/IE?
I'm trying to find a way to make dingbats appear exactly the same
You will never make fonts look exactly the same in all browsers, whether the characters in question are Dingbats or not.
For me, most of the characters on that page don't render in IE or WebKit. IE traditionally has poorer font fallback than average and Firefox typically better then average. The font that Firefox and Opera manage to choose to render the symbols for me is Meiryo (a Japanese font installed with Windows Vista and later). On IE and WebKit it falls back to the much more limited selection of symbols available in Arial, leaving most of the characters missing.
So for the best chance of rendering symbol characters how you want, do as you do for any other characters, and specify the font you want, eg. CSS font-family: Meiryo. But of course anyone who doesn't have that font installed will get something different, and browser/OS settings may change how fonts are rendered in general.
The symbol characters from the Zapf Dingbats set are not safe to use on the web, as the basic default sets of fonts installed by operating systems do not typically include glyphs for most of them. (‘Wingdings’ on Windows does, but it's a legacy font with a custom mapping that puts the symbols on ASCII characters instead of where they should be in Unicode, so again it's not safe to use on the web.)
There are a few symbol characters that you can typically get away with using for commonly-available font sets, eg:
● ■ ☺ ☻ ♥ ♦ ♣ ♠ • ▲ ▼
others, I'd try to avoid.
Interesting...On a MacOS X 10.6.6 machine with Firefox 3.6.13 and Chrome 8.0.552.231, the Wikipedia pages do render the first table, the ITC Zapf Dingbats, slightly differently. The effect is most noticeable on the solid half-circle at the bottom left corner of the set of characters.
The main Unicode Dingbats table renders almost the same; Firefox generates boxes containing the 4 hex digits of the missing character for the missing symbols, but Chrome just generates empty boxes - I prefer Firefox's technique.
The browsers must either be using slightly different fonts or slightly different font sizes (though I can't detect a size difference by eye). I've not looked at the HTML that is being rendered.
On the whole, I think that this is within the realm of 'allowable variation' - but I'm not an expert. I suspect you have a world of worry ahead of you if you demand pixel-for-pixel similarity between browsers. The concern should be to get the message across clearly.
Related
Not sure if SO is the best place for this question, but don't know where else to ask.
Is there any way to transform a svg like this one for ex: (https://svgsilh.com/image/1775543.html) into something that i can use inside an editor with copy/paste like this one? 🦄
No, because the unicorn emoticon is one example of a character. And just as with letters, digits, and punctuation, the appearance of emoticons and other plain-text symbols is decided by fonts.
LSerni wrote the following:
The reason you can "copy and paste" that icon is that the icon already has a UTF-8 code and your editor is UTF-8 aware. And this is why the same emoticon is slightly different between Apple, Android and so on: it's because it's always code XYZ, but code XYZ is rendered with different icons on different platforms.
But that's not entirely correct. The difference in rendering lies more in the font than in the operating system that displays emoticons. Unless the font supplies its own version of a symbol, that symbol will usually be supplied by the font specified by default by the operating system, and different operating systems supply different symbol fonts.
I have found this letter / character in facebook, but how can this have a color? is just insane for me, look this: ✔️
Added image (From Firefox on windows)
It's not an ASCII character, it's likely an emoji. Emoji are part of Unicode and the actual glyph displayed to the user is open to interpretation by the platform displaying it. The spec suggests a name/description, but the implementation varies.
So while you may see a colored check mark, I see black & white. Other times, a single glyph will have multiple styles made available on a particular platform; for example, I can select multiple "skin" tones when I use a smiley face on my iPhone, but your Android device may only show a generic one.
Edit: The image edited into the original post is a perfect example. Using Chrome on Windows, I see a black check mark. The screenshot from Firefox shows green.
The symbols used here aren't ascii-encoded. They use the much more vast range of Unicode encoding. Ascii(extended) is restricted to a 256 symbol set.
The unicode interpretation for symbols/glyphs(small pictorial representation)(these ticks aren't characters), can vary for different platforms as some the range of unicode is open for usage and isn't set as global.
Which is why, while the unicode encryption remains the same for every device irrespective, the decryption is differently interpreted by different devices/online-platforms, allowing us to perceive either a coloured or a black symbol.
Firefox can display the following character in div but cannot display it in input.
龗 滙 羣 邨 埗 衞
There are two issues here. First, Firefox (like browsers in general) uses a specific default font for input element (though this font depends on user settings). That font may well lack glyphs for some characters that are present in the font used for normal text (whether as per browser defaults or as per your CSS settings). This can be handled by setting the font-family for input elements suitably. To set it the same as the normal text font, you can use the following CSS rule:
input { font-family: inherit }
Second, your data contains Private Use code points such as U+F5D0. They have absolutely no meaning outside of private agreements on their use. In HTML, they are typically used in conjunction with privately-encoded “icon fonts” that have fancy icons placed in those code points, though they might also be used e.g. for rare Chinese characters (typically occurring in proper names only) that have not (yet) been encoded as characters in Unicode.
This means that such a specific font must be used to make any sense of the content. To make things work across devices, this should be a downloadable font specified with #font-face. If you have done that, simply declare that same font for input elements in CSS.
The browser shoule be able to display HKSCS if the Font set as 細明體_HKSCS, MingLiu_HKSCS, PMingLiU or MingLiU.
I tested in Firefox, Internet explorer and Chrome.
I have Museo-300 mostly working with #font-face, but certain letter combinations like "ff" and "fi" are disappearing in Firefox (confirmed in v3.6 and v7.0.1). So "microfinance" becomes "micronance".
Note that I'm outputting these as individual letters, not as ligatures. When I view source on both the server and the browser, "coffee" for example is spelled with all six letters individually—not a unicode ligature character for "ff".
The output looks right in Opera, Chrome, Safari, and IE (even IE6).
I downloaded Museo-300 from MyFonts along with their web font example template.
#font-face {
font-family: 'Museo-300';
src: url('webfonts/151B6C_0.eot');
src: url('webfonts/151B6C_0.eot?#iefix') format('embedded-opentype'),url('webfonts/151B6C_0.woff') format('woff'),url('webfonts/151B6C_0.ttf') format('truetype'),url('webfonts/151B6C_0.svg#wf') format('svg');
}
and all the referenced files are in place. I invoke it like this:
font-family: 'Museo-300', sans-serif;
I tried a different font as a test (Code Pro Light Demo, also gotten from MyFonts) and Firefox dropps "fi" but not "ff" for that one.
An idea what's going wrong?
For anyone reading this in the future, note that as of FF 15 (I think) the syntax has now changed, and you'll need to use this:
-moz-font-feature-settings: "liga=0";
-moz-font-feature-settings: "liga" 0;
You can tell Firefox to skip looking for ligatures and treat them as regular characters by adding
-moz-font-feature-settings: "liga=0" in your font-face declaration.
In case others hit this problem, I resolved it with help from MyFonts technical support. I'm not sure whether this issues is specific to MyFonts, but I suspect it affects other web font sources.
Direct (Solvable) Cause
When a standard True Type font (TTF) gets processed into the multiple versions that are useful for a web font (EOT, SVG, WOFF), the processing tool or vendor can decide whether or not to include the font's full character set. Some will default to a reduced character set to reduce file sizes.
In my case, one or more of the generated web font files excluded ligatures, presumably considering them to be non-essential typographic tweaks. To fix the problem I used a custom web font builder at MyFonts to generate font files with the full character set.
(For MyFonts specifically this was at Order History > select relevant font > Webfont Kit Builder tab > Advanced, then check both "Complete Character Set" and "Keep OpenType Layout".)
Underlying Cause
My belief, which is only an educated guess:
I think Firefox is going out of its way to do nice typography, more so than other browsers. So when it sees something that it could render as a ligature ("fi", "fl", "ff", etc.) it tries to render the letters as a single ligature glyph rather than as two distinct characters. If your web font doesn't include the ligature glyphs, your letters will disappear. (If my guess is right, I'm surprised I haven't read about this problem before.)
Myfonts.com recently changed some display settings. Their support wrote back very quickly with the following info:
If you click on the Font image (the image that shows the sample),
which is located right above Kit Options, you will see the Complete
Character set and Keep OpenType Layout options.
This view is not currently available through Firefox though, but I was able to download the complete character sets using IE9.
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.