Copy and Paste Text Art

Three sizes, and they behave differently

Text art covers everything from a one-line figure like ᕕ( ᐛ )ᕗ to a multi-line drawing to a full block of ASCII art hundreds of characters wide. The distinction matters because only the first size can be pasted anywhere. A one-line piece is just a run of characters and travels like any other text, which is why the shrug or the table flip can go into a username or a chat window that would destroy the cat further down this page. As soon as a piece needs two lines, it depends on two things the destination may not give it: line breaks, and a font in which every character is the same width.

Multi-line art needs a monospace font

The three-line cat and rabbit on this page were drawn on the assumption that each character occupies one column. That holds wherever a monospace font is in force: a code block, a terminal, a plain-text editor. It does not hold where the text is set in a proportional font, because a proportional font gives every character its own width — the letter i is narrower than o, the columns stop lining up, and the drawing shears. If you cannot tell which kind of font a field uses, paste a line of iiiiiiii above a line of oooooooo: if the two lines come out different lengths, the art will shear there.

Where the field accepts Markdown, the fix is a fenced code block: put three backticks on a line of their own above the art and three more below it. A code block is rendered in a monospace font and its contents are printed as typed, so the line breaks and the column alignment both come through.

Line breaks get eaten

A single-line input holds one line by definition, and nothing obliges it to tell you what became of the other two. Paste the three-line rabbit into a username, a display name, a search box or a one-line bio and what you get back is one long row of brackets, with the newlines gone and the drawing with them. If a field is one line tall, assume it will flatten anything you put in it, and read back what it stored before you rely on it.

Column width is not the same as character count

Even in a monospace font, not every character gets one column. Fullwidth characters — the CJK ideographs, kana, and the fullwidth brackets in （ ´∀｀） — are drawn two columns wide. Mixing them into a piece that was aligned with ASCII characters puts every following line out by one column per fullwidth character.

Worse, the box-drawing characters that make up a flipped table, ┻ and ━ and ┬ and ─, are classified in Unicode as East Asian Width “Ambiguous”. That means the standard explicitly leaves their width to the environment: one column in a Western context, two in an East Asian one. This is why the same table-flip art lines up perfectly in one terminal and is ragged in another, with no change to the text itself.

Invisible characters are still characters

The Lenny face ( ͡° ͜ʖ ͡°) looks like eight glyphs and is eleven code points. Three of them are combining marks, which draw on top of the character before them and take no space of their own. Where a limit counts code points, those three count against it although nothing is drawn for them. Anywhere a field strips characters it does not recognise, those three are the first to go, and the face collapses into ( ° ʖ °). Which variants survive that stripping and which do not is set out on Lenny face.

The shorter, upright faces are collected at the kaomoji hub. The sideways :-) family is at ASCII emoticons, and the notes on where a pasted face arrives changed are at kaomoji copy and paste.