atari
Membru Junior
Inregistrat: acum 11 ani
|
|
Postez mai jos cateva puncte unde cred eu ca Tutorialul ar putea fi corectat, precum si cateva explicatii si opinii personale despre html-ul generat de cele doua metode.
O fac aici si nu pe pm lui Utilitas, in speranta ca explicatiile tehnice de mai jos pot fi de folos si altor useri. Seven a zis ca explicatiile ar trebui sa se adreseze unui public cat mai larg si nu unui grup restrans de cunoscatori, asa ca am ales sa explic mai "poetic" :-) unele aspecte. Stiu ca multor useri experimentati explicatiile mele li se vor parea triviale, dar e un risc asumat.
In Tutorial, primele doua imagini sunt folosite pentru a ilustra cat de mizerabila este metoda 1. Dar se compara “omizi cu fluturi” nu “fluturi cu fluturi”.
Din tutorial: “Imaginea 1 prezinta codul html dintr-un epub facut dupa prima metoda” Afirmatia e falsa, nu e html dintr-un epub, ci e ceea ce salveaza Word-ul.
E fisierul de intrare in Calibre si nicidecum fisierul de iesire (epub). E comparata cu imaginea 2, care e fisierul de iesire din Atlantis (epub). -> Omizi(fisier de intrare) cu fluturi(fisier de iesire)
Corect ar fi sa se inlocuiasca Imaginea 1 cu ceea ce genereaza Calibre in epub pentru paragraful in cauza. Dar parca nu mai e asa de efect daca e inlocuita, nu? Se pare ca toti parametrii aia aditionali de la inceputul paragrafului "plini de cod inutil" au cam disparut in noua imagine, iar codul html arata absolut rezonabil…
Explicatie tehnica: In Word exista doua moduri principale de formatare:
1. Formatare directa - selectam textul de formatat - schimbam font, culoare, dimensiune, identare, etc, din controalele din ribbon-ul Wordului.
2. Formatare cu “stiluri”: - definim “stiluri” (font, culoare, dimensiune, identare, etc) pentru tipuri de text: Text normal, Titlu Capitol, Titlu subcapitol... - selectam textul de formatat - aplicam stilul corespunzator din cele definite mai sus -> fontul, dimensiune, identare, etc a textului selectat se vor modifica conform cu cele ale stilului.
(Putem sa folosim si stilurile predefinite, nu e nevoie sa definim neaparat stiluri noi. Un stil poate fi modificat dupa preferinte si apoi salvat.)
Diferenta dintre cele doua metode de formatare (stiluri vs direct) nu este vizibila cand te uiti la doc: ambele arata la fel. Intern insa, diferenta este destul de mare, si voi apela la o metafora pentru a o explica:
Sa presupunem ca avem o haina super inteligenta: putem sa schimbam textura (grosime, culoare, model, etc) la o simpla atingere. Haina are o serie de texturi preinstalate, iar la apasari succesive alegem una din texturile astea, pentru o portiune din haina. -> Asta ar fi formatarea cu stiluri. Dar avem si o alta metoda: putem sa punem un petic, dintr-un material cu textura dorita, peste acea portiune. -> Asta ar fi formatarea directa.
Formatare cu Stiluri: “Natural”, Word-ul e orientat pe “stiluri”, ceea ce inseamna ca orice paragraf din text are asociat un stil (in cazul in care nu-l definesti tu, il defineste Word implicit ca “Normal”). “Are asociat un stil” inseamna ca Word tine minte numele stilului si foloseste elementele de formatare (fontul, dimensiune, identare, etc) definite in acel stil. -> stie “textura” care se aplica acelei portiuni
Atunci cand salvam in format html, paragraful va arata ceva de genul:
<p classMsoNormal> <span lang=RO> Paragraf de test 1</span></p> - classMsoNormal e “legatura” cu stilul folosit, in cazul nostru e stilul “Normal”
Formatare directa: Orice modificam prin formatare directa (font, culoare, dimensiune, identare, etc) va fi memorat de Word individual, in sensul ca va crea descriptori aditionali ai paragrafului pentru fiecare element de formatare (-> petice diferite). Aceste valori sunt prioritare celor definite in stil, in sensul ca daca sunt prezente, acestea sunt folosite iar cele din stil sunt ignorate (au rol de petic peste textura originala).
Exemplu: Formatez direct fontul unui paragraf la Arial. Atunci cand salvez in html, paragraful va arata ceva de genul:
<p class=MsoNormal><span lang= RO style='font-family:"Arial","sans-serif"'>Paragraf de test 1</span></p>
-> Am pus un petic ('font-family:"Arial","sans-serif"') la textura initiala (“MsoNormal”)
Mai schimb si marimea fontului, tot prin formatare directa:
<p class=MsoNormal><span lang= RO style='font-size:12.0pt;font-family:"Arial","sans-serif"'>Paragraf de test 1</span></p>
-> Am mai pus un petic ('font-size:12.0pt'), langa cel existent.
In cazul in care mai multe paragrafe sunt formatate direct (selectez o portiune de text, de exemplu), descriptorii aditionali vor fi creati pentru fiecare paragraf in parte. In exemplul de mai sus, daca selectatam tot textul, fiecare paragraf din document va primi un descriptor aditional style='font-family:"Arial","sans-serif". -> fiecare paragraf va primi “peticul” lui.
Deci, cu cat facem mai multe formatari directe, cu atat devin mai “stufosi” descriptorii de formatare ai paragrafelor.
Si uite asa ajungem la Imaginea 1 din Tutorial. Poate e derutant, dar “codul inutil” (alta dezinformare in Tutorial) sunt formatarile noastre directe. Nu e deloc inutil.
Aceeasi filozofie (textura + petic) se aplica si reprezentarii interne a doc, nu doar cand salvam html. Aceeasi problema e prezenta si in doc-ul importat in Atlantis. Nu are nimic de-a face cu una dintre metode, e pur si simplu modul in care Word tine minte formatarile.
Cum prelucreaza Calibre campurile astea? La conversie in epub, Calibre adauga clase aditionale de “stiluri” (“CalibreX” – nu sunt stiluri in sensul stilurilor Word, dar le numesc asa pentru simplificare). Cu asta simplifica printre altele si formatarile directe din html-ul folosit la intrare. In principiu, se uita la toti descriptorii, gaseste elementele comune si creaza clase noi css. Apoi inlocuieste sirul de elemente din descrierea sirului cu clasa corespunzatoare.
In termenii metaforei: Grupeaza peticele si genereaza tipuri de petice mai complexe, cu caracteristicile elementelor grupate. Este tot un petic peste textura initiala, dar are acum mai multe caracteristici (culoare, grosime, etc).
Rezultatul e un cod html mult mai compact in epub-ul generat.
Exemplu: <p class="MsoNormal"><span lang="RO" class="calibre6">Paragraf de test 1</span></p>
Si asta e ce avem in mod normal intr-un epub generat cu Calibre, nu o copie directa a html-ul din fisierul de intrare, cum gresit se sugereaza in Tutorial. Din punctual meu de vedere HTML-ul rezultat este mai mult decat onorabil.
"Bun, dar codul generat de Atlantis e totusi si mai compact" Asa este, iar asta e pentru ca Atlantis a ales sa simplifice formatarile directe intr-un alt mod: La conversie in epub, Atlantis modifica stilul paragrafului folosit, pentru a ingloba formatarile directe. Deci genereaza “texturi” noi, in loc sa mentina textura originala + petic. Cea mai folosita "textura" in text este declarata ca implicita, de aceea la majoritatea paragrafelor nu apare nimic aditional ca si atribute de formatare. Rezultatul e un cod html si mai compact in epub-ul generat.
Exemplu: <p>Paragraf de test 1</p> <p class="p2">Paragraf de test 2</h1>
Destul de interesant facut, si se preteaza foarte bine la carti, unde avem un numar foarte mare de paragrafe de text normal si un numar mic de paragrafe formatate altfel (Titluri, motto-uri, etc)
”Pe mine unul ma deranjeaza teribil cum arata formatarile astea directe in Word HTML filtrat“ In cazul nostru, rolul lui html_filtrat din Word este de fisier intermediar, folosit intre Doc si Epub (un capat al procesului e doc-ul, celalalt capat e epub-ul). Echivalentul lui in cazul folosirii Atlantis-ului, ar fi un fisier temporar, folosit intern doar de Atlantis la conversia din Doc in Epub. Cati dintre cei care genereaza epub-uri se uita in fisierele intermediare folosite de soft? Si daca se uita in ele, cu ce-i ajuta? Ce le fac? Modifica la mana tag-urile?
“Ia sa vedem ce html scoate Word-ul” e interesanta pentru unii dintre noi, dar total inutila pentru 99% din useri (in cazul generarii epub-urilor). Toti folosim Internet dar pe putini ne intereseaza care-i treaba cu protocolul TCP/IP. Atata timp cat rezultatul e cel asteptat ni se falfaie de complexitatea bijbelor de sub masa. Si asa e si normal sa fie. Dar tot normal e sa si spunem (sau macar s-o gandim): “Nu vreau sa inteleg asta in detaliu, pentru ca daca ma uit in detaliu la tot ce-mi iese in cale atunci imi voi pierde toata viata cu detalii, si cand sa mai citesc si eu o carte?” si nu o aroganta de genul: “Asta e o chestie nasoala rau. Ia uitati-va si voi ce paros e fluturele asta! Si comparati-l cu celalalt!”
Pai in primul rand e omida, nu fluture. Dupa ce-l treci prin Calibre va fi fluture, dar aia e o alta imagine! Si e paroasa pentru ca tu ai chinuit larva (ai facut formatari directe excesive in doc), nu pentru ca metoda o prefera asa.
”Bun, si cam ce-ar trebui sa facem acum? Formatam totul cu stiluri si nimic direct, ca sa avem fisiere html mici? Formatarile directe nu sunt neaparat gresite, nu e nimic gresit in a le folosi moderat. E adevarat, reprezentarea interna e mai stufoasa (ne-optimala), se pierde posibilitatea reformatarii unitare prin modificarea stilului, fisierele salvate vor fi mai mari. Dar atat timp cat soft-ul folosit le intelege si se descurca cu ele iar rezultatul este cel asteptat, cui ii pasa cat de paroasa e omida? “Atat timp cat soft-ul se descurca cu ele” depinde in acest caz de cat de moderat folosim formatarea directa.
Cateva opinii/concluzii proprii:: 1. Nu “sculele” folosite de o metoda sau alta sunt cel mai important aspect, ci fisierul de intrare: doc-ul. Pentru un epub de calitate e necesar un doc formatat cat mai “curat” si simplu: stiluri, formatare directa moderata, fara brizbrizuri.
Aici cred ca ar trebui canalizate eforturile: in metode/scule pentru a curata un doc de "petice" inutile conversiei in epub. Sunt cateva metode expuse de-a lungul timpului pe forum, dar cred ca putem veni cu ceva mai simplu, care sa fie foarte usor de folosit si cat mai putin distructiv fata de doc-ul original.
2. “Cat de compact e html-ul din epub” nu e un criteriu de selectie al unei metode. Nici “cat de citibil este html-ul” nu e un criteriu. User-ul nu citeste html. El citeste ce-i arata readerul. Deci important e ca software-ul readerului sa inteleaga html-ul generat, nu userul.
3. Pot fi alte criterii dupa care o metoda e mai buna decat alta, si ma gandesc aici la: - usurinta in folosire - flexibilitate - posibilitatea de a adauga optiuni noi - functionalitati aditionale (de exemplu tot comparam Atlantis cu Calibre, dar sunt chestii total diferite: Atlantis e un editor de text care poate salva si epub, iar Calibre e un soft de organizare a bibliotecilor electronice, care poate si converti dintr-un format intr-altul. Nu conversia in epub e centrul sau de greutate – dar se descurca rezonabil si aici, dupa parerea mea)
- … lista e deschisa …
Modificat de atari (acum 11 ani)
|
|