> semmi extra teendője nincs a karakterrel kapcsolatban ahhoz, hogy pont úgy működjön, ahogy működnie kell
Ez így ebben a formában nem igaz. Minden Unicode karakterrel kapcsolatban van tennivaló, hogy úgy működjön, ahogy kell, például ki kell rajzolni. Minden egyes betű, amit elmentesz egy dokumentumba, mindaddig egy bithalmaz, amíg meg nem kell jeleníteni, és ki nem kell rajzolni ezeket a karaktereket.
Kétféle karakter létezik:
- amit simán csak meg kell jeleníteni (betűk, emojik, írásjelek, stb), ezek az "egyszerűbb" esetek, fogod a betűkészletet, megkeresed, hogy mi van rendelve az adott bitkódhoz, kiveszed a vektorgrafikus képet és kirajzolod. Valójában ez se ilyen egyszerű. mert egy csomó speciálisan kirajzolandó Unicode karakter létezik, de ezt most elegánsan léptessük túl.
- úgynevezett vezérlőkarakterek. Ilyenek például a szóköz, a sortörés, az oldaltörés, a kocsivissza, a BELL, a színváltoztató ANSI szekvenciák, stb. Ezeknek a működését külön le kell kódolni ahhoz, hogy maga a hatás, amire rendelve vannak, megvalósuljon.
Vegyük a legegyszerűbbet, a BELL-t, ugye ennek egy egyszeri pittyegést kell kiadnia. Igen ám, de hogyan? Egy grafikus alkalmazás esetén egyértelmű, hogy az aktuális default hang outputon, de Linux alatt ez ugye PulseAudio-tól JACK-ig bármi lehet. TTY alatt pedig még az is elképzelhető, hogy PC Speakeren kell. Ezt mind-mind le kell programozni - azaz van vele teendő.
A legtöbb grafikus szövegszerkesztő például a kocsivisszát valójában kocsivissza+soremelésként valósítja meg, holott ennek terminálok esetén kritikus szerepe van, hogy az adott sort felül tudod írni akár a képernyő utolsó sorában is, anélkül, hogy görgetnéd a képernyőt. Másképpen kódolták le a grafikus szerkesztőkben ezt a hatást.
Aztán ott vannak példálul a színváltós ANSI szekvenciák. Magának a szoftvernek támogatni kell a színes karaktereket, és ezeknek állapotának szabad változtatását, azaz soron belül is meg kell tudni változtanti a karakterek színét, hátterét, stb, ami például függ attól is, hogy a keretrendszer, amiben megvalósítják magát a szerkesztő-megjelenítő eszközt, mire képes ezek kapcsán. Azaz, a szoftver programozójának itt is van extra teendője ezzel.
Ami a nem törő szóközt illeti, ez a legtöbb esetben a weben és tipográfiában értelmezett dolog, nem véletlen, hogy mindkét helyen speciálisan kell beilleszteni, és minden részt vevő alkalmazástól támogatottságot igényel. Alapból ugyanis a legtöbb szoftverben a szövegkezelés úgy van megvalósítva, hogy a legközelebbi whitespace karakternél tör, bármi is legyen az. Az nbsp pedig tulajdonképpen whitespace karakternek minősül (például szóhatároló karakter), de mégsem lehet ott eltörni a szöveget (hiszen ezért nem törő szóköz!), így megintcsak külön feladata van a programozónak ennek támogatásában.
Normál plain text fájlokban ez a karakter nem túl gyakori, emiatt sok szövegszerkesztő - pláne a konzolosok - egyáltalán nem, vagy csak részlegesen vannak rá felkészítve. Néhány szövegszerkesztő "egyszerűsíti", "normalizálja" a benyitott szövegfájlt, például automatikusan egységesíti a sortöréseket. Egy ilyen karakternél, mint az nbsp simán lehet, hogy mivel whitespace karakternek érzékeli, és nem sortörés, a normalizálás során kicseréli normál ASCII 32-es szóközre.