I have the websafe font georgia that is beuatifull for what I want.
The only problem I am having is that the bottom of the font doesn't line up.
http://jsfiddle.net/JW7F8/
<style>
.georgia {
font-family:georgia;
font-size:1.9em;
}
</style>
<span class="georgia">
1234567890
</span>
As you can see in the fiddle is that the 1,2,6 and 8 all start a bit higher than the rest.
The question:
How can I render georgia that it all starts on one line whilst still being able to set the site with XXem.
I do not mind:
splitting up the string
setting different classes
I just need a workable solution that still allows for dynamic sizing.
This is just the style of the font, technically all the font characters line up (if you highlight the text it will show the height of the font character).
You won't be able to consistently line up Georgia font even by splitting the font because the offset will have to vary depending on font size. This could be possible using em's, but it would be hacky at least, and would be very difficult to get working consistently cross browser.
Also, changing the font position will cause Kerning issues.
However, there is another similar font which Georgia was influenced from, which does line up:
Georgia incorporates influences from Clarendon-style typefaces
http://en.wikipedia.org/wiki/Clarendon_(typeface)
For a websafe solution I ended up implementing this: http://jsfiddle.net/JW7F8/2/
<style>
.georgia {
font-family:georgia;
font-size:1.9em;
}
.subitx {
position:relative;
top:0.18em;
}
.subity {
position:relative;
top:0.13em;
font-size:1.2em
}
</style>
<span class="georgia">
<span class="subity">1</span><span class="subity">2</span>345<span class="subitx">6</span>7<span class="subitx">8</span>9<span class="subity">0</span>
</span>
Only shame is the fonts that are sized up are bolder than the rest.
I really wish there were more web safe fonts that work cross browser... sigh
The Georgia font has old-style digits, i.e. digits that vary in height and may extend below the baseline too.
Most fonts that people use on web page have modern-style “lining” digits, all digits being of equal height, roughly the same as uppercase letters.
Some fonts contain both. It has relatively recently become possible to choose between such alternatives in CSS, in several browsers, using font-feature-settings. But Georgia has only old-style digits.
It is best to choose a different font if you think that such a fundamental feature is not suitable for your text.
However, on WebKit browsers (Chrome, Safari), using #font-face (for local fonts, not embedded) and unicode-range, you could specify that digits be taken from another font. It’s technically simple but not really a good idea:
#font-face {
font-family: Georgiax;
src: local("Times New Roman");
unicode-range: U+30-39;
}
#font-face {
font-family: Georgiax;
src: local("Georgia");
unicode-range: U+0-29, U+40-10FFFF;
}
Then you would just use font-family: Georgiax as if it were a real font family. But as said, this technique is not supported by other than WebKit browsers, and taking digits from another font means a typographic blunder.
P.S. Georgia is not web-safe. No font is. You won’t find it on an Android, for example.
Related
I use as font-family stack like this:
body{
font-family: icon, 'Merriweather Sans', ui-sans-serif, sans-serif;
}
with icon being an icon-font that has some symbols in it for example arrows, which can occur in copy text or headlines.
The icon font is loaded like this (simplified example):
#font-face {
font-family: 'icon';
src: url(icon.woff2);
unicode-range: U+1F872, ..., ...;
}
That way whenever the 'arrow bold to right' is used in a text it will be rendered in the icon font. It works well and is foolproof.
I also use (simplified example again)
p.text{
max-width: 70ch;
}
which ensures that text paragraphs don't have too many characters in one line for readability.
Firefox makes those text paragraphs a lot smaller than chrome. And after some experimenting, I found that FF uses the icon-font to determine the width of the zero while Chrome uses Merriweather Sans.
The icon font has no zero-glyph in it and would be hindered by its Unicode range to display one.
So at first glace it seems correct that Chrome calculates ch based on the first font-family in the stack that contains a zero and is allowed to render a zero.
On the other hand I'd think that for calculating the abstract ch unit one can argue that the actual presence ot the zero character isn't necessary. Also it should be perfectly ok if one would use one font only for displaying number (through Unicode-Range) while the next font displays letters. What font should be used for calculating the ch value then?
Can anyone tell me if one or the other browsers does it wrong and the other does it right?
And has anyone an idea for a good workaround?
I'm finding Unicode for special characters from FileFormat.Info's search.
Some characters are rendering as the classic black-and-white glyphs, such as ⚠ (warning sign, \u26A0 or ⚠). These are preferable, since I can apply CSS styles (such as color) to them.
Others are rendering as newer cartoony emoji, such as ⌛ (hourglass, \u231B or ⌛). These are not preferable, since I cannot fully style them.
It appears that the browser is making this change, since I'm able to see the hourglass glyph on Mac Firefox, just not Mac Chrome nor Mac Safari.
Is there a way to force browsers to display the older (flat monotone) versions to display?
Update: It seems (from comments below) there is a text presentation selector, FE0E, available to enforce text-vs-emoji. The selector is concatenated as a suffix without space onto the character's code, such as ⌛︎ for HTML hex or \u231B\uFE0E for JS. However, it is simply not honored by all browsers (eg Chrome and Edge).
Append the Unicode variation selector character for forcing text, VS15, ︎.
This forces the previous character to be rendered as text rather than as an Emoji Symbol.
<p>🔒︎</p>
Result: 🔒︎
Learn more at: Unicode symbol as text or emoji
I had a Unicode character in the content of a span::before, and I had the font-family of the span set to "Segoe UI Symbol". But Chrome used "Segoe UI Emoji" as the font to render it.
However, when I set the font-family to "Segoe UI Symbol" explicitly for the span::before, rather than just for the span, then it worked.
For a CSS-only solution to prevent iOS displaying emojis, you can use font-family: monospace which defaults to the text variant of the glyph rather than the emoji variant:
<p>Normal character: ↩</p>
<p>Monospace character: <span style="font-family: monospace">↩</span></p>
If your primary concern is forcing monochromatic display so the emoji don't stand out from the text too much, CSS filters, either alone or in combination with the Unicode variation selector, may be something you want.
p.gscale {
-webkit-filter: grayscale(100%);
filter: grayscale(100%);
}
a {
color: #999;
-webkit-filter: grayscale(100%) sepia(100%) saturate(400%) hue-rotate(170deg);
filter: grayscale(100%) sepia(100%) saturate(400%) hue-rotate(170deg);
}
<p class="gscale">You've now got emoji display on 🔒lockdown🔒.</p>
<p>External Link: celebrate 🎉</p>
Unlike the variation selector, it shouldn't matter how the emoji are rendered, because CSS filters apply to everything. (I use them to grayscale PNG-format "link type" icons on hyperlinks that have been modified to point to the Wayback Machine.)
Just mind the caveat. You can't override a parent element's filter in a child, so this technique can't be used to grayscale a paragraph, then re-colorize the links within it. 😢
...still, it's useful for situations where you're either going to be making the whole thing a hyperlink or disallowing rich markup within it. (eg. titles and descriptions)
However, this won't work unless CSS actually gets applied, so I'll give a second option which is more reliable in <title> elements than the Unicode variation selector (I'm looking at you GitHub. I don't like fake icons in my browser tabs):
If you're putting a user-provided string into a <title> element, filter out the emoji along with any bold/italic/underline/etc. markup. (Yes, for those who missed it, the standard does call for the contents of <title> to be plain text aside from the ampersand escapes and the browsers I tested all interpret tags within as literal text.)
The two ways I can think of are:
Directly use a manually-maintained regex which matches the blocks where the newest version of Unicode puts its emoji and their modifiers.
Iterate through the grapheme clusters and discard any which contain recognized emoji codepoints. (A grapheme cluster is a base glyph plus all the diacritics and other modifiers which make up the visible character. The example I link to uses Python's regex engine to tokenize and then the emoji package for the database, but Rust is a good example of a language where iterating grapheme clusters is quick and easy via a crate like unicode-segmentation.)
None of the other solutions worked for me but I eventually found something that did courtesy of css-tricks. In my use case, I was adding a link symbol at the end of each markdown header for direct linking to sections within articles but the emoji symbol looked a bit distracting. The following code allowed me to make the emoji look like a plain symbol and then switch back to looking like an emoji when hovered over which was perfect for my use case. If you just want to make the icon look more like a symbol just change the text-shadow hexadecimal color to #000 as shown in the second example.
.direct-link {
color: transparent;
text-shadow: 0 0 #dbe2ec;
}
.direct-link:hover {
color: inherit;
}
<h3>Blog Subheading🔗</h3>
.direct-link {
color: transparent;
text-shadow: 0 0 #000;
}
<h3>Blog Subheading🔗</h3>
Android fonts are not rich as you may expect.
Font files don't have these exotic glyph and Android has a hack for few characters without glyph. They are replaced with icons.
So solution is to integrate the site with a web font (woff).
Create new font file with FontForge and pick required glyph from free serif TTF for example. Every glyph takes 1k. Generate woff file.
Prepare simple CSS to import the custom font family.
style.css:
#font-face {
font-family: 'Exotic Icons';
src: url('exotic-icons.woff') format('woff');
}
.exotic-symbol-font {
position: relative;
top: 1px;
display: inline-block;
font-family: 'Exotic Icons';
font-style: normal;
font-weight: normal;
line-height: 1;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
index.html file:
<html>
<head>
<meta charset="utf-8">
<link href="style.css" rel="stylesheet"></head>
<title>Test custom glyphs</title>
</head>
<body>
<table>
<tr>
<td class="exotic-symbol-font">
😭 ☠ ♠ a g
</td>
</tr>
</table>
</body>
</html>
Google Chrome, desktop version 75, seems to disambiguate its approach to rendering Unicode characters based on the first Unicode escape it encounters while loading a page. For instance, when parsed as the first HTML Unicode escape in a page source, and having no emoji equivalent, ⏷ seems to clarify to Chrome that the page contains escapes not to be rendered as emoji.
Expanding upon ssokolow's answer, using a filter is nice and at least makes the contours visible instead of using a simple font, but converting an RGB color into a sequence of CSS filters is very hard when you want to use a specific color.
A better (although quite wordy) option is to use the <feColorMatrix> SVG filter. Combined with the grayscale filter and the data URI scheme, you can represent the color via RGB and in-line CSS:
.violet {
color: white;
filter: grayscale(100%) url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><filter id='f'><feColorMatrix type='matrix' values='0.78 0 0 0 0 0 0.082 0 0 0 0 0 0.522 0 0 0 0 0 1 0'/></filter></svg>#f");
}
Unfortunately, you cannot interpolate the URL with data (taken from attributes or variables), but at least you don't have to calculate CSS filters from RGB.
My specific version of the problem
My site is using the ◀︎ (BLACK RIGHT-POINTING TRIANGLE) and similar characters in CSS pseudo-elements (::after and ::before) to indicate the current item in a list.
In my tests, I always used the triangle character and the variation selector 15 together. First I was using both a webfont from Google Fonts and a font installed on the device that should both have contained the glyphs for those characters, but for some reason, this assumption must have been wrong. I also tried different subsets on Google Fonts, to no avail: Two of my android devices with Google Chrome and Samsung Internet (Chromium) always rendered the emoji instead of the text glyph.
My solution
My solution was to download the latest WOFF of the Gnu Free Font (which I knew to contain glyphs for those characters), include it in my project, and define it using #font-face:
#font-face {
font-family: "Free Sans";
src: url("/site/static/fonts/FreeFont/FreeSans.woff") format("woff");
}
Then, to set the styles for my pseudo elements:
span.current::after {
font-family: "Free Sans", $universal-font-family ! important;
}
Discussion
I'm not yet sure about the performance impact of using that 786K extra font just for those few characters. If that becomes a problem, it should be possible to use a stripped-down custom font with just those characters instead.
If none of the other answers work for you, it's possible you have one or more of these fonts in your font stack (as was the case for us):
Segoe UI Emoji
Apple Color Emoji
These are included in a number of commonly used font stacks, like the Github font stack if I'm not mistaken.
I dont know of a way to turn off the emoji type rendering. Usually I use an icon font such as font awesome or glyphicons (comes with Bootstrap 3).
The benefit of using these over the unicode characters is that
you can choose from many different styles so it fits the design of your site;
they are consistent across browsers (if you ever tried doing a unicode star character, you'll notice it's different in IE vs other browser);
also, they are fully stylable, like the unicode characters you're trying to use.
The only downside is that its one more thing for the browser to download when they view your page.
For me on OSX the solution was to set font-family to EmojiSymbols
None of the solutions above worked for the "Emoji for Google Chrome" Extension.
So as a workaround I made a screenshot of the Unicode Character 'BALLOT BOX WITH CHECK' (U+2611) and added it as image with php:
$ballotBoxWithCheck='<img src="pics/U2611.png" style="height:11px;margin-bottom:-1px">'; # ☑ or /U2611
See: https://spacetrace.org/man_card.php?tec_id=21&techname=multi-emp-vessel
I was wondering if someone could point me in the right direction. I am looking to display the Google Font Orbitron at consistent weights at every given font size. Sounds pretty easy, right? Not in my scenario. At certain font-sizes, some characters have multiple weights within the same character.
Note: I am testing this in Windows 7, Chrome v27
The Code:
<link href='http://fonts.googleapis.com/css?family=Orbitron:400,500,700,900' rel='stylesheet' type='text/css'>
.sixteen{
font-family: Orbitron;
font-weight: 400;
font-size: 16px;
line-height: 22px;
}
.nineteen{
font-family: Orbitron;
font-weight: 400;
font-size: 19px;
line-height: 22px;
}
<h4 class="sixteen">Home of Front End Developer and</h4>
<h4 class="nineteen">Home of Front End Developer and</h4>
Here is a fiddle to explain my issue. If you take a look at the fiddle, you'll see in the first line that the top line of the uppercase F, E, and D characters have more weight/thickness than the rest of the characters in that line. But as you'll notice on the next line, that
In case you cannot replicate what I'm seeing, here's a screenshot:
My question is two-fold:
What would the best way to technically describe this? 'Multiple font weights in one given character' lacks brevity, and isn't likely to have any valuable Google results.
Is there a way to fix this and make the weight consistent in every character at every font-size?
What you describe is as such just variation of the visible width of strokes in glyphs, or stroke width variation to put it briefly. Such variation is normal in serif fonts and also appears, at least to some extent, in many sans-serif fonts. However, in this case, the font is designed to have a rather constant stroke width, so the visible effect is caused by font rendering differences.
There is no way to remove the font rendering differences. Font rendering is a complex issue, and although some proposed or experimental CSS settings might affect some aspects of it, it’s basically outside your control. For example, font smoothing (also known as anti-aliasing) depends on the operating system and its settings as well as the browser and its settings.
I've found this issue with a bunch of fonts used online when you go down to a certain size. It's the way the font is being anti-aliased.
You can see the same issue from Google showing off that font: http://www.google.com/fonts/specimen/Orbitron
On MS Word we have a text feature called "Small Capitals". It turns all letters uppercase, but the lowercase letters turn smaller then uppercased. I need to know if it is possible in CSS.
Example:
Original: Hello World
Small Capitals: HELLO WORLD
Notes: SO Markdown does not support CSS font-size style in tags nether small, so I show as a hack. Well, the strong letters is bigger than normal letter in small capitals.
Is it possible in CSS? How I can do that?
It’s called “small capitals” or “small caps” in English. In typography, small capitals are separately designed (by font author) versions of letters. They have the shapes of capital letters, but their height is usually just a litter larger than the x-height (the height of the lowercase letter “x”) of the font. They may be implemented in a small caps font, but more often, they are glyph variants inside font.
In MS Word up to and including Word 2007, as well as in CSS implementations for font-variant: small-caps, the “small capitals” are really just reduced-size capital letters. (Word 2010 gives access to OpenType features and real small caps.) This typically means that their stroke widths are too small, and to avoid this effect from getting all too bad, the font size reduction is rather modest, so the fake “small caps” are not that much smaller than normal capitals.
For such reasons, “small caps” are mostly best avoided on web pages.
However, there is ongoing work in giving access to OpenType features in CSS. Currently, support exists in the form of browser-prefixed versions of the font-feature-settings property as proposed in CSS3 Fonts. Example:
<style>
body {
font-family: Calibri, sans-serif;
}
.sc {
-moz-font-feature-settings: 'smcp';
-webkit-font-feature-settings: 'smcp';
-ms-font-feature-settings: 'smcp';
font-feature-settings: 'smcp';
}
</style>
<div class=sc>Hello world</div>
<div><span style="font-variant: small-caps">Hello world</span>
(fake small caps)</div>
This works on supporting browsers (Chrome, Firefox, IE 10), provided that the font has small capitals (e.g., Calibri, Cambria, Candara, Constantia, Corbel, Palatino Linotype).
yes, you can do it with font-variant. I think you mean "capitalized"
<span style="font-variant:small-caps;">Hello World</span>
I think you are talking about small caps, So try:
font-variant: small-caps;
Usually by "small caps" it's intended a style where all capital letters are preserved as they are and lowercase letters are rendered in uppercase using as a smaller variant of the font.
Using text-transform: uppercase; will convert all letters to uppercase, but will not achieve the effect of rendering them with a smaller font.
https://www.w3schools.com/cssref/pr_text_text-transform.php
Using font-variant: small-caps; will achieve the result described above, i.e. render all lowercase letters to uppercase using a smaller font size (which, as mentioned by #jukka-k-korpela) is usually done via dedicate glyphs within the font itself.
https://www.w3schools.com/cssref/pr_font_font-variant.php
There's also font-variant-caps: all-small-caps; which forces the small-caps effect on all letters (lowercase and uppercase alike). This might be useful in some edge cases, e.g. in older styling conventions where 'A.D.' and 'B.C.' would be rendered with smaller letters, i.e. combining the effects of text-transform: uppercase; and font-variant: small-caps;.
https://www.w3schools.com/cssref/css3_pr_font-variant-caps.php
My site displays just like I need it to in IE and Opera, but in Firefox I can't use CSS to get font sizes smaller than Firefox's default minimum-font-size. Of course, I can go to Tools → Options and remove this value, but some users will see some of the elements displaced.
I have tried using !important, but it doesn't work, and I can't substitute the images for the text since they are dynamic fields.
Okay. I'm going to explain how you do this, but you need to know a few things first.
1. You shouldn't be doing this.
There is a reason, and a very good one, that the minimum font size setting exists. Simply, with most fonts, it is already a struggle to read anything below 12px, never mind below the default minimum of 9px. If your design calls for such font sizes for anything but an extremely restricted set of circumstances¹, then your design is just bad and excludes a huge category of users.
2. You really shouldn't be doing this.
The web is an intrinsically flexible medium, and a good design must take account of this. Designs that require a fixed font size to work are suitable for print, but they are not suitable for the web. Any designer who cannot work with this requirement does not understand the medium, and no decent PM should prioritise a designer's bad decisions over practicality and usability. You have far bigger, more fundamental problems to deal with if you can't argue against this decision.
3. You really, really shouldn't be doing this.
Depending on your jurisdiction, you may be wandering on a legal grey area. Tiny font sizes are difficult to read, and will make it very easy for your users to miss information—which is especially troublesome if the text at hand is legally significant, such as opt-out information or a disclaimer. You are also treading on thin ice with respect to the accessibility of your site by causing serious problems for people with visual impairments.
How to do it anyway
It is quite easy to make Firefox display fonts at less than the minimum specified size: just use the font-size-adjust property.
Here comes the science bit
Every font has something called an aspect value, which is the ratio between its x-height (the height of a letter x)² and the actual font-size you set. In Comic Sans, for example, this is really big (0.55), as you can tell by how big the shorter letters (a, c, e…) are compared to taller letters (b, d, h…), whereas in Courier New it is a lot smaller (0.43).
This variability can cause some problems. For example, let's say you specify a super-fancy font for your body text, but because you're a good designer you provide several fallback fonts. That's great, but because some of those fallbacks have different aspect values, letters might be smaller and less legible at the size you specified. font-size-adjust allows you to make sure that any fallback has the same x-height as your super-fancy font.
Unfortunately, we can also use it to make text less legible. Let's say your body copy is Segoe UI at 12px:
body {
font-family: "Segoe UI";
font-size: 12px;
}
The aspect value of Segoe UI is almost exactly 0.5, so if you specify that as the font-size-adjust value, your font size doesn't change:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.5; /* x-height = 12px × 0.5 = 6px */
}
What happens if we set it to something smaller? Well, the browser will adjust the font size to use an x-height equal to font-size × font-size-adjust. The below, for example, will result in an effective font-size of 6px:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.25; /* x-height = 12px × 0.25 = 3px */
}
This forms the basis of our attack. It turns out that Firefox will honour font-size-adjust even if it overrides the minimum font size. (It goes without saying that this is a bug.)
The demo
Try this out in Firefox with a minimum font-size set. It exploits two bugs: the aforementioned font-size-adjust issue and a separate issue with reporting the rendered font size via getComputedStyle.
You need to know the aspect value of the font you are using for this to calculate the right font-size-adjust value, for which this list of aspect values might help you. (Alternatively, try an estimated x-height for fonts installed on your system.)
But wait! There's worse!
The above technique only works in Firefox. It's even easier to override the minimum font size on an element in Webkit, including Safari, iOS Safari and Chrome—just use the non-standard -webkit-text-size-adjust property:
-webkit-text-size-adjust: none;
This is another bug, by the way. text-size-adjust is a non-standard proposal intended to limit the extent to which text-size is automatically inflated on mobile devices. It isn't meant to work on desktop UAs, much less prevent manual text resizing.
Last word: it won't last forever
Bugs get fixed eventually. You are not meant to be able to override the browser's default font size, no matter how much your irresponsible designer and PM want you to. Sooner or later, people will figure out that these properties are being exploited to make the web worse for everybody, someone will land a patch and the fun will be over.
That said, if you are being forced into this, I wholeheartedly advocate a solution that will eventually force the parties involved to rethink their decision.
¹ Hint: if your text conveys any information that is meant to be readable by anyone, ever, then you shouldn't be messing with browser accessibility settings. Legitimate cases include purely decorative effects (complex ASCII art, shape poetry) and document previews.
² More correctly, the distance from the baseline to the median height, which is the height of a letter x in most fonts.
You cannot do it. It's a setting that Firefox provides so that people like us cannot override it with some CSS settings.
You can effectively shrink text below the minimum size using CSS3's transform: scale(x) syntax, where x < 1. This is guaranteed to work in future browsers (as that's the point of scaling), but does come with its own challenges/caveats.
Just in case it might help anyone, I ended up replacing the small text areas, initially in HTML, with SVG zones. I fill these zones with the Raphaël JS library, with code like
logo_text = $j("#logo_text").val();
logo_text_preview_paper.clear();
logo_text_preview_paper.text(0, 4, logo_text).attr({"font-family": 'Helvetica', "font-size": 7, "text-anchor": 'start'});
I did not use an HTML canvas, because of its lack of availability on certain browsers, and because SVG offers a much better user experience on Retina displays.
It might seem overkill to do that, but I was not able to find an easier solution to the Minimum Font Size problem of FF.
In some cases you can use <canvas> element and fillText().
If you set the default CSS font size in your web pages to a percentage ... then through em sizing you can provide cross-browser scalability ... Setting the font size to 62.5% is a basis for rescaling fonts base hx sizes to 10px.
body {
font-size: 62.5%;
}
p {
font-size: 1em;
}
So if you really wanted to make your standard paragraph text say 10px ... You would just state it in your CSS as 1em and it would render as 10px. Please note that if you really want to do this correctly ... you need to do a CSS reset too as you want your display to be consistent ...
Eric Meyers CSS Reset
HTH
you can try the following code
body {
min-font-size: 15px!important;
}
If you set the the font size attribute on the body it should set it as default font size.
body
{
font-size: 12px;
}