Problem lining up same font with different heights.

[Pete]

Code: (Select All)

$Color:32

Screen _NewImage(1300, 600, 32)

_ScreenMove 20, 0

Cls: _Display

Dim f&(6)

f&(1) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 16)

f&(2) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 20)

f&(3) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 24)

f&(4) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 30)

f&(5) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 38)

f&(6) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 48)

f& = 1: _Font f&(f&)

Line (20, 201)-(200, 201)

row = 200

_Font (f&(1))

fh& = _FontHeight

_PrintString (20, row - fh&), "O"

_Font (f&(2))

fh& = _FontHeight

_PrintString (50, row - fh&), "O"

_Font (f&(3))

fh& = _FontHeight

_PrintString (80, row - fh&), "O"

_Font (f&(4))

fh& = _FontHeight

_PrintString (110, row - fh&), "O"

_Font (f&(5))

fh& = _FontHeight

_PrintString (140, row - fh&), "O"

_Font (f&(6))

fh& = _FontHeight

_PrintString (170, row - fh&), "O"

_Font (f&(1))

I thought subtracting the height of the font from the row would make the bottoms of each character align themselves horizontally on the line. What I noticed is that as the font size is increased, the larger character prints progressively slightly higher, above the line. Is there a remedy for this, and not just with lucon fonts, but others as well?

Pete

[Pete]

The best I can figure, without seeing the pixel grid, is the difficulty stems from different characters like a j and an I being at different bottom starting pixels, and when we increase the size, this causes the distortion.

Oh, I had to edit the above post. Messing around with it to see how it looked with and without the _FontHeight, I forgot to put the underscore back when I pasted it in the post. It's correct now.

Anyway, this code may not be the best, but it's getting close to whatever the correct algorithm might be to solve for this problem...

Code: (Select All)

$Color:32

Screen _NewImage(1300, 600, 32)

_ScreenMove 20, 0

Cls: _Display

Dim f&(6)

f&(1) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 16)

f&(2) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 20)

f&(3) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 24)

f&(4) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 30)

f&(5) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 38)

f&(6) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 48)

f& = 1: _Font f&(f&)

Line (20, 201)-(200, 201)

row = 200

_Font (f&(1))

fh& = _FontHeight

_PrintString (20, row - fh& * .75), "O"

_Font (f&(2))

fh& = _FontHeight

_PrintString (50, row - fh& * .75), "O"

_Font (f&(3))

fh& = _FontHeight

_PrintString (80, row - fh& * .75), "O"

_Font (f&(4))

fh& = _FontHeight

_PrintString (110, row - fh& * .75), "O"

_Font (f&(5))

fh& = _FontHeight

_PrintString (140, row - fh& * .75), "O"

_Font (f&(6))

fh& = _FontHeight

_PrintString (170, row - fh& * .75), "O"

_Font (f&(1))

Pete

[bplus]

@Pete they, the developers, did some font fixing that controls the problem you are bringing up. It was a version or 3 ago that they started fixes with fonts.

I am having senior moment what they called it _Q prefix to all normal font subs and functions,
_Qprint or _QprintString, oh Lord the memory is like sieve... there is like a _QPrintWidth, _QFontHeight...
oh let me see in Wiki if I am close... nope dang! it doesn't start with _Q because nothiong in QB64 starts with _Q

@RhoSigma nothing in _font stuff mentions the new font fix prefixes for all the equivalent old _font functions ie when it says see such and such with links.

I will start digging, I sort of remember where I was messing with new font fixes.

[bplus]

Found it _U was the prefix!

   

_USee ? I think _UlineSpacing might be helpful for you @Pete

[Pete]

So far I can't see any way to use the _U keywords.

This algorithm of .8 seems the closest for this font...

Code: (Select All)

$Color:32

Screen _NewImage(1300, 600, 32)

_ScreenMove 20, 0

Cls: _Display

Dim f&(9)

f&(1) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 16)

f&(2) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 20)

f&(3) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 24)

f&(4) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 30)

f&(5) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 38)

f&(6) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 48)

f&(7) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 58)

f&(8) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 68)

f&(9) = _LoadFont(Environ$("SYSTEMROOT") + "\Fonts\lucon.ttf", 90)

f& = 1: _Font f&(f&)

row = 200

_Font (f&(1))

fh& = _FontHeight

_PrintString (20, row - fh& * .8), "O"

_Font (f&(2))

fh& = _FontHeight

_PrintString (50, row - fh& * .8), "O"

_Font (f&(3))

fh& = _FontHeight

_PrintString (80, row - fh& * .8), "O"

_Font (f&(4))

fh& = _FontHeight

_PrintString (110, row - fh& * .8), "O"

_Font (f&(5))

fh& = _FontHeight

_PrintString (140, row - fh& * .8), "O"

_Font (f&(6))

fh& = _FontHeight

_PrintString (180, row - fh& * .8), "O"

_Font (f&(7))

fh& = _FontHeight

_PrintString (220, row - fh& * .8), "O"

_Font (f&(8))

fh& = _FontHeight

_PrintString (270, row - fh& * .8), "O"

_Font (f&(9))

fh& = _FontHeight

_PrintString (330, row - fh& * .8), "O"

Line (20, 201)-(400, 201)

_Font (f&(1))

Not prefect in all instances, but probably close enough.

Pete

[TerryRitchie]

I ran into something similar years ago when creating my menu library. I had to come up with a magic number (like your .8) to nudge fonts here and there to make the align properly.

[SMcNeill]

I think what you're seeing is just an affect of how fonts work.  Take a look at the following characters

fog

Notice how all the characters line up on an imaginary line on the screen?  The problem you're facing is rather obvious though, once you put that "o" in perspective with the other two characters.  The "f" prints taller, so the "o" isn't going to align to the top of our font character area.  The "g" prints lower, so the "o" isn't going to align to the bottom of the font character area.

That "o" has whitespace above and below it -- it just kind of "hovers" in its proper position there, in the middle of the top of the "f" and the bottom of the "g".

Thing is, when you increase the font size, you also increase the amount of whitespace above and below that "o".  

If you need pixel perfect alignment of that "o" on a line, like your demo, then you'd want to do 2 possible things:

1) Write a routine to use POINT or similar to find out exactly how many pixels of blank lines exist above/below that character, so you can strip them off and ignore them when positioning

OR 

2) Try and position by _Fontheight / 2.   <-- Seems to me that this would center those characters and probably align them proper along a line.  It'd just along the centerline and not the top or bottom of the character.


And then we have HACK #1)  Try and guess at the ratio of actual pixels and blank spaces, and modify all heights by that value.  (Such as your .8 in your test code.)  It'll vary a lot from font to font, depending on how they space things, but it's probably the easiest solution, if you're going for a limited font-use situation.

[Pete]

We are on the same page here. I had tried the /2 thing, a few days ago. It looked promising when there was little difference as when writing with font sizes 16 to 20, but go something like 12 to 60 and it fell apart. That's when I started thinking about the ratios that font designer hav to take into account to make tall vs below the line characters like j look correct. I figured since most of all letters are top oriented, something around .75 would be close.

As for the POINT suggestion, that's a neat idea, although I'm worried about slowing the WP process down a bunch. I wonder what approach software makers use for sites, like this one, to line up variable sized fonts...

sIjP1z  

Just making each of those really makes me think each font has a ratio assigned to it in the software WP.

Pete

[SMcNeill]

All that information tends to be stored in the font itself.  Baseline, height, padding, line spacing, ect, ect.

You can keep your execution times down, by pre-processing those calculations.  Make an array of 0 to 255, slide each character through it, and calculate once what the blank pixels are going to be for each character and store it.   Then instead of the row - fh&, it'd be row - char_height(ascii_value) for placement.

[bplus]

Am I mis-informed or under the wrong impression that all the _U prefix stuff is supposed to help with alignment problems better than the older font stuff?