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