XML talk:TSFF

From OniGalore
Jump to navigation Jump to search

Adding new fonts

Taking notes...

http://web.archive.org/web/20180117132342/http://www.devasp.net/net/articles/display/139.html

You could probably generate images of every glyph. Instead of saving these images, the pixels could be read and turned into int32 values...

More interesting than import them as text would be import them with font files: http://www.acutesystems.com/fonts.htm. However for this we would need that Neo would add this functionality to OniSplit. Script 10k (talk) 10:53, 30 November 2016 (CET)
Paradox is talking about a way to generate arrays of ints to represent the glyphs' pixels. If you export TSFFTahoma to XML, you'll see that OniSplit generates a raw list of ints which could be replaced with the ints generated by that VB code. It also takes that XML back in with the -create command and generates the TSFF.oni file again. It's not elegant, but it might work.
As for OniSplit handling a font file automatically, I don't think we can count on Neo adding frivolous functionality like that to OniSplit. I don't know if he is even planning on making any more releases. This is the sort of thing that normally a community would add to their primary modding tool, but in our case we don't even have a direct release of a recent version of the source code. That's why we would be better off trying to get Neo to open-source OniSplit than asking him for new features. I tried to contact him about this, but I don't think he checks his Yahoo email anymore. --Iritscen (talk) 17:15, 30 November 2016 (CET)
[Update: We finally got his OniSplit source in 2020. See here. --Iritscen]
Oni supports only bitmap fonts. (Or is that wrong??) So not even Neo can bring a vector based font to Oni because that would mean changing Oni's or Daodan.dll's code and not OniSplit.
Also, I don't think it would be dirty to create bitmaps for a new bitmap font... It's just about how accurate we write the code to output suitable distance values (line height, row distance, space between glyphs, ... ) --paradox-01 (talk) 20:07, 30 November 2016 (CET)
You're right that Oni can only display bitmap-based fonts. In theory, OniSplit could perform the same process as that VB code, using as its source a font file which we supply the path to. In that case, it wouldn't matter if the font was bitmap- or vector-based because OniSplit would simply draw the letters into a graphics context in memory and encode the resulting pixels as ints, just like that VB code. I'm not sure if that is what Script meant to suggest.
Another issue would be a legal one; we shouldn't import a font that we don't own the rights to. There are probably enough fonts in the public domain, however, that we wouldn't have to design our own. In that case, the font metrics that you speak of would already have been worked out by the font designer. The only thing that Oni can't support is variable distances between letters (kerning) or any other complex font behaviors, so we would have to look for a font that doesn't depend on those features to look nice. Personally I don't see a big advantage to importing a new font, as it would simply create inconsistency in the look of the game. --Iritscen (talk) 21:39, 30 November 2016 (CET)
I think that copyrighted fonts contain a flag that can be read by programs such as InDesign so that the user gets notified when he tries to 'summarize' all files or attempts to embed it into a PDF. That could be used to reject font use in this hypothetical Oni tool. --paradox-01 (talk) 20:22, 5 December 2016 (CET)
If want to look further into this, maybe look here too, Google's top hit for "font bit flags": http://www.derwok.de/downloads/ttfpatch/ --paradox-01 (talk) 20:33, 5 December 2016 (CET)

Just want to make a new note here about the fact that some localizations of Oni did add new fonts to the game. This was necessary in order to display foreign characters. See Japanese Oni, which has .fnt files in its GameDataFolder and a patched Oni.exe that reads them into memory. --Iritscen (talk) 16:03, 21 August 2020 (CEST)