I like this plan [.col14]very much![/col] The only possible modification I would suggest is maybe we only need the short versions of codes. What is the benefit of having the long ones too?
On Sat, Jun 6, 2020, 5:27 AM Ralph Versteegen <teeem...@gmail.com> wrote: > 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 >
_______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org