This may not be a bug with nitobe at all but strangely, many of those reporting this bug are using the nitobe theme.

Here's my comment to the taxonomy bug report containing details:

http://drupal.org/node/275352#comment-1288586

Thanks.
Ed

Comments

Anonymous’s picture

Anonymous (not verified) commented
Assigned: Unassigned »

Ed,

Thanks. I'll look into this.

Shannon

Anonymous’s picture

Anonymous (not verified) commented

Ed,

I've added a comment on the issue you cited. I don't think it's an issue with the theme per se, but I may need to patch the theme to accommodate the problem. I will leave this open pending further research on #275352: Taxonomy throwing odd errors when previewing node.

Thanks again,
Shannon

ebuck’s picture

ebuck commented

Thanks Shannon. I appreciate your looking into it. From what I can gather, it's more of an aesthetic bug than anything serious but I did notice it within one or two posts of using your theme.

By the way, I love your theme! It's very well designed, clean and professional looking. It's running on my blog:

http://www.nixer.org

I don't know too much about theming in drupal but as I get more comfortable with the inner workings, I hope to be more helpful with these bugs later. I did spend some time the other day troubleshooting why the default content font was ugly when viewed on my Debian system. After looking through your style sheets and determining the font was Helvetica, I realized that the font was not anti-aliasing because of my fontconfig configuration (I had disabled small font anti-aliasing so MS fonts would look better). Free fonts tend to look really bad without anti-aliasing! I fixed the problem on my end and the font looks fine now.

Ed

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (fixed)

Ed,

Thanks for the compliments! I'm going to mark this one as closed since it's been identified as a problem in core. I tried implementing a work around in the theme, but this resulted in different errors from taxonomy.module, so I'm going to leave it as is and see what develops with the core issue.

The older fonts in the MS catalog were actually designed for use on screens without anti-aliasing. This is part of the reason why they don't look good in print above about 14 points. And they haven't been updated except to convert them to Open Type and add Unicode characters. Apple got around this in the early Macintosh days by providing bitmap versions of print fonts for use on the screen.

Newer fonts (and most free fonts) rely on the rasterizer to handle any anti-aliasing. That approach tends to provide more consistent rendering between screen and print. The unfortunate part is that the "core" web fonts are all antiques designed for low resolution screen use.

Another thing to keep in mind with fonts in CSS is that IE doesn't read the entire font-family list before it tries to substitute in a font. I discovered this a while back (#297585: Bad font list in text.css) in an earlier release of Nitobe in which I had placed the free fonts at the beginning of the list. Instead of IE reading the entire list, it substituted the first font it didn't recognize with something that didn't match the language encoding.

Shannon