When using zipWith to join multiple words, please note that it is improper to use only a [sup] tag and not also a [sub] tag. Without the [sub], the ``bottom'' word is sized disproportionately to the ``top'' word.
Compare: SCUURMPSRHIOSTE SCUURMPSRHIOSTE
Note how, in the former (incorrect) example, the two words are different sizes, and the baseline of the ``top'' word undesirably overlaps the cap height of the ``bottom'' word. In the second (correct) example, the two words are visually separated, of consistent sizes, and are overall more aesthetically appealing.
>>18
They're not quotes at all. ` is grave. Not apostrophe. ` goes above letters as in è. It isn't punctuation at all and duplicating it doesn't make it punctuation either. Also, it's asymmetric, which makes it naturally aesthetically unpleasing to those with a functioning concept of balance. On most non-monospace fonts, it also puts an abnormally large gap between letters.
There are countless other reasons too, but that's essentially why.
Current known limitations:
-2 strings of different length will not! be spaced correctly
-zipTextInfrastructure API does not yet allow usage of non-standard (other than hard-coded) modifier tags The Dev Team is aware of those limitations, and will release a patch in near future.
>>26 ghci> let top = ["sup", "i"]
ghci> let bottom = ["sub", "b"]
ghci> let open = concat . map (("[" ++) . (++ "]"))
ghci> let close = concat . map (("[/" ++) . (++ "]")) . reverse
ghci> let f = zipWith (\a b -> open top ++ a : close top ++ open bottom ++ b : close bottom)
ghci> putStrLn $ concat $ f "fictional" "language" fliacntgiuoangae
Known limitations:
-spaces on the longer string will not be rendered if the corresponding character on the shorter string is also a space (this is a BBCODE limitation - it may be possible to overcome it though)
-the BBCODE generated is too long