SVG? Podivnost... (diskuse)

[pht]

souhlasim, take jsem na to hresil, kdyz jsem to implementoval. co je mi platne ze pouzivam hotovy xml parser, kdyz si tenhle balast musim rozparsovat sam, a to navic ne ze by to melo nejakou primitivni gramatiku, nebudeme prece omezovat uzivatele kery to pise od ruky.

uplne nejlepsi by samozrejme bylo

<path>
<moveto x=... y=... />
...

uplne nejhustsi je specifikace a prepocet eliptickeho oblouku

[pht]

ps. myslim, ze inkscape svg je jen obycejny svg s nejakym namespace navic. reprezentace vseho coby cesty je prave dusledkem toho, ze kazdej normalni program (i ten co jsem delal ja) nakonec vsechno prevede na bezierky a ty pak kresli pomoci de casteljau. a ze je to pak v necem jinem nez xml je na prd, viz vyse.

[kralyk z abclinuxu]

jj je to tak, vono už to původní SVG nic moc...

[andree]

heh, tak to je slusny humus

[Daniel Kvasnička ml.]

(Btw. Co mi to jen připomíná? Jakobych už o podobně (asi ještě o dost víc) zmršeném XML někde slyšel... =D)

Kdyz v OOXML bylo v jako value nebo c jako cell, to bylo revu, jak je to strasne proti XML a necitelne. Ale ze se v HTML uz 10 let pouziva a, i a b nebo ze tady maji nejake d, to nikoho moc nevzrusuje

Jinak ano, tvurci Inkscape si SVG pekne upravili. A nikoho krome nich to moc nevzrusuje. Interoperabilita Inkscape s ostatnim vektorovym SW ze sveta linuxu je prakticky nulova. Akorat s GIMPem si celkem rozumi. Ale udelat v Inkscape grafiku a chtit ji importovat do Scribu?...

[koroptev]

kdokoli preci muze konverzni program/plugin napsat, tohle preci neni zadnej argument sakra, ze to nikdo neudelal, vo to tu vubec nejde...

[kralyk z abclinuxu]

Jenže kdyby Inkscape pracovalo s obecným SVG, maximálně si něco přídalo, ale originální standardy respektovalo, tak nikdo nic takovýho zbytečnýho psát nemusí.

[koroptev]

Humor, a miril jinam, Inkscape & SVG je mi u prdele

[pavlix]

miril jinam

Chtělo by to lepší mušku.

[Filip Jirsák]

Nemělo by být v titulku příspěvku místo „SVG“ spíš „SVG v Inscape“? Ten zápis křivky v SVG ne opravdu poněkud anti-XML – asi byla snaha ušetřit nějaké místo, když se s SVG počítalo i pro mobilní aplikace. Ale je to taková podivnost, protože se přišlo o některé výhody XML, ale všechny nevýhody zůstaly.

[Filipec]

Mně to nepřijde tak špatné - od oka tipuji, že se tím ušetří okolo poloviny velikosti souboru, pokud obsahuje hlavně složitější křivky.

A skutečně, když se totéž uloží jako "SVG" a "Inkscape SVG", je druhá možnost znatelně menší. Přitom nebyla potřeba použít zlou a ošklivou kompresi jako u SVGZ - zkrátka se jen vyhodila redundundantní data.

[Filip Jirsák]

Jenomže kdyby se to samé zapsalo v nějakém binárním formátu, ušetřila by se ta druhá půlka velikosti souboru Buď je pro SVG velikost souboru důležitá, a pak je zvolené řešení polovičaté, nebo důležitá není, a pak je ta „komprese“ zbytečná. Jenže zvolené řešení vypadá, jako by velikost souboru pro SVG byla napůl důležitá. Navíc takhle už to není ani pořádné XML – když s tím budete chtít pracovat třeba pomocí XSLT, dělat něco s řídícími body křivky bude problém.

Mně osobně by zvětšení SVG souborů nevadilo, a jsem rád, že SVG je XML, protože se to pak dá číst a upravovat v běžném textovém editoru. Ale zápis řídících bodů křivky do jednoho atributu se mi nelíbí. Už jenom proto, že běžné editory XML nezachází s kilometr dlouhým atributem zrovna nejlépe.

[Filipec]

Nemyslím si, že by to bylo polovičaté řešení. Naopak, zdá se mi přehledné a úsporné - pokud budeme brát ohled na lidi, kteří se odvažují psát SVG ručně, je tento stručný textový formát podle mého nejvhodnější.

Navíc mám dojem, že konverze mezi oběma formáty musí být velmi snadná. Možná by to šlo i pomocí jednoho regulárního výrazu.

[Filip Jirsák]

pokud budeme brát ohled na lidi, kteří se odvažují psát SVG ručně, je tento stručný textový formát podle mého nejvhodnější.

Moje zkušenost s ručním psaním cesty je přesně opačná. Kolikrát jsem si vzpomněl na Perl a nějaký pěkný regulární výraz přes celý řádek. V obou případech to bylo téměř write-only a najít v tom nějakou konkrétní část „kódu“ bylo takřka nemožné. A to bych do regulárních výrazů v Perlu teoreticky mohl psát komentáře, u XML atributu mám s komentáři smůlu.

[kralyk z abclinuxu]

Pokud by cesta byla rozepsaná tak ja jsem navrhoval já nebo ještě lépe pht, nebyl by problém. To by pak totiž bylo skutečně XML...

[pavlix]

Zvyknout se dá na obojí, uznávám, že v duchu stromové struktury by bylo asi lepší udělat i ty cesty.

Btw, XML (aneb s trochou nadsázky "nejsložitější formát pro uzávorkování") podivnost není?

[kralyk z abclinuxu]

Nejde o duch nebo neduch stromové struktury, de o to, že psát extra parser pro zápis cest a buhvíjaké další černé SVG-magie se nikomu nebude dvakrát chtít a není pak divu, že SVG není tak oblíbené, jak by mohlo...

XML hodnotim pozitivně, libí se mi, že je hodně obecné a jednoznačné, což zaručuje přenositelnost. Navíc je dobře čitelné obyčejným texťákem. S knihovnou TinyXML se mi pracuje dobře, je rychlá, stabilní ... Prostě si nemám na co stěžovat

Samozřejmě tvůrce XML to nesmí přehnat, je potřeba XML užívat střídmě, aby si zachovalo přehlednost, čitelnost a přenositelnost. Někteří hyperaktivní tvůrci jsou schopni vytvořit v XML neuvěřitelné struktury, ale to je jejich vina že...

Víš o lepším řešení než XML? nejsem proti skoušení nečeho novýho...

[pavlix]

No, já "písmeno argument argument" nepovažuju ani za složitou gramatiku ani za černou magii.

Jestli se do SVG někomu nechce, tak je to proto, že je to vektorová grafika. Uživatelé proto, že se naučili s programem na úpravu fotek a už jsou kingové, implementátoři proto, že monitor rozvěcí pixely a nekreslí křivky.

Zkus si imlementovat SVG prohlížeč... a uvidíš, že těch několik málo řádků kódu parseru bude ta největší prkotina, kterou budeš řešit (samozřejmě se ti může stát, že použiješ hotový kód/knihovnu, ale to nic o složitosti neříká).

Víš o lepším řešení než XML? nejsem proti skoušení nečeho novýho...

Tak třeba... kulaté závorky... hranaté závorky... složené závorky... ;) nebo třeba i špičaté závorky, proč ne :D. To všechno je dobře čitelné jak strojově, tak očima a plní to stejný účel (popis stromu).

Neříkám, že je XML špatné, jen že si s sebou nese nějaké zbytečné komplikace z historie jako každý systém, který se snaží být zpětně kompatibilní s něčím.

Největší výhoda XML je to, že se všude používá (ne to jak je navržené) a za to můžete děkovat i třeba společnostem jako je Microsoft. A taky že se XML obvykle kurví jenom nešikovným použitím, ale za dodržení standardu.

Ještě jsou důležitá namespaces, bez toho by to byl jen další stromový formát. Díky nim má smysl používat XML pro různé internetové technologie.

[kralyk z abclinuxu]

No, já "písmeno argument argument" nepovažuju ani za složitou gramatiku ani za černou magii.

Já taky ne! Ale urpsotřed jinak pěknýho XML to černá magie je. Ať má teda SVG vlastní formát úplně oproštěný od XML, ať si tam má jakoukoli gramatiku, ale jesi to chce být XML, tak ať to teda XML je. Ale hlavně nic mezi vlastním formátem a XML.

Zkus si imlementovat SVG prohlížeč... a uvidíš, že těch několik málo řádků kódu parseru bude ta největší prkotina, kterou budeš řešit (samozřejmě se ti může stát, že použiješ hotový kód/knihovnu, ale to nic o složitosti neříká).

Jo, je to ta největší blbá prokotina, kterou musím řešit. Kdyby SVG korektně dodržovalo XML, nemusel bych se s tím naprosto zbytečně patlat a moh bych se soustředit na ty důežitější věci. A mimochodem, blbuvzdorný, rychlý a přesný parser gramatiky cesty taky není tak úplně na "několik málo řádků"

Tak třeba... kulaté závorky... hranaté závorky... složené závorky... ;) nebo třeba i špičaté závorky, proč ne :D. To všechno je dobře čitelné jak strojově, tak očima a plní to stejný účel (popis stromu).

Myslel jsem konkrétní obecný formát, na který existuje svobodný parser fungující podobně elegantně jako TinyXML, no ale to je jedno...

[pavlix]

Kdyby SVG korektně dodržovalo XML

Nemám jediný důvod si myslet, že nedodržuje.

Myslel jsem konkrétní obecný formát

Vznikla jich za posledních několik desetiletí celá řada, hledej :). A parserů podobných formátů je spousta.

[kralyk z abclinuxu]

Kdyby SVG korektně dodržovalo XML

Nemám jediný důvod si myslet, že nedodržuje.

A co teda ta gramatika path? Ta ti připadá XML?
Můžeš mi říct jedinej rozumnej důvod proč není zapsaná třeba takto:

<path>
  <moveto x=... y=... />
  <lineto x=... y=... />
  ...
</path>

(jediný co mě napadá - šetření velikosti, to ale nepovažuju za rozumný důvod, máme přece svgz)

[pavlix]

Pokud tvrdíš, že SVG porušuje syntaxi XML, tak by to měla být aspoň pravda. Takhle je to bohapustý kec.

[kralyk z abclinuxu]

parametr d u <path> je cokoli, jen né XML. Můžeš uvést jediný rozumný důvod, proč by neměl být XML např. tak, jak jsem napsal v předchozím příspěvku.

[pavlix]

Nevidím jediný rozumný důvod, proč uvádět rozumné důvody ve vlákně, kde tvrdíš, že SVG není korektní XML :). Sorry.

[kralyk z abclinuxu]

SVG je korektní XML do té míry, že parser XML v něm nevidí chyby.
Zřejmě požaduješ až strojově přesné vyjadřování, takže extra pro tebe: SVG je korektní forma XML, ale vadí mi, že naprosto zbytečně a bezdůvodně není atribut d tagu <path> rozepsán do podtagů místo nahečmání do jednoho stringu, ok Sheldone?

[andree]

to si asi zle pochopil, ale to je tak ked miesto bavenia sa o podstate veci tu tahas ludi za slovicka... ten inkscapeovsky svg moze byt pefektne korektne xml - ale xml asi nevzniklo kvoli tomu, aby si clovek potom aj tak vrazil cele podstruktury do atributov a aby to potom musel parseovat... spravit to samozrejme moze, kludne moze pouzit CDATA bloky miesto podstromov, a do nich vkladat xml subory - ale ze to je kvalitne nechutny pristup, o tom asi malokto normalny bude pochybovat...

ale ak nas tu chces presvedcit, ze to je ako uplne-tyvee-v-pohode, tak si mozme spravit contest, ty napises parser pre toto:

<path id="path1" d="M 100,100 L 200,200 ..." />

a my pre toto:

<path id="path1">
  <v kind="M" x=100 y=100 />
  <v kind="L" x=100 y=100 />
  ...
</path>

fakt netusim, kam touto diskusiou mieris - mne teda pride vcelku zrejme, ze ten prvy pristup je konina, ktoru evidentne vymyslel niekto, komu sa nechcelo napisat o 3 riadky navyse na vytvorenie podstromu XML... tak radsej vrazil tu blbost celu do atributu - a fest by ma zaujimalo, ako velmi je odolna na vlozenie whitespace-ov a pod...

[pavlix]

inkscapeovsky svg

Odpovídáš mimo téma, bavili jsme se o SVG.

kam touto diskusiou mieris

Reaguju na něco, co bylo řečeno, nebyla to pravda a mohlo by to zmást další lidi. Nehodnotil jsem který postup z dvou možných (a obou korektních a zřejmě i odůvodněných!) je lepší.

Rozdíl mezi námi je v tom, že já se snažím reagovat na to, k čemu mám co říct a na co mám znalosti.

Ty víš jistě, že pánové od SVG jsou ignoranti a nevědí, k čemu je XML. Já nemám dost informací, abych věděl, jestli jejich rozhodnutí bylo odůvodněné a správné nebo nebylo.

Ty máš potřebu mě přesvědčit o tom, že autoři SVG jsou hloupí. Já ještě neviděl žádný výsledek práce od tebe, takže ani netuším, jestli na takové soudy vůbec máš!

[andree]

ok, mohol som si to pozriet lepsie holt by sa to do XSD asi prepisovalo tazsie (ak by to vobec slo), ako ked to napisu pomocou takejto gramatiky... sice je blbe, ze na to nestaci normalny validator - ta ale co uz, ked to takto vymysleli za nas howgh aj tu

[kralyk z abclinuxu]

No v plain-SVG i v Inkscape-SVG se path ukládaj stejně, teda alespoň dparametr je úplně to samý. Inscape si akorát přidá nějaké ty svoje sodipodi. A pak má některé svoje vlastní objeky, jako hvězdice nebo spirály, ale ty už se SVG nemaj moc co dělat, a protože plain-SVG je v tomhle ohledu obecnější než Inskscape-SVG, je také větší, ale velikost souboru jinak Inkscape-SVG nezlepšuje, naopak (sodipodi).

Mimochodem, proč je svgz ošklivé? Kvůli zlib licenci? Proč teda nepoužít gz?

[pavlix]

Hmm a já čekal, že se bude v blogpostu kritizovat SVG a najednou se tam píše, že ten špatný je Inkscape (plus něco okolo zápisu křivek).

Tak mám tedy tři dotazy:

1) Čím bys nahradil SVG, pokud bys ho nahradil?

2) Čím potom Inkscape?

3) Co je tak složitého na gramatice zápisu cest?

Sám neumím na žádnou z těchto otázek dobře odpovědět, vektorovou grafiku mám rád a nechápu třeba "webdesignery", kteří místo vektorové podoby loga či tlačítka umí jen 640x480 (či podobně velký) rastr, o ktém řeknou "zmenšovat to jde a zvětšovat to není potřeba".

Takže, pokud otevřený vektorový formát a použitelný opensource vektorový editor (nebo alterantivně nepříliš drahý multiplatformní vektorový editor), kde hledat?

[andree]

2) preco by si chcel nahradzovat inkscape? stacilo by keby zapisoval "poriadne svg"

3) vid 1 NF - myslim ze sa to da napasovat na xml, tak isto ako aj na sql a ine databazy...

len dufam ze nie som offtopic

[...............23]

2) inkscape normálne svg zapisovať vie (aspoň myslím že normálne ), stačí vybrať plain svg namiesto inkscape svg ako formát pri zápise...

[pavlix]

ad 2) Někomu se tu nelíbilo SVG a ten skvělý vektorový formát, který je odpovědí na otázku (1) nejspíš Inkscape ani neumí ;). Jinak s SVG s Inkscape jsem žádné problémy neměl, naopak, když jsem psal vlastní (a korektní) SVG, tak jsem měl tendenci používat věci, co neumí třeba ani Konqueror nebo Opera (jako třeba CSS pro SVG).

ad 3) Já si myslím, že relační logika se bude na XML obecně pasovat velmi těžko, vzhledem k úplně odlišné struktuře XML stromu a relační databáze. Samozřejmě že jde strom převést na relační db a naopak, ale oba směry ale úplně odlišným způsobem a...

Myslím, že jsi hodně offtopic. Já se totiž ptal, co je na té (podle mě velmi jednoduché) gramatice složitého a na to jsem odpověď nedostal.

[andree]

2) moze byt no... ten ne-inkscape svg som neoveroval na validitu :)

no prave ta 1NF nie je zase az tak natvrdo priputana k relacnym databazam, som to spomenul nejak tak 'v prenesenom vyzname' - ide o to, ze keby to clovek chcel dotiahnut do extremu, tak si urobi subor na styl

<xml>
 BlaBlaKoren:atribut1=123:atribut2=abc
   BlaBlaList:atributN=yes
     text
   BlaBlaList
     text
</xml>

a to by som povedal, ze sice bude validne xml, ale co z toho, ked vacsinu prace nespravi xml kniznica/parser, ale clovek si to musi fakticky 2. krat rozprarsovat sam.. a (aj) o tom je ta 1NF, a v tom je uvedenie nejakych suradnic v atribute vcelku blby napad (ked sa da pekne pouzit nativna 'featura' xml, a snad aj specifikacie svn...) - v sql je napr. uvedenie viacerych atributov v jednom stlpci tiez nie tak uplne OK...

no.. ale mam pocit ze nosim drevo do lesa, hm?

[pavlix]

Spíš mám pocit, že jsi si vzal do hlavy, že sem napasuješ 1NF, ačkoliv nemá žádnou blízkou souvislost s tím, co píšeš.

[andree]

no ako myslis, ide mi o princip, nie nejake poucky ked sa nerozumieme, tak to radsej nechajme tak... peace

[pavlix]

NF1 je právě ta poučka, ne "princip" :).

[andree]

dakujem za objasnenie ooo velky guru... ostaneme kazdy pri svojom, ako som uz pisal vyssie - nemienim sa bavit o slovickach, uz toboz nie s dalsim matfyzakom... howgh

[pavlix]

Bav se o čem chceš a s kým chceš ;) a nejlépe s někým, kdo ti bude přitakávat.

[andree]

ouch

[default]

1) Čím bys nahradil SVG, pokud bys ho nahradil?

EPS, PDF

2) Čím potom Inkscape?

Adobe Illustrator (a to v každém případě)

[Aleš Kapica]

No fůůůůj..

[pavlix]

ad 1) Jsi si jistej, že EPS a PDF obsahují všechno, co SVG (nebo aspoň všechno, co je z něj užitečné)?

Adobe Illustrater nesplňuje podmínky, které jsem napsal. Nevím, jestli ti dělá problémy čeština:

"použitelný opensource vektorový editor (nebo alterantivně nepříliš drahý multiplatformní vektorový editor)"

ale měl bys s tím něco dělat.

[kralyk z abclinuxu]

1) Čím bys nahradil SVG, pokud bys ho nahradil?

Změnil bych ho tak, aby respektoval zásady XML. Protože stávající SVG je XML jen napůl a XML parser mi tedy zdaleka nestačí.

2) Čím potom Inkscape?

Inkscape je mi celkem ukradený, ale když je to svobodný editor vektorové grafiky, mohl by plně implementovat stávající SVG formát, místo neúplné implementace & přidání vlastních featur.

3) Co je tak složitého na gramatice zápisu cest?

Nic! Nechápeš - nestěžuju si na složitost zápisu cest, stěžuju si na návrh jeho tvaru. Z pozice programátora totiž musím jednak parsnout XML jako takové, ale kromě toho ještě napsat další parser, který navíc není obecně použitelný, ba naopak, naprosto specializovaný. Je to zbytečné a přidělává to akorát lidem práci.

Ideály jako znovupoužitelnost kódu a harmonie návrhu úložného formátu se pak propadají kamsy do hlubin ingorance...

[pavlix]

ad 1) XML parser ti nikdy na zpracování vektorové grafiky stačit nebude.

ad 2) A nějaké bližší info, co neimplementuje... a co při exportu do "čistého" SVG dělá špatně?

ad 3) O tom už jsem něco psal výše...

Ignorací bych to nenazýval, je to buď lepší nebo horší strategické rozhodnutí.

[kralyk z abclinuxu]

ad 1) XML parser ti nikdy na zpracování vektorové grafiky stačit nebude.

To jsem nikdy netvrdil, jenže:
Kdyby SVG dodržovalo standardy XML tak mi stačí XML parser a zobrazovací engine+drobnosti. Takle potřebuju XML parser, SVG parser a zobrazovací engine+drobnosti. A to naprosto zbytečně.

ad 2) A nějaké bližší info, co neimplementuje... a co při exportu do "čistého" SVG dělá špatně?

Čistě namátkou např. <polygon>, zobrazí ho, ale nemůžu měnit polohu vrcholů. Přitom dle standardu SVG to je jedno z grafických primitiv.

[pavlix]

ad 1) K tomu už jsem napsal všecko, co jsem chtěl, snad jen že pojem "SVG parser" používáš nesmyslně. Co víc, jsem si téměř jistý, že jsi to ani nezkoušel naprogramovat.

ad 2) Pošli odkaz na bugreport.

[kralyk z abclinuxu]

ad 1) K tomu už jsem napsal všecko, co jsem chtěl, snad jen že pojem "SVG parser" používáš nesmyslně. Co víc, jsem si téměř jistý, že jsi to ani nezkoušel naprogramovat.

Nezkoušel jsem naprogramovat co? SVG parser mám, sice parsuje jen celkovou strukturu plus ty cesty, žádný velký podrobnosti, ale mě to stačí... no transformace neparsuju, ale taky nedělám SVG editor...

ad 2) Pošli odkaz na bugreport.

No je to stršná námaha ale asi to udělám no ... i když myslím že, pánové za Inkscape vo tom věděj, akorát se jim to nechce řešit

[pavlix]

Nesuď dokud nemáš jejich vyjádření :).

[kralyk z abclinuxu]

je to tajhle:
http://inkscape.org/wiki/index.php/SVG_Test_Suite_Compliance
v části shapes... u polygonu, polyline a line maj poznámku editing problem.

takže o tom zřejmě vědí...