Conversation
- parse LANG and issue warnings on improper styles - rewrite LANG -> USTY for apple2, c64, aambox - -iftf-sys-* platform overrides - foreground text color (c64) - warning options (see usage for flags)
|
But first I have to figure out why the gosling test fails with blank lines but not on my Mac :^P |
|
This generally looks good to me! Just a few things:
|
|
Oh, and one more thing: I think it's a bad idea to try to match hex color codes to the closest available fixed color. Better to make users explicitly acknowledge which color they want by name, which ensures they know about the limited palette available. |
|
I agree, RGB parsing is out for now. I added a spec and implemented the color: initial behavior. I made room for SET_BODY background colors, coming in a later PR :) Should I bump the minor version too? |
|
Not sure what's going on with the tests; the files are byte-identical on my Mac and Linux. |
|
Hmm. That test failure is what I would expect if something was going wrong with div margins…in particular, that would match the old behavior where SPC was incorrectly set to PAR instead of LINE when leaving a div. |
|
Otherwise, this all looks good! And yeah, I do think it's good to have this be version 1.1.0. |
|
The tests also pass on my local machine. What's going on? |
|
Oho, nope, I was able to reproduce the test failure, and I see the cause. The USTY chunk is not capturing top and bottom margins. Here's the LOOK chunk of gosling.aastory: And here's the USTY chunk of gosling.ustory: |
|
If style warnings are not silenced: |
|
And while I poke through gen_usty.c for this: I believe it should be |
|
That was probably left over from before the So I'll pull out The margin stuff is weird and I suspect an esoteric sscanf() library version thing, but I'll have to test. |
|
Running this code: Produces this: It looks like the |
|
This behavior varies between C libraries. It looks like if the current code works, it's actually a bug in sscanf according to the spec (from https://en.cppreference.com/c/io/fscanf):
Unfortunately it looks like the only real way to fix it is to do our own number parsing. Maybe try to match both |
|
The following code seems to work: With this code, values like |
|
Yep, that's it. Who knew a 45-year old function could still be clunky? ;) |
|
This is looking good overall now! All that's left are a couple minor quibbles. Some of these could also go in another PR.
None of these are too important, though; no need to change them if you disagree. |
|
Maybe we just lose the format nibble in the version byte? Nothing reads it except aamshow, and since the .ustory files are neither portable nor backward-compatible nothing really needs to check it. It can always come back in a future header revision if needed, i.e. if aamshow can't parse without it. There is always at least one style, thus USTY is always present, the More than 255 styles in USTY is a hard error in aambundle. The 6502 is much happier this way. Agreed SHORT is better. C64 will obey |
2 participants
Been sitting on this awhile, so time to PR! Apologies for the huge commit.
This patch parses the LANG chunk and replaces it with a binary USTY chunk which is now mandatory for apple2, c64, aambox.
The parsing is more complex than frontend.c, it supports RGB colors and gives warnings on lots of things.
You can also override styles with -iftf-sys--* syntax.
For example: "-iftf-sys-c64-color: red"
It also adds a foreground text color feature to C64, activated by the above syntax or just "color: red".
There is also a generic warning subsystem sort of based on the Dialog compiler, which might be overkill (--help-all shows all warning options)
Aamshow will decode the currently-versioned USTY chunk for debugging purposes.
The USTY format is documented a few times in the comments, but I don't know if a small internal spec might be better (since it'll change with new features)