[Ohrrpgce] Text markup, again

Sat Jun 6 09:20:14 PDT 2020

This is all fantastic, and I am excited! :D

We could also add a feature to string editing so you could pull up a menu
that will list codes and let you insert one at the current cursor location.
When people memorize markup codes, they probably won't use it, but it can
double as a help screen for markup, and a quick way to find the obscure
ones that you might not use as often and won't have memorized

On Sat, Jun 6, 2020, 11:08 AM Ralph Versteegen <teeemcee at gmail.com> wrote:

> ...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
>>
> _______________________________________________
> 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/9028954b/attachment-0001.html>