New to Typophile? Accounts are free, and easy to set up.
While working on a typeface in Illustrator CS6, I came across an aliasing issue, that I'm not sure what to do about. I've attached a screen cap of two different "n"s worked on in different occasions, (same system, same software) there was another post regarding aliasing in illustrator on this forum but it wasn't this particular problem. I tried saving the file in a legacy format and pasting them back in, but I really am just shooting in the dark...
Any help would be appreciated!
I need to render these glyphs in a Word document, without resorting to copy/paste images as I did here.
Thanks in advance for any hint
Hi, I was hoping to get some help with some bizarre problems.
#1- "w" doesn't appear until struck twice in illustrator. But only when it is the first letter in the text box.
#2- The lower counter on the ampersand appears filled when illustrator is zoomed in. This appears to be related to the character's optical size on screen, not the specific zoom level.
#3- a few characters display little hairlines at small sizes.
I'm frankly stumped. Has anyone seen any of these before?
I've red at multiple places that the font rendering on Mac OS-X should be the same on every browsers.
Mac OS X Browsers,
We’ll kick this off the easy way. On a Mac, all web browsers use Core Text – the system default text rendering engine – and OS font smoothing settings. There are no browser preferences that affect the way type is anti-aliased. So, on a Mac, type looks the same no matter which browser you use.
Well, my personal tests didn't approve these results and I wanted to understand why.
Does iPad make any use of font hinting, if available, please? I mean not just safari browser, but the device itself, e.g. in purchased apps.
As far as I know, the CoreText rendering engine on Mac OS X completely ignores font hinting and rather employs subpixel antialiasing (source: http://www.typotheque.com/articles/hinting).
However, iOS devices do not use subpixel antialiasing (probably due to portrait/landscape orientation switching) and do only standard "grayscale" antialiasing, which obviously leads to less precise results. So I am wondering whether or not do they make any use of font hinting (to compensate this)?
I am having an issue with a font in development, and it is this: The vertical stems are too irregular in width/colour/weight when they are rendered in webbrowsers like Safari or Firefox in OS X. Firefox is marginally better than Safari. A PDF has the same issue, but to a lesser degree. All the stems in question are of exactly the same width. Other fonts like Ariel or other webfonts do not show this issue. I tried both CFF/OTF and TTF, but they both have the same issue. This leads me to think there is some hinting setting I have borked, but OS X does not use hinting, so huh? What can be wrong? I'm working with a UPM of 2048, but I seem to remember making a test in 1000, and that had the same issue.
I'll be grateful for any pointers, hints, puns.
I'm puzzling over what the problem is, with using @font-face. I was wondering if someone can tell me if this is an issue in setting up the embedding, a problem with the creation of the font itself, a browser issue, or something else entirely.
Here's the problem.
Occasionally, when embedding a font using @font-face, the tails or extenders somehow get rendered clipped. Also, sometimes the baseline or topline (did I make that up word?) get rendered all wobbly and wonky.
Now, due to licensing issues, font embedding legalities and such, I'm pretty limited to what typefaces I can use. I recognize it's possible it's just a poorly constructed font. Any help would be appreciated. See my image attached, for an example.
It is simplified, but generally speaking these are main possible paths with default settings.
X axis is market share (with some guessing).
I know a small examples of renderings could be included for better understanding, and I will post this & other refinements later.
A few things not mentioned:
Linux with FreeType rendering, but I have no idea how many people use subpixel rendering or other settings. Each setting has probably less than 1% of users.
Quartz rendering does also other types than subpixel AA, but I would say they are in minority (I really don't know).
There is also an old version of Safari, with Quartz rendering on Windows with default setting.
I am running OS X Snow Leopard and now again I a pronlem with certain fonts rendering properly. The characters are displaying as a glyph not found symbol.
The attached file is an example that occured when testing @font-face implementation in Chrome, weirdly Safari was fine. I have also had the same issue in OpenOffice, TextEdit, PowerPoint and at other random time.
Anyone got any ideas?
An Ars Technica article on text legibility issues with the new Mass Effect 2 game. The discussion is interesting in regards to how much flexibility developers should give to the players over how the text is rendered and such impact on the game design. As we move beyond existing standards, I believe these types of problems will become much more commonplace.
There are two major drawbacks with @font-face at the current state, IMO: The subscription model (exception for Typotheque) and the unreliable browser rendering. Both makes me uneasy about using web fonts for anything but playing around.
Have any of you actually relied on @font-face in real life projects?
So, fonts on the web.
As many from this community have seen, when fonts are used in @font-face, they can come out looking quite different on the various browsers and operating systems. As part of the Type Rendering project (along with Tim of Nice Web Type, Ethan of Fonthead, and Zoltan), I want to figure this issue out. I want custom type on the web to succeed.
At this point we’re ready to pin down and illustrate the aspects that contribute to poor rendering quality. But I need this community’s help in one key part: We need to select appropriate typefaces to use as baselines.
We think we need three typefaces:
1) A CFF OTF font, designed for the web, with hinting.