- You can hand-edit a glyph's settings individually. You can also modify the kerning and ascent values for all glyphs at once. - Glyphs define two sets of coordinates: coordinates for each corner of the glyph within the TEX file; and values for the width, height, ascent, and kerning. These values are not redundant. Oblivion renders text by constructing a 3D mesh for it at run-time, with one quad per glyph. The corner-coordinates are UVs for each vertex in the quad, while the width, height, and other values are used to control the position of each vertex. As such, the UVs and the pixel-values don't actually have to match up; you can make a high-resolution font that gets downscaled for display (and we provide a "Scale Mult" option to control this). Of course, this isn't recommended, because the downscaling isn't very high-quality. Downscaled fonts would only be useful in cases where the user's screen resolution is taller than 960px, because the UI is rendered to a height of 960px and then scaled to the user's screen height; on taller screens, the UI (and fonts) would be scaled up. - The bottom bar contains a rendered preview of your font. Type "\n" to add a line break. The preview should live-update as you load/create fonts and make changes to glyphs. The preview code mimics how Oblivion positions glyphs (and I disassembled the game to verify this), but has some inaccuracies due to how web browsers handle graphics. Our preview is a 2D graphic rendered at 1:1 size, but Oblivion renders text to a 3D canvas that is scaled based on your screen size. The most notable differences are that glyphs won't appear at the same size, and glyphs with sub-pixel values (e.g. kerning) will appear fairly blurry in our preview but not in-game. - Vertical alignment of text was made accurate in the v1.2 patch. The changes were verified by disassembling Oblivion. Unfortunately, vertical alignment is not strictly intuitive. Every font has a value that, at run-time, is stored in a field at offset 0x2C; we refer to it as engineUnk2C in the editor. This field is set to the maximum of these values, computed for every glyph: Font Line Height + Glyph Height - Glyph Ascent When it comes time to render a run of text, the text is offset by the following value: (Engine Unk2C - Font Line Height) * 2 This, of course, simplifies to the following value (again, the maximum out of all glyphs): (Glyph Height - Glyph Ascent) * 2 This means that to edit the alignment of text within a TEXT element in the user interface, without also editing the height of each line of text, you generally need to use a non-printable character as a "dummy" and change its height and ascent. If ((height - ascent) * 2) is less than the font line height, then text will be pulled upward; if ((height - ascent) * 2) is greater than the font line height, then text will be pulled downward. If ((height - ascent) * 2) is exactly equal to the font line height, then the text baseline (the bottom of the "ascent" portion) will be aligned with the bottom edge of the element. For fonts generated from scratch, we configure the null glyph (00 NULL) to have a height and ascent as outlined above (i.e. ((height - ascent) * 2) is equal to the font line height). To move the first line of text downward by one pixel, you would increase the height of the null glyph by 0.5. - When you've selected a glyph, underlays appear on the displayed data. These underlays indicate: - RED -- The glyph's bounds (visible) size. Everything in the red box is part of the visible glyph. - CYAN -- The glyph's "hitbox," accounting for ascent and kerning. The bottoms of every glyph's "hitbox" will be aligned when text is rendered. - GREEN -- The glyph's vertical positioning within a line of text. - YELLOW -- The boundaries of the text element itself, assuming a single line of text. See explanation above. - If you see text with a dotted underline, hover over it for a tooltip that explains what it does/is. - When generating fonts, the Outline thickness can be a bit quirky due to idiosyncrasies in how browsers render outlined text to canvases (the 2D render tech that this tool uses). An outline that's "three pixels thick" will appear to be closer to one pixel thick. An outline that's "five pixels thick" won't be nearly that thick in the rendered image. Note also that fonts *without* an outline may have indistinct or low-quality edges when rendered in-game. For a sans-serif font at 22px or so, I've had the best results using a "three-pixel outline" (so, one pixel thick). - Bear in mind that when generating fonts from scratch, the editor *estimates* the dimensions of each glyph. It does this based on the alpha transparency of each pixel in the font. You may want to go through each glyph by hand and make sure that its width/height bounds aren't too large. This is preferable to just using kerning to compensate for the difference, because kerning can knock text off of alignment when it needs to be centered, justified, etc.. How you go about verifying that will vary depending on your font's character- istics. I mentioned using a font with a one-pixel border earlier: what I can do in that case is just move one of the corner UVs inward and see if the out- line is cropped off. Of course, when you're changing the size of a glyph, remember to change BOTH the UVs AND the width/height values, so that your glyph isn't stretched. - The editor now offers macros, which can be used to quickly make fonts that force rendered text to all-uppercase or all-lowercase. Note that these operations directly modify the loaded font data and cannot be undone. Make sure you've saved a separate copy of your normal font before using these macros. These macros work by modifying the glyph data, copying one set of glyph coordinates over another. This means that an all-uppercase font and an all-lowercase font generated from the same base font can share a TEX with that base font and with each other. - The editor now offers PNG import/export. If you are importing an image that is a different size from the loaded image, you will be asked how to handle the size difference. Internally, glyphs store their coordinates as UVs (i.e. percentages along the width and height of the image); in order to keep the glyphs' pixel sizes the same, the UVs must be rescaled from the old image to the new image. This is what the editor asks permission to do. - The editor now allows you to multi-select glyphs. When multiple glyphs are selected, only glyph bounds (not line bounds) will be overlaid in the TEX view on the left. The input fields for editing glyph properties will be blank; you can use the increment and decrement buttons on each field to change that field for all selected glyphs.