Why fonts look different on LOVE than on web browser?

[qwdqwqwffqw]

It's nothing really problematic, but I've been wondering why same font(+ same size & same text) looks different on Love, than on web browser, pdf viewer, etc.

The text rendered in love seems to have same heights but narrower width. After several testing, I noticed it's not only letter spacing & kerning, but also thickness of stroke and width/height ratio are slight different(letters like "/" shows noticeable differences in slope angle in stoke), if I'm not mistaken.

Why is it so? Is there any fundamental difference in rendering method?
Since narrowly condensed text can be harmful to readability, is there any way to control this(other than scaling horizontally)?

[dusoft]

Please, post screenshots. AFAIK LOVE uses bitmaps internally for font rendering. Even if you provide TTF, an internal bitmap font will be created from it. This could be the cause.

[slime]

love uses FreeType for truetype text rendering. FreeType has its own rasterization algorithms and default hinting that may behave differently from a specific operating system's own text renderer.

(In fact, text rendered through the OS will look different on each OS.)

That being said, without knowing what your fonts and code are, we can only guess about what you're seeing.

[qwdqwqwffqw]

Oh, sorry for not providing any examples & code.

Here is an example with Segoe UI TTF file(system font. file could be found in C:\Windows\Fonts), but similar difference could be found in other font files including OTF ones.

1. A paragraph from love2d github page(I added "/" for better comparison) in chrome browser :

git1.PNG (11.28 KiB) Viewed 5010 times

which will be rendered with Segoe UI + 16px size in my environment.

git2.PNG (20.34 KiB) Viewed 5010 times

2. Made simple .html with same text, to be sure :

html1.png (17.4 KiB) Viewed 5010 times

3. in notepad2(and other apps) :

notepad1.png (6.7 KiB) Viewed 5010 times

> All above shows same rendering output. You can download images and compare them(they are on the same scale).

4. love, 16px : same height, but narrower output :

love-16.PNG (7.35 KiB) Viewed 5010 times

5. love, 17px : taller, but still narrower ouput :

love-17.PNG (7.78 KiB) Viewed 5010 times

As you can see, rendering of LOVE show more 'condensed' output.

love code used :

Code: Select all

love.graphics.setFont(love.graphics.newFont("segoeui.ttf", 16))
local s = "There/ are also branches for currently released major versions, which may have fixes and changes meant for \nupcoming patch releases within that major version."
function love.draw()
	love.graphics.print(s, 20, 20)
end

[pgimeno]

This looks like if anything, it should be reported to FreeType.

[dusoft]

The difference seems to be in kerning and I would be curious why.

[qwdqwqwffqw]

I tried out many things to fix this problem for some time. So I am sharing what I've found out so far.

In LOVE, its determining X-coordinate for each next character seems not precise(it tends to be biased toward lefter position than it should). So, just adjusting kerning is not enough(and is not as important as adjusting x-coordinate).

A simple expedient is like this :
1) Create font object with much larger size. (I think the size should be equal to some kind of standard size defined inside the otf/ttf file, but I'm not sure.)
2) With that 'big font', caculate width(font:getWidth) of every glyph you want to use.
3) Create 'small' font object with which you will use in rendering.
4) Get ratio between those two font sizes.
5) Whenever you want to print string, print it glyph by glpyh. The x-position where next glyph should be :
(previous x-pos) + (small/big ratio)*(size of previous glyph in 'big font').
- Also, you should round to integer and apply kerning likewise.
6) Printed text will still show slight difference, but be noticeably more readble.

Please understand that I know almost nothing about how fonts work and it is quite a lousy solution; but I hope it can be of some help to someone having similar nuisance!

[pgimeno]

Why not use a bitmap font?

[qwdqwqwffqw]

Why not use a bitmap font?

Thanks for the advice, but I'm afraid it wouldn't be better approach for the purpose. To get texts rendered in LOVE similar to those of other universal programs (for readability and aesthetic), the requirements would be :

[1] Each glyph should be rendered precisely, whichever size the font has.
[2] The intervals between each two glyphs should be precise.
[3] Special characters and non-latin characters should be able to get rendered.

FreeType does [1] and [3] with no problem. The only problem is in [2], which I think is caused by inaccrancy in approximating width of each glyph in smaller font sizes(bigger the font size, less the gap it shows). The discrepancy happens both in print functions and getWidth function.

On the other hand, bitmap font glyph is optimal for fixed font size and/or in low-res games. Scaling will mostly show visibly poor quality. Also, to accomplish 2), we still have to pre-cacluate glyphs' widths(which can be different from bitmap image widths) and kernings. Besides, bitmap font can be too inefficient for hi-resolution and countless non-latin characters. (e.g. Hanzi, Kana, Hangeul usually have no kerning and each group shares same width so the interval calculation is far less expensive than its rendering)

[qwdqwqwffqw]

By the way, the code is :

Code: Select all

-- big = big font size
-- small = small(main) font size

function alt_print(s, x, y)
	love.graphics.setFont(font)
	for i=1, #s do -- Ascii only example(1glyph=1byte)
		x = math.round(x)
		love.graphics.print(s:sub(i, i), x, y)
		if i < #s then
			x = x + bigFont:getWidth(s(i))*small/big + kerning(s:sub(i, i), s:sub(i+1, i+1))
		end
	end
end