tahoma kerning issue

skater_king's picture

My Tahoma font on CS3 (mac) messes up big time on odd font sizes (9,11,13 ect).

Check out example attached.



skater_king's picture


Theunis de Jong's picture

It's not kerning, it's rounding. Although Tahoma is designed with a pixel grid in mind, there is no way all spacing can be taken into account for all pixel sizes.

Although I must add that your screen shot is especially bad looking ... On my machine, even a size of 7 points displays nicer text. Mind, that's an 1280x1024 TTF screen with ClearType on. It sure helps with the small sizes.

See these fountains -- 7, 8, 9, 10, 11 pts. Note the difference in length between 9 and 10 points -- also due to rounding, but this time it appears to preserve character form instead of character width (courtesy of Microsoft, I guess).

Any special reason your measurements are in pixels, rather than points? What program did you use?

[Edit:] Oh, CS3. Well, it's still a lousy display. Do you have the highest possible setting for text in your preferences? (I.e., anything better than "lowest"?)

jasonc's picture

" Although Tahoma is designed with a pixel grid in mind, there is no way all spacing can be taken into account for all pixel sizes."

Actually, it was, at least for these sizes. But that was done for the Win rasterizer. IN CS3, unless I'm mistaken you're using the Adobe rasterizer, and I'm not sure what it's doing to get quality, whether it's doing some sort of oversampling as the Mac rasterizer, or something else all together.

As Theunis noted, it's not a kerning issue. This would be a really small size to show large kerning values. However it's also not a simple rounding issue either. In the 11pix sample it looks like that, but note that in the 13 pix sample, you're not only seeing strokes crash, but overlap. see the word "in", where the "i" and left stroke of the "n" actually overlap. Normal rounding issues wouldn't explain that. This is some miscalculation of the advance widths, is my guess.

Hmm, although aside form describing the issue, I can't help more, as I don't have a Mac with CS right now. Perhaps the other Adobe experts will fill in the gaps?

Jason c

Si_Daniels's picture

CS3 Photoshop set to bi-level rendering? That might be your problem?

skater_king's picture

Sorry it is set to pt's.

jasonc's picture

Sorry it is set to pt’s.

you mean set to points? That's not what Sii's asking about.
Your sample is in Black and White, not greyscale, which seems really odd to me.
That could be causing the problem.

Theunis de Jong's picture

On a slightly different note, "CS3" is not a program. Is this Illustrator, Photoshop (as Si and Jason assume), InDesign (as I was thinking)?

I do get this ugly small text in InDesign (CS1), if and only if I set the text real small -- 7 pts, on a medium sized page -- A5, zoomed out to show the entire page, and then only if I force InDesign's display performance to really really low: "Optimized", which turns off anti-aliasing on the screen.

That "screen anti-aliasing" is another important point. If this is text from Illustrator or InDesign, you don't have to worry about the screen quality. If you print it, it will look great. (Oh, okay, only if your printer has a reasonable quality as well!) If you zoom in onto it, it will not look great (because you will still see aliasing), but at least the characters will separate. And if you set the view quality to better than the worst possible, it'll look much better, even in small sizes.

If this is text in Photoshop, you have a totally different set of problems. If this is meant to be printed at, say, a reasonably 200 dpi (and "print quality" images should at least be 300 dpi), your tiny 9 pixel text will be about 0.045 inch tall, or in the metric system, about 1 millimeter.
If it's intended for the screen (as in: a web page), try selecting one of the other rendering modes for text. Photoshop allows a number of quality settings, and again you seem to have chosen the worst one possible.

(What Jason is suggesting is also possible: Photoshop needs a few more colours to be able to draw the text antialiased.)

skater_king's picture

Photoshop. web. Of course points. the sample @ the top is RBG.

It was happening before then i did a fresh install of everything on a new HD and it was fixed for a while, but now its doing it again. Only with Tahoma tho....

I also tryed a re-install of the font as well.


Miguel Sousa's picture

Nothing wrong on my end. The configuration I'm using is,
- Photoshop CS3 (v10.0.1)
- Tahoma Regular (v5.01.2x)
- Mac OS X (v10.5.4)
- Anti-aliasing: None

Miguel Sousa's picture

Could it be some of your Justification/Hyphenation settings? Or it might be an effect of the "Every-line Composer". Try reseting the paragraph settings.

Thomas Phinney's picture

No, that couldn't be an effect of the composer choice. Certainly not when it's in a ragged-right setting. If the text were justified, it could be due to other justification settings, maybe?

charles ellertson's picture

Question Thomas . . .

I thought that if you specified ragged, with hyphenation, ID would allow varying word spacing, and it was only when hyphenation was turned off that the *ideal* space value was always used. I've always set indexes ragged, hyphenation on (but minimal), with wordspacings of 97%-100%-103%. Am I just wasting time?

Miguel Sousa's picture

It does make a difference, Thomas, at least when using no anti-aliasing. That's why I mentioned it. Below are the exact same paragraphs; the ones on the left are using the Every-line Composer, and the ones on the right are using the Single-line Composer. All paragraphs are set flush-left ragged-right.

skater_king's picture


I just did the paragraph reset to no avail. Didn't help.....

Rob O. Font's picture

"Every-line Composer" & "Single-line Composer."

That looks like it's trying to mean non-integer or integer spacing.

Is that so!?


Bert Vanderveen's picture

What is the versionnumber of the fontfile?
Do a Command-I and check the info.

. . .
Bert Vanderveen BNO

Theunis de Jong's picture

“Every-line Composer” & “Single-line Composer.”

That looks like it’s trying to mean non-integer or integer spacing.

Is that so!?

Fortunately, not even remotely close.
See this older thread for a quick overview.

Rob O. Font's picture

"Fortunately, not even remotely close."
Then, "looks like", means something different to you. If it is not, in fact, the difference between the two specimens, it is the difference in one. MS's example on the right, is most certainly integer spacing according to the bitmap or hints, how do you think things 'down there' become readable? The left is... taking another route to another destination and the older thread is an under-view.

Theunis de Jong's picture

Well, the OP mentions "it was fixed for a while, but now its doing it again", which suggests something else than mere local software settings.

The difference between Single Line and Multi-Line Composer is that the former fills a line of text, adjusts for space settings, looks for possible hyphenation to the previous line(s) (to count the number of successive hyphens), then moves on to the next.
The Multi-Line Composer does the same, but also takes into account the average space width in each separate line. It then averages the space widths over the entire paragraph, rather than taking them for granted. To appreciate the difference, compare InDesign's formatting to that of WordPerfect, PageMaker, Quark, and Word. ID's text spacing is by far more consistent.

"Non-integer or integer" could apply to the internal calculations of character and space widths, but I'd expect (and certainly hope!) calculations are done with as high as possible precision. Referring back to Word: it appears to me it bases its spacing and character positioning on the resolution of the printer, which means documents will re-flow if you change to another (and hey, so it does). InDesign does not have that flaw.

Be it kerning, rounding, or integer-based maths, the OP has had this problem on and off for presumably the same InDesign/Photoshop settings, the same OS, and the same font file.

Rob O. Font's picture

“Non-integer or integer” could apply to the internal calculations [...], but [...] I certainly hope!) calculations are done with as high as possible precision"

I don't think this person's posts are related to printing, so I don't think you are remotely relating to the precision of the post.

If the Single Line Composer is other than simply planting each bitmap glyph end to end on integer metrics, until it runs out of full words and starts a new line — I'd be surprised (from what I see), wouldn't you?


Syndicate content Syndicate content