Celkem dobre napsany clanek. Dekuji.
Vidim tu nejaky rozpor:
1. veta clanku "Pripad GIF" z 10.8. rika "Dne 11.8.2006 vyprší platnost posledního patentu".
2. veta 1. kapitoly tohoto clanku z 17.8. rika "ohledně dvou současně platných patentů".
Tak jak je to tedy?
Dale pisete, ze v pripade, ze neni pritomna ani Global ani Local Color table, mel by prohlizec dodat systemovou paletu
nebo web-safe 216 barev+odstiny sedi. Jiz zde jednou citovana
originalni specifikace od Compuserve (napr. http://www.wotsit.org/download.asp?f=gif89a) rika toto:
"if there is no Global Color Table in the Data
Stream, the active color table is a color table saved from a previous Data
Stream, or one supplied by the decoder." To znamena, ze se
ma pouzit paleta z predchoziho souboru GIFu (!!!) nebo defaultni, jakou autor prohlizece prohlasil
za vhodnou.
A ted k te prodleve. Jsem autorem PictView, nejprve DOSovskeho prohlizece, pak i okenniho
prohlizece a konvertoru a v posledni dobe hlavne pluginu
do file manageru Servant Salamander (http://www.altap.cz).
V minulosti jsme skutecne nulovou prodlevu interpretovali
jako nulovou. Pak nas ale uzivatele zacali bombardovat
soubory s tim, ze v jejich oblibenem web browseru
neni ta prodleva nulova, ale "nejaka prijatelne defaultni".
Tim nas donutili zavest vlastni defaultni prodlevu.
Nevim, zda autor clanku programuje, ale ve specifikacich
lecceho je zcela bezne, ze nulova hodnota nejakeho parametru
znamena default, takze to neni az tak prekvapujici:
Opet cituji specifikaci: "Delay Time - If not 0, this field specifies the number of
hundredths (1/100) of a second to wait before continuing with the
processing of the Data Stream".
Zatim jsem se nesetkal s tim, ze by nekdo pouzival vice
ramcu pro 1 snimek kvuli optimalizaci velikosti souboru.
Naopak kvuli sbirce souboru pocitajicich s defaultni prodlevou,
kdyz je zadana nula, neplanujeme prechod na puvodni chovani.
Takže jestli to chápu správně, potom gif nikde neukládá informaci o tom, že jde o animace, uživatelem řízené slideschow nebo jeden obrázek složený z rámců. Tak to potom záleží na uživateli, jak se na gif bude chtít dívat. Dal bych mu k dispozici kontextové menu, aby si vybral. I když už je to všechno asi trochu zbytečné.
ten rozpor možná vznikl na základě mnou nepříliš jasně napsané věty. Nepíšu tam o dvou _v_současnosti_platných patentů, ale o dvou patentech na stejnou věc, které _byly_ platné současně - ve stejný čas (a vypršely před dvěma lety, letos šlo o třetí patent, který vlastnila firma IBM).
PictView mi jménem něco připomíná, nebyla to (v době DOSu) aplikace běžící v textovém režimu s tmavomodrým pozadím?
Právě že dost programuji a tak jsem zvyklý na různé nejasnosti vyskytující se ve specifikacích (hlavně se to týká chování různých API funkcí v okrajových podmínkách). Ale ve specifikaci ke GIFu se jasně píše, že prohlížeč má obrázky zobrazovat bez zbytečných delayů (už jsem text pastnul do předchozích odpovědí):
The decoder has the following primary responsibilities.
- Process each graphic in the Data Stream in sequence, without
delays other than those specified in the control information.
Pokud to uživatelé opravdu vyžadují, pak samozřejmě záleží na vás, jak budete danou věc implementovat - buď se držet specifikace, nebo se "podřídit" :-). Pokud se však podřídí všichni, tak se nemůžeme divit, že se vícerámcové GIFy moc nepoužívají, což je škoda.
Tak jsem nakonec ten PictView našel na svém druhém cédéčku (společně s Vimem čtyřkou - to byla doba). Je to verze 1.67 DM (to jako kvůli Dementovi?) a kupodivu mi šla i na moderním stroji spustit :-)
Ještě k těm defaultním hodnotám: první tři "truecolor" GIFy uvedené v článku nemají ani rozšiřující grafický blok, takže žádné delay by se konat nemělo. Ale chápu, že uživatelé zvyklí na nějaké chování animací v IE/Netscape/Firefox a spol. vás donutí k vytvoření stejně funkčního programu. Jaké je tedy "defaultní delay" - 10ms?
Ano, verze DM byla kvuli Dementove Parenisti a jeho formatu X.
Aktualni verze pro DOS, lec nekolik let neaktualizovana, je vicemene 1.95, ma mj. nekolik vylepseni kvuli modernim strojum ;-)
Koukam, ze s tou defaultni prodlevou jsem mystifikoval sam sebe.
Hodnekrat jsme to pretrasali, ale nakonec to zustalo s tak
malou prodlevou, jak jen to HW a OS dovoli.
Koukam, ze tam mam jeden (opravdicky) bugik: dalsi frame hledam podle GCE, ale v tech vasich souborech se vesmes nevyskytuje :-(
Chci se jeste zeptat na ten autoloop - kde a jak je to dokumentovano? Nemohu to najit...
Pravda, v prvnich ctyrech obrazcich se GCE nevyskytuje, ve skutecnosti by se mohlo jednat i o GIFy87a (ale ted me napada, ze by to mozna nektere prohlizece asi rozhodilo vic, nez ten nulovy delay :-). Ten posledni obrazek s ramci o ctvercovem tvaru uz GCE ma.
S autoloopem muze byt trosku problem, protoze se nejedna o vec, ktera by byla zminovana primo ve specifikaci GIFu (ani 87a ani 89a). Ale uz nekolik let - tusim od roku 1995 +-2 roky - je snad vsemi web prohlizeci a mnohymi "off-line" prohlizeci podporovano aplikacni rozsireni puvodne pochazejici od Netscape. To ma hlavicku "NETSCAPE", oznaceni aplikace "2.0" a vlastne jen jeden menitelny udaj - pocet opakovani smycky 1-(2^16-1). Pokud je tam 0, jde o nekonecnou animaci.
Prakticky to vypada tak, ze se v GIFu za globalni barvovou paletou nachazi tato sekvence bytu:
33 ff 0b 4e 45 54 53 43 41 50 45 32 2e 30 03 01 LO HI 00
V LO a HI max. hodnota pocitadla smycky, takze vetsinou 00 00 (oblibena nekonecna smycka). Na netu jsem vsak nasel nekolik malo GIFu, ktere maji treba pouze tri opakovani - to se mi docela libi, sice je na strance neco pohybliveho, co zaujme pozornost, ale po chvilce to prestane otravovat, takze obe strany mohou byt spokojeny a uzivatel se nebude namahat s blokovanim reklam apod.