Apple II supports no styling at all

[dstelzer]

It seems like the only styling the Apple II natively supports is inverted or flashing colors. Dialog currently has a way to specify reverse-video style, but it doesn't appear to be used currently. Support for that would help a lot in distinguishing e.g. tutorial messages from the rest of the game. (I don't think we need, or should support, flashing.)

Tagging @sehugg for this, since he's the driving force behind the Apple II port. Making the engine set a bit in the style variable for reverse-video would not be difficult (and could be implemented on C64 as well, increasing the color options from 4 to 8). The question is, how hard would it be to consult that variable when printing on an Apple II?

[sehugg]

Inverse video should be do-able on the Apple, the flag just has to be carefully managed because the 80 column path clears the background based on it.

It looks like the 6502 engine doesn't parse the text-decoration attribute, so I guess it would only be exercised via the opcode method for now.

I was thinking though, if the engine did parse that attribute, here's a proposal:

• text-decoration: reverse - Invert the text if supported. I think the C frontend already recognizes this.

• text-decoration: highlight - Highlight the text somehow, using inverted video if there is no better method.

The reasoning is that inverse video is not very readable, so 'highlight' would be ignored if something better can be used, like color. AFAIK these will be ignored by web CSS.

Cons: It would add some bytes to the interpreter file size (thought not much RAM), and it may be confusing.

[dstelzer]

Yeah, if this is supported, text-decoration should be added to the CSS parsing. And before that we should probably discuss on the forum whether this is worth synchronizing with how the new Glk extensions represent reverse-video in CSS, or how Parchment does it, which are both separate and incompatible…

I like the idea of "highlight", but would it be used for anything beyond the 6502? Currently all the other platforms allow the color and background-color properties, which provide a better version of that.

[sehugg]

Yeah, my thought with "highlight" was it would only be used by systems that have limited style capability. It says "I really want this highlighted by any means you have available" -- color on the C-64, inverse video on the Apple, maybe underline on a teletype. The web and more capable systems would prefer the more specific attributes and only consider the highlight attribute if no attributes in a style are applicable.

Also it occurs to me that the C-64 does not have individual background colors for cells which is probably why inverse was never implemented (its character set has extended chars instead of inverse chars) and probably means background-color will be awkward unless it's just for the main div.

Also I just discovered "highlight" is called "standout mode" in curses/terminfo:

   If your terminal has one or more kinds of display attributes,
   these can be represented in a number of different ways.  You
   should choose one display form as standout mode, representing a
   good, high contrast, easy-on-the-eyes, format for highlighting
   error messages and other attention getters.  (If you have a
   choice, reverse video plus half-bright is good, or reverse video
   alone.)

But from your previous comment it sounds like a bigger can of worms with Zmachine and Glk etc.

[dstelzer]

Yeah, in theory the C64 could even implement the color property (with its named Z-machine values), but the background is all or nothing. And the upper ranges of the font are used for non-ASCII characters, so there's no room for inverse letters (or something like a proper bold font).

Imo, it would be nice for the backends to recognize the same properties as much as possible. On the Z-machine that's bold, italic, reverse, monospace, color, and background color. (And monospace isn't especially relevant on the 6502 backend.) If we went with "highlight", I think the only interpreter that would treat it differently from true "reverse" would be the C64 (since it's not a standard CSS property for the web interpreter), and the C64 can't do a "reverse" separate from a "highlight" anyway, so I think that's adding more complexity for not much gain.

I suppose the most semantically-logical way to do it would be to support full color on the C64 and reverse on the Apple II, and people who needed a particular effect would style their games differently on each platform (which I'm already doing!). But a specific binary property would be more convenient than full color support, because it could be easily combined with the other binary properties: I could make my tutorial boxes be "reverse" (or "highlight" or whatever), and then still use bold and italic text inside them.

[sehugg]

I wonder if aambundle could pre-parse the LOOK chunk for the 6502 platforms, like the compiler does for Z-machine? It would save ~1000 bytes of disk space and open up more complex parsing. For example:

text-color: orange
--aa-c64-background-color: 10
--aa-apple2-text-decoration: reverse
--aa-atari-font-size: double

It could emit a chunk with the 8-byte array elements that the 6502 CSS parser builds (though the parser might be kept around a while just for aambox). The re-chunked story files lose their cross-platform nature but since they're embedded in disk images it doesn't matter much.

Maybe the bundle parser tries to map the standard attributes like font-style and color (like Z-machine does) unless there are specific overrides for a system. That way authors can keep all their styles in one place.

[sehugg]

BTW back to the original question, I found a simple way to support the (reverse) opcode in Apple II so I'll have a fix for that soon.

[dstelzer]

I wonder if aambundle could pre-parse the LOOK chunk for the 6502 platforms

I like that idea a lot, actually! It could also trim the C64 font down to only the characters it needs. Loss of cross-platform compatibility isn't an issue at that point—the .aastory itself is cross-platform, but the disk images most definitely aren't.

[dstelzer]

From the forum discussion, it sounds like we're settling on -iftf-reverse-video: reverse | none | inherit as the CSS property for reverse-video. If you want to support a highlight option as well, we can throw that into the mix.

[dstelzer]

For documentation purposes: the seven-byte block used by the 6502 interpreter is:

• 0: width
• 1: height
• 2: top margin
• 3: bottom margin
• 4: styles to set
• 5: styles to unset
• 6: flags

Styles:

• 01: reverse (not in the parser yet)
• 02: bold
• 04: italic
• 08: fixed-pitch (in the parser but does nothing? why is this implemented?)

Flags:

• 01: width is a percentage
• 02: height is a percentage
• 40: float left
• 80: float right

That seems like it's going to be enough space for anything an 8-bit interpreter could need, but we could also add an eighth byte for future-proofing and also alignment purposes.

This definitely seems like something that could be better delegated to aambundle than to the actual 6502. But there is also a certain appeal in being able to run your own .aastory files on the 6502 interpreter with no pre-processing…

[dstelzer]

A hypothetical eighth byte could hold color (foreground in one nybble, background in another, one bit each for R/G/B, last bit for brightness or something), but I think for now having the C64 use color as a proxy for the style bits is a better option. It's very nice that currently "bold" (bright) and "italic" (blue) combine into "bold italic" (bright blue) without the author needing to explicitly code that in.

[sehugg]

Yeah, this approach loses a little 'purity' but I think it's worth it. Having style warnings in aambundle will be handy.

We need 8 bytes anyway, so one could be reserved for system-specific things like C64 color -- I guess it would adjust the 'normal' color and style bits would take priority. Also could override global colors in a global style.

So something like:

;; system-specific attributes
-iftf-c64-color: red | #ff0000 | 2

;; these are only valid in @Body style
-iftf-c64-background-color: white
-iftf-c64-bold-italic-color: cyan

;; override attributes on a specific system
-iftf-apple2-reverse-video: none
-iftf-apple2-margin-top: 2em

I'm not sure about float/width/height, I can't get them to do anything.

[dstelzer]

Main issue fixed in #104 and #101 ; I'll make a new issue for the other discussion