Assume an origin of (x,y) = (0,0) in the top left corner of the screen; then the y-coordinate at which a glyph is rendered is calculated as baseline - yOffset, where yOffset is encoded per glyph. The other baseline related property you mentioned is an offset to adjust the font offset relative to the GUI (it offsets an entire block of text rather than individual glyphs.
That does not seem to match with the rendering in Empire. The per glyph y offsets are smaller for lower glyphs, and higher for capitals and glyphs with ascenders, your way would make for an uneven line in Empire.
[*]short 5: seems to have something to do with baseline, but there is a maximum and a minimum, in one font I tested changing default 7 to 0xF resulting in the text moving down two pixels, while 7 to 1 results in moving up by five pixels.
I call it LayoutYOffset. It is a signed short (rather than the unsigned ones that most of the others are). The absolute value is an offset as described earlier, where 0<= offset <= 0x7ff. If the bit corresponding to 0x8000 is set then it is a negative offset, otherwise positive.
In FormatConstants.java you seem to call this baseline and #6 LayoutYOffset. This value is between 3 and 0x1C in the Empire fonts.
[*]short 6: also seems related to baseline, changing this matches the changed baseline exactly.
It is the baseline.
It has a value of 0 or lower, are you sure it is the actual baseline? And to what is it relative? It doesn't seem to match with the top of the container in which the text is drawn.
I figured it'd be something like that (I ignore it in font previews, though), however note that this value does not directly correspond to the *actual* largest width of any glyph in the font. (HSize)
It does match in the Empire fonts (with the bitmap with, not that other horizontal value), but it can be made larger without any side effects.
Not ints according to my tests. Rather shorts. Position in the array indicates UTF-16LE/UCS2 code point, 0xFFFF indicates “not supported”.
You are correct, those are shorts, my apologies.
[*]byte 0: starting height of the glyph in pixels above the baseline, 0x80 indicates the glyph doesn't have a height.
Odd, the logical thing to do would've been to set it to 0. It suggests, though, that the value is signed and 0x80 means “literally”: -0 ?
It is a signed value, some characters start below the baseline, especially underscores have a tendency to do that. Signed integers do not have -0 value, it would mess up calculations (the way it works now the basic cpu operations don't have to take into account signed or unsigned integers, the results are correct either way).
Do positions correspond to glyph index as mapped by the char table earlier minus the number of positions to skip? E.g.: if V has position 5 in the char table and A has position 3 and the font is configured to skip 2 positions; does it follow that the combination “AV” is given as position (1, 3) ? Or are there blank entries in the loops?
There are no blank positions.
The header in a font is 0x15E (350) and 0x21 (33) After that are 350 blocks of 350 bytes.
The glyph IDs as related to code points and characters for that font are:
Code:
UniC ID Char GlyphProps Kerning
0000 FFFF
0001 0000 80 00 00 00
0002 0001 80 00 00 00
0003 0002 80 00 00 00
0004 0003 80 00 00 00
0005 0004 80 00 00 00
0006 0005 80 00 00 00
0007 0006 • 80 00 00 00
0008 0007 80 00 00 00
0009 0008 80 00 00 00
000A 0009 80 00 00 00
000B 000A 80 00 00 00
000C 000B 80 00 00 00
000D 000C 80 00 00 00
000E 000D 80 00 00 00
000F 000E ¤ 80 00 00 00
0010 000F 80 00 00 00
0011 0010 80 00 00 00
0012 0011 80 00 00 00
0013 0012 80 00 00 00
0014 0013 ¶ 80 00 00 00
0015 0014 § 80 00 00 00
0016 0015 80 00 00 00
0017 0016 80 00 00 00
0018 0017 80 00 00 00
0019 0018 80 00 00 00
001A 0019 80 00 00 00
001B 001A 80 00 00 00
001C 001B 80 00 00 00
001D 001C 80 00 00 00
001E 001D 80 00 00 00
001F 001E 80 00 00 00
0020 001F (spc)80 03 00 00
0021 0020 ! 08 06 03 08 350 x 04
0022 0021 " 08 08 04 03 350 x 06
0023 0022 # 08 08 07 08 350 x 07
0024 0023 $ 0A 08 06 0B 350 x 07
0025 0024 % 08 0D 0A 08 350 x 0B
0026 0025 & 08 0A 08 08 350 x 08
0027 0026 ' 08 04 02 03 350 x 02
0028 0027 ( 09 05 04 0B 350 x 04
0029 0028 ) 09 05 04 0B 350 x 04
002A 0029 * 08 08 06 05 350 x 07
002B 002A + 06 08 07 06 350 x 07
002C 002B , 01 04 03 03 350 x 03
002D 002C - 04 05 04 01 350 x 04
002E 002D . 02 04 02 02 350 x 02
002F 002E / 08 04 05 08 350 x 04
0030 002F 0 08 08 07 08 350 x 07
0031 0030 1 08 08 04 08 350 x 06
0032 0031 2 08 08 06 08 350 x 07
0033 0032 3 08 08 06 08 350 x 07
0034 0033 4 08 08 07 08 350 x 07
(The kerning tends to be 350 times the same value, only few values have it adjusted)
If I want to make "12" look like "1 2" I would increase the 17th byte of the 16th block from say 6 to 10.
I forgot to mention that in Empire if your resolution is lower than 1280 horizontal or 960 vertical then text gets scaled proportionally, obviously leading to blurry text. Larger does not lead to scaling, so that might be something to take into account when previewing text and how/where to place your pixels.