2011. február 3., csütörtök
PRC készítés házilag 8.rész - .prc6 - HTML tisztítás
PRC készítés 6.
HTML-tisztítás
Korábban többször szóba került, hogy a mobi PRC alig a töredékét ismeri az évtizedek alatt CSS kódokkal elbonyolított HTML szöveg-formázásoknak. Ez nem is baj, hiszen a képes albumok kivételével az olvasnivalóban a szöveg számít, nem a csicsás kinézete.
Ha a nyersanyagot eleve HTML-ben írjuk meg, akkor biztosan egyszerű és letisztult kódot kapunk. De mindenki szövegszerkesztőt szeret a felkészítésre használni, mert a műveletek elvégzése sokkal egyszerűbb: erre készültek ezek a programok. Viszont a szövegszerkesztős anyagokból automatán generált HTML fájlok messze vannak az egyszerűtől és a letisztulttól! Mivel mi Word DOC-al foglalkozunk, elrettentésül álljon itt az a HTML-kód, amit a konvertálás DOC-ból készít:
és ebből valójában ennyi a PRC számára hasznos anyag:
Évekkel ezelőtt a Mobipocket fórumán jvoq által megosztott VisualBasic szkript adta meg a megoldást számomra a kényelmes Word felkészítés és a letisztult HTML-kód ellentmondására. Egyébként léteznek kimondottan HTML/XHTML optimalizáló programok is, viszont jvoq szkriptje nekem nagyon bevált, így ezek a programok nálam kimaradtak.
Volt az eredeti szkriptnek néhány hibája (például az üres sorok automatikus törlése), amit időközben kijavítottam, és ahogy gyűltek a szkriptre bízott feladatok, végül megírtam az ide is mellékelt utolsó változatot. Hogy nagyjából látható legyen mire képes, és előre tervezhető legyen a szövegfelkészítés, álljon itt egy korábban írt összefoglaló a szkript funkcióiról:
- a programrészek magyar kommentezése
- magyarázattal ellátott szkript-vezérlő konstansok bevezetése
- felhasználó választhat win-1250 és UTF-16 kódolású fájl között
- a <head>-be visszaírja a kódlapra vonatkozó meta-sort
- külön fájlból képes <style>...</style> stíluslistát visszaírni a <head>-be
- többsorba tördelt <h#> címsorok egyesítése
- a <p> és <h#> tag-ekben csak az align bejegyzést hagyja meg
- felhasználó által megadott width és height értékeket tud a <p> tag-ekbe írni
- az ismétlődő üres sorokat nem törli
- kitakarítja a style bejegyzéseket az <i>, <b> és <br/> tag-ekből
- a </span> cseréjénél nem szóközt használ, hanem tényleg töröl
- törli a <font> bejegyzéseket
- a képhivatkozásokból töröltethető a "./" relatív mappajelzés
- jelölőkarakter-párokat háromszintű <y#> tag-ekre képes cserélni
- felhasználó választhat, hogy felülírással vagy új HTML készítésével működjön
- felhasználó bekapcsolhatja az átmeneti állományok megőrzését
Mielőtt végigmennénk a legfontosabb szkript funkciókon és a javasolt DOC felkészítésen, tisztáznunk kell a legfontosabb korlátját is. A szkript az XHTML szabványnak megfelelően csak a kisbetűs tag-bejegyzéseket ismeri meg, például <body>. Szerencsére a Creator a DOC nyersanyagból ilyet készít, sőt a Word is ilyen HTML kimenetet készít, ha mentési formátumnak ezt választjuk (csak több szemetet rak a kódba, mint a Creator-os konvertálás). Ezzel szemben az OpenOffice - annak ellenére, hogy teljes mellszélességgel az XML mellett van - valami érthetetlen okból a HTML kimenetén nagybetűs tag-eket használ: <BODY>. Ez utóbbiakba a szkript belefagy. Tehát a szkriptes tisztítást használni mindig csak Word DOC-ból Creatorral készített HTML fájlokon lehet!
A szkript használata végtelenül egyszerű: rakjál egy példányt a Windows Asztalra, majd a tisztítandó HTML fájlokat a fájlkezelőből egyszerűen húzzad rá az ikonjára. A szkript ugyanabba a mappába fogja a tisztított változatot elkészíteni, amelyből ráhúztad a nyers fájlt. Többször ellenőriztem, hogy a hasznos szövegen semmit nem változtat, a szkript műveletei csak a HTML tag-eket befolyásolják, úgyhogy kárt nem okoz.
A szkriptbe beépítettem néhány választható funkciót, amelyek a kód elején kommentezve felsorolt konstansok átirogatásával szabályozhatóak. Ha a szkript ikonjára jobbgombbal kattintasz, akkor a menüből kiválaszthatod a "Szerkesztés" pontot, ami a szkript kódját jeleníti meg a Jegyzettömbbel:
A kód elején lévő felhasználói beállítások a következők:
1. Const html_overw = True Ez szabályozza az eredeti fájl felülírását. False érték esetén egy új eredményfájlt készít, amelynek a nevéhez egy CLEAN megjegyzést fűz. Ha a nyersanyagban - a Word szokásához híven - olyan képhivatkozások vannak, amely a *****-elemei mappára mutatnak, akkor nem szerencsés a HTML fájl nevének megváltozása, mert a fájl és a képeket tároló mappa összekapcsolása elveszik. Tehát alapértelmezésben a tisztítás felülírja az eredeti fájlt, így ha bizonytalan vagy a végeredményben, akkor vagy átírod ezt a kapcsolót, vagy készítesz a nyersanyagról egy biztonsági másolatot a tisztítás előtt.
2. Const unicode_html = True A későbbiek során szó lesz a betűkészletek és kódlapok környéki mizériáról. Most elég annyi, hogy a Creator legújabb változatai jobban szeretik az univerzális kiosztású Unicode kódolást, mint a Word DOC konvertálásából alapesetben származó windows-1250 kódlapú fájlokat. Alapértelmezett beállításban tehát a szkript a windows-1250 kódolású fájlból egy UTF-16 kódolásút készít. Ha ezt ki akarod kapcsolni, akkor a konstans értékét False-ra kell átírni és így a végeredmény windows-1250 kódolású marad.
Alapjában véve nincs szükség az UTF-16 konverziót kikapcsolni, de van egy speciális eset. A szkript csak windows-1250 kódolású HTML fájlokat fogad el bemeneti nyersanyagként. Tehát az egyszer letisztított és UTF-16-ra konvertált HTML újból nem "etethető meg" a szkripttel. Olyan esetben, amikor előre látod, hogy még későbbi futtatások is lesznek, érdemes megőrizni az anyagodat windows-1250-ben, és csak a legutolsó tisztításkor elvégeztetni rajta a kódlap váltást.
3. Const style_file = "C:/E-Books/header_styles.txt" A szkript gyakorlatilag kiüríti a nyers HTML fájl stílusokkal teleszemetelt <head> részét. A Word ugyanis nem képes megfékezni magát, ha betű- és bekezdés-sítlusokról van szó, csak nézzetek bele egy DOC-ból frissen készített HTML kódjába: percekig lapozhattok, mire a hasznos szöveg előkerül, annyi szemét van a <head> részben. Minekután a szkript kiszedi az eredeti stílusokat (és a szövegből is törli a ráhivatkozó class="..." attribútumokat), azok akik utólag a saját jól beállított stílusaikat szeretnék a HTML-ben használni, itt lehetőséget kapnak arra, hogy egy külső fájlból az összeállított stílus listájukat automatikusan bemásoltassák a végeredménybe. Gyakorlatilag a <h#> címsorok stílusának beállítására érdemes egyedül saját definíciókat használni, ugyanis hiába a definíciós lista automatikus bemásolása, ahol a szövegben használni szeretnénk a stílust, ott kézzel kellene a class="..." attribútumokat egyesével visszaírni. És ez rámutat egy fontos DOC felkészítési szabályra. Mivel a stílusoktól a szkript végleg megszabadítja a szöveget, minden olyan formázás, amit a Word-ben stílussal oldottunk meg, elveszik. Ha fontos az adott formázás, akkor mindig a Normál stílus megtartásával a szövegformázási funkciók (rendezés, dőlt stb. nyomógombok) használatával alakítsuk ki a kívánt képet, ne pedig egy "Sajátstílusom24" nevű egyéni stílusba legyen beledrótozva a beállítás!
4. Const pict_path_corr = True A régebbi Word-ök a képek hivatkozásainál a HTML kódban használnak egy "./" relatív mappajelzést. Az új Creator viszont így nem találja a képet, tehát aki hozzám hasonlóan csak Word2000-est vagy hasonlóan régi változatot használ, az hagyja itt a True értéket. Aki frissebb Word-del dolgozik az nyugodtan False-ra állíthatja, de azért tegyen egy próbát, hogy a PRC-ben megvannak-e a képei. Ha ugyanis eltűntek, akkor neki is ott van az a fránya mappajelzés a képek hivatkozásaiban, és a szkripttel ki kell szedetnie.
5. Const p_width = "0" és Const p_height = "0" Szó volt róla, hogy a width="..." és a height="..." speciális mobi attribútum szabályozza a bekezdések elsősorának behúzását és az első sor előtti szünetet. Tehát aki változtatni akar az alapértelmezett kinézeten, az itt adhatja meg a megfelelő értéket, amelyek szigorúan csak a <p> tag-ekbe kerülnek be, de kivétel nélkül mindegyikbe. (Viszont a címsorok <h#> tag-jeit nem befolyásolja.) A leggyakoribb egyéni akció természetesen a nulla értékek használata, ezért van a szkriptben ez alapértékként, de a macskakörmök közé mindenki olyan számot írhat, ami neki tetszik. Ha viszont egyáltalán nincs szükséged erre a két attribútumra, vagy a kettő közül egyikre, akkor eléírt "Rem" utasítással teljesen kikapcsolhatod. Ez azt eredményezi, hogy a kikapcsolt attribútumot egyáltalán nem írja bele a <p> tag-ekbe. Egyébként ez az alapállapota a szkriptnek.
6. Const sign1_start = "..." és Const sign1_end = "..." Magamnak kidolgoztam egy rendszert <y#> tag-ekkel a tartalomjegyzékbe kerülő szövegrészek megjelölésére. Nem részletezném a dolog működését, hiszen a korábban ismertetett címsoros eljárás egyértelműbb. Viszont mivel a Creator bármit elfogat TOC-készítésnél jelölésnek, ezért mi bármit használhatunk, akár egy szabványon kívüli új tag-et is. A saját megoldásom azon alapul, hogy a DOC felkészítés során a kijelölendő szövegrészek elejére és végére egy-egy jelölőkaraktert rakok (makróval, mi mással), majd a HTML elkészülte után a jelölőkaraktereket lecserélem az <y#> tag-ekre. Ez a beállító rész gyakorlatilag a jelölőkarakterek és az <y0> <y1> <y2> tag-ek összerendelését adja meg. Aki címsoros tartalomjegyzék generálást használ, nyugodtan "Rem"-ek beírogatásával kikapcsolhatja ezt a funkciót.
7. Const sign_brake = "˛" Ismét egy saját megoldás. A szkript nem képes megbirkózni a többsorra tördelt kódú Word szeméttel a HTML-ben, és az egyik ilyen az oldal- és szakasztörések HTML kódja. Tehát a szkript használata esetén kötelező még a DOC felkészítés során minden oldal- és szakasztörést törölni. Ha viszont mégis szeretnék egy-egy ponton laptörést a PRC-ben, akkor a szkript egy megfelelően(!) megválasztott jelölőkarakter helyére képes automatikusan az <mbp:pagebreak/> kódot írni. Mivel a csere úgy történik, hogy azt a <p> sort, amiben a jelölőkarakter megtalálható, a szkript <mbp:pagebreak/><p> </p> sorra cseréli, így a DOC felkészítése során szigorúan ügyelni kell arra, hogy a laptörés jelölőkaraktere csakis egy enterrel készített üressorban lehet! Ellenkező esetben ugyanis az adott sor teljes tartalma elveszik azzal, hogy a <p> </p> HTML üressora cserélődik. Természetesen a jelölőkarakter olyan legyen, ami a magyar szövegben (plusz görög és cirill betűk) soha nem fordul elő. A szkriptbe alapértelmezetten beállított kunkor egy ilyen karakter. Egyébként a funkció eléírt "Rem"-el kikapcsolható, ahogy az alapesetben is van.
8. Const save_temp = False A szkript futása közben két átmeneti állományt készít, majd töröl le. Ha hibakereséshez szükséged lenne az átmeneti fájlokra is, akkor ezt a konstanst írd át True értékre.
A szkript további kódjába természetesen mindenki belejavíthat, ha van egy kis Basic gyakorlata, a többiek inkább ne bolygassák. A kódot igyekeztem blokkokra bontani és kommentezni, hogy rajtam kívül más is eligazodjon benne.
A felsorolt felhasználói beállításokon kívül még maradt néhány javaslat és felkészítési követelmény.
Említettem, hogy a szkript lefagy a többsorba tördelt HTML kód esetén, így egy-egy fagyás alkalmával érdemes a szkript által érintetlenül hagyott tag-ekre gyanakodni, és a HTML kódban kézzel rendberakni. Az oldaltörések mellett még a <table> elemei hajlamosak ilyen fagyást okozni, ezért javasolt a táblázatokat tartalmazó fájlok tisztítása előtt a HTML kódban szép rendezett formára alakítani a táblázatok anyagát, és kitörölni belőlük a class, span és egyéb tölteléket. (Aki megvizsgál néhány kitakarított HTML-t, az tudni fogja mi a felesleg a táblázatok kódjában.) A biztonság kedvéért a táblázatok kódjának rendezése után a táblázatot mindig ellenőrizzük böngészőben is, nehogy egy-egy tag óvatlan törlése miatt szétessen a szerkezete!
A szkriptben használt keresés-cserék igen érzékenyek a szóközök darabszámára. A megfelelő működéshez mindenképpen el kell tüntetni a többszörös szóközöket a DOC-ból. A művelet még a szövegfelkészítés során a Word keresés-csere eszközével elvégezhető: két szóközt kell egy szóközre cserélni, és addig ismételni a "Mindet" cserét, amíg nulla találattal nem fejezi be a műveletet.
A mobi PRC-ben nem javasolt a betűszínt vagy a méretet lerögzíteni, de néha szükség lehet ilyen formázásra. Mivel a szkript automatikusan kiszedi az összes <font> tag-et, ha valóban lényeges betűformázás van az anyagban, akkor azt a tisztítás előtt kézi beavatkozással kell megvédeni a törléstől. Az adott pontokat még a tisztítás előtti HTML-ben meg kell keresned, és a nyitó <font ...> valamint a hozzá tartozó záró </font> tag-ekbe be kell írni valami "elrontó" karaktert például így: <#font ...> és <#/font>. A szkript így már nem találja meg ezeket a bejegyzéseket és a tisztítás után a <# kombináció keresésével-lecserélésével megszüntetheted a tag-ek védelmét.
Legvégül, általában is nagyon hasznos, ha a Word szövegfelkészítés során már egységes, következetes és letisztult anyagot készítünk. Tehát törekedni kell egyrészt az egyszerű megoldásokra, hogy a kipucolószkript minél kevesebb potenciális hibalehetőséggel találkozzon. Másrészt ugyanazok a formai elemek a teljes szövegben következetesen ugyanazzal a megoldással készüljenek, hogy a hasonlóság a HTML-kódban is megmaradjon, így segítve téged az eligazodásban és az utólagos HTML módosításokban.
Jelen esetben az ismertető letölthető csomagjában természetesen a kipucolószkript legutolsó változata is benne van.
"Elminster"
PRC gyártás házilag 1.rész - Javaslatok
PRC gyártás házilag 2.rész - Szövegjavítás
PRC gyártás házilag 3.rész - .prc1 - Bevezető
PRC gyártás házilag 4.rész - .prc2 - Konvertálás Creator-ral
PRC gyártás házilag 5.rész - .prc3 - Tartalomjegyzék alapfokon
PRC gyártás házilag 6.rész - .prc4 - Tartalomjegyzék megoldások
PRC gyártás házilag 7.rész - .prc5 - Szövegformázás
PRC gyártás házilag 8.rész - .prc6 - HTML tisztítás
PRC gyártás házilag 9.rész - .prc7 - Karakterek és kódlapokPRC gyártás házilag 10.rész - .prc8 - Képek kezelése
PRC gyártás házilag 11.rész - .prc9 - Linkek és jegyzetek
Feliratkozás:
Megjegyzések küldése (Atom)
Beépített PDF olvasó
Állítható a szöveg mérete
Autómatikusan forduló kijelző
1 megjegyzés:
A legjobb online eszköz Word dokumentumok HTML-lé alakítására és tisztítására www.html-cleaner.com.
Próbáljátok ki!
Megjegyzés küldése