I am using the CM-Unicode version of the font Computer Modern Serif, and the left double quote looks bad.
CSS:
#import url("ComputerModern/serif/cmun-serif.css");
body {
font-family: "Computer Modern Serif", serif
}
HTML:
“conscience”
Result:
Is there any way that I could fix this, or is it just an error on the CM-Unicode people's end?
As answer to your question: you can open the font in any half-decent font editor, find the glyph for the opening double quote, fix the pathing, and then save and use the fixed font. Although, if you're going down that route then what you should actually be doing is of course to just file an issue with the people that maintain this font so that they can fix it for everyone, forever, not just for you, for now.
However, the solution to your problem is to not use Computer Modern. CM was designed for print, not for screen media (that wouldn't be an option for decades to come when CM was designed) and this port looks absolutely dire. It's super jagged and clearly no one bothered to put in the hours necessary to get the most out of the OpenType port. If you want to use a "modern" font and you like the look of Computer Modern, then give the OpenType version of Latin Modern a try instead.
Compare the weird Computer Modern font you're using to the proper Latin Modern OpenType font:
And of course remember that if you know the sizes you're using on your page, you'll want to make sure to pick the most appropriate font: default browser size is 16px, so using the optimized-for-8-points lmroman8 will look better than using lmroman10. Conversely, using lmroman10 for text that's sized to 20px will look better than lmroman8, etc.
Related
I’m building a website using Google Fonts. In particular I’m using “Archivo Black”.
The font supports special characters such as accents and others, however in Firefox those accents are rending in a really weird position… and in Chrome they look perfectly fine.
I’ve been looking all around but I don’t think there is a way to control the position of such elements via CSS, so I really don’t understand why this might be happening.
In the images below I'm just highlighting one instance when this is happening but if you look closer you'll see it's a consistent issue.
The problem is likely that you are using the 'COMBINING ACUTE ACCENT' (U+0301) along with the U character instead of the 'LATIN SMALL LETTER U WITH ACUTE' (U+00FA) Ú.
The former character set is not in your font so the browser has to use an other system font, which is why it may not render correctly. You can check this in the font panel of your dev-tools.
However, your font does have the Ú character, so if you fix it in your markup, you should be good in all browsers.
#import url('https://fonts.googleapis.com/css?family=Archivo+Black');
body{
font-family: 'Archivo Black', sans-serif;
}
<div>MÚSICA (U + ́ )</div>
<div>MÚSICA (Ú)</div>
I have an – character that becomes invisible when the text is rendered at a smaller font size (the applicable font-size rule is 14px, at which it is invisible; if I zoom in one level in Firefox, it becomes visible.) I have only seen this behavior on Firefox on Windows. With Firefox on Linux, I see the character at all sizes. I believe that what happens is that at smaller sizes, the dash is allowed to render as a line of zero width. So the question is, how can I remedy this? Here's what I can think of -
Try a different dash character and hope for the best
wrap the dash in a span and force it to be bigger - seems clunky
maybe my font definition is broken - this is embedded Open Sans
any other approach I'm overlooking?
Don't use any of the legacy 90's Microsoft core fonts in Windows (Arial, Verdana, etc). They have very aggressive hints intended to prevent "fat" or "blurry" stems at all costs, that result in some of those stems disappearing at small sizes. Perpetuating the pixelated look Windows users were accustomed to was the only thing Microsoft cared about at the time (there are built-in workarounds in the Microsoft rendering stack to hide the bugs of those fonts, but they don't exist in third-party apps).
Have you tried a different font-family to see if it's showing the same problem?
This is a problem of fonts, not browser support. Try to use another font like "Times New Roman" to verify.
In the case of the small icons, the most reliable solution is to use the CSS #font-face rule to ask the browser to download a particular font. Then you'll know for sure that the user has an appropriate font installed. There are even some fonts designed specifically for this use, with extra icons built in: "Font Awesome" is a well-known example.
Please look here for more information: Does every browser support all unicode?
I'm working on a site where small caps are important: setting the text of the Bible. In the Old Testament the name of God is transliterated as Lord but in small caps—not LORD. However, the state of OpenType small caps support at the moment is… less than optimal. Safari (even up through Safari 8 on Yosemite, from which I am typing this) still doesn't support the -webkit-font-feature-settings: 'smcp' option, and a lot of the hits for this website will be coming from mobile.
Unfortunately, "graceful degradation" is problematic here: if you specify both font-variant: small-caps and font-feature-settings: 'smcp' in a browser that supports the latter (e.g. Chrome), the font-variant declaration overrides it, so the horribly ugly old-style version still comes into play. (Note: this is as it should be per the spec: the font-variant declaration has a higher priority than the font-feature-settings declaration). Given the current implementations of font-variant: small-caps, though—shrunken capitals rather than actual small capitals—the result is that using font-variant: small-caps realists in not-so-gracefully degrading everyone's reading experience.
In the past, I have exported the small caps as a distinct webfont and specified them directly; see this post for a simple example: the first line of each paragraph is specified that way.
While I can do the same thing here (and at least in theory could deliver a pretty small typeface, since I really only need three characters: o, r, and d), I'd prefer simply to enable sane fallbacks. As noted above, however, that's not possible. I am open to but would very much prefer to avoid server-side solutions (browser detection, etc.) as a point of complexity that is better to minimize, especially given how rapidly browsers change. How else might one solve this problem, and especially are there existing solutions for it?
Edit: clarifying based on comments—in the future, font-variant: small-caps will handle this nicely, as per the spec it should display a small-capitals-variant of the typeface if the typeface supplies it. However, at present, no browser supports this (at least, none that I can find!). This means that instead, they all render fake small capitals simply by scaling down actual capitals. The result is typographically unpleasant, and unacceptable on this project.
Last updated 2016/02/28.
I spent a considerable amount of time researching this and wrestling with it.
After digging around as best I could, the top solutions for now are:
#supports
Take advantage of the #supports rule in browsers. This is what I initially
opted to do on this project.[1] You use the rule this way:
.some-class {
font-variant: small-caps;
}
#supports(font-feature-settings: 'smcp') {
.some-class {
font-variant: normal;
font-feature-settings: 'smcp';
}
}
I've simplified by leaving out the prefixed versions; you'll need to add the
-webkit- and -moz- prefixes to get this actually working. Update,
2012/02/28: you no longer need the -moz- prefix, and this will work in
Safari in the next release (iOS 9.3 and OS X Safari 9.1).
This has the advantage that support for real small caps and
support for the #supports rule are very similar:
#supports: Can I Use Feature Queries?: Chrome 31+, Firefox
29+, Opera 23+, Android 4.4+, Safari 9+, Edge 12+, Chrome for Android
Update, 2016/02/28: as the chart linked above will make clear, all
evergreen browsers now have #supports support.
font-feature-settings: Using Small Caps & Text Figures on the Web:
Chrome, Firefox, IE10+
This isn't perfect: since IE10/11 don't implement #supports, you miss one
browser. (Edit, 2015/09/31: IE proper doesn't have #supports, but Edge 12+
does, and that should increasingly cover all consumer users of the site.)
Still, this gets you most of the way there, and it should be future-facing: this
should progressively enhance the site nicely. The normal (bad, but functional)
small caps are displayed in the meantime, and when browsers eventually get
around to using OpenType small caps by default for font-variant: small-caps,
this will continue to work just fine. It's "progressive enhancement" and it'll
work nicely for most purposes.[2]
Typeface subsetting
As mentioned in the question, one can create a subset of the typeface that
includes only small capitals. This is what I have done for the small caps on my
own website; see the first line of the first
paragraph in this post for an example.
To pull this off, you'll need to start by subsetting the typeface. You can do
this manually with a font tool, or (the simpler way) you can use FontSquirrel's
custom subsetting tool in their webfont generator. (Note: You
must check the license and confirm that the typeface in question allows this
kind of modification. See below.) In the web font generator, first upload the
file you wish to modify. Then choose the Expert radio button. Most of the
settings you can leave as they are; they're good sane defaults. Midway down the
page you'll see OpenType Flattening options. Here, select only "Small Caps".
Run the generator. The result will be a complete replacement of the normal
lowercase letters with the small caps set.[3]
In that case, you can simply apply a style to the elements you want to have
small capitals, e.g.:
.divine-name {
font-family: 'my_typeface_smcp', 'my_typeface', serif;
}
The major advantage to this approach is consistency: that typeface is going to
display on every browser out there, back to IE5.5, as long as you deliver it
correctly using the various hooks required by #font-face.
There are a few disadvantages to this approach, though:
It means delivering another font file. In my case, this would be an
acceeptably low size (since I actually only need four characters), but it's
still something to consider in general. It is in any case another HTTP
request, which is going to further slow the page load time or at least give
you some flash of unstyled text when it reloads.
It may violate the licenses of the typefaces in question. For at least one
of the fonts I am using on this project, it does: the license explicitly
forbids rebuilding the font using tools like FontSquirrel. (FontSquirrel was
the tool I used for this approach before, and it works quite well.) This is
a make-or-break issue for using a subset of a typeface to accomplish the
goal. That being said, if you have a good reason to do it, you may be able
to get support from the vendor (especially if they're a small shop). For the
project that prompted this question, I was able to do just that with a nice
email—the designer is a great guy.
The other major reason not to do it this way is that it has a significantly
higher maintenance cost. If at any point you need to change or update the
typeface, you have to go through the subsetting process all over again. By
contrast, the first option will simply work, though admittedly not as
pleasantly as one might hope, and will not only continue to work but will
actually improve over time as browsers increase their implementation of the CSS3
standard.
Notes
For various reasons (especially see note 2 below), I actually opted for the
second approach outlined here, which is the same approach I was trying to
avoid. Alas.
Issues remain: even in the latest Chrome (38 as of the time of this
edit), using the font-feature-settings: 'smcp' approach has some
issues. For example, if you turn on letter-spacing (a fairly common
recommendation for small caps), the small caps will revert
to normal lowercase letters. Fixed in Chrome 48. HT to answerer
below.
From the FontSquirrel blog post that introduced the feature:
If you have a font with OpenType features, you can now flatten some of
them into your webfont. For instance, some fonts have small caps built in,
but they are completely inaccessible in a web browser. By selecting the
"Small Cap" option, the Generator will replace all the lowercase glyphs
with the small cap variants, giving you a small cap font. Please note that
not all OpenType features are supported and if the font lacks OpenType
features, using these options won't create them.
Support for font-feature-settings:"smcp" has improved in recent browsers. Chrome 48 fixes the letter-spacing bug. And according to caniuse.com, upcoming versions of Safari for both iOS and Desktop will support it. The prefixed version is still required for -webkit, though.
You already mentioned it here, graceful degradation.
Use the font-feature setting and if a browser does not support opentype features then the user will receive all the content still, with the worst-case scenario being full-size capitals; nothing is lost. I'd say that is a graceful degradation.
Aa an alternative you might want to consider using Typogruby (http://avdgaag.github.io/typogruby/), or similar, or manually adding a class to that word which you can target directly in your html, faking it with CSS2 e.g.:
.caps {font-size: .83em; letter-spacing: .25em; text-transform: uppercase;}
Edit: Of course, with the above method you can also specify a different font for the .caps class, one with full caps that will work well at small sizes in place of true small caps.
Stop thinking OpenType for a moment and think content: you need different styling for semantically different data (in this case, smallcaps styling for a special religious word) That's literally what HTML markup was invented for. Just auto-wrap those words in <span class="smallcapped"> markup with javascript, and have its class use a dedicated small-caps font. This is very easy to do, and even allows you to find the best suite smallcaps look independent of the main text typeface.
Simply run some code every time a section is DOM-loaded (emphatically not after your entire content is done, unless you're only ever showing short stretches of text):
function wrapSmallcaps(element) {
var content = element.innerHTML;
["LORD"].forEach(function(term) {
var search = new RegExp(" W?"+term+" W?",'g');
content = content.replace(search, function(a,b) {
return a.replace(term, "<span class='smallcapped'>"+term+"</span>");
});
});
element.innerHTML = content;
}
ex: http://jsbin.com/cowumaxe/1/edit
We could solve this by trying to make use of OpenType fonts, but you'd be tying yourself to one font, rather than one for for each style, making it extremely hard to improve the looks later on without violating font licenses when a better running text typeface or smallcaps typeface is found, or user feedback prompts you to improve the looks.
(and of course, this code is literally universal for any browser since IE8 -- http://caniuse.com/#search=queryselector shows zero "no support" or even "partial support" for all browsers people actually use)
I'm currently developing a site for my University's library, and a very strange issue came up. The font on the website, whether the live version or the one on my machine (not the server) is always smaller than it should be. This is only the case on two computers--my own, and my supervisor. It happens in all browsers. I'm pretty sure it's happening on both of ours because we've handled code, but I can't think of any CSS rules that would be affecting it. To make it worse, it's affecting two different CSSs--the old site (which I have not touched) and the new site which is intended to be rolled out tomorrow. I've tried fixing the way the computer displays fonts, the way browsers display fonts, changed the resolution, and tried zooming in. None of those methods worked. Also, other computers with the same resolution and monitors look at it just fine. No other websites that I visit have this issue. I'm stumped. Any ideas?
The site is here: http://library.uis.edu
Comparisons of the text can be seen here: http://imgur.com/a/Tb7Mv
I think this might be a font issue, rather then a font size issue. Myriad pro is not considered a websave font. As your machine and probabaly the one of your supervisor have probabaly Adobe installed, wich comes with Myriad, you are seeing the site in Myriad, while the other machines are seeing the site in Verdana. (not entirely sure though)
It looks like you are calling Myriad Pro as the first font. I have that font installed on my system, but you're calling the font size to be 75%, which on a font like Myriad Pro, will shrink it down considerably. If I clear the font-size, and font-family to just Verdana, it renders okay, but some of your elements such as the tabbed nav, would need to be addressed.
I'd stay away from fonts like that unless you are using #font-face and a web generated font pack. By choosing Myriad Pro as your font, you will only render that font on computers that also have the font. Consider using something like Google Web Fonts: http://www.google.com/webfonts/
Having fonts at the body level is fine, and cross fonts (headings versus paragraph) should be handled at a global level for those elements (not the body). Assume the body will take the bulk of the text in the body. You can define a standard font size such as 1.0em; at the body level if you wanted, and then define em sizes for other elements such as h1, h2 tags, and p tags if you don't want to use 1.0em from the body.
I'm stuck with a problem. I'm trying to embed fonts with #font-face but they always looks bolder. I have tried everything: other fonts, change font-weight to "ligher" or "100" etc...
The font looks always as it is bolded. I'm pretty sure it could look good because I've seen it used in many other websites with #font-face and it looks thin and fine.
See the attached image link text (I know it would never look as in PS, but so different?)
thanks
Set the following in your stylesheet on whatever elements you are using font face on and it fixes the issue:
-webkit-font-smoothing: antialiased; /* This needs to be set or some font faced fonts look bold on Mac. */
You are probably using the wrong weight file. Fonts will often be sold in different weights. You should verify that the file you're embedding with #font-face is the right weight.
The way the font looks on photoshop is obviously a graphical version of the font, specially, when photoshop has 5 types of blurring for fonts: none, sharp, crisp, strong and smooth. Those beside the original fonts, which they commonly are in one TTF and have the versions inside or, varios fonts for the different weights and faces.
Maybe if you enlighten us about the font type, the weight, blurring and whatever is useful for reproducing purposes would be useful to help you...
Fonts vary according to OS (Linux, Mac,PC) and even by browser, never mind the Photoshop blurring variants that Billeeb mentioned. For example Safari on windows applies some heavy anti-aliasing to make text smooth, which makes it look blaringly different on Firefox, even on the same machine.
In my opinion, the best way to have a consistent font experience is to use some sort of font replacement technology like Cufon. But this only works for not standard fonts with simple effects, you wouldn't want to use this if you need crazy amounts of drop shadow or blurring. For that its best to stick with images
This could even happen if you are using <h1> tag. h tags makes the font looks bolder.