cmang / durdraw

Versatile ASCII and ANSI Art text editor for drawing in the Linux/Unix/macOS terminal, with animation, 256 and 16 colors, Unicode and CP437, and customizable themes
http://durdraw.org
BSD 3-Clause "New" or "Revised" License
672 stars 20 forks source link

durformat spec reverses x/y #24

Open saulpw opened 8 months ago

saulpw commented 8 months ago

I'm trying to write a converter from .dur to .ddw (DarkDraw), and it looks like the specification for colorMap has the x/y coordinates reversed from the actual format.

From durformat.md:

Each element of the colorMap should coordinate with a corresponding line and column in the contents. For example, colorMap[2][3] should describe the foreground and background color for the character at contents[2][3], which is the character at Line 2, Column 3 of the given frame.

This makes sense to me and is what I expected, but looking at e.g. indyz-linuxfire.dur, there are 80 elements in colorMap, which corresponds to the width instead of the height.

cmang commented 8 months ago

Hey Saul. Good to see you again. :) Thanks for your report. Much love for DarkDraw here. Thanks for working on a converter.

Yep. The issue is exactly as you described. Many years ago when I wrote the first version of Durdraw I didn't think hard enough about my data structures, and copied the lousy names "x" and "y" from Ncurses standard functions. In retrospect, this was a very bad idea that has led to various confusion, including this bug. Something like "line" and "column" would have been more clear.

There are many places in the source code where these member names are touched. Fixing it has not been the highest priority.

For now, I think the thing to do to is to update the spec file to match reality, with the "rotated" color map. It's kind of lame, but if this is fixed in a future version, then both the .dur file format version number will increment, and the spec file will be updated again.

saulpw commented 8 months ago

Yeah that makes sense to just update the spec. Though, you're pre-1.0 now, so if you think you might want to change the format, now (or before 1.0) is the time. It's a hassle but it never gets any easier :)

cmang commented 8 months ago

You're right, and I do want this fixed in the next version (8) of the file format. Even if internally Durdraw is a bit confused about X and Y, it doesn't make sense for the file format to have the rotated color map.

I'll work on updating durformat.md to accurately reflect .dur format version 7 (with the rotated color map), and work on the code+spec for version 8 to fix this issue.

Officially, File format 7 contains the rotated color map, so you might want to reflect that in your converter. (I'm sorry for making you write extra code here when version 8 comes out, but you'll probably want compatibility with whatever people are currently making with Durdraw, I'm thinking.)