Az összes UNICODE karakter jól jelenjen meg a terminálban

Linux-haladó

Mit kell felraknom Linuxra, hogy a https://www.unicode.org/Public/13.0.0/charts/ oldalon található CodeCharts.pdf összes karaktere jól jelenjen meg terminálban.

  • 971 megtekintés

( Qury v | 2020. 10. 25., v – 23:52 )

Nem tudok a kérdésedre valaszt, de ha megtalálod szólj. Egyébként úgy tudom az unicode szabványnak vannak OS-dependent részei is a "corporate range"  szóval azok nem biztos hogy barmilyen font alatt megjelennek majd.

Support Slackware: https://paypal.me/volkerdi

( Raynes v | 2020. 10. 26., h – 03:17 )

Minden karakter nem fog jól megjelenni. Ennek az az oka, hogy rengeteg Unicode-karakter van, sok tízezer, és nincs az a font, ami mindegyiket támogatja az utolsó szálig, az eleve egy 100-200 megás font lenne, mint ez a pdf is, és főleg lassabb gépeken jól belassítaná a fontrendelést, meg megnövelné a memóriaigényt. Eleve mást támogatnak az angol nyelvterületre szánt fontok, mást a programozásra, terminálos felhasználásra szánt code/nerd fontok, mást a matematikai fontok, más karaktereket támogatnak a nemzetközi piacra szánt nemzetközi latin betűs fontok, mást a cirill betűsök, mást az ázsiai nyelvekhez készült fontok, mást ez emoticonos fontok, de vannak sakkozáshoz szánt betűtípusok is.

Azt sem ártana tisztázni, hogy milyen Linux disztróról van szó, meg hogy terminálról vagy konzolról. Ugyanis függ initrendszertől, disztrótól, termináltól egyaránt, hogy mit kell állítani.

Alapból normális modern disztróra semmit nem kéne hekkelni, mert ha nem gányoltad szét, az alapértelmezett beállításnak UTF-8-asnak kéne lennie, meg rendszerfontnak olyan fix szélességű modern fontnak kéne lennie beállítva, ami alapból azért a leggyakrabban használt angol, magyar, európai nyelves karaktereket, nyomdai jeleket, alap matekszimbólumokat meg tudja jeleníteni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ez igaz, de csatlakozom a topiknyitóhoz hogy e téma engem is érdekel, mert már többször belefutottam abba a problemuszba, hogy de jó lenne ha a „szokásos” jeleken kívül meg tudnám jeleníteni a terminálban mondjuk a Tolkien tünde-nyelveihez készült betűket is; meg mondjuk a Voynich-kódexben található „betűket” amik nagyon tetszenek nekem... de, hogy mást ne mondjak, a programnyelvem tervezésekor eszembe jutott hogy de jó lenne belevenni néhány olyan operátort ami az Unicode-ban a matematikai szimbólumok közt található azaz ezen utóbbi ötletem még csak nem is annyira extrém módon extravagáns... de hiába, mert amikor ki akartam iratni azon karaktereket, akkor semmi se jelent meg a helyükön...

Arról nem is beszélve hogy még a magyar rovásírás jelei se támogatottak, ami pedig Magyarországon már lényegesen nagyobb érdeklődésre tarthat számot mint a Voynich-kódex betűi. Vagy azok amik a Codex Seraphinianus-ban vannak.

> jó lenne ha a „szokásos” jeleken kívül meg tudnám jeleníteni a terminálban mondjuk a Tolkien tünde-nyelveihez készült betűket is; meg mondjuk a Voynich-kódexben található „betűket” amik nagyon tetszenek nekem

Csak olyan x-terminal esélyes (minimálisan), ami egyszerre tud több fontot használni. Próbáld ezt. Amúgy a terminál nem regényírásra való.

> a magyar rovásírás jelei se támogatottak, ami pedig Magyarországon már lényegesen nagyobb érdeklődésre tarthat számot

A rovásírásra gerjedők már talán tervezgetik emiatt linux, unix témájú könyvek égetését darálását.

Gnome terminal nekem alapol mutatja ezeket:
https://www.w3.org/2001/06/utf-8-test/UTF-8-demo.html

Ha custum font beallitas -ra megyek akkor kiesnek azok amiko ott nincs-enek.

Milyen unicode test filoket erdemes meg nezgetni ?

xterm default nem mutatja az Ethiopian -t.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Amúgy meg engem marhára nem is érdekel a rovásírás, még csak nem is hiszek abban hogy az lett volna a magyarok ősi írása mert olyan betűkombinációkra (is) van benne jel ami abszolút idegen a magyar nyelvtől. Szerintem azt a Mátyás udvarában levő humanisták hákolták össze. „Rekonstruálták”. Nyilván volt nekik pár töredékes rovásírásos nyelvemlék ami még valóban a magyarok egykori rovásírásával készült (mert azt azért elhiszem hogy volt ilyenje a magyaroknak) de már nem tudták olvasni őket (ezek a humanisták), rövidek is voltak, sok betű hiányzott róluk, erre a „rekonstruálás” közben hasraütésszerűen kitaláltak pár szimbólumot a hiányzók helyére, olyat ami vizuálisan jól illett a többihez.

Én ebben hiszek, de nem akarom a nézetemet senkire se ráerőltetni. Csak amiatt említettem a rovásírást mert tudom hogy elég nagy a hype körülötte Magyarországon, így felhoztam példának, mint olyasmit amit kínszenvedés manapság megoldani Linux alatt, terminálban legalábbis. Már ha megoldható egyáltalán. Na oké, valahogy biztos, de hogy nem egyszerű az tuti.

> Csak olyan x-terminal esélyes (minimálisan), ami egyszerre tud több fontot használni. Próbáld [az mlterm-et].

Éveken át foglalkoztam terminálokkal. A GNOME és KDE alapúak mögött ott van az adott toolkit teljes infrastruktúrája, amivel össze tudják kombinálni a fontokat. Nem akarok flamewart nyitni, de tapasztalataim szerint az mlterm ami marketing dumát lenyom, hogy támogatja a többnyelvűséget, az smafu, mások is alapból tudják, és mindehhez képest egy ronda, vacak bugkupac.

> A rovásírásra gerjedők már talán tervezgetik emiatt linux, unix témájú könyvek égetését darálását.

Két nagy tábor küzdött egymás ellen, hogy a rovásírás pontosan hogyan is kerüljön bele a Unicode-ba. Ha utánanézel, találsz cikkeket, honlapokat, ahol egyk-másik tábor véleményét, stílusát megismerheted. Felér jónéhány könyvdarálással ami mocskolódás ott folyt.

A rovásírásra gerjedők már talán tervezgetik emiatt linux, unix témájú könyvek égetését darálását.

[szemlétetés, érzékeltetés, a szóhasználatot érzékeld:]

ne légy tahó barom nem áll jól. Ahogyan az általánosítás sem :).

[/szemléltetés vége]

kb ennyire volt korrekt az amit írtál az ugyanolyan kreténség(legalábbis a megfogalmazás) mintha minden tüntetőt a huligánokkal azonosítanál.

Ez ellen -szerintem teljesen jogosan- egyaránt kikelne

 - a most pl többek között SZFE-n tüntető

 - de ugyanúgy a 2006ban az 56os események 50es( :) )  évfordulójára szemkilövetéssel emlékeztetett 

tömeg.

Már sokszor gondaltam rá, hogy jó lenne,ha a BIOS-ban lenne egy minden kódpontot tartalmazó fontkészlet, frissíthetően. Vagy készíteni kellene egy font-processzort. Régen a mathprocesszor is csak külön létezett, most meg már a GPU is integrálva van CPU-val. Itt Bábelben ennek lenne értelme.

eutlantis

> Arról nem is beszélve hogy még a magyar rovásírás jelei se támogatottak

https://github.com/OldHungarian/old-hungarian-font – Itt van egy, a végleges Unicode kódpontoknak megfelelő rovásírás karakterkészlet.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908817 – Erre szavazz, ugorj rá stb. ha a Debian / Ubuntu vonal érdekel és szeretnél kész csomagot.

Kell még a rovásíráshoz a jobbról balra írás támogatása is. VTE-n alapuló terminálok ezen widget 0.58-as verziójától, így például GNOME Terminal 3.34-tól támogatja ezt, lényegesen jobban mint a többi terminál ami ezt állítja magáról.

Ez nem ilyen szokásos, nem szokásos, neked mi lenne jó alapon megy. Utána kell járni szép sorban: azokhoz a Tolkien nyelvekhez a betűket, meg a rovásírást beemelték-e a legújabb Unicode szabványba? A magyar rovásírásról rémlik nekem, hogy igen, de ezt tolkienes dolgot nem tudom, ennek neked kell utánajárni. Ha ez megvan, akkor meg kell nézni ezeknek a karaktereknek a Unicode kódjait a neten vagy a szabványban, ez alapján beazonosítani, hogy ezt konkrétan melyik fix szélességű betűtípus támogatja. Ha ezt is megtaláltad, akkor szükséges lesz egy olyan terminálra, ami támogatja ezt a fontot, és a Unicode kódolást is, továbbá egy olyan linuxos rendszerre, amin ez szintén be van állítva a lokalizációs beállításoknál, hogy pl. hu_HU.UTF-8, vagy en_akármi.UTF-8, akármi_akármi.UTF-8, stb..

Mindezek után így tudod bevinni a terminálba az általad akart Unicode karaktert: Ctrl+Shift+u, erre megjelenik az aláhúzott u jel, majd elengedve ezeket a gombokat elkezded gépelni az illető Unicode-karakter hexadecimális kódját. A másik lehetőség, hogy megkeresel a neten egy táblázatot, amiben benne van ez a karakter, és onnan kimásolod vágólappal. Ezek akkor is fognak menni, ha nem támogatja a betűtípus a terminálban ezt a karaktert, csak akkor ilyen négyszögletesen bekeretezett krix-krax-ként jelenik meg.

A linuxos konzol megint más kérdés, azokra az initrendszernek a beállításai vonatkoznak, meg oda másik formátumú betűtípus kell, ami támogatja az illető Unicode-karaktereket. A disztró pontos mibenlétét cselesen titkoljátok a témaindító kollégával egyetemben, így konkrétumokat nem tudok írni a konzolhoz. És mielőtt félreértés lenne: a konzol nem egyenlő a terminállal. Konzolon én most a BIOS-os vagy UEFI-s, vagy framebufferes vagy KMS-es karakteres konzolt értem, ami akkor is rendelkezésedre áll, ha nincs X.org-os vagy waylandes grafikus felület, login manager, ami telepítve lenne vagy futna. Ez persze itt a HUP-on egyértelműnek kéne legyen, de azért hívom rá fel a figyelmet, mert ezt netszerte keverni szokták, és tévesen szinonimaként használják a konzolt és a terminált.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem, azt nem keverem, nyugi. Tökéletesen tudom, hogy amit ma terminálnak hívunk, az terminál emulátor. De ennyi pongyolaság tényleg belefér, mert fizikai terminált már nem nagyon használ senki, főleg nem Linuxhoz. De a konzolt keverni a terminál(emulátor)-ral az viszont gáz, és azt hinné az ember, hogy csak kezdők keverik, de a neten neves, angol nyelvű szakmai oldalakon is keverik szép következetlenül, és nem a pendáns szakmaiság miatt fontos ez, hanem nem egyszer előfordult, hogy kifejezetten konzolhoz kerestem volna valami zárolós, karakterkódolással vagy fontokkal kapcsolatos megoldást, mert eleve olyanhoz kellett, amihez nem akartam grafikus felületet futtatni, és a kereső olyan cikkeket hoz fel console címszóval, ahol a Gnome Terminal beállításait mutogatják screenshotokon, pocsékolva az ember idejét.

Épp így nincs ellenemre, ha valaki a Linuxot OS-ként emlegeti, és nem részletezi ki, hogy GNU/Linux, meg a Linux nem egy OS, hanem csak a kernel. Ezzel még akkora baj nincs, mert mindenki tudja miről van szó, és félreértést nem okoz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> Tökéletesen tudom, hogy amit ma terminálnak hívunk, az terminál emulátor. De ennyi pongyolaság tényleg belefér

Teljesen egyetértek. Abszurd lenne mindenütt kimondani a rendkívül hosszú „terminál emulátor” nevet. Viszont hasonló logika mentén...

> De a konzolt keverni a terminál(emulátor)-ral az viszont gáz

... én ezt sem tartom gáznak, sőt, gyakorlatilag értelmetlennek tartom megpróbálni a kettőt két külön kategóriába betuszkolni. Mindkettő hasonló mértékben szoftveres, csak abban van eltérés, hogy a szoftver mekkora része van a kernelben és mekkora része külön programban implementálva, vagy mekkora mértékű egyéb infrastruktúra kell egyik vagy másik alá; a felhasználót ez általában csöppet sem érdekli, és mivel a funkciójuk tök ugyanaz, ezért bármit is jelentsen pontosan a „konzol”, „terminál” vagy „terminál emulátor”, azonos mértékben húzható rá egyikre vagy másikra.

Sőt, nem is kell külön kategóriába betuszkolni, mert a "console" pont úgy van leírva a termcap/terminfo adatbázisban, mint egy valódi vagy egy virtuális terminál.

A valódi terminálok is sokat változtak. Régen volt pl. egy VT320 terminálod,  25 évvel később a hardver már tudott 25 féle terminált (jól-rosszul) eljátszani, tehát emulálni.

Programoztam olyan rendszert, ahol DOS+Netware+Dataflex alapokról kellett portolni terminál+terminál szerver+AIX+Dataflex -re. A fejlesztőrendszer terminál helyett linux konzol+telnet+AIX+Dataflex volt. Az utóbb színes-szagos és a rengeteg billentyűkonbinációból csak 2 nem működött. Mint érdekesség, az input oldalon 12 lehetséges konverzió volt, az outputnál csak nyolc.

Szerintem, aki csinált hasonlót az érti, a többiek meg nem. ;)

Mi számít ma soknak? A .pdf-nek körülbelül a felénél ér véget az U+FFFF. És addig a codepointig többé-kevésbé jól jelennek meg a karakterek a Gnome-Terminálban. Ergo ha a karakterek fele támogatott (pedig itt megtalálható az összes alap CJK karakter) akkor nem hinném hogy túl nagy terhet jelentene a memóriára ha még 1x annyi karaktert meg tudnánk jeleníteni.

Meg igazából ember sincs, akinek az összes Unicode-karakterre szüksége lenne. Mert nem is ismeri a felét, nem ismeri azt a szakmát, nyelvet, ami az adott karakterek mögött van. Pl. nálam nem jelennek meg jól az ázsiai nyelvek, nem csak a japán, mandarin, de ilyen tamil meg egyéb karakterek sem. Nem is bánom, feltehetnék ezekhez való betűtípust, amire fallbackelne ilyenkor a terminál, de semmire nem mennék vele, mert amúgy sem értem ezeket a nyelveket, és csak annyit érnék el, hogy bekeretezett kódok helyett másfajta krix-krax lenne a képernyőn, amit épp úgy nem értek. Épp ugyanez lenne a magyar rovásírással is. Szóval eleve overkill lenne mindent megjeleníteni, főleg egy terminálban, ami rendszeradminisztrációra való, nem bölcsészkedni. Ahol fontos lehet, az a kiadványszerkesztés, esetleg böngészés., de ott akkor erre bevett fontokat használnak eleve, meg grafikus alkalmazásról van szó, változó szélességű betűtípussal.

Magyar, angol, német, karaktereket, nyomdai jeleket, stb. minden font szokta támogatni, tapasztalatom szerint. Ennyi terminálban a legtöbbünknek bőven elég.

Eleve terminálban a legtöbb spéci karakter hátrányban indul, mert a fix szélességű betűtípus sokat torzít. Sose lesz olyan megfelelő a megjelenés, mint egy változó szélességű betűtípusnál.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( uid_20558 | 2020. 10. 26., h – 08:55 )

A Google Noto fontkészlet pont azért készül, hogy minden Unicode karaktert megjelenítő fontcsaláddá váljon. Hogy mekkora munka lehet terminálba hákolni (mármint, hogy tényleg minden karakter minden nyelven helyesen megjelenjen) azt nem tudom, de én nem tenném, lévén az egész csomag 1.1GB!

https://www.google.com/get/noto/

Nem tudom, sosem próbáltam, de ha LibreOffice telepítve van, akkor elvileg ez a három betűtípus is telepítésre kerül (Noto Sans, Noto Serif és Noto Mono). Terminálban inkább a Mono-t használnám, ami csak 212 nyelv, de mondom, terminálban sosem próbáltam... Windows alatt használt jegyzetelőszoftverben sikerült olyan karaktert kérnem tőle, amit nem jelenített meg, de nincs is telepítve, csak a fent említett 3 csomag.

( bucko | 2020. 10. 26., h – 11:23 )

összes karaktere jól jelenjen meg terminálban

valamint

a terminál nem regényírásra való

Ezen kívül a terminálhoz tartozik egy NLS beállítás is. (LANG és társai) 

Az általad megálmodott funkció általában valamilyen szoftveren keresztül érhető el. Általában már egy NLS specifikus szoftver - pl. adatbáziskezelő - saját NLS környezetet használ, mintegy függetlenítve magát az operációs rendszertől.

Tudom, hogy csak a megjelenítést kérdezted (output), de hogyan oldanád meg a speciális karakterek bevitelét (input) egy terminálon?

hogyan oldanád meg a speciális karakterek bevitelét (input) egy terminálon?

Vannak erre megoldások, az Unicode érték közvetlen begépelésével. De különben se izgat ez a kérdés (engem), mert a saját programjaimban a saját stringosztályomat használom, ami eleve Unicode értékekként tárolja a karaktereket, és természetesen van rá funkció ami kiíráskor ebből előállítja az UTF8 szekvenciát, s azt küldi ki a terminálra. Hogy aztán a karakter a programírás közben miként kerül bele a stringembe, már teljesen mellékes, végső esetben egyszerűen oda lesz írva a string megfelelő helyére a szükséges unicode számérték hexában vagy akármi... ezer megoldás lehetséges.

A lényeg, hogy aztán a terminálon megjelenjen a megfelelő betűkép. Sajnos, elég gyakran nem jelenik meg...

( Nextra | 2020. 10. 26., h – 12:18 )

Olvastam a hozzászólásokat, és meg kell jegyeznem hogy a terminál és az X - betű megjelenítési motorja nem egy és ugyanaz. A konzol mivel általában nem használ framebuffert, Max 512Kb kernel memóriával rendelkezik, ezért nem megoldható minden egyes karakter megjelenítése. Max 512 karakteré.

Ráadásul ez is úgy, hogy a videobuffer kárára. Pl. a LatArCyrHeb-16 betűtípus használata miatt az élénk színek már nem állnak rendelkezésre a konzolban. 

S mint említettem, a különböző motorok miatt, a Xorg nem ismeri, nem kezeli a terminál betűk psfu típusát, és vice-versa. A terminál mit sem tud a ttf-ekről. Vagyis amit a LibreOffice ismer, azt sohasem fogja tudni a terminál.

Azt én magam is elismerem, hogy az emoji-k beemelése az Unicode-ba egy hatalmas baromság volt. Meg van még ezen kívül is egypár olyan dolog benne ami teljesen agyhalott hülyeség. Ennek ellenére, azért az nem ártana hogy egyetlen fontkészlet által tudjunk írni a terminlba (vagy akárhova) az összes európai nyelven, beleértve a cirillt és görögöt is, plusz arab nyelven, héberül is, meg rúnákkal, rovásírással, dévanagári betűkkel, hiraganával, katakanával... meg még pár más ennél is egzotikusabb ABC-vel. Az óegyiptomi hieroglifák már nem lenne kötelező a szememben, de ha belefér, pluszpont a szememben, amint még egy jópár egyéb dolog is ilyen.

Ami Tolkien betűit illeti - legalábbis a legismertebb tünde-betűit - arról ezt találtam:

Tengwar are currently included in the unofficial ConScript Unicode Registry (CSUR), which assigns codepoints in the Private Use Area. Tengwar are mapped to the range U+E000 to U+E07F;

Ami igazán SZÉGYEN, mert ezek egyrészt tényleg szépek, másrészt, ennél messze nagyobb idiótaságok is elfértek az Unicode táblában, akkor ennek is illene adni egy fix helyet. Pláne mert nincs is olyan rém de sok jelről szó.

azért az nem ártana

Véleményes, szubjektív dolog:

 pl szerintem ha mástól vesz el erőforrást -> még árthat is (nincsenek végtelen erőforrásaid, pláne egy konzolban nem).

Én attól is idegbajt kapok, hogy miért kell egy statikus html oldal megjelenítéséhez 1gb+ memória (elindítok egy chrome-ot és megnézek egy oldalt amit a localban futo nginx szolgál ki :) ). De biztos kőkori mamut vagyok aki sajnálja a gépéből az erőforrást a fölösleges csicsákra.. Ami van az nem arra van..

pl szerintem ha mástól vesz el erőforrást -> még árthat is (nincsenek végtelen erőforrásaid, pláne egy konzolban nem).

Na de most őszintén, miért kéne annak az egyetlen fontkészletnek a maga teljességében azonnal betöltődni a memóriába?!

Legyen csak ott szépen az egész a merevlemezen vagy SSD-n, akárhol, ezek a háttértárak ma már annyira olcsók, hogy a kutyát nem zavarja ha plusz 10 gigabájtot is elfoglal rajta az a fontkészlet. Annál többet meg nem nagyon hiszem hogy megenne.

A memóriába meg azon karakterek képe kerülne bele, ami épp kell az adott fontból az adott feladathoz. Nem tudom, van-e már erre valami módszer, de meglehetősen biztos vagyok abban, ha AKARNÁK, akkor ez simán megoldható lenne!

Megjegyzem amúgy, manapság már a RAM is annyira olcsó, hogy nem igazán szempont szerintem, abból mennyit eszik egy alkalmazás. De ezt tényleg csak mellékesen jegyeztem meg, mert a lényeg az amit fentebb írtam: simán meg lehetne oldani hogy csak a szükséges karakterek képei kerüljenek be a RAM-ba. Amennyiben viszont szükséges, akkor szükséges és kész, akkor valamiképp úgyis ott lesz valami font a lemezen amiből az adott karaktereket be kell tölteni (vagy a teljes fontkészletet.,.) azaz semmit nem vesztünk vele ha egyetlen fontkészleten belül megtalálható az összes.

Akinek meg tutira nem kell az Unicode 90+ százaléka, ÉS még a picike merevlemezét is félti mert jajistenem akkor nem marad hely rajta a legújabb animalpron filmnek, akkor az legfeljebb nem telepíti ezt a nagy fontkészletet és problem solved.

Most nem tudom mire gondolsz hogy mi van megoldva. Az ugyanis lehet hogy meg van oldva hogy csak a megfelelő "igényelt" karakter kerüljön be a memóriába, de mit érek vele ha az akkor sincs megoldva hogy meglegyen minden Unicode karakter egyetlen fájlban, az aztán meg pláne nem hogy helyesen jelenjenek meg terminál(emulátor)ban! Gyakorlatilag ugyanis terminál(emulátor)ban, (mély)konzolban, whatever még azon karakterek egy része se jelenik meg, amiről jól tudom hogy ott kell lennie valahol a gépemen mert naponta használom például LibreOffice-ben. Igen, ezek még az X alatt futó terminálemulátorban se mindig jelennek meg.

Most persze lehet ehhez ideológiát költeni, megmagyarzni hogy „jaj kérem ott fix szélességű a betű és a bonyolult karaktereket ezért nem lehet jól kirajzolni, whatever”, de akkor is tény, hogy ez a gond nincs megoldva. Nota bene, a kínaiak meg japánok „hieroglifái” gyakran jóval bonyolultabbak mint azok a karakterek amikről én beszélek, s ők érdekes módon mégis megoldották - ennek egyik módja ha jól tudom hogy 2 karakterhelyet fogtak össze egynek, s így máris több helyük maradt a kirajzolásra.

De különben is, ha X alatt fut a terminálemulátor, akkor ugyanúgy meg lehetne oldani a karakterkirajzolást mint amikor a LibreOffice-ban történik. Az X mindegyik alatt ott dübörög elvégre. Attól hogy terminálemulátor, még nem okvetlenül kell ragaszkodni hozzá hogy bittérképesen jelenítse meg a karaktereket. Elvégre amiatt EMULÁTOR és nem „igazi” terminál, mert nem igazi és kész. Ergo, bőven nyílik lehetőség akár a továbbfejlesztésre is, mert nem ugyanazok a fejlesztés korlátai mint az „igazi” termináloknak, amiket én amúgy mélykonzolnak nevezek, bár tudom hogy ez sokaknál kicsapja a biztosítékot. Mindegy, tehát én értem hogy annál ahol nincs egy X „a mélyben” ott elég limitáltak a lehetőségeink, de ahol van X ott nekem senki be ne mesélje hogy ez megoldhatatlan lenne.

Most persze lehet ehhez ideológiát költeni, megmagyarzni hogy „jaj kérem ott fix szélességű a betű és a bonyolult karaktereket ezért nem lehet jól kirajzolni, whatever”, de akkor is tény, hogy ez a gond nincs megoldva. Nota bene, a kínaiak meg japánok „hieroglifái” gyakran jóval bonyolultabbak mint azok a karakterek amikről én beszélek, s ők érdekes módon mégis megoldották

 

nem tudok mást tenni, mint egyetérteni, ott van pl. az U+10005, amit két egymásra merőleges csík, mégse jelenik meg sehol helyesen

Ezt gondolom te írtad. A legjobb cucc a témában, többször is elolvastam :) Csak azt szeretném megkérdezni, hogy nem érzed az ellentmondást? Például ezt írod a leírásban:

Ha egy magyar ő betű bárhol átalakul hullámos õ-vé, az elfogadhatatlan. Ennél többet nem akar tudni a felhasználó, és nem is szabad, hogy szüksége legyen ennél nagyobb tudásra. A többit oldják meg a szoftverfejlesztők.

Miért elfogadottabb az, ha megpróbálok UNICODEban megjeleníteni egy egzotikusabb karaktert, akkor üres négyzeteket meg hexakódos négyzeteket látok viszont? Sokkal többet tudsz nálam az egész háttéréről, technikai megvalósításáról. Én ha nem látok egy karaktert akkor nincs kedvem hiányzó fontok után kutatni, vajon melyik fogja helyesen megjeleníteni azt. Legfeljebb felrakok egy extensiont, amiben ott az összes, ami nincs fent alapból. Ez olyan nagy kívánság 2020-ban?

Értelek. Rossz helyen kopogtatsz, és amúgy rossz címet választottál, mivel kérdésed nemcsak terminálokra vonatkozik. Sem a hup fórumon nem tudjuk ezt megoldani (csak elvinni a témát a legkülönfélébb, teljesen irreleváns irányokba, ehhez több hozzászólónak rendkívüli tehetsége van), sem a terminálok fejlesztői nem tudnak segíteni. A különféle disztribúcióknál kell jelezni, hogy ez az elvárásod: alapból az összes Unicode karakter legyen lefedve fonttal. Természetesen frissítés is jöjjön, valahányszor a disztró támogatási időtartamán belül új Unicode verzió jelenik meg.

Miért elfogadottabb az, ha megpróbálok UNICODEban megjeleníteni egy egzotikusabb karaktert, akkor üres négyzeteket meg hexakódos négyzeteket látok viszont?

Azért elfogadottabb, mert ezt egy szoftvercsomag telepítésével orvosolni tudod, míg ha magyar ő helyett hullámos vagy kalapos o látszik, az sokkal mélyebben rejtőző hiba, azt nem tudod így megoldani. Az egyiknél "csak" hiányzik egy bármikor pótolható komponens, a másiknál viszont súlyos elvi hibák vannak.

Ohh, nem idéztem be a teljes bekezdést, amire válaszoltam, csak egy részét.

A memóriába meg azon karakterek képe kerülne bele, ami épp kell az adott fontból az adott feladathoz. Nem tudom, van-e már erre valami módszer, de meglehetősen biztos vagyok abban, ha AKARNÁK, akkor ez simán megoldható lenne!

Erre válaszoltam. Gyakorlatilag kizártnak tartom, hogy ne lenne megoldva.

Normális program vagy libraray ugyanis nem úgy olvas nagy fájlt, hogy allokál memóriát és read() hívással beolvassa, ekkor ugyanis a processzeknek esélyük sincs egymás közt osztozni a területen; hanem mmap() hívással képzi rá a memóriára. Ha egy fontkezelő progi vagy library nem így csinálja, az kapásból kuka. Ha meg így csinálja, akkor a kernel egyszerűen nem olvassa be azokat a részeket, amikre nincs szükség. Nyilván kell még hozzá egy olyan fájlformátum is, amit nem egy totális idióta tervezett, értsd nem kell végigolvasni az egész fájlt ahhoz hogy megtaláld azt a kis részt ami éppen kell belőle, de hadd legyek már optimista, hogy nem te fogod itt feltalálni a spanyolviaszt, hanem régesrég fel van találva.

de mit érek vele ha az akkor sincs megoldva hogy meglegyen minden Unicode karakter egyetlen fájlban

Nem értem, hogy ez miért lenne megoldandó cél. Megoldandó cél, hogy a karakterek megjelenjenek. Hogy egy fájlban vannak-e letárolva vagy többen, nem tök mindegy?

Most persze lehet ehhez ideológiát költeni, megmagyarzni hogy „jaj kérem ott fix szélességű a betű és a bonyolult karaktereket ezért nem lehet jól kirajzolni, whatever”, de akkor is tény, hogy ez a gond nincs megoldva.

Nem ideológiát költenek, hanem technikai korlátozásról van szó, ugyanis egyes írásoktól elképesztően idegen a fix szélesség. És nem a kínaira és japánra gondolok, mert az nagyon jól megoldható a dupla széles cellákkal, vannak ezeknél sokkal bonyolultabb írások is.

De különben is, ha X alatt fut a terminálemulátor, akkor ugyanúgy meg lehetne oldani a karakterkirajzolást mint amikor a LibreOffice-ban történik.

Nyilván el lehet képzelni egy olyan parancssort, amely nem ragaszkodik a fix szélességhez. Pusztán kábé 50 év munkáját kell kidobni és elölről kezdeni, felépítve egy olyan rendszert, amely nyilvánvalóan nemcsak előnyökkel hanem hátrányokkal is járna a mostanihoz képest, például nem tudnád ssh-n távoli gépről a terminál szélességéhez igazodva megformázni a szöveget anélkül, hogy tudnád, a vonal innenső végén milyen karakterkészletet választott a felhasználó, vagy hogy megengednéd hogy azt menet közben átváltsa egy másmilyenre. Meg nem tudnál táblázatokat rajzolni, szóközökkel igazítva pontosan egymás alá a függőleges vonalakat. Meg millió egyéb. Csodálkozol, hogy senki nem mozdult még rá erre? Ha ez kell, a web egy remek platform.

Attól hogy ott lenne a lehetőség terminálban a nem fix szélességű fontkészletek használatára, attól még lehetne továbbra is fix szélességűt is használnia annak aki azt akarja, s akkor az általad említett hátrányok megszűnnének.

Különben meg ha maradunk a fix szélesség mellett, akkor is tök felesleges azt 8 vagy teszemazt 16 pixel szélességre korlátozni. Miért nem lehet 64 pixel széles egy karakterhely?! Elvégre manapság már akkora őrületesen nagy a legtöbb monitor felbontása, hogy még úgy is bőséges mennyiségben férne el karakter egyetlen sor szélességébe, és 64 pixel széles karakterek esetén már igencsak bonyolult betűk vagy akármik is meglehetősen szépen mutatnának azt hiszem, akkor is ha maradunk a fix szélesség mellett.

Biztos vagyok benne, hogy a legtöbb grafikus terminál-emulátorban be lehet állítani nem fix szélességű betűkészletet is, legfeljebb nem a GUI-n keresztül. A szöveg renderelés pontosan ugyanúgy működik fix szélességű és proporcionális betűkészletekkel is. Próbáld ki, aztán majd kiderül, hogy ez mennyire jó ötlet.

Szintén a grafikus terminál-emulátorod biztosan nem 8 vagy 16 pixel szélesen rendereli a karaktereket. Leginkább pontban lesz megadva, amit a kijelződ dpi beállításainak megfelelően fog átszámolni pixelben kifejezett magasságra, ami a használt betűkészlet függvényében fog adott szélességű karaktereket eredményezni. Jobb grafikus terminál-emulátorokban ez a méret futásidőben is állítható nagyítás/kicsinyítés segítségével, ami a szöveg újrarenderelését eredményezi, hogy az ne legyen pixeles.

Attól hogy ott lenne a lehetőség terminálban a nem fix szélességű fontkészletek használatára,

Ott lenne, ha amit 50 év során fejlesztők ezrei hoztak létre, azzal egy párhuzamos, sok szempontból eléggé másmilyen világ csettintésre megjelenne. Nem fog.

attól még lehetne továbbra is fix szélességűt is használnia annak aki azt akarja, s akkor az általad említett hátrányok megszűnnének.

Nem szűnnének meg a hátrányok, mert ha a fix szélesség nem kötelező viselkedés volna, hanem opcionális, akkor az alkalmazások nem tudnának számítani és építeni rá. De teljesen fölösleges tovább ragozni ezt a hipotetikus irányt.

Nem ideológiát költenek, hanem technikai korlátozásról van szó, ugyanis egyes írásoktól elképesztően idegen a fix szélesség. És nem a kínaira és japánra gondolok, mert az nagyon jól megoldható a dupla széles cellákkal, vannak ezeknél sokkal bonyolultabb írások is.

Csak egy példa, arab írás tud olyat, hogy bizonyos karakterek egymás mellett összevonhatóak, amitől rövidebb lesz a szó. Egy elég jó magyarázatot tartalmaz ez a videó.

Így van; köszi a videót.

Tapasztalataim alapján háromféle ember van: aki képes elfogadni, hogy terminálban ezek az írások bizony messze nem tökéletesen, jóllehet jól használhatóan jelennek meg; akik emiatt kerülik a terminált ezeken a nyelveken; és akik osztják az észt hogy hogyan kellene az egészet gyökeresen másképp csinálni, csak épp tenni nem tudnak ennek érdekében semmit sem.

Tökéletesen egyetértek, nem kell, hogy az összes font támogassa az összes UNICODE karaktert. Legyen egy, nekem mondjuk az alapértelmezett (Monospace Regular) nagyon is megfelel, szép is, forráskódra is szuper. Legyen egy csomag, amit ha felrakok, akkor onnantól kezdve az adott font összes karaktere legyen meg, amit a legújabb UNICODE doksiban megtalálható. Mert jelen állás szerint semmi értelme az újabb és újabb UNICODE verziónak, ha senki nem emeli bele az újabb specifikáció karaktereit a fontkészletbe.

Ezt az oldalt ismered-e?

http://unifoundry.com/unifont/index.html

Itt ugyanis megtalálsz egy olyan unicode fontkészletet (ttf) ráadásul free, amiben azért igensok minden benne van. Sajnos ebben se mind... Bár, az én gépemen még ennek az 5.1 változata van meg ami 2008-as kiadású, vélhető hogy azóta sokkal bővebb a választék benne...

Mert jelen állás szerint semmi értelme az újabb és újabb UNICODE verziónak, ha senki nem emeli bele az újabb specifikáció karaktereit a fontkészletbe.

Ez nem igaz. Attól, hogy egy karaktert jelen pillanatban semmilyen fonttal nem tudsz reprezentálni, attól még azt használhatod egy Unicode adathalmazban, ami a standardnak megfelelő jelentéssel bír. Pl. gondolj írott szöveg digitalizációjára, archiválására. Ha a szabványban megvannak a megfelelő kód pontok, akkor tudod digitalizálni, még akkor is, ha fontod még nincs hozzá. Amint lesz, meg is fogod tudni jeleníteni.

( BaT | 2020. 10. 26., h – 19:24 )

Szerkesztve: 2020. 10. 26., h – 19:32

Nemrég egy hasonló problémám volt egy másik programban, ezért picit utánajártam a témának. Az igaz, hogy olyan fontot valószínűleg nem fogsz találni, amiben minden Unicode glyph megtalálható, de ez nem baj, erre van a font substitution. Jó eséllyel a grafikus terminálodban erről a fontconfig gondoskodik, ami hoz magával egy rakás konfigurációs filet, amik többek között leírják a substitution szabályokat is. Jó eséllyel a disztribúciód ezt megfelelően összerakta, vagyis a te dolgod mindössze annyi, hogy a megfelelő fontokat telepítsd, amik az összes karaktert lefedik. Ha esetleg olyan fontokat is használsz, amiről a disztribúciód nem tud, akkor lehet írni saját konfigurációt, pl. így lehet custom emoji fontot használni adott alkalmazáshoz. Ezt a blogbejegyzést is javaslom, vannak benne hasznos infók.

( ddmb | 2020. 10. 26., h – 20:13 )

Szerkesztve: 2020. 10. 26., h – 20:18

Egyébként azért merültem el a témában, mert az applikációnk behalt bizonyos karakterek bevitele esetén, például a U+FFFF vagy bizonyos ASCII control karakterek esetén. De U+10000-tól felfelé semmit se támogat. Írtam egy progit, ami kigenerálja az összes valid codepointot UTF-8-ban, ha valaki ugyancsak szeretné tesztelni saját fejlesztését:

#include <stdio.h>

int main() {
	unsigned int i, result;

	for (i = 0x0; i <= 0x10ffff; i++) {
		if (i <= 0x7f) {
			printf("%c", i);
		} else if (i <= 0x7ff) {
			result = 0xc080;
			result |= (i & 0x3f);
			result |= ((i << 2) & 0x1f00);
			printf("%c%c", result >> 8, result);
		} else if (i <= 0xffff && (i < 0xd800 || 0xdfff < i)) {
			result = 0xe08080;
			result |= (i & 0x3f);
			result |= ((i << 2) & 0x3f00);
			result |= ((i << 4) & 0xf0000);
			printf("%c%c%c", result >> 16, result >> 8, result);
		} else if (0x10000 <= i && i <= 0x10ffff) {
			result = 0xf0808080;
			result |= (i & 0x3f);
			result |= ((i << 2) & 0x3f00);
			result |= ((i << 4) & 0x3f0000);
			result |= ((i << 6) & 0x7000000);
			printf("%c%c%c%c", result >> 24, result >> 16, result >> 8, result);
		}
	}

	return 0;
}

 

Remélem nincs benne hiba...

( sigellef | 2020. 10. 27., k – 13:28 )

:D ott a baj, hogy a "mindenféle karakter" kódolására, karakter-képének tárolására még mindig csak félkész megoldások vannak, és szerintem még vagy 20-30 évig így is fog maradni.

Ha minden létező karakter képét tárolnánk egy fájlban, akkor több gigás fontfájlok lennének, még akkor is, ha vonalrajzra lenne leegyszerűsítve az egész. Érdemes lenne külön-külön fájlokban tárolni az összetartozó karakterrendszerek fontképeit, címezni meg akár jó lenne az UTF-8 is... Mondjuk 1-1 fontfájl 1-1 unicode blokk képeit tartalmazná.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( viraghj v | 2020. 10. 28., sze – 17:36 )

Ehhez bizony elég sok font kellene. Kiindulásul lásd pl. https://www.unicode.org/charts/fonts.html

Itt ezt írják:

The Unicode Consortium currently uses over 390 different fonts to publish the code charts and figures for The Unicode Standard.

Tehát biztosan nincs egyetlen olyan font, ami mindent tartalmazna.

( st3v3 v | 2020. 10. 28., sze – 22:46 )

Szerkesztve: 2020. 10. 28., sze – 22:46
  1. define jól
  2. define context for terminal

define betű

define pixel...

 

nem tudom mit nem értesz azon, hogy "jól", ha a fent említett .pdf-ből kimásolom pl. ezt (蕣, U+8563) és beillesztem a Gnome-Terminálba, notepadba, Wordbe, vagy ide a HUP-os textboxba akkor ez a karakter fog megjelenni. De ha például kimásolom a (ᮆ, U+1B86) vagy a (𐳯, U+10CEF)-et akkor GnomeTerminálban egy négyzet fog megjelenni amiben ott az UTF32BE kódja, notepadban, Wordben egy üres négyzet lesz, itt a HUP-on meg láthatod te is...

Átmásoltam ezeket mind gnome-terminálba. Megjelentek jól.

Mi is a probléma? Nincs fenn az adott font a rendszereden.

Mi a megoldás? Rakd fel a fontot.

Nem kell túlbonyolítani.

itt a HUP-on meg láthatod te is...

Különösen amikor hiányzó fontok a téma, elég érdekes gondolat azt feltételezni, hogy másnak a gépén pont ugyanaz fog látszani, mint a tiéden, nemde?

Igazából az kéne hogy legyen EGY unicode karakterkészlet, mármint egy ttf fájl amiben minden benne van, ÉS EZ MINDEN DISZTRÓBAN BENNE LEGYEN, mondhatnám kötelező jelleggel, persze tudom hogy a Linux a szabadság világa ahol semmi nem kötelező, de úgy értem ezt hogy „illene” hogy benne legyen, és a telepítéskor automatikusan felkerül, kivéve természetesen ha valaki direkt kiixeli hogy neki az nem kell. Nyilván, erre szintén illik hogy legyen lehetőség, de a „default” az lenne hogy települ. És bármi más fontkészletet használ valaki bármi X alkalmazásban, vagy épp X alatti terminálemulátorban, ha abban a fontkészletben nincs meg az igényelt karakter, akkor automatikusan fallbackelne erre a default fontkészletre, addig amíg a hiányzó karaktert kirajzolja oda.

És ekkor nem lenne gond hogy jaj milyen fontkészletet telepítsünk, meg fenn van-e az adott font. Mindenképp jól jelenne meg a szöveg, maximum annyi szépséghiba lenne hogy az amúgy használt fontkészlethez a stílusában nem illene az a karakter amit ebből a default fontkészletből használ a rendszer a kiíráshoz. De, ettől még olvasható lenne minden. Ez már önmagában is óriási haladás volna.

Attól, hogy valamit meg lehet csinálni, még nem biztos, hogy volna is értelme. Pl. egy magyarul nem beszélőnek miért lenne jobb, ha látná a renderelt magyar rovásírást ahelyett, hogy csak négyzeteket vagy kérdőjeleket lát.

Ha már ilyen dolgokon rugózunk, legyen neked, játsszunk el a gondolattal: tegyük fel, a magyarul nem tudó illető egy német ókortörténész, eképp bár magyarul nem tud, de németül nagyonis, s mert történész, jól ismeri a saját népe rúnaírását. És egy nap eszébe ötlik hogy „hm, hallottam a magyaroknak is van rovásírásuk... Hasonlítsuk össze a mi rúnáinkkal, hogy legalább vizuálisan mennyire tűnnek egy közös őstől származónak”...

És nem mondom hogy lehetetlen lesz megoldania hogy látszódjék a gépén a mai német szöveg is, a rúnák is meg a rovásírás is, de szerintem vért izzad majd vele. Terminálban pláne.