bbcode was my preference too. I've been thinking about how backcompat could be maintained with a bit, and I've decided it's just too much trouble. Instead I propose the syntax [.col3]...[/col]. That's just as easy to type as bbcode, because even international keyboard layouts will all have easy access to ".", and very unintrusive (even more so if using a proportional font.) Or as an alternative, [:col3]...[/col]. I propose [/col] instead of [./col] because there's no need for the extra character. More details at the end.
I wrote an rpgbatch script to scan the gamelists for strings. I only scanned textboxes, items, attacks, global text strings, and slices. Some totals (probably a lot of duplicate games): num textboxes: 658473 attacks: 101674 items: 336286 num scripts with strings: 4967 strings containing [ or ]: 22539 And scanning for valid tags (eg no internal spaces) like [b], [/b], <b>, </b>, [.b], <.b> I found: [foo] tags: 3722 <foo> tags: 482 [.foo] tags: 0 <.foo> tags: 0 [/foo] tags: 2 </foo> tags: 2 games containing [...] or <...>: 225 Of the two uses of [/...], one was "[/Demo]" in Detelamane.rpg and the other was in my "1 day in IRC" game! [01:27] spoonweaver> [IMG] http://i46.photobucket.com/albums/f117/spoonweaver/Tim-Tim0016.png[/IMG] Of the two uses of </...>, "</whisper>" and again 1day irc.rpg: [11:25] C9X[Homework]> <blink> <img src="facepalm.jpg"> </blink> Now, <blink> is actually a markup I might add some day, but 1day irc.rpg used its own text system using box border sprites (those strings are in scripts), so those occurrences are irrelevant. I also scanned for some other character sequences Many uses of [$ especially as e.g. [${C0}] 4 games used \] 4 games used [! (never as would-be-valid markup like [!foo]) Two games used <! (never as would-be-valid markup) One game used <. (never as would-be-valid markup) 12 games used [. particularly for "[...]" and e.g. "[...no?]" (never as would-be-valid markup) No games used [: A handful of games had binary characters < 32 due to corrupt data. Also some contained ASCII 13 (\r), apparently we didn't strip those out when importing textboxes. So a more complete specification: Markup looks like [.<TAG><ARGS>] or [/<TAG>] TAG: A tag name is case insensitive, containing only a-zA-Z. Tags would usually have a short and a long spelling, eg sp and space, b and bold. ARGS: Some tags take one or more arguments. An argument is either a number, or a string not containing ], comma or whitespace. ARGS can optionally start with =, mandatory for string arguments Multiple arguments are separated with commas. If a tag doesn't meet the above syntax or isn't a recognised tag name or has the wrong number of arguments then it's displayed literally. [/foo] doesn't need to follow [foo]. It undones the last [foo], and tags can be closed in a different order than they were opened. If a tag can't be undone (e.g. [space]) then the closing tag is ignored and displayed literally. Escaping: [\. can be used to display as [. \[. would be a bad choice of escape sequence because appending markup to arbitrary text wouldn't be safe. I probably wouldn't bother to actually implement this escape code until later. On Tue, 2 Jun 2020 at 10:31, James Paige <b...@hamsterrepublic.com> wrote: > I have been thinking about this today. > > There are pros and cons for different markup styles, but > [color=10][/color] with backcompat-optional bbcode markup would probably be > most familiar to people, and easiest to type. [img#.#] for images/sprites. > [sp#] for horizontal spacing > > Any of the styles will actually be fine-- but if you need help breaking > the tie and settling on one, that is my 2 cents :) > > --- > James > > > > On Mon, Jun 1, 2020 at 5:55 AM Ralph Versteegen <teeem...@gmail.com> > wrote: > >> I want to finally expose the ability to use text markup and non-8x8 fonts >> to users. Even before all the menus and slice collections are updated, and >> before the textbox file format or any others are replaced. Therefore there >> will be graphical problems and shortcomings, but we need that in order to >> find and fix what needs fixing. It can be marked experimental. >> >> (I have a plan for textboxes: just repurpose the 304 bytes used to store >> the existing 8 lines of text as a single autowrapped 304 byte string, plus >> an extra 200 bytes or so tacked onto the end of each SAY record so there's >> plenty of spare space to actually use markup/compact fonts.) >> >> But this means we need to finalise the markup. I'm very undecided. Sorry, >> lots of waffle. >> >> Previously: >> >> On Friday, January 27, 2017, Ralph Versteegen <teeem...@gmail.com> wrote: >> >>> >>> On 28 January 2017 at 13:10, Ralph Versteegen <teeem...@gmail.com> >>> wrote: >>> >>>> Also, I decided that it's best not to use ${...} codes for markup >>>> supported by printstr such as color and font. ${...} should be exclusively >>>> for inserting a string variable in the text, as in many programming >>>> languages. Instead I was thinking of using #{...}, or maybe quite different >>>> syntax which has (optional) closing tags, like $[col45]...$[/col], since >>>> closing tags really are needed (right now I'm using -1 to mean 'restore >>>> previous'). Other tag names could include colbg, pal, spc (no closing tag), >>>> font, indent, indentr, and even link=. >>>> >>> >>> Plus also no-argument $[b], $[i], $[h] tags, which switch to the >>> bold/italic/highlight font. >>> Actually, maybe we can just use [b], [col45], etc, or <b>, <col45>... >>> and add a backcompat bit to enable them, and use a $ prefix to escape them >>> >> >> Godot also uses bbcode: >> https://docs.godotengine.org/en/stable/tutorials/gui/bbcode_in_richtextlabel.html#reference >> >> I like the idea of allowing both short and long forms of markup, eg both >> [c10] and [col10] and [color10], because there will be a lot of codes. But >> it makes parsing harder. So I'll just list long forms below. >> >> Options include: >> -#{color10} #{/color} >> -or some other variant like :{color10}, !{color10}. >> -[color=10] [/color] or [color10] (= is optional) >> -just [color=10] [/color] (= is mandatory if there's an arg) >> -$[color10] $[/color] >> -<color10> </color>, or <color=10> </color>. Not quite XML. >> -RPG Maker uses \C[10] and a lot of other one-character backslash codes >> (see attachment) for other things like pauses. >> >> Two-argument tags are also required, for embedding image n frame m. E.g. >> <spr4,8> >> >> I already notice that I find it really easy to accidentally type ${i} >> instead of #{i}. >> >> Markup beginning with ! or with : has a problem: the ! or : is easily >> mistaken as part of the preceding text, eg "Gold:{C10} ${V2}" >> >> $ is used for string operators and embed codes, and I wanted the syntax >> $"Gold: ${gold}" to embed a local or global variable by name. so Using $ >> neerd >> >> Note that the text renderer doesn't process markup that doesn't have a >> valid tag name or argument. So there's less backcompat risk >> >> Nonetheless If we were to use bbcode, a backcompat bit to disable it >> seems warranted. If we used anything else, like #{i} then I see no need for >> a bit. That would simplify a lot of code since we wouldn't need to pass the >> backcompat bit as "withtags" all over the codebase, which seems pretty >> horrible, and especially for text slices in slice collections. Should >> probably rule out bbcode just for this, unless the backcompat only affected >> textboxes (and maybe plotstrings) and nothing else. That's probably already >> good enough to avoid all backcompat problems. I guess I should run >> rpgbatch.py to extract textboxes and other strings and see what I find. >> >> bbcode or <color10> are easiest to type. That's important. >> >> bbcode or angle brackets may be a nuiscance on forums, wikis, or help >> pages. >> >> And then I also want to support mediawiki markup, for help pages. That >> would be an optional per-slice setting, available to users too. But >> mediawiki isn't a popular markup. Markdown is. Honestly if easy typing is a >> concern, optional markdown seems like the ultimate solution for >> italics/bold/underline/strikethrough/indent. This comparison of markup >> languages is interesting: >> http://hyperpolyglot.org/lightweight-markup#text-style >> >> And then there's the tag names to use. >> [i] should mean italic, but I also wanted i for icon. Hmm, ico or icon. >> And img for sprites... or spr? spr is probably too similar to spc, for >> horizontal space (in pixels). I suppose s would be strike-through not space >> or sprite? >> >> >> _______________________________________________ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >
_______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
