ub's #20

ub's Space at the End of the Universe

Desktopologia III.

2017-05-13, tagged as desktop, utilities
Texty mame, fonty mame, uz nam chybaju len obrazky. Ziadne ine "objekty" Desktop nepozna.

Cast tretia: format obrazkov

Najskor si povedzme, co Desktop rozumie pod pojmom "obrazok".

Mat moznost dat do textu len klasicke spekrtisticke screen$ (cize velkost 256x192 pixlov) by bolo znacne obmedzujuce. Preto po nahrati obrazka do Desktopu mame moznost vybrat si len nejaku jeho cast, ktoru v texte pouzijeme. Takymto sposobom je mozne docielit napriklad efektu velkeho (napr. 24x24 pixloveho) pismena na zaciatku odstavca. To musite uznat, ze by sme s obrazkom o velkosti 256x192 nedosiahli bez toho, aby sme do obrazka nedali aj znacnu cast celeho odstavca, co by nam samozrejme potom komplikovalo nielen naslednu editaciu textu, ale aj spojenie s dalsim textom.

Takze, ako som uz spomenul, po nahrati obrazka mame moznost vybrat cast, ktoru chceme v texte pouzit. Je len par podmienok, ktore musime mat na pamati:
  • Vyrez obrazka, ktory chceme pouzit musi mat vysku nasobku 12 pixlov. Je to preto, lebo jeden riadok textu ma prave 12 pixlov a Desktop vie iba ci na riadku obrazok je alebo nie je.
  • Sirka vyrezu musi byt nasobkom 8 pixlov. Netusim, preco toto obmedzenie, vsak aj znak fontu je ulozeny v bajtoch (cize 8miciach bitov), ale moze mat variabilnu sirku. Preco tomu tak nie je s obrazkom, to neviem. Mozno len kvoli zjednoduseniu kodu, aby zostalo viac miesta v pamati pre text.
  • Vyrez moze zacinat na osi Y na lubovolnom mikroriadku, avsak po osi X sa vieme posuvat len po bajtoch, cize po 8 pixloch. Ak ale potrebujeme vybrat cast, ktora zacina v strede bajtu, je tu moznost pred samotnym vyberom posunut cely obrazok o pixel dolava ci doprava (a to aj niekolkokrat po sebe ;])

Po vybere je vyrez dalej rozrezany na riadky - "slize" o velkosti 12px na vysku a kazdy takyto "sliz" je ulozeny (a tiez komprimovany) samostatne a je mozne ho v texte pouzit nezavisle na ostatnych "slizoch" (cize neplati ze ak vo vyreze boli dva "slize" nad sebou, tak musia byt rovnako ulozene aj v texte). A tiez je mozne pouzit ho aj niekolkokrat na roznych miestach textu (v pamati tak bude len raz, viackrat nan bude iba odkaz v texte). V Desktope teda pod pojmom "obrazok" budeme rozumiet prave jeden takyto "sliz".

Obrazky su v pamati ulozene "odzadu", a tiez su odzadu aj komprimovane, a na rozdiel od fontu su komprimovane aj v pamati a nie len na mediu. V podstate je to o tom, ze do buffra volnej pamati sa texty zapisuju od zaciatku buffra smerom ku koncu a obrazky su ukladane od konca smerom k zaciatku buffra. Tym padom je pamat pouzita na to na co ju treba - ak treba viac textu ako obrazkov, tak sa nakoniec text a obrazky stretnu blizsie ku koncu buffra a ak treba viac obrazkov, tak sa stretnu blizsie zaciatku buffra. Zvlastnostou je, ze obrazky su komprimovane nie po bajtoch, ale po dvojbajtoch.

Kazdy obrazok ("sliz") sa sklada z:
  • "hlavicky" obsahujucej sirku v bajtoch a dlzku (komprimovanych) dat
  • niekolkych blokov skladajucich sa z:
    • informacneho bajtu:
      • bit 0 urcuje ci je blok komprimovany alebo nie (0-nekomprimovany, 1-komprimovany)
      • bity 7-1 urcuju velkost vysledneho obrazka v dvojbajtoch (wordoch)
    • samotne data bloku:
      • ak je blok komprimovany, tak su to 2 bajty, ktore sa vo vysledku opakuju az kym nenaplnia pozadovanu velkost
      • ak blok komprimovany nie je, tak je tu prislusny pocet dvojbajtov, ktore sa do vysledku len jednoducho skopiruju
  • pripadneho zarovnavajuceho byte (celkova velkost obrazka aj s hlavickou je vzdy parne cislo)

A to je viac menej vsetko, takze nas dekomprimovaci program by mohol vypadat nejako takto:


(vstupny subor stiahnete tu: reklama P.B a skript tu: uncompress_pics.php)


[: to be continued :]


--