- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Template talk:Diagram/sandbox
One of the problems is that DF uses its own font. It's difficult to mimic the DF interface exactly with other fonts. I'm getting frustrated enough that I've actually considered cutting up curses_800x600.png into 256 different little images with transparent backgrounds and using them to build these diagrams. Won't work, of course, but short of making a custom font directly from the default DF font image, and somehow making the browser download it automatically, I don't see what I can do. Hussell 02:45, 3 December 2009 (UTC)
- I think the image strategy would work, except we wouldn't have control over the foreground color (resp. background color if we did it backwards). It would be strange if it were impossible to get another font to line up end to end. After all, it happens naturally when putting text into the edit box here. VengefulDonut 03:00, 3 December 2009 (UTC)
The difficulty isn't end-to-end. That works fine. The problem is getting the bottom of one line to touch the top of the next. Several of the monospace fonts seem to have different heights for different characters (e.g., ┼ vs █▓▒░), which leads to problems either with overlapping or gaps, depending on how the line-height is set. Hussell 03:06, 3 December 2009 (UTC)
- The difficulty is top end to bottom end :). It would be nice if there was a well behaved font that most people have. I'm going to see if I can find a mediawiki extension for generating images. VengefulDonut 03:25, 3 December 2009 (UTC)
Well, with the 16 DF colors, at most 256 * 16 = 4096 images would be needed, with fixed foreground colors and transparent backgrounds or vice versa. Assuming they'd be 16x16, each would be ~32 bytes, for a total of ~131 kilobytes, which is less than some individual screenshots on this wiki. In practice, many of those would never be used in any diagram, and the vast majority wouldn't be used in any particular diagram. The only difficulty would be in generating those 4096 images in the first place, and giving them a simple system of names so that a template can convert characters into images. There's also the issue of which tile set to use. 16x16 with minimal alterations to the default characters would be good, but the default set used by the game is hard on the eyes, IMO. Maybe the Cooz set, unshaded version? Hussell 17:13, 3 December 2009 (UTC)
- Oh, that's different from what I was thinking (finding an extension that creates images on the fly.. I did find an inline SVG extension), but your idea probably has more merit since generating and uploading the images is easier than making the SVG versions.
- For naming we could use the DF color (eg: 7:1) paired with the actual character being displayed. If we do generate the ~4k images, are you able to upload them to the wiki? VengefulDonut 20:57, 3 December 2009 (UTC)
- Another option. If we can find out what the necessary parts are for writing a mediawiki extension, perhaps we can convince Breiss to install the result. The PHP involved in taking a tile from a tileset map, recoloring it, and putting it into the page may turn out surprisingly accessible. Or better yet, we could try to find someone who knows PHP and has experience with writing wiki extensions. VengefulDonut 21:03, 3 December 2009 (UTC)
- An HTML trick is to have a single image for a bunch of tiles, then in the display code set a background origin to pick the tile you want to display out of the image. Not sure if something like that is possible with what tools we've got here. Cheepicus 23:57, 3 December 2009 (UTC)
- The HTML trick may work, if we set it up right; however, finding someone to write an extension (if that ends up the best option) will be a tough trick: I'm terrible with PHP, and the mediawiki codebase is such a tangled mess of hack jobs and bad code that I'd want to steer clear of it if possible. --Briess 05:05, 4 December 2009 (UTC)
- Templates aren't very well suited to converting characters into the corresponding offsets. It's doable, but it would require a rather large template page to be loaded for each cell. That problem could be solved with javascript or php, but we're avoiding php, and javascript cuts out the people who don't have it enabled.
- And this hasn't come up much, but it's worth pointing out that any method we use that goes through the wiki will get ~~~~ and other magic words parsed first. Anything using parser functions has the limitation that = and | mean something special and can't be used in the diagram without some sort of special input method.
- Maybe rather than trying to make the diagrams from within the wiki, we could put up a separate page specifically for creating diagrams which users could then upload afterward. Over all, this is starting to seem like a sticky problem. VengefulDonut 14:16, 4 December 2009 (UTC)
- Having a separate page to generate images for diagrams seems like the best solution available. Until that happens, is Diagram/sandbox good enough to replace Diagram? Since the last note, I've changed the color scheme to use DF default colors, encoded using a hexadecimal digit (see Template:C), and decided that treating spaces as part of the diagram is useful after all. (The diagrams already on the site use spaces. See the testcases.) I've also fiddled with the formatting until I'm finally satisfied that it's going to look reasonably good in most browsers. If it looks good on more browsers than Diagram does, and the various other changes meet general approval, I'm ready to replace Diagram and change all the current uses of Diagram to the new version. Hussell 16:09, 23 December 2009 (UTC)