[Ohrrpgce] Text markup, again

Sat Jun 6 08:07:57 PDT 2020

...fair enough. Mainly I couldn't decide whether I would prefer c or col,
so was thinking of allowing both.
But I guess very short codes are a bit obscure. Can you make out what these
mean?
f, bg, lm, rm, hl, u, s, rgn
I get the picture: I guess we should avoid one-character codes (but no harm
when the bbcode is one character already) and aim for 3-4 characters.
So: b, i, s, u, font, col, bg, sp, tab, lmargin, rmargin, wave, shake, var
(variant), big, small.
left/right margin could maybe be called lgap/rgap. Or ldent, rdent, or lm,
rm. I don't know.
(big/small: I'm planning to add markup to go to the font defined as the
next size up/down, which avoids assigning numerical sizes to fonts.)

And more markup for controlling display of text, like pausing, waiting for
key, or showing text all at once.
Wait for...[.w] half a second by default...[.w2.5] or longer.
[.nowait]Show this text all at once[/nowait]
Press a key[.wkey]
I guess the rpgmaker codes for these (all single characters), have too much
of a learning curve, they're less readable.

Aside, I am considering a binary form of each tag for file and in-memory
storage. The binary form of most codes will be two bytes. This will make it
practical to use markup in numerous length-limited strings like textbox
choices, global text strings, attack captions and descriptions, even item
names (because item names are stored as 8 characters in 16 bytes, which I
mentioned I wanted to change) without needing to replace file formats.
So the textual length doesn't matter.

On Sun, 7 Jun 2020 at 01:49, James Paige <Bob at hamsterrepublic.com> wrote:

> 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
>>
> _______________________________________________
> 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/20200607/7e512b72/attachment-0001.html>