[Linux, OSX] DF crashes with a TTF Font with width>height.

TimRobinNet commented 5 years ago

Hi,

I hope this is not completely stupid. It has been years since I played DF the last time so please bear with me..

I'm running DF on a Mac OS X 10.12.6. I downloaded DF 0.44.12 and extracted it. I download CLA-44.xx-v26.zip and extracted it. I copied the files, as you described, and tried both

deleting data/art and replacing with yours; replacing colors.txt, d_init.txt and init.txt with yours; deleting raw/graphics and replacing with yours; replacing raw/objects/item_tool.txt with yours
as well as just throwing the content of data/art into the DF folder while keeping the original things in there (only replace if you had the same name); same for the content of raw/graphics

When I start DF, I can select "Create New World" and it loads till the point of "Welcome to the Alpha of Dwarf Fortress" - but as soon as I press ESC to continue, the game just crashes.

Do you have ANY idea what I'm doing wrong? I don't have any tileset or so (you mention Myne) installed, it's literally DF out of the zip. Is that a problem? I followed the instructions as much as I could but have no idea how to continue from here.

Thank you for your time and help :) Tim

VictorElHajj commented 4 years ago

I can confirm the same issue with DF on Archlinux, same versiond of DF and CLA. Error: Dwarf_Fortress: /build/dwarffortress/src/dwarf_fortress_unfuck/g_src/ttf_manager.cpp:140: ttf_details ttf_managerst::get_handle(const std::list&, justification): Assertion `pixel_width >= ttf_width' failed. Aborted (core dumped)

obabichev commented 4 years ago

I've got the same problem on the 0.44.12 version

claireanlage commented 4 years ago

Hi! Sorry for the late reply, I was under the impression that I would get email notifications of issues. I don't have a Mac OS system I can test it on, but it might be the same error @VictorElHajj has. Could you try using the original TTF font that comes with the game instead of the one I include?

In other words: download CLA-44.xx-v26.zip and extract it. delete font.ttf continue as usual with copying the files.

Edit: It seems to be related to this existing DF bug: https://www.bay12games.com/dwarves/mantisbt/view.php?id=5819

But it would be nice to see if it's just the new TTF font I made or if it's happening with all TTF fonts for you.

VictorElHajj commented 4 years ago

I followed your instructions and installed without the font.tff file. After doing so it seems to work, no crash when pressing escape as described in the OP.

claireanlage commented 4 years ago

Okay, so it's something with the font that's the issue. I hope I can find time to fix it in the coming weeks. ~~Either way, i'll revert the default to the other font when I get to it next week. Or someone else just makes a pull request.~~

Edit: I'll leave the issue open until I can fix the font.

jecowa commented 4 years ago

I've been messing around with this font in font editor, and haven't had any luck. It seems to crash when trying to load a particular character. I can't find anything wrong with the font. The canvas width of every glyph seems to be the same "1904". The validation check comes up with much fewer errors than the working profont.tff. Fixing the validation errors (mostly glyph overlaps) does nothing to help either. Tried changing the font's Em size so that it's a traditional power of 2.

Oh, minor success. After deleting every single glyph and making the Em size 1024, it finally gets to the world gen parameters. Thirteenth time's the charm. Narrowed it down some more. The bugged character(s) are within the 62 alphanumera. It's one of the capitals, and the Em size doesn't matter. It's from A-M range. There's an error in the F-M range. There's no error in the A-F range. There's an error in the K-M range. No error in the G-J range. K & L are fine; it must not like the M.

I don't see anything wrong with the M, though. Deleting just the right-half of the M fixes it. Deleting half the M had a strange effect - the right half of other characters is also not consistently displaying now. https://i.imgur.com/wgIXnnE.png I don't understand why this would have any effect on the other characters. With deleting the left half instead, it still crashes. It's something in the right-most 6 points of M. Deleting just the right-most 3 didn't fix it. Deleting just the left of the top-most side of the right stem of the M didn't help. Deleting just the 2nd 3 right-most points didn't help. Deleting just the top 4 of the right stem of M didn't help.

I dunno. Here's a version with a mangled M that works: https://www.mediafire.com/file/q1ifz62khokynyw/18x18-CP437-deletingrightthirdofM.ttf/file

claireanlage commented 4 years ago

Maybe the 'M' is just used to calculate the em-width, so if you cut it off, the width is smaller and it works. It feels like there's no issue with the actual font, but with libgraphics.so (see the df bug report linked above), but I'm wondering why it's not crashing with other ttf fonts then. Maybe it has to do with fact that the font here is monospaced? But profont was too, IIRC. I'm inclined to close this and just warn Mac and Linux users to disable ttf or use another font. What do you think?

jecowa commented 4 years ago

I think you're right about the "M" just being used to do a check, though it doesn't seem to check the "M" until it's displayed on-screen. The "M" glyph works fine when copy-pasted to the "D" spot.

It doesn't seem to be measuring the size of the glyph alone; it's measuring the distant between the far left border of the canvas and the far right side of the glyph.

If I move the glyphs that are getting cut off (like "w", "r", and "g") to the far left side of their canvas, then they don't get cut off anymore. And with the "M" moved over to the far left side, it's just 1% away to getting to a state to not making the game crash. On the "Profont", most the glyphs seem to be left-aligned.

I suspect the real issue might be the aspect ratio of the canvases of the glyphs of Newfont. This font is unusual in that the width of the canvases are wider than they are tall. If the canvas size is changed to be square or taller than it is wide, that might fix it.

Setting width to 1800 to match the height didn't fix it. Setting width to 1800, and then shifting every glyph left by 300 seem to fix it. Oh, just shifting everything left 300 does it too.

Here it is if you want to check it out: https://www.mediafire.com/file/54japow7no1oqmk/18x18-CP437-shiftLeft300.ttf/file

jecowa commented 4 years ago

The function that shifts everything to the left also shortens the width of the canvas. Shifting everything to the left by only 105 to bright the width down to 1799 to match the height of 1799 fixes it too. https://www.mediafire.com/file/eiy7wcv18xeyhqf/18x18-CP437-shiftallLeft105.ttf/file

claireanlage commented 4 years ago

Now I remember that I purposely widened it to fit the tileset as close as possible. Damn. The whole point of this font was to get a ttf font that looks exactly like the tileset to visually conform to the tile grid. With your fixed font (and the one I had before with a height and width of 1800 to make it easy to import the 18x18px glyphs) the font looks squashed compared to the tileset -- which I guess was the whole point of ttf in the first place, to get a proportional font with square tilesets.

Anyway, so the actual issue seems to be that fonts which are wider than they are high cause a crash, right?

jecowa commented 4 years ago

Yes, I think they actually needs to be taller than they are wide. Moving it only 104 left isn't enough to prevent the crash, but 105 does it.

I'm trying to make it taller now so that they're 1905x1904 to see what that does. It didn't work. They're all still 1800 tall. "Set Vertical Advance" must not do what I thought it would do.

It seems strange that it needs to be wider than it is tall in order to look like a square font. I wonder if there's some other way to get the same spacing without making the glyphs so wide.

Would it be so bad to not be the same spacing as the tileset? Imo, narrow fonts are easier to read than square fonts.

claireanlage commented 4 years ago

Oh yeah, of course it's not a problem. Just a personal preference. I will just use the unwidened font in the future. Hopefully with the graphics rewrite for steam that won't be a problem in the future anyway. Thank you so much for your research on this. I'll see that I upload the unwidened font that i had before for testing in a moment.

We should probably file a bug report on mantis, since it's only a problem for DF and only for Mac and Linux. Maybe libgraphics.so or SDL_ttf or whatever is the culprit. Not sure though if we should use a new bug report or one of the existing ttf bugs.

claireanlage commented 4 years ago

Ok, I pushed the changes in a new branch here:

https://github.com/DFgraphics/CLA/tree/ttf-issue-workaround

@jecowa, @VictorElHajj, @habegage could you test if this fixes the crash? Here's a direct link to the file: https://github.com/DFgraphics/CLA/blob/ttf-issue-workaround/data/art/font.ttf

jecowa commented 4 years ago

Sorry, it needs to be taller than it is wide. It still crashes for me.

claireanlage commented 4 years ago

updated it again. This time with the font you provided. I hope this is ok, by the way.

jecowa commented 4 years ago

Yeah, it's fine with me.

DFgraphics / CLA

[Linux, OSX] DF crashes with a TTF Font with width>height. #8