Beköszöntött a Feature Freeze a Focal Fossa-nál

Én is csipázom. F(a)ecal Fossa, legeslegjobbabb kódnév eddig. Garancia lesz a stabilitásra, az biztos. Nem tudom mikor unják meg ezt a kódneves hülyeséget, bőven elég lenne a verzió, 20.04 és kész, azonnal tudni, hogy 2020. áprilisában jön ki.

Rpi4-et érdemes r=1 userhez betenni desktop gépnek? Rokoni körben van aki ~10 éve innen-onnan levedlett notebookokat kap, és mindig van valami baja. Általában abból kifolyólag, hogy széthullik a gép. A use case 99%a web alapú, mellé minimális Office, de csak annyi, hogy évente 1-2 oldalt kinyomtatna Writerből amit legépel. Nagyjából. Egyébként asztalra kell, nem kell hordozhatónak lennie.

Most, hogy az ára is zuhant egy kicsit, elgondolkoztam rajta hogy ajándékozok egyet oda. Valami desktop Linux-szal, csak Chrome/Firefox menjen elfogadhatóan. (1-2 tab maximum, yt, fb, google, ennyi).

Vagy az tegye fel aki ezeket a hülye neveket használja, verziószám helyett.

Amíg nem kattintottam a cikkre nem tudtam mi ez a Focal Fossa(=Ubuntu) és csak kíváncsiságból jöttem, ha az lett volna a cím, hogy  "Beköszöntött a Feature Freeze az Ubutnu 20.04 LTS-nél" simán továbbhaladok.

Nem, upstream-ben még nem csináltuk meg (és nincs is tervben a közeljövőre). Eoan-hoz képest a VTE és GNOME Terminal nem változik érdemlegesen. (Bionic-hoz képest akadnak újdonságok.)

Az egyik gond: ha tökéletesen implementálnánk, a végeredmény, a teljes végfelhasználói élmény akkor sem lenne tökéletes. Gondolj a szövegszerkesztőben a margóknál félbevágott jelekre, mondjuk egy "!="-ból csak a "!" fér ki a jobb szélen. A terminál nem tudja, hogy a szerkesztett fájlban mi a következő karakter, így nincs esélye egy "≠" bal felét renderelni. Ez kifejezetten félrevezető, ha például a "<==" jelből csak "<=" fér ki, teljesen hibás ligatúrát kapsz. Ezt nem lehet máshogy megoldani terminálban, mint egy vadiúj kiterjesztéssel, ami a vásznon kívüli karaktereket is át tudja küldeni, egyetértésben a terminálok közt, implementálva kellően sok terminálban és applikációban – esélytelen, hogy ilyen megszületne, elterjedne. Nem tiszta az sem, hogy ha "cat"-olás során pont itt törik új sorba, akkor a ligatúrát kéne felesben/harmadolva rajzolnunk, vagy az eredeti szimbólumokat.

A másik gond: nincs olyan font engine, ami készen megoldaná a ligatúrák rendeselését, egyszersmind atombiztosan garantálnál a fix betűszélességet. A monospace font pedig legfeljebb elvi síkon létezik: a gyakorlatban ott van a fontconfig a fallbackjével, meg csomó nemzetközi írás, egyesek (például dévanágari, arab) igencsak hadilábon állnak a fix szélességgel. Namost a fontconfig ezeket összegyúrja egy virtuális fonttá, az eredmény minden csak nem monospace.

Jelenleg minden betűt egyenként teszünk ki, a megfelelő helyre, ezért nincs ligatúra. A másik triviális megközelítés az volna, hogy valahogy detektáljuk a grapheme cluster-eket, vagyis az egyben renderelendő dolgokat, amíg nem kell a "ceruzát felemelni" (erre talán, remélem van API), és azt kirajzoljuk, na de hogyan is pontosan? Tegyük fel, hogy 10 pixel széles egy cella, és 10 betűből áll egy szó. Odaadjuk a font engine-nek, várunk tőle vissza egy 100 pixel széles képet, de ehelyett kapunk mondjuk egy 88 pixel széleset. Vagy 107 pixeleset. Mihez kezdjünk vele? (Arról nem is beszélve, hogy ha a kurzor ennek a közepén van, akkor azt hova és hogyan is rajzoljuk ki pontosan?) Ha szélesebb a kelleténél, akkor kezdjük el jobbra tolni a maradékot (mint a Konsole-ban), elrontva a függőleges igazításokat, a sor vége meg lehet hogy már nem is fér ki?

De láttam már olyan screenshotot is valamelyik terminálról, hogy a "fi" betűket összevonta egyetlen karaktercellás ligatúrába, majd utána egy üres cella áltt. Hát, kösz, nem. Egyelőre amelyik terminált én láttam ligatúrákkal próbálkozni, azok mind különféle problémáktól szenvednek, remélem most már érthető hogy miért.

Szóval kellene valami olyasmi intelligencia, vagy akárcsak beégetett szabályok, amelyik különbséget tesz ligatúra típusok között. Például a "!="-re azt mondja, hogy jó, az jöhet, a dévanágari betűkre pedig azt, hogy nem, ott inkább betűnként külön renderelünk, mert a kisebb szakadások vagy átfedések a betűk között még mindig jobbak, mint ha hosszú távon esik szét a sor. Hogy ez a döntés hogyan nézne ki, min alapulna, mondjuk Unicode karakter-osztályonként (betűkre tiltjuk, írásjelekre engedjük), majd esetleg folytatjuk azzal hogy lemérjük hogy a font mit csinál, és tiltunk akkor is ha a ligatúrával renderelt szélesség nem pont akkora mint kellene (esetleg tűréshatáron belül), ez nagyon nem tiszta. Rengeteg heurisztika, kísérletezés míg talán sikerülne belőni valami viszonylag jót.

Amúgy a VTE 0.56 vagy 0.58, nem is emlékszem már, immár egész sorokat renderel egyszerre, kisebb egységeket (egy-egy betűt külön) nem, ez egy hatalmas előrelépés a ligatúrák implementálhatósága irányába. Valamint rendereléskor mindig ismert a teljes "bekezdés" szövege (a következő explicit újsorig előre-hátra, akkor is, ha az az aktuális vásznon kívül van), ami szükséges akkor ha implicit sortörésnél a ligatúrát szeretnéd félbevágni, ez is egy fontos előrelépés volt a közelmúltban. De még elképesztően nagy munka befejezni innen (beleértve azt is, hogy talán az egész pango renderelést harfbuzz-ra kéne cserélni előfeltételként).