ACBF - Advanced Comic Book Format (diskuse)

[Aleš Kapica]

Stranky projektu su na launchpade (pre rypalov: GIT a ine systemy nepoznam a ucit sa mi ich nechce, takze je to tam :-P

Sorry, ale to není pro tebe ta nejlepší vizitka..

[Aleš Kapica]

Nehledě na to, že objevuješ kolo, protože tyhle věci lze už dávno a mnohem elegantněji pořešit v rámci DjVu.

[GeoRW]

hmm, no v djvu asi tazko

[Aleš Kapica]

Ty asi toho moc nevíš o textové vrstvě DjVu, co?

[Aleš Kapica]

Abys nemusel moc hledat. Já už to tam dopisovat nebudu, ale pokud máš něco mezi ušima, tak ti dojde že pro to co děláš je to ideální formát.

[Martin Doucha]

Nějak jsem tam nenašel jednu zásadní věc: dá se v DJVU vyrobit několik textových vrstev a mezi nimi přepínat dle libosti? Pokud ne, pro překlad komiksů je DJVU drbání se levou nohou za pravým uchem.

[Aleš Kapica]

Dá. Textová vrstva podporuje unicode. Může obsahovat i rámce, které se překrývají a jejich velikost nemá žádnou souvislost s objemem obsaženého textu. Výsledné zobrazení bublin je ovšem již záležitostí prohlížeče. Způsobů jak by to bylo možné implementovat je několik. Z hlediska zobrazení by mi přišlo nejlepší mít vložený primární text se souřadnicemi a paralelní strukturu pro "překlady", kterou by prohlížeč zpracovával obdobným způsobem jako pracuje gettext.

[Aleš Kapica]

Mimochodem - ta paralelní struktura by klidně mohla být součástí vrstvy pro poznámky.

A také ti nic nebrání začít používat vlastní vrstvu. Standardně se prohlížeč DjVu chová tak, že co nezná ignoruje.

[Martin Doucha]

Takže jestli tomu dobře rozumím, tak si stejně budu muset navrhnout a implementovat většinu nezbytných struktur sám, protože DJVU ve specifikaci nemá všechno, co k tomuhle potřebuju. A z toho, co ve specifikaci má, vlastně využiju jenom embedding obrázků a základní kostru dokumentu. Fakticky tak vezmu Boeing 747, rozeberu ho na součátky a postavím z něj fichtla, protože nic složitějšího než fichtla ve skutečnosti nepotřebuju. To ti připadá normální?

[petr_p]

Nic rozebírat nemusíš. Stačí začít podporovat vedle JFIF JB2 a IWW44.

[Martin Doucha]

A jak mi tahle práce navíc pomůže ukládat a sázet text s překladem komiksu?

[petr_p]

S textem nijak. Ale ušetří značné místo na kompresi bitmap.

[Martin Doucha]

Komprese bitmap je mezi prioritami tak daleko vzadu, že se ani nevešla na seznam.

[Martin Doucha]

Obdoba gettextu je v tomhle případě nepoužitelná, protože různé překlady můžou potřebovat různé rozmístění textu na stránku. Ne všechny jazyky píšou zleva doprava shora dolů.

[GeoRW]

no ACBF je format pre komixy, nie prehliadac obrazkov. To, ze podporuje samostatnu textovu vrstvu je len jedna vlastnost. DjVu dokumenty su malo rozsirene, kniznic na pracu s nimi je malo. Takze implementovat DjVu nema moc vyznam. Pre mna je dolezita aj kompatibilita s existujucim CBZ archivom. Ziadne DjVu som v CBZ archive este nevidel a nie je IMHO ani podporovane existujucimi aplikaciami. Mozes sice vytvorit format, ktory bude mat uzasne vlastnosti, ale ked nebude spatne kompatibilny s najrozsirenejsim CBZ archivom, tak narazis. Ale nechcem ti brat iluzie. Kludne mozes vytvorit svoj vlastny format pre komixy postaveny na DjVu. Prajem vela stastia

[kralyk z abclinuxu]

Pánové, neberte to tak konfrontačně...

Zpětnou kompatibilitu s CBZ jsem asi přehlíd, ale souhlasim, že to je důležitý, to může rozšíření tvýho formátu dost usnadnit... CBZ je na českých sharech afaik rozšířený, nevíš, jestli je takhle rozšířený i v zahraničí?

[GeoRW]

je to v podstate jediny rozsireny format Kazdy zlozitejsi foormat je bud proprietarny alebo nezdokumentovany a velmi jednoduchy.

[Aleš Kapica]

DjVu dokumenty su malo rozsirene, kniznic na pracu s nimi je malo. Takze implementovat DjVu nema moc vyznam.

Víš vůbec o čem mluvíš?! Mám silné pochyby. Koukni se pro zajímavost na http://www.archive.org

A pokud jde o CBZ - je to v podstatě prachsprostý zazipovaný archív. Stejně jako CBR. Koukal jsem se na to, když jsem řešil čím krmit čtečku.

DjVu podporuje každá lepší čtečka a pokud jde o knihovny - jsou pod GPL a běžnou součástí linuxových distribucí. Včetně toolů, které můžeš využít.

Očividně ti dosud nedocvaklo, že na komixy, které většinou stejnobarevné plochy a černobílá kresba, je to ten nejúspornější kompresní formát, jaký můžeš potkat. To co ušetříš na objemu dat u obrázku, můžeš investovat do textové struktury schované uvnitř.

[Josef Kufner]

Paměťová karta od Kingstonu o velikosti 2GB stojí 132 Kč. K čemu mi je pár procent úspora ve velikosti obrázku? Proč se namáhat, když obyčejné PNG bohatě stačí? Tím spíš, když ušetřený čas může investovat do vývoje užitečných funkcí programu?

Pokud by DjVu umělo vše, co potřebuje, a mělo to dostatečnou podporu v čtečkách, pak to má smysl. A dokonce by to bylo i celkem rozumné. Ale jinak je úplně jedno, co použije.

[petr_p]

Úspora není v procentech. JB2 má proti optimalizovanému PNG běžně osminovou a menší velikost. A nejde jen o pamět, ale i o síťový přenos. Když jsem stahoval zde inzerovanou ukázku, tak jsem se divil, proč to tak dlouho trvá. Těch pět několikastránkových komiksů mělo celkem 34 MB. Uvedu příklad. 140 A4 černo-bílých stránek notového zápisu v rozlišení 600 DPI komprimovaných JB2 zabírá 12 MB.

[GeoRW]

no myslim, ze tebe nedocvaklo ovela viac veci, takze diskusia zbytocna

[Josef Kufner]

Ta knížka je taková na prd. Tedy alespoň pro člověka, který o tom nic neví a očekává, že se něco dozví. Zcela chybí popis toho, co to je a jak to vypadá uvnitř -- prostě "big picture". Pořád něco o výhodách a kompresi, ale to podstatné tam není.

[Dreit]

Tak to abych začal překládat Futuramu

[kotyz]

Jenže neni zatim editor

[Mustafa]

Na operacni systemy existuje uz nekolik desitek let, tak neke. Opet se ukazuje jak linux narazi hned pri tom nezakladnejsim.

[kotyz]

A jakej?

[kralyk z abclinuxu]

1. Editor zřejmě je, viz níže
2. No jistě, titulkování komixů a anime pomocí soft-titulků patří k těm nejzákladnějším činnostem počítače To asi dělá denně aspoň polovina společnosti...
3. U mad though...

[kotyz]

Když si tady prvně psal o tom prohlížeči a oddělený textový vrstvě (kvůli překladům) a pak tě napadlo vymyslet úplně novej formát tak sem nevěřil že z toho něco bude. A ono už z toho něco je. Teď už jenom aby to začal taky používat někdo další a časem to může nahradit i ty .CBZ dokumenty Ale to taky můžem čekat donekonečna. Teď to ještě potřebuje nějakej šikovnej editor na ty textový vrstvy - něco jako je AegiSub na SSA/ASS titulky (tam je možný udělat s textem fakt snad úplně všechno, ale má to moc tlačítek a nevim jak se s tim dělá). Ale ten editor na tom bude IMHO to nejtěžší a bez něj to nebude mít moc cenu, protože ty výhody proti těm stávajícim řešenim nepudou využít všechny (a jenom kvůli metadatům na to asi nikdo moc přecházate nebude). No každopádně oceňuju že někdo místo keců taky něco praktickýho dělá. Výhledově bych to moh používat třeba i já, na nějaký mangy třeba, doteď mě moc nelákaly, ale kdyby se to víc rozšířilo a lidi by je pak díky tomu víc překládali do nějakejch použitelnejch jazyků, tak by to mohlo přitáhnout i nějaký nový čtenáře. Asi sem moc velkej optimista

[GeoRW]

tak editor by nemal byt az taky problem. Momentalne to robim tak, ze v Inkscape nakreslim nad podkladovym JPGckom polygony pre framy/texty a potom to z vysledneho SVGcka vyexportujem do XML tagov pre ACBF. V tom editore clovek v podstate bude len kreslit polygony nad podkladovym obrazkom s tym, ze to bude priamo zapisovat do ACBF suboru a nie do SVG ako Inkscape. Zas az taky problem to nevidim, ale mne sa ten editor robit teraz nechce. Mne uplne staci Inkscape (i ked aj tam mam obcas problemy s konverziou, musim to este vyladit)

[kotyz]

Tobě stačí Inkscape, ale kolik lidí s nim umí dělat? Nebo vůbec ví že něco takovýho existuje? Já v něm umim akorát exportovat svg do png

[GeoRW]

inak aj tie metadata stoja zato. Casom chcem doplnit do Viewera kniznicu, ktora bude postavena na tych metadatach. Takisto, ked si citam komixy tak si k tomu vytvorim .acbf subor kvoly obsahu (kapitoly a tak). Uz mam niekolko takych CBZ file-ov s ACBF embedded, ale tie nie su volne siritelne

[Martin Doucha]

Ale, tak mému ComicSubu už roste konkurence. Až na to, že já to beru z opačného konce - mám kromě prohlížeče i primitivní editor zaměřený hlavně na přesné začleňování překladu do obrázku, ale datový formát je minimalistický a bude se v nejbližší době dost měnit. SSA/ASS titulky jsou mimochodem pro můj projekt hlavní inspirace. Jen škoda, že teď nemám čas na tom dál pracovat.

[kotyz]

Byste to mohli dát dohromady, ty máš dobrej editor, on má dobrej formát a prohlížeč ...

[Martin Doucha]

To těžko. Zběžně jsem prolítnul to XML schéma a ten formát podle všeho neumí ani půlku z toho, co já teď v ComicSubu používám (hlavně styly). Navíc je to XML.

[kralyk z abclinuxu]

Navíc je to XML.

Ze zvědavosti: v ComicSubu používáš formát jaký?

[Martin Doucha]

Vlastní strukturovanej texťák. Příklad (pár řádků z ukázkového komiksu na stránce projektu):

style {"Style3", "#000000", "#ffffff", "Arial", 12pt, 0, 1, 0, 0, 0}
style {"Style4", "#000000", "#ffffff", "Comic Sans MS", 18pt, 0, 0, 0, 0, 0}
style {"Style5", "#000000", "#ffffff", "Comic Sans MS", 36pt, 0, 1, 0, 0, 0}

page("ubunchu01_02.png") {
	overlay {"Style4", "Ubunchu!", Ellipse, 823, 204, 211, 301}
	overlay {"Style4", "M... My recommendation is...", Rectangle, 941, 143, 202, 184}
	overlay {"Style4", "It is very popular with the users, and it is the hottest desktop Linux distribution available!", Ellipse, 99, 186, 223, 343}
	overlay {"Style3", "Isn't it Ubuntu not Ubunchu?", Rectangle, 409, 635, 369, 28}
	overlay {"Style5", "NO WAY!", Ellipse, 415, 690, 194, 202}
}

[kralyk z abclinuxu]

Aha, hm, tak to bys imho měl lepší přejít na něco jako XML nebo, pokud nemáš rád XML, tak třeba JSON nebo něco takovýho, protože komu by se chtělo psát parser texťáku s vlastní specielní strukturou?

[Martin Doucha]

komu by se chtělo psát parser texťáku s vlastní specielní strukturou?

Mně.

[Bystroushaak]

A to bude ten důvod proč se to zatím nerozšířilo :)

[Dreit]

+1

[Martin Doucha]

No neblbni, a já si celou dobu myslel, že je to tím, že jsem to ještě nedotáh ani do alfa verze.

[Martin Petr]

Že se ti nechtělo použít XML, to chápu, cpát ho zrovna sem je blbost (ono je asi blbost ho cpát vlastně kamkoliv).

Ale proč jsi vymýšlel nějaký vlastní formát a psal pro něj parser, místo toho abys použil třeba JSON, pro který existují minimalistické knihovny a kterýžto formát dokáže totéž, co potřebuješ, a mnohem více?

Tímhle přístupem defacto zabiješ chuť ostatních v navazání na tvou práci, psaní alternativních klientů atd. Tohle vidímo tak často, že se mi chce brečet.

[Ladicek]

Navíc, podle rychlého pohledu na zdrojáky, načítání i ukládání jsou natvrdo zadrátované do datových struktur (jsou asi tři, pokud dobře koukám).

[Martin Petr]

Libovka.

[Martin Doucha]

Tohle je jenom rychlej hnusnej hack, abych mohl vydat aspoň v nějak funkční verzi. Načítání a ukládání mám v plánu přepsat do modulárního systému, kde půjde snadno definovat různé verze formátů. Jenom jsem na to zatím neměl čas.

[kralyk z abclinuxu]

Načítání a ukládání mám v plánu přepsat do modulárního systému, kde půjde snadno definovat různé verze formátů.

Uhhhh... taky se přimlouvám za JSON. Ušetříš práci sobě a víc motivuješ ostatní, navíc jak koukám na ten tvůj formát, nejspíš by to asi ani nebyl moc velkej rozdíl. Anebo něco jako JSON (XML, ...)

[Martin Doucha]

Až dodělám ten modulární systém, klidně do něj můžeš napsat JSON modul.

[GeoRW]

ja osobne JSON nepoznam, tak som ho nepouzil. Nemam uz tolko casu studovat rozne formaty. s XMLkom pracujem uz dlhsiu dobu a pomerne casto aj v praci. Nemusi to byt najlepsi format na dany problem, ale velmi dobre pouzitelny. Pre mna bolo pomerne jednoduche a rychle vytvorit specifikacie v XML a nasledne vytvorit XML schemu. Takisto je plno kniznic, validatorov a roznych dalsich toolov na pracu s XML. Neviem, ci vobec existuje take nieco ako XML schema pre JSON na validovanie jednodlivych instancii daneho dokumentu. Takisto z toho, co som zatial z JSONu videl mi XMLko pride prehladnejsie a jednoduchsie aj na rucnu editaciu. Mozno v buducnosti niekto vytvori podobny format pomocou JSONu alebo ineho formatu/standardu buducnosti a bude to lepsie ktovie. Moznosti su neobmedzene

[Martin Petr]

... mi XMLko pride prehladnejsie a jednoduchsie aj na rucnu editaciu.

Ale no, lepší ukázkou formátu, více vhodného pro čtení a psaní dat aplikací a ne pro ruční editaci, už by snad byl jen nějaký binární formát. Vždyť kolikrát je poměr vlastního obsahu k XML datům samotným i 50:50 a hůř.

[phr]

poměr vlastního obsahu k XML datům samotným i 50:50 a hůř.

O to účinnější je potom komprese. Takže se to dá šířit zazipovaně , dekomprimovat on-line před použitím a pak zase zahodit.

[Martin Petr]

A to se k té snadné ruční editaci vztahuje jakým způsobem?

[phr]

Proč by všechna JPGčka, XMLka i ostatní soubory týkající se jednoho komiksu nemohly být v jednom archivu ? Pokliká na obrázek, rozbalí se mu všechny jeho součásti, zvolí (například) tu ruční editaci, opraví, zapíše a má to zase pohromadě, bez toho, aby mu vznikal na disku nepřehledný bordýlek. Když vidím chaos co vzniká při vývoji libovolného projektu, docela bych se za takové řešení přimlouval, má to výhody i při zálohování.

[Martin Petr]

Četl jsi příspěvek, na který jsem původně reagoval? Pochopil jsi, na kterou část toho příspěvku jsem reagoval? Píšeš o věcech, které s mou původní námitkou vůbec nesouvisí.

[phr]

Dobře, tak proč ti vadí XML formát zrovna proto, že je hodně redundantní ? I kdyby to psal jenom v editoru, stejně může jenom vyplňovat nějaké předpřipravené šablony. Z hlediska funkčního XML formát nepochybně vyhoví, z hlediska použití bude možná lepší, protože názvy tagů mohou být samovysvětlovací.. Vrať se k nějaké úsporně navržené syntaxi po pár letech, kdy už jsi vyhodil dokumentaci, z hlavy se to vykouřilo a stejně pootřebuješ vzít hotový komiks, udělat pár "aktualizačních" změn a víc se s tím nezabývat. Potom je ukecaný formát k nezaplacení. To co jsem napsal výš je nápad, který může využít, případně rozvinout, když by chtěl dát dohromady celé vývojové prostředí

A vůbec, jdu spát, už na to nevidím.

[Josef Kufner]

Hele, k JSONu ti chybí jen kousek. Pár závorek, nějaká ta čárka, špetka uvozovek... co říkáš na tohle?

{
  "styles": {
    "Style3": { "fg": "#000000", "bg": "#ffffff", "font": [ "Arial", "12pt" ], "wtf": [0, 1, 0, 0, 0]},
    "Style4": { "fg": "#000000", "bg": "#ffffff", "font": [ "Comic Sans MS", "18pt" ], "wtf": [0, 0, 0, 0, 0]},
    "Style5": { "fg": "#000000", "bg": "#ffffff", "font": [ "Comic Sans MS", "36pt" ], "wtf": [0, 1, 0, 0, 0]},
  },

  "pages": {
    "ubunchu01_02.png": {
      "overlay": [
        {"style": "Style4", "text": "Ubunchu!", "shape": [ "Ellipse", 823, 204, 211, 301 ]},
        {"style": "Style4", "text": "M... My recommendation is...", "shape": [ "Rectangle", 941, 143, 202, 184 ]},
        {"style": "Style4", "text": "It is very popular with the users, and it is the hottest desktop Linux distribution available!", "shape": [ "Ellipse", 99, 186, 223, 343 ]},
        {"style": "Style3", "text": "Isn't it Ubuntu not Ubunchu?", "shape": [ "Rectangle", 409, 635, 369, 28 ]},
        {"style": "Style5", "text": "NO WAY!", "shape": [ "Ellipse", 415, 690, 194, 202}
      ]
    }
  }
}

Výhody:

• Normalizovaná syntaxe.
• Díky názvům položek nepotřebuješ dokumentaci k porozumění.
• V budoucnu bude lehké přidat nové vlastnosti (narozdíl od pozičně určovaných parametrů).
• Existují hotové parsery snad pro všechny jazyky.
• Lidé to budou ochotněji přijímat.

Nevýhody:

• Je to maličko ukecanější než to tvoje, ale s tím si libovolná komprese hravě poradí. Kompresní poměr tohoto příkladu při použití gzip -1 (tj. nejhorší komprese) je 57 % (1017 B → 441 B).

[__dark__]

Jaky ma smysl kompresovat definicni soubor komixu, kdyz ty obrazky v nem zaberou 100x tolik mista?

[Josef Kufner]

Pokud to pak celé (obrázky + textové překlady) zabalíš do zipu, tak zabiješ dvě mouchy jednou ranou. A co jsem dělal nějaké jednoduché benchmarky, tak použití gzcompress() v PHP při úrovni komprese 2 a horší nemá na rychlost zápisu a čtení souboru měřitelný vliv, ale i tak to stáhne velikost na polovinu. Takže pokud je textu hodně a každá věta má u sebe kopec metadat, může to být znát, ale pochybuju, že by velikost byla nějak vážný důvod.

Další výhoda je, že když nějaký rejpal vidí binární humus, tak do toho nerejpe. A zrovna ten gzcompress() nevyrábí standardní hlavičky, takže to programy nepoznají a blbě se to edituje

[kralyk z abclinuxu]

+1

[Josef Kufner]

http://qjson.sourceforge.net/

[GeoRW]

No ideme odlisnym smerom. Ja v specifikaciach nedefinujem konkretne styly pre konkretny text. Zatial v specifikaciach nie su ziadne styly. Styly sa budu definovat na urovni aplikacie. V textovej vrstve sa definuje iba semantika. O konkretne vykreslovanie do danej text-area sa bude starat aplikacia. Casom mozno v specifikaciach pribudnu aj styly a fonty, ale tie styly sa budu viazat len na konkretne semanticke tagy, nie na konkretnu text-area. IMHO text v komixoch (hlavne pri prekladoch) nie je taky dolezity, aby musel byt presne nasadzany. Ak je to pre niekoho dolezite, tak si ten text moze presne nasadzat v nejakom grafickom editore a vyexportovat ako obrazok.

[Martin Doucha]

Já naopak chci vyrobit formát, který by zvládal kvalitní vysázení textu na úrovni klasicého exportovaného scanlation překladu, ale bez nutnosti nevratně měnit původní obrázek. To je pro mě výchozí bod.

[__dark__]

Jeden retezec a par parametru ti na kvalitni sazbu textu nikdy stacit nebudou. Mrkni se do HTML+CSS, jak muze byt zobrazeni textu komplikovane. U tveho pripadu bych jeste navic doporucil mit moznost linkovat primo ttf fonty a moznost pouzit vlastnosti, ktere jsou popsane treba tady a tady. No a z toho duvodu, ze uz to je vsechno popsane, bych ti doporucil prejit na XML a klidne pouzit subset z HTML/CSS pro formatovani a stylovani textu - je to pro tebe to nejlepsi, co muzes udelat

[Aleš Kapica]

Je to marný. Je to marný. Je to marný.

[__dark__]

Musim ti dat za pravdu :)

[Martin Doucha]

Je to marný, protože vy dva jste se ani na vteřinu nezamysleli nad tím, co ten formát potřebuje za vlastnosti. Místo toho tady jenom plácáte nesmysly a doporučujete to největší kladivo, co vás zrovna napadlo. Jestli chcete, abych vám uvěřil, že se na problém nedíváte z jedoucího rychlíku a hodně velké dálky, tak se předveďte sami a ten svůj formát implementujte. Mně na formátu zajímá co se do něj dá nebo nedá uložit a ne kolik je v něm buzzwordů.

[__dark__]

Ja nejak nechapu, proc se tu porad ohanis tim, at si neco zkusim implementovat. Ja jsem ti chtel spis poradit, protoze mi pripadalo, ze misto toho, abys resil veci tykajici se komixu, tak zabijis cas vlastnim formatem, ktery krome jineho typu zavorek neprinasi nic navic (sorry, ale to je muj pohled na vec)

Ja mam svuj projekt, ktery me bavi, a dostal jsem se do faze, ze me zacal i zivit, a pritom je to open-source. Nemam cas ani chut forkovat jine projekty.

[Martin Doucha]

Jasně, a proto mi radíš patlat se s jiným vlastním formátem, který mi ve finále zabije 10x tolik času.

[Martin Doucha]

Co se týče toho dokumentu o CSS fontech, tak i v téhle primitivní podobě podporuju kapitolu 3 skoro kompletně (to je těch 5 čísel na konci definice stylu, chybí jenom font-stretch a font-size-adjust), kapitolu 4 a 5 za mě řeší QT (místo možnosti zadat víc fallback fontů bude možnost embeddovat fonty přímo do balíku) a podpora kapitoly 6 je do budoucna plánovaná, ale teď není aktuální. Použití XML se budu dost agresivně bránit a o používání subsetu HTML/CSS platí to o rozebírání Boeingu 747 a stavění fichtla, co jsem na podobný návrh s DJVU napsal už předtím.

[__dark__]

Ja jsem mluvil ale hlavne o tom, ze muzes napsat text, ve kterem budou pouzite ruzne styly, treba neco zvyraznit, atd... No a kdyz se podivas do toho druheho linku a najdes "Swashes" a "discretionary ligatures", tak to jsou podle me zajimave features, ale nevim jestli je v Qt pro ne podpora.

Jinak si myslim, ze s tim XML to trochu prehanis. Vzdyt ukladas jen metadata, text, a odkazy na obrazky. Nedokazu si predstavit vhodnejsi reseni. Do budoucna muzes jen rozsirovat tagy a atributy a mas zajistenou zpetnou kompatibilitu a rozvoj tveho formatu (napriklad pridat moznost definovat prostor pro text jako SVG cesty).

No uvidis sam, ale podle me mas jen velmi malou sanci na uspech se soucasnym resenim, a pokud budes nekompromisne odmitat vsechno ostatni, tak snizujes i sanci, ze se k tobe prida nekdo dalsi;)

[Martin Doucha]

Já si vhodnější řešení představit dokážu. Vlastně mě napadá jen hodně málo horších řešení než pomocí XML, a většina z nich jsou věci typu XML zakódované do base64 a obalené další vrstvou XML. XML je nejsložitější známý způsob uzávorkování. Na takhle jednoduchou věc s minimální hierarchickou strukturou je to orbitální iontové dělo na vrabce.

Co se týče možnosti použít víc stylů v jedné bublině, zase je to plánovaná fíčura, která je někde uprostřed seznamu priorit. Nejvyšší prioritu v tuhle chvíli má ale modulární systém na ukládání a načítání (tj. zjednodušení práce se stávajícím formátem + možnost transparentně pracovat s víc formáty přes jednotné rozhraní), pak bubliny ve tvaru obecných polygonů a uzavřených křivek, a pak ještě rotace textu. Pak bude nejspíš na řadě napsání vlastního mechanizmu na sázení textu do bubliny, protože QTextLayout umí jen zlomek toho, co potřebuju.

[__dark__]

Já si vhodnější řešení představit dokážu

Je to tvuj format, tak se ani nedivim, ze ho budes branit klidne i do krve:) Problem nastava v okamziku, kdyz udelas deset tisic komixu, a zjistis, ze bys potreboval implementovat nejakou novinku, ktera ti je vsechny rozbije.

Jinak ja osobne jsem to napsal hlavne z duvodu ostatnich. Stylovani v CSS dneska umi kazdy, pouzivat HTML tagy taky, a pokud se rozhodnes pro trochu vektorove grafiky, tak tu je SVG, ktere opet kazdy umi a na netu je milion tutorialu. Ja tak nejak pochybuju, ze to vsechno dokazes udelat znovu a jeste lip v dohledne dobe (tedy driv, nez te to prestane bavit) :)

Je mi jasne, ze potrebujes "jen neco malo z toho vseho", jenze z vlastni zkusenosti vim, ze to neco malo bude za nejakou dobu malo, no a budes pridavat, pridavat, az z toho bude bastl, na ktery ted nadavas:)

[Martin Doucha]

Podívej, jestli si myslíš, že by bylo lepší na tenhle problém nasadit nějakého kočkopsa splácaného dohromady z HTML, CSS a SVG, nikdo ti nebrání to udělat. Klidně si k tomu forkni můj projekt, ať máš nějaké základní grafické rozhraní na editaci a můžeš se soustředit jen na samotný datový formát. Aspoň si sám na vlastní kůži ověříš, jak neskutečně debilní nápad to je.

[Josef Kufner]

HTML + SVG + CSS = XML + CSS ... tolik ke kočkopsu

Ale co jsem zatím dělal s XML, tak vždy to bylo na prd a do pohodlného to mělo daleko.

JSON má oproti XML výhodu v tom, že uzel stromu dokumentu má jen jeden typ potomků (v XML jsou minimálně 3 -- atributy, uzly a text). A ty potomci jsou pojmenovaní unikátním klíčem. Díky tomu existuje možnost jednoznačného a pohodlného převodu JSONu do datové struktury a zpět.

Zrovna v Qt ti na tenhle převod stačí QObject a jeho dynamické properties, do kterých uložíš QObject* nebo QList<QObject*>*. Takže můžeš pohodlně zajistit dopřednou kompatibilitu s budoucími vlastnostmi, kdy sice editor nebude vědět co s nimi, ale bude schopný je zachovat i během editace. Samozřejmě namísto QObjectu můžeš použít odpovídající třídu pro styl, stránku a podobně, dokud to bude dědit z QObjectu, tak můžeš rozšiřovat formát souboru, aniž bys sáhnul na parser či serializaci (doslova).

[petr_p]

Prohlížel jsem zdrojáky, tak mám pár drobných postřehů:

Archiv se zdrojáky nemá kořenový adresář.

Instalátor je takové veselé cp, které ani neumí instalovat do standardních cest pythonu.

V archivu vedle zdrojového kódu máš zabalený i bajtkód.

Při spuštění se program pokouší otevřít jeden dokument v tvém domovském adresáři.

Vedle kláves PgUp/PgDn by bylo dobré reagovat na mezerník a B nebo Backspace.

Skákání po rámcích zvětšuje každý rámec přes celé okno. Takže jinak velké rámce se zvětší s různým měřítkem. Líbil by se mi režim přecházení mezi rámci se zachováním měřítka. Nejlépe aby zůstalo viditelné okolí. Jsou totiž komiksy, kdy obrázky z rámců se překrývají. Zvětšení proto, že je třeba malý displej. Byl by to takový panning s přecházením z jednoho snímku na další podle jejich pořadí.

[Josef Kufner]

Zajímavý by také mohl být "jen vertikální posun". Při stisku mezerníku/šipky by se přešlo na políčko, které je níž než aktuální. Pokud je vidět celá šířka stránky, ale nevejde se na výšku nebo dole navazuje další stránka...

[GeoRW]

Zakladnu kostru programu + dost dalsich veci som zobral z Comixu (http://comix.sourceforge.net) Takze znacne ulahcenie prace. Instalator funguje, to je hlavne. Ked sa to bude niekedy v buducnosti distribuovat, tak predpokladam, ze pomocou .deb balikov a pod. Tento instalator zatial staci.

Při spuštění se program pokouší otevřít jeden dokument v tvém domovském adresáři.

To neni bug, to je feature, aby som nemusel zakazdym otvarat ten komix, ked testujem nove casti kodu. V buducnosti by sa default mal otvorit "Help" dokument popisujuci funkcie programu v ACBF formate.

Vedle kláves PgUp/PgDn by bylo dobré reagovat na mezerník a B nebo Backspace.

Medzernik a backspace mozem zaimplementovat, neni problem.

Skákání po rámcích zvětšuje každý rámec přes celé okno. Takže jinak velké rámce se zvětší s různým měřítkem.

Momentalne to funguje tak, ze obrazok ramca sa zmensi aj presahuje plochu, na ktoru sa ma vykreslit. V opacnom pripade sa nezmensi. Planujem zaimplementovat moznost pre "stretch" obrazku na celu vykrelovaciu, v pripade, ze je obrazok mensi.

Líbil by se mi režim přecházení mezi rámci se zachováním měřítka. Nejlépe aby zůstalo viditelné okolí.

Take nieco planujem do buducnosti, nejaky animovany prechod medzi ramcami (so zachovanim okolia), ale momentalne je to v prioritach velmi vzadu

[petr_p]

Ked sa to bude niekedy v buducnosti distribuovat, tak predpokladam, ze pomocou .deb balikov a pod.

A už jsi nějaký balíček vytvořil? Ten instalátor je totiž pro výrobu distribučních balíčků nepoužitelný.

[GeoRW]

Ten instalator som prebral z povodneho kodu pre comix Hold pri vytvarani packagov si bude musiet balic nastudovat dany install.py. Inak neni to nic zlozite, samotny program je cely v adresari /src a da sa pustit cez acbf.py aj bez instalacie. Ostatne veci su len ikony, desktop configuration file a definicia novej .acbf pripony.