I think that you are assuming that by giving the macros generic names that it will solve our problems. It won't. If anything it will make things more confusing because authors will insist on using the wrong numbers for the wrong types of text. If anything what you did was add two flags where only one is needed, thus adding bulk to our document.
How about this. I've got to assume that specific styles are going to be made by the main author as they would take the time to actually make special background images and such and any style sheets applied would be of the generic variety, to make a uniform look or to change the formatting for a specific device.
So let's revisit the header section again. Now we have two "constants" for the headers, title and default. I've got to think that like any document in the history of everything you are only going to have two font styles 90% of the time, so as long as any supplemental header has those two we are good. What we can do is default back to the "default" font settings if a flag is unregognized or a section of text doesn't have any formatting tags.
Examples:
Let's say we have a entry with a header like so:
<head>
<font size=1 color=0,0,0>default</font>
<font size=2 color=255,0,0>title</font>
<font size=1 color=128,128,128>gray</font>
<bg color=255,255,255 img=bg.png>default</bg>
<bg color=0,0,0 img=title.png>title</bg>
<bg color=255,255,255 img=char1.png>char1</bg>
</head>
Note the background flags, those are going to be needed as well (although they won't encapsulate the text, there will be one per section).
So lets say somone makes a generic style sheet for all the entries and applies it. It has a header like so:
<head>
<font size=1 color=255,255,255>default</font>
<font size=2 color=0,255,0>title</font>
<bg color=0,0,0 img=bg.png>default</bg>
<bg color=0,0,0 img=title.png>title</bg>
</head>
Note that it doesn't have enough entries. That is OK because when the renderer comes across the "gray" and "char1" flags it will default back to the default font and background settings respectively. The original header will be completely ignored. So this will work for generic formatting.
But if someone wants to make a specific re-skin for a specific entry that would work as well. They have the option of overriding any entry specific macros so it will work just fine.
The thing that would be important with this method is to get everyone's understanding that the macros "default" and "title" are a requirement and they must be defined so that when any formatting is stripped away their contrasts with each other will make text viewable. Also "default" needs to be used for the bulk of the text and "title" needs to be used for... well titles, and in the case of backgrounds, any time when the default background won't do but a character/section specific bg isn't necessary, like the title section, which might use a graphic instead of text.
Oh and about the about the bg macros... they won't work like the font ones. I'm trying to be mindful of the html conversion and in html backgrounds are a option in a section, like in the "body" flag or in the "table" flag. So instead of encapsulating text, they would either immediately follow the section entry or be included in it as an option, like so:
<section bg=default>
This section uses the default background!
</section>
I think that should cover most issues and allow us to apply different formattings to entries.
In terms of the sections, think of them as chapters in a book not pages in a book. Renderers are obviously going to have their own method of rudimentary page navigation and such, sections would just be used to, for example jump to the next fighter's movelist. The length and complexity of a section would be up to the author. That being said, we would try to keep it standardized. Just to use command.dat as an example, I would like to think that we would have a section just for the title of the entry, because you might want to use a fancy graphic (like the game's marquee) and this first section would be made cosmetically nice so that the user would have something pretty to look at if they choose not to browse the game's docs. Then you would have a legend section, to associate the icons with their meanings. Next you would probably have a generic movelist section that lists the moves common to all characters and finally an individual section for each character.
The only other issue I can think about is how to handle the backgrounds. It seems simple enough, but it isn't. Sections would be just that... sections of text. Some could be long and some could be short. So how do you display the background behind them? In my command.dat viewers I always made it to where you could only read one section of text at a time. This method would make it easy.... a background image obviously becomes a full screen image this way. If you want to display things all at once, however things get a little hairy. You can resize the image to only fill that section of text, piece of cake, BUT whatever font the renderer uses is going to effect the output dramatically. Even if it's a mono-spaced font, the font height might vary, meaning that the bg image could get distorted. We could make an iron-clad rule that you can only use a specific font, but you've got to think that would be especially difficult to enforce on html conversions, where the device in question might not have said font.
There is of course the option of raster fonts, but many low end devices would choke on so many images, so it wouldn't be very universal.
That is why I'm leaning towards a rule about displaying one section at a time... it just eliminates a ton of headaches. Even then we've got aspect ratios to deal with (UGH).
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Upgrading command.dat and other documents (Read 11714 times)
