<div dir="ltr"><div>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.<br></div><div></div><div><br></div><div>(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.)<br></div><div><br></div><div>But this means we need to finalise the markup. I'm very undecided. Sorry, lots of waffle.</div><div><br></div><div>Previously:<br></div><div><br></div><div>On Friday, January 27, 2017, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 28 January 2017 at 13:10, Ralph Versteegen <span dir="ltr"><<a>teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div>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=.<br></div></div></div></blockquote><div><br></div><div>Plus also no-argument $[b], $[i], $[h] tags, which switch to the bold/italic/highlight font.<br></div><div>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</div></div></div></div></blockquote><div><br></div><div>Godot also uses bbcode: <a href="https://docs.godotengine.org/en/stable/tutorials/gui/bbcode_in_richtextlabel.html#reference">https://docs.godotengine.org/en/stable/tutorials/gui/bbcode_in_richtextlabel.html#reference</a></div><div><br></div><div>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.<br></div><div><br></div><div>Options include:</div><div>-#{color10} #{/color}</div><div>-or some other variant like :{color10}, !{color10}.<br></div><div>-[color=10] [/color]  or [color10]    (= is optional)<br></div><div>-just [color=10] [/color]  (= is mandatory if there's an arg)</div><div>-$[color10] $[/color]</div><div>-<color10> </color>, or <color=10> </color>. Not quite XML.<br></div><div>-RPG Maker uses \C[10] and a lot of other one-character backslash codes (see attachment) for other things like pauses.</div><br><div>Two-argument tags are also required, for embedding image n frame m. E.g. <spr4,8><br></div><div><br></div><div>I already notice that I find it really easy to accidentally type ${i} instead of #{i}.</div><div><br></div><div>Markup beginning with ! or with : has a problem: the ! or : is easily mistaken as part of the preceding text, eg "Gold:{C10} ${V2}"</div><div><br></div><div>$ 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<br></div><div><br></div><div><div></div><div>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<br></div><div><br></div></div><div>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.</div><div><br></div><div>bbcode or <color10> are easiest to type. That's important.</div><div><br></div><div>bbcode or angle brackets may be a nuiscance on forums, wikis, or help pages.<br></div><div><br></div><div>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: <a href="http://hyperpolyglot.org/lightweight-markup#text-style" target="_blank">http://hyperpolyglot.org/lightweight-markup#text-style</a></div><div><br></div><div>And then there's the tag names to use.<br></div><div>[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?<br></div><br><div><br></div></div>