[Ohrrpgce] Text markup, again

[James Paige]

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 <teeemcee at 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 <Bob at 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 <teeemcee at 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 <teeemcee at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On 28 January 2017 at 13:10, Ralph Versteegen <teeemcee at 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 at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200606/47950a35/attachment-0001.html>