• Wiki Suggestions
• Colorized text

MayLith: Can wiki text be colorized somehow? I would like to translate dungeon.txt into wiki for the Documentation pages. (I guess that makes me a glutton for punishment.)

I don't even know if this is possible in wiki. My search of the wiki help only shows something about colorizing python code.

NeilStevens: Re: dungeon.txt: Don't. Just don't. Obsolete data files in barely-human-readable formats are not needed here.

As for your question, nobody here knows the wiki code yet. You'd best familiarize yourself with the MoinMoin wiki, in particular the Markets like the MacroMarket.

IainMac: I do not know if this would be helpfull but you might want to consider this link to get a code snipit that does simple coloured text.

NeilStevens: Thanks, but that's not applicable to what we're using.

MayLith: Thanks for the links, both of you. I am going to very cheerfully take Neil's advice to not go there, at least not for dungeon.txt.

FearofFours: I'm not sure that Maylith and Neil are talking about the same thing here. Maylith is talking about help/dungeon.txt whereas I believe Neil is talking about edit/d_info.txt . help/dungeon.txt is NOT obsolete in anyway whatsoever, and would benefit from being presented in colour on the wiki, as would the Documentation/HelpfileFormat page. The other way round this would be to be able to use html tags, but this doesn't seem to be supported either.

NeilStevens: Good question, and you sound right to me.

MayLith: Thanks, FearofFours. I didn't know enough to recognize the difference.

Next question: From what I understand of that code snippet, the wiki itself will have to be recompiled in order to make this help, yes? Whether it does or does not, though, it seems to me that that snippet would have to be expanded, as there are many more colors in the game palette (which would need to be used in a wiki version of dungeon.txt) than in that snippet.

NeilStevens: OK, I say don't use colored text to lay out documentation of the game. Please use layouts that need no color to be clear and understandable. You don't know what CSS people will use, you don't know what kinds of color-blindness people will have, you don't know whether the user's client will even be capable of displaying color. We have much text on here already without color, after all.

Note that you can't even match the in-game colors with the CSS colors, anyway. There are some things the in-game help can do that the Wiki won't be able to. Each side of the documentation has its place.

FearofFours: OK, seems like we're going to have to do without text color on the wiki.

MayLith: Neil: I completely agree re: CSS and color-blindness issues. The only thing I was interested in colorizing is that great big long list of assortedly-colored terrain types (e.g. '.' = road, ice, dirt, glass, whatever, based on what color it is.) That was all. If you don't mind trashing that, I'm more than happy to drop it.

In its place, I guess what I might suggest is to:

• list an ASCII terrain type (e.g. '.') and then what it might possibly be, or
• scrap even that and explain how to use the look command to look directly at assorted terrain, or
• just trash it.

Comments?

NeilStevens: Trash it, probably. Something that basic should be in-game, and ideally the docs should be upgraded to use the map-drawing code to display the correct symbol or graphic according to the users' settings.

FearofFours: Can you do the necessary coding for that Neil? It would be very useful.

NeilStevens: I can't promise to do that anytime soon, sorry. My plate's full.

MayLith: FF, given this, we'll need to start tracking split between in-game and wiki Doc. I'll post over on wiki doc. Methinks just leave a stub that says "see in-game help."

SoulWynd: If anyone could point me to the source code of MoinMoin's colorize processor, I could spend some time and try to make it work with diferent tome syntaxes, including map color and similar things. I believe that would have some with the color problem.

MassimilianoMarangio: The source code is available from Sourceforge.net. Some extensions to MoinMoin are gatherd in http://moinmoin.wikiwikiweb.de/MoinMoinExtensions. See e.g. Color.py in the Macro Market and the Parser Market for a more general language support.

SoulWynd: I gave it all a look and I'm gonna try coding a processor to format a few things. The only problem is that I have no way of testing it here.

MayLith: That's a very generous suggestion, but I'm still concerned about the effects of CSS/etc. Probably the very simplest solution (aside from just trashing the terrain lists outright, which would save me a lot of work!) is the first of my three suggestions above, namely just doing something like:

SoulWynd: Well, the color processor in this wiki only works inside code spaces, ie, inside {{{}}}'s ... We could choose a standard color setting for each processor. The #!python processor works just like that right now. The simpliest thing I can do right now is a processor to read tome html dumps, since there's no real translation to be done. A second one would be to colorize and format (if needed) character dumps. I'm not sure of how useful this will be, but it can be a nice idea.

MayLith: I'm not sure what that has to do with tables... (apparently nothing?) IMHO (and others' opinions may vary) there's no point to put character dumps here on the wiki; we've already got oook.

SoulWynd: If that's all you want to do, I can try coding a color processor for it. I will use the CSV.py as source, it seems easy enough.

Okay, all done:

# -*- coding: iso-8859-1 -*-
"""
    Processor for MayLith's terrain table, based on CSV processor
    
    Original header (I never remember GNU GPL rules, so there you go):
    
    

    MoinMoin - Processor for CSV data

    @copyright: 2002 by Jürgen Hermann <jh@web.de>
    @license: GNU GPL, see COPYING for details.
"""

Dependencies = []

def process(request, formatter, lines):
    # parse bangpath for arguments
    exclude = []
    color = 0
    for arg in lines[0].split()[1:]:
        if arg[0] == '-':
            try:
                idx = int(arg[1:])
            except ValueError:
                pass
            else:
                exclude.append(idx-1)
        if arg == 'color':
            color = 1

    # remove bang path, create output list
    del lines[0]
    output = []

    if lines[0]:
        # expect column headers in first line
        first = 1
    else:
        # empty first line, no bold headers
        first = 0
        del lines[0]

    output.append(formatter.table(1))
    for line in lines:
        output.append(formatter.table_row(1))
        cells = line.split(';')
        for idx in range(len(cells)):
            if idx in exclude: continue
            if first:
                output.append(formatter.table_cell(1))
                output.append(formatter.strong(1))
                output.append(formatter.text(cells[idx]))
                output.append(formatter.strong(0))
                output.append(formatter.table_cell(0))
            else:
                if color and (idx == 0):
                    output.append(formatter.table_cell(1, {'bgcolor': '"black"'}))
                    output.append('<FONT COLOR="%s">%s</FONT>' % (cells[1], cells[0]))
                    output.append(formatter.table_cell(0))
                else:
                    output.append(formatter.table_cell(1))
                    output.append(formatter.text(cells[idx]))
                    output.append(formatter.table_cell(0))
        output.append(formatter.table_row(0))
        first = 0
    output.append(formatter.table(0))

    request.write(''.join(output))

This should replace the processor\CSV.py file ... I think It will work... Or at least I hope it will... It shouldn't damage the CSV processing at all, it only adds what MayLith wants to do.

Format should be the same as creating a CSV table, but the second column of the table must have valid html color for it to work. Here's a reference guide for the html color keywords

Example (Read the raw page to see how it's done):

NeilStevens: Actually, I'd love to put all my character sheets here instead of on oook. That way I get a history, something not available there. I'd also have them tied to my name instead of an email address and be able to fix my mistakes.

As for colorization: That's great, but that doesn't address a key issue: You can't color-match CSS and ToME, so really the color stuff's only any good as documentation when in game.

ReenenLaurie: Could that work for just normal formatting? So that one can type [[ColorText(color,mytext)]] to have the text in a certain color. (The aim here is to have Neil's RecentChanges shopkeeper quote able to display fine with a different font color).

ReenenLaurie: I found this on the Macro Market

"""
    MoinMoin - Color Macro

    Copyright (c) 2002 by Markus Gritsch <gritsch@iue.tuwien.ac.at>
"""

def execute(macro, args):
    if args:
        sep = args.find(':')
        if sep != -1:
            return '<FONT COLOR="%s">%s</FONT>' % (args[:sep], args[sep+1:])
    return '<B>Example: [[Color(blue:Hello World!)]] or [[Color(#8844aa:Hello World!)]]</B>'

SoulWynd: That macro is extremely exploitable, besides I think they don't want to mess with people's CSS choices.

ReenenLaurie: Yes it would seem exploitable (and would wiki formatting work through this?). However changing a table's background colour also messes with people's CSS choices. You could have the macro for extreme purposes, and/or have people to specify a background colour explicitly as well.

SoulWynd: That's easy to change and I could make it non-exploitable as well. But the problem as it was discussed before is that it completly ignores CSS. Besides that, we have the problem that we have diferent background color for our styles so someone might use a color that only looks good (readable) on a white background, while that would be horrible for a black background. My suggestion is that we use the color processor from wiki to only process certain texts. It's rather easy to translate tome help files' color into html, but then again, we need to pick a default background color for that kind of thing (i'd say black to match tome's) and also have in mind that any processed text will ignore CSS.

MayLith: Umm.... SoulWynd? That was beautiful work you did, there, but it's all showing up as white text on my monitor. (I'm using the starlight theme.)

SoulWynd: That's because NeilStevens never installed that processor It has to go in place of the original CSV processor, like I said, it wont affect CSV at all. It will only add to what you want to do.

MayLith: D'oh! (That's what I get for not reading closely enough.)

NeilStevens: I still say I'd rather not see this wiki blindly follow the color usage of the in-game help. In general, I just don't see the point in making this wiki's data HTML-specific just to capture a couple of tables incompletely.

MayLith: I don't have a problem with that. It seems like part of the above discussion is focussed on the technical challenge. We certainly don't have to "blindly" follow the color usage of the in-game help. On the other hand, we may come across another use for the capability.

Neil, are you going to pull out your suggestion for putting character dumps here into a separate suggestion?

NeilStevens: No, because there is no policy or software suggestion to make! Either people post them or they don't! At least, I had no trouble at all making my post, though if I did it on a regular basis I might do a double-sub-page format:  NeilStevens/Character Name/Level 5  or if that character dies and I re-use the name (common):  NeilStevens/Character Name/Level 5-Attempt 2 

MayLith: Sorry, I didn't intend for it to be a policy/software suggestion -- I was quickly checking the RecentChanges and thought for a moment I was over in the IdeasArchive. What you just noted down typifies the sort of thing I was after: Some sort of suggested tree format, and any other suggestions that would make browsing/searching more uniform...not a hard and fast rules. <g>

NeilStevens: Well, just another note then, in case someone does feel like taking my words here as documentation: what I suggest here isn't the only way to do it. One can always rely on the page history to access old versions of the character sheet.