U ovom će članku biti svega i svačega, no sve će biti povezano u jednu suvislu cjelinu. S obzirom da se radi o osobnom osvrtu, ovaj će članak iznimno biti pisan u prvom licu. Za one koji žele ukratko saznati o čemu se radi, bez da prvo pročitaju čitav tekst:

Počet ću s problemom koji me već godinama (da ne kažem par desetljeća) mučio, ali nisam imao volje, vremena, znanja (ni želje za stjecanjem potrebnog znanja) i/ili idealnu tehnologiju da bih ga riješio, sve do ove godine.

Kako stvari funkcioniraju?

Autori koji pišu za tiskano izdanje Buga članke predaju kao Wordove (.docx) dokumente, i to uvijek u paru, popraćene slikovnim datotekama i Excelovim (.xlsx) tablicama. Jedan dokument je "goli" tekst (bez korištenja stilova, tek s mjestimično boldanim ili ukošenim tekstom), s oznakama kojima se urednicima i grafičarima daje do znanja što je što u članku (NN> je oznaka za nadnalov, NA> za naslov, PN> za podnaslov>, INFOBOX> za okvir sa specifikacijama, OKVIR> za, već vam je jasno, izdvojeni okvir...) te s imenima datoteka za slike i potpisima za te iste slike (tekstom koji ide ispod slike).

• +1

Urednik prođe kroz taj dokument, uredi ga, ukloni oznake, pošalje ga lektoru, lektor ga lektorira i vraća uredniku, te onda taj dokument s pratećim datotekama ide grafičaru na prijelom - na slaganje članka u InDesigneu, na stranice budućeg tiskanog Buga. Taj dokument je "goli", da bi se izbjegli potencijalni problemi s copy&pasteanjem teksta u InDesign i CMS za online izdanje Buga, Bug.hr.

Usput rečeno, zapravo već niz godina članke započinjao sam pisati u Notepad++-u (besplatni, nezahtjevni editor izvornog kôda, s tabovima, bojanjem sintakse i još mnogo toga drugog), kao običan tekst, a kad su se članci polako počeli približavati kraju, tad sam to copy&pasteao u Word pa onda išao to oblikovati kako treba, podebljavati i ukošavati tekst, brisati sve ono što ne bi trebalo završiti u dokumentu kojeg ću poslati uredniku.

Drugi dokument je isti kao prvi, ali s ubačenim slikama, da urednik može eventualno reagirati na redoslijed slika ili možda koju izbaciti, te da grafičar ima jasni pregled koja slika ide u sklopu kojeg dijela članka i da vidi koji potpis ide pod koju sliku. Tu sad dolazimo do jednog od problema koji mi je izazivao frustracije. Kako imam lošu percepciju vremena i vrlo često "kreativnu blokadu", obično sve radim 5 do 12. I onda članak završim u 1 do 12 (a realno u većini slučajeva 12:15, ili možda tek drugi dan, što, zamišljam, izaziva pakleni bijes urednika). I taman kad ga završim, ne mogu ga poslati. Prvo ga je potrebno pročitati te provjeriti nema li kakvih grešaka (a u pravilu se uvijek nađe barem nekoliko) i kad je to gotovo, tek tada ide "veselje" - ubacivanje slika.

U čemu je problem?

To nije neki problem ako je članak kratak i treba ubaciti par slika. Ali ako treba ubaciti dvadesetak slika, pedesetak ili više slika, onda to postaje mukotrpan proces. Naime, slike treba ubaciti na pravo mjesto - iznad naziva datoteke za tu sliku u dokumentu. Tu sad ostaje pitanje koju strategiju odabrati - ubaciti sve slike u Word pa ih premještati ili cut&pasteati na pravo mjesto, ili to činiti s grupicama slika (recimo po jedna slika za svaki okvir) ili ubacivati jednu po jednu sliku u Word, odmah na pravo mjesto.

Čak i kad ih ubacite na pravo mjesto, to nije dovoljno - velikoj većini slika treba promijeniti veličinu (u pravilu smanjiti ih), jer se obično rasprostru po cijeloj širini stranice, što nam nikako ne odgovara. Pa onda mijenjamo veličine slika - sliku po sliku. Nekad slike imaju dosta "lufta" (bjeline, praznog prostora) s gornje i donje strane pa ih onda i obrežemo (cropamo) što dodatno oduzima vrijeme (bolje je to obaviti prije ubacivanja u dokument).

Znači, taman čovjek obavi najvažniji dio posla, iscrpljen i krvavih očiju, i skoro pa je spreman poslati članak uredniku, a tek tada ide naporno i dosadno ubacivanje slika u dokument. Netko će možda reći - pa zašto odmah ne ubaciš slike u dokument, kako radiš na članku? Na kraju krajeva, zar ne bi bilo bolje da su slike odmah u dokumentu, odnosno da ih autor ubacuje kako radi na dokumentu, jer tad ima bolji pregled nad cijelom situacijom?

I da i ne. S jedne strane dobijete bolji uvid u ono što radite, i ne ostavljate si ubacivanje slika za kraj, no s druge strane skrolanje kroz dokument je sporije, treba dalje skrolati. Ujedno, Word je time jače opterećen, a i .docx datoteke bit će daleko veće - možda će narasti i na više megabajta, ako ne obavite kompresiju slika u Wordu.

Situacija se u mom slučaju tu malo komplicira, jer svako malo datoteku spremim pod novim imenom. Naime, iskustvo iz prošlosti naučilo me da ne overwriteam dokumente nakon što sam napravio neku malo veću izmjenu - uvijek vam se može dogoditi da ste greškom obrisali neki komad dokumenta, a onda prepisivanjem preko postojeće datoteke ostajete bez toga, osim ako niste jako revni u backupiranju (ili si niste sredili nekakav automatski backup). Lakše je, kad ste gotovi s dokumentom, obrisati stare verzije s diska, nego čupati kosu kad shvatite da ste nehotično obrisali ili promijenili nešto što niste htjeli.

Malo ozbiljnije počeo sam se interesirati za rješavanje tog problema s ubacivanjem slika kad sam uočio da se u Markdown datoteke (.md), koje, primjerice, tipično možete vidjeti na GitHubu, mogu ubaciti slike. Tako sam stvorio .md datoteku u Visual Studio Codeu i u pretpregledu datoteke (dokumenta) dobio ubačenu sliku, uz naziv slikovne datoteke. Ali to jednostavno nije bilo to. Razmišljao sam mogu li nešto napraviti s .md datotekom, no sintaksa .md datoteka činila mi se groznom i problematičnom za ono što meni treba, odnosno za ono kako bih želio da stvari funkcioniraju. Stoga je ideja o .md datotekama stavljena na pauzu. Kako je ispalo, na trajnu pauzu, tj. u konačnici je odbačena.

To je sve?

A i nisu u pitanju bile samo slike. Htio sam imati i mogućnost dodavanja "bilješki" i linkova vezanih uz temu koju obrađujem. Prije je to išlo tako da sam sve to držao u dokumentu i onda prije slanja uredniku te stvari brisao iz dokumenta.

Nadalje, neke rubrike više zovu na Excel, nego na Word, kao što je rubrika Hardver - Noviteti pri početku Buga (interno je zovemo Sitni hardver). Naime, ta se rubrika sastoji od 8-9 opisa novih uređaja, tipično dugačkih nekih 300-700 znakova, opremljenih naslovom, nadnaslovom, slikom ili dvije (a često i četiri-pet, za online inačicu rubrike), cijenom i ustupiteljem. Preglednosti radi, to se čini zgodnije odrađivati unutar Excela, nego u Wordu, jer u jednom stupcu mogu imati sve vezano uz jedan proizvod. Također, kod te rubrike, slike nemaju potpise pa ih je u dokumentu sa slikama koji se šalje uredniku puno bolje smjestiti u tablicu s dva stupca, jer tada u većini slučajeva sve vezano uz jedan uređaj stane na jednu A4 stranicu papira. A ručno "gurati" slike u tablicu je naporno.

Još jedna stvar koja me mučila su "infoboxovi" - okviri sa specifikacijama testiranog hardvera (ili softvera), s istaknutim pozitivinim i negativnim karakteristikama, dojmom, cijenom i ustupiteljem. Excel se i za izradu, odnosno uređivanje specifikacija, čini boljim alatom od Worda, a i htio sam da ti okviri izgledaju slično kao u tiskanom izdanju Buga, jer je tako preglednije, pogotovo prilikom korekcija (provjeravanja je li u prijelomu stranica tiskanog izdanja Buga sve odrađeno kako treba).

I, skoro zaboravih - od autora se očekuje da iza svakog podnaslova navede koliko je dugačak u broju znakova, te se isto očekuje za tekst članka ili okvira. Te brojke olakšavaju urednicima i grafičarima da si bolje predoče gabarite poslanog im materijala, odnosno na koliko bi stranica poslani materijal mogao završiti u prijelomu. Znači, još jedna stvar koja se radi tek prije slanja dokumenata uredniku, a zapravo i prije ubacivanja slika - označiti podnaslov, pogledati u Wordovom status baru koliko je to znakova, te utipkati tu brojku iza podnaslova. Isto napraviti i s glavnim tekstom članka ili okvira, koji se možebitno prostire kroz nekoliko stranica.

Pomaže li piton?

Onda sam se prisjetio da sam nedavno odgovarao na pitanje forumaša, vezano uz .bat datoteke, i preporučio mu korištenje Pythona - programskog jezika, koji se interpretira, no može se iskoristiti i kao napredni skriptni jezik, znači može se koristi kao nešto poput basha pod Linuxom ili kao PowerShell skripta pod Windowsima. Tad o Pythonu nisam znao gotovo ništa, no prilikom odgovaranja forumašu, dovoljno sam upoznao komadiće Pythona da forumašu mogu dati konkretni savjet, konkretni kôd kojim će riješiti svoj problem. Dalje od toga tada nisam išao.

No, sad sam se zapitao - je li moguće pomoću Pythona stvoriti .pdf ili .docx datoteku, u koju bih programski ubacio slike (i to u prilagođenoj veličini, umjesto da budu razvaljene od lijevog do desnog ruba stranice)? Barem da si olakšam ubacivanje slika u Wordov .docx dokument, kojeg šaljem urednicima. Ispalo je da Python ima biblioteke za to - stvaranje i zapisivanje .pdf i .docx datoteka.

Što je s izvorom podataka? Excel, odnosno Excelove .xlsx datoteke, za to su se činile odličnim odabirom. To je kao da imate malu, vrlo fleksibilnu bazu podataka (ili barem tablicu unutar baze podataka), koju je vrlo lako uređivati, a mogućnost kalkulacija dobrodošao je bonus - dio toga može odraditi sâm Excel, umjesto da sve visi na Pythonu. Pogledam može li Python čitati .xlsx datoteke - može! Super.

Inicijalno sam htio urednicima slati PDF-ove umjesto .docx datoteka sa slikama, nadajući se da će se prilikom konverzije u .pdf datoteku slike ujedno komprimirati. Stoga sam tražio biblioteku za koverziju .docx u .pdf, a prva koju sam našao, za to je iskorištavala Word, te bi prilikom pokretanja prvo (nasilno) zatvorila Word pa pokrenula konverziju. To mi se nikako nije dopalo. Tako da sam odustao od PDF-ova i odlučio ipak stvarati .docx dokumente s ubačenim slikama. Što s veličinom slika (njihovim zauzećem)? To sam ostavio za rješavati poslije - ako ne iznađem neko drugo rješenje, prije slanja dokumenta mogu reći Wordu neka komprimira ubačene slike.

Što sad s .docx dokumentima? Zar ću ih ručno, programski graditi? Isprva sam tako i počeo, no to se činilo jako nepraktičnim. Zar ne bi bilo bolje kreirati si nekakav .docx predložak pa da se onda samo pomoću Pythona taj predložak ispuni potrebnim podacima, potrebnim sadržajem? Potražim postoji li biblioteka za to i - vid' vraga, postoji!

Sad se već počinje činiti da bi cijela stvar mogla uspjeti. Naravno, uz ulaganje puno truda i vremena, s obzirom da sam se sa svim tim prvi put susreo.

Predlošci za dokumente

I tako je prvo krenulo s malim skriptama napisanima u Pythonu, koje otvaraju .xslx tablice s opisnim podacima, tekstom, nazivima datoteka za slike (i eventualno potpisima slika) za rubriku Noviteti te za veliki usporedni test USB-C hubova. Tim podacima punilo se .docx predloške.

Tu je nastao problem - biblioteka za .docx predloške (python-docx-template) omogućavala je kreiranje jednog .docx dokumenta iz jednog predloška. To bi značilo da bi se za rubriku Noviteti kreiralo 8-9 dokumenata, koje bi onda trebalo spojiti u jedan. Ručno? To bi bilo vrlo nezgodno i smanjilo bi ugodu korištenja. Kako dalje?

Otvorio sam korisnički račun na GitHubu kako bih autora biblioteke pitao kako višestruko izrenderirati isti predložak, ali da sve ide u istu .docx datoteku. Javio se isti dan, no s odgovorom da se to ne može i predložio da koristim for-petlju unutar .docx templatea. Iako bi se možda moglo riješiti na taj način, to je zapravo loš pristup, jer se onda ta problematika premješta u svaki template kojeg bi čovjek želio koristiti (a trebaju mi različiti templateovi za različite vrste članaka, i još k tome dva templatea za svaku vrstu članka - jedan čisti, samo s tekstom, drugi vizualno napredniji, da barem donekle sliči izgledu članka u tiskanom Bugu, obogaćen slikama). Umjesto toga, to bi trebalo biti riješeno unutar Python skripte (programa).

Ipak nisam odustao - ostavio sam to polu-rješenje za slučaj da ne uspijem riješiti onako kako sam zamislio. Guglanjem sam pronašao biblioteku koja bi trebala omogućiti spajanje .docx datoteka putem klase Composer. Kako sam u to vrijeme još bio početniku u Pythonu, a i početnik u korištenju tih biblioteka koje su mi trebale, nisam baš bio u najboljoj poziciji da iznađem rješenje. Krenuo sam nabadat - Composeru sam "podvalio" objekt za renderiranje templateova, umjesto putanja do izredneriranih .docx datoteka na disku. I stvar radi! Čak sam onda to svoje rješenje postao na GitHub, u temu u kojoj sam postavio upit, da i drugi znaju kako to napraviti.

Programski kôd

Prvo je sve bilo proceduralno izvedeno i funkcioniralo je tako da sam različite, prilagođene .py skripte vukao unutar iste rubrike iz mjeseca u mjesec. To je onda značilo da, ako sam napravio neka poboljšanja u skripti za rubriku Noviteti, to isto morao sam prekopirati u skriptu za rubriku Pitanja i odgovori, a i za druge rubrike.

Stoga sam odlučio većinu svog tog kôda nagurati u dijeljenu biblioteku, a da za svaku rubriku ili članak imam tek manju skriptu, koja će služiti za određivanje vrste sadržaja (rubrike), kako bi se koristili ispravni templateovi, te još ponešto.

Ujedno sam onda odlučio svoj kôd prebaciti iz proceduralnog stila u OOP (objektno orijentirani), da iskoristim koncept nasljeđivanja. A i zato što volim OOP, jer se u toj paradigmi definiraju "ponašanja" objekata - objekte inicijalizirate, povežete i "pustite" ih da međusobno komuniciraju. Pustite ih nek' žive.

Ono što nije funkcioniralo su stilovi fonta - podebljani (masni, bold) i ukošeni (kurziv, italic) tekst. Naime, kad tekst pišete u Notepadu ili Notepad++-u, nema boldanja, nema italica, s obzirom da je u pitanju obični tekst. Kako onda do toga? Ispada da klasa za .docx templateove za oblikovanje traži rich text ("bogati tekst"). To sad znači da treba ručno brljati po običnom tekstu - treba ga cijepati na dijelove istog stila i potom ručno na kraj rich texta dodavati pojedine dijelove teksta pritom zadajući odgovarajuće oblikovanje. To je tako na "izlazu", no postavlja se sad pitanje kako označiti u tekstu što treba biti podebljano, što ukošeno.

Tu sam se odlučio na (prilagođene) html tagove, nakon što sam prokužio kako radi HTML parser (klasa za vađenje HTML tagova iz teksta). Tako, ako želim da mi u tekstu nešto bude podebljano, stavim standardne oznake <b>podebljani tekst</b>, a po istom principu riješio sam ukošeni i podcrtani tekst.

Također, tu je i tag <p>, koji se može, ali i ne mora zatvoriti, a koji označava odlomak (isto kao stisak Entera, kad tekst pišete u Wordu), ali i <br>, za prelazak u novi red, ali bez stvaranja novog odlomka (isto kao da ste u Wordu pritisnuli kombinaciju tipki Shift+Enter). Imam još i tag <mt>, koji označava međunaslov (bio je posebni problem s implementacijom toga u templateovima, jer sam htio da bude ispisan većim fontom u crvenoj boji).

Nije izostao ni tag <code></code>, mada njega treba doraditi. Jedan od posebno korisnih tagova je <ignore></ignore>, koji znači upravo to - sve ono što je unutar tog taga, bit će ignorirano, odnosno neće biti uključeno u izrenderirane .docx dokumente - posebno korisno za stavljanje dodatnih informacija uz tekst na koji se one odnose, korisno za bilješke, ideje, tekst o kojem razmišljam hoću li ga uključiti ili ne, korisno i za linkove, ako ih neću staviti u članak za tiskano izdanje, ali hoću u online verziju članka na Bug.hr-u. Svaki od tih tagova mogu se ubaciti u određene ćelije u Excelu ili unutar pojedinačnih html datoteka koje uređujem Notepad++-om.

Drugi elementi

Prije spomenuti tagovi tiču se oblikovanja teksta. No tu je i niz drugih tagova, kojima se definiraju metapodaci ili dijelovi članaka. Oni se pišu isto kao html tagovi unutar pojedinačnih html datoteka, no u Excel tablici, oni se upišu u prvi stupac tablice, pa onda služe kao "ključ", odnosno onda na vrijednosti u tom redu gledam kao na "polja" (u bazi podataka).

To su tagovi poput article_type (vrsta članka), category (kategorija - recimo, "Videonadzor" u zaglavlju stranice Buga), topic (tema napisana u zaglavlju, nakon kategorije - recimo naziv uređaja ako se radi o recenziji), title (naslov članka - jasno samo po sebi), subtitle (podnaslov članka), question i answer (pitanje i odgovor, ako se radi o rubrici Pitanja&Odgovori), text (tekst članka), author (autor), badge (značka, odnosno nagrada koju dobije neki uređaj, na primjer Bug preporuka) te img (slika, odnosno slike).

Za slike odstupio sam od standardne HTML oznake, jer mi je praktičnost bila prioritet. Tako slike definiram na ovaj način:

<img>slika.jpg|<b>Podebljani dio potpisa</b> ostatak potpisa</img>

Tako to izgleda kad pojedini članak ili okvir pišem unutar html (ili bolje reći "html") datoteke. Slike se u pojedinačnim html datotekama samo nižu jedna za drugom, negdje unutar dokumenta.

Za razliku od definiranja slika u pojedinačnim html dokumentima, unutar Excel tablice, umjesto taga img, koristi se tag (možda bolje reći "polje") images, s tim da se u prvi redak sa slikama stavi tag images/, a u posljednji redak sa slikama tag /images (jedan otvara blok redaka sa slikama, drugi zatvara).

Također, unutar Excela postoji i tag (polje) external_text. To je ostavljeno za usporedne testove uređaja, gdje kraći opisi idu izravno u ćeliju u Excelu (u polje text), a za dulje opise specificira se vanjska html datoteka, koja se uređuje u Notepad++-u (ili nekom drugom editoru kôda).

Infoboxovi

U Excel datotekama koje služe za infoboxove, koje najčešće koristim za recenzije hardvera (iako se mogu iskoristiti i za recenzije softvera), također postoje i polja poput product_name (naziv proizvoda koji se recenzira), plus i minus (pozitivne i negativne karakteristike uređaja), impression (dojam o uređaju), sold_by (ustupitelj - navodim samo oznake ustupitelja, odvojene zarezima, a puni naziv, web-stranica i, eventualno, telefonski broj, "čupaju" se iz druge Excel tablice, koja sadrži te podatke o ustupiteljima čije sam uređaje dosad testirao).

To polje sold_by posebno je korisno kod rubrike Hardverski noviteti, za slučajeve kad je potrebno navesti pet-šest ustupitelja, s njihovim web-stranicama, te odvojiti ih točkom sa zarezom - uvelike olakšava unos tih podataka.

Infoboxovi ujedno sadrže i tehničke specifikacije uređaja i dodatne informacije. Kako je sve to jako varijabilno, ovisno o vrsti uređaja (ili vrsti softvera), postoji još jedno polje koje se može prostirati u više redova, kao što je to polje images. U ovom slučaju to je polje infobox (infobox/ otvara blok redaka, /infobox zatvara). Da bi se odvojile vrste specifikacija od vrijednosti, u drugi stupac u Excelu upisuju se vrste specifikacije (primjerice Oznaka brzine, Bežična povezivost..., Dimenzije i masa, Jamstvo, Cijena), a u naredne stupce konkretne vrijednosti tih specifikacija. Dakle, govorim u množini - jedna Excel datoteka može sadržavati puni infobox za jedan uređaj, ali i za 25 uređaja, ako treba, što je vrlo korisno kod usporednih testova (većeg broja uređaja).

Infoboxovi ponekad sadržavaju piktograme - male, jednostavne sličice, najčešće popraćene nekim kratkim podatkom, koje vam nastoje prenijeti neku informaciju. Kod velikog usporednog testa USB-C hubova piktogrami su u tablici bili definirani tako je za svaki piktogram navedena odgovarajuća slikovna datoteka u jednom retku i onda podataka koji piše uz tu sliku u retku ispod, a blok piktograma ograničen je bio poljima pgm_first i pgm_last. To je bilo tako u začetku, trenutna verzija programa u Pythonu ne podržava piktograme, no implementirat ću ih, samo na malo drugačiji način, kad budem idući put radio veliki usporedni test uređaja. Bez ovakve automatizacije ubacivanje piktograma je naporno i podložno greškama.

Kompiliranje

I tako, kad je pripremljena osnova (početna skripta u Pythonu, u kojoj se definiraju nazivi datoteka, putanje i još ponešto), kad su sve datoteke (jpg, png, html) smještene u odgovarajuće mape i ispravno imenovane, jednostavno se dvoklikne na .py skriptu, i ako je sve bilo dobro napravljeno, rezultat su dvije .docx datoteke, oblikovane točno onako kako ih treba poslati uredniku.

Ako se "ne pojave" ili zamijetim blok debug informacija u naredbenom retku koji se ekspresno zatvori, znači da negdje postoji neka greška. Najčešće se radi o pogrešno imenovanoj datoteci, ili nisam spremio ažuriranu Excel tablicu ili html datoteku, ili kod kasnijih pokušaja renderiranja u Wordu imam već otvorenu izrenderiranu datoteku, koju nije moguće prepisati prije nego li se ona zatvori u Wordu (on je "zaključa"). Tu onda obično otvorim naredbeni redak pa pokrenem skriptu iz naredbenog retka, odnosno terminala:

py naziv_skripte.py

pa onda dobijem bolji uvid u to koji je stvari uzrok greške. Uklonim uzrok, ponovno pokrenem tu naredbu (najlakše samo stisnuti tipku za gore u terminalu i pritisnuti Enter).

Zatim dvoklikom u Exploreru u Wordu otvorim .docx datoteku sa slikama. Ako sam u terminalu, onda za to koristim naredbu:

start "ime datoteke - Sa slikama.docx"

Provjerim je li sve OK. Ako nije, vratim se u Notepad++ korigirati ono što nije OK. Kad sam pri kraju s člankom, u Wordu provjerim pravopis, ispravim greške u Notepad++-u, spremim promjene, ponovno izrenderiram, provjerim i, ako je to to, .docx datoteke iskopiram u mapu sa slikama, zazipam, uploadam na Google Drive i uredniku pošaljem link za preuzimanje. I taj dio priče je završen.

Korekcije članaka

Kad to prođe kroz urednikove i lektorove ruke, kad grafičar prelomi, kad se bliži zaključenje broja tiskanog izdanja Buga, od urednika primim PDF datoteku s prelomljenim člankom. Na meni je da je detaljno pregledam, označim korekcije, odnosno što treba ispraviti u prelomljenom članku (korekcije radim u Adobeovom besplatnom Acrobatu) te pošaljem PDF datoteku s korekcijama natrag uredniku, koji će to proslijediti grafičaru i poslije se uvjeriti da su tražene korekcije doista i učinjene.

Ako je u pitanju vrlo velik članak, onda može doći i do nekoliko "loptanja", jer se i od autora članka tada traži da se uvjeri da su sve korekcije ispravno unesene. I kad više nema uočenih grešaka, kad se broj Buga zaključi, on ide u tisak.

Što dalje?

Hoću li ovo još dalje nadograđivati - ne znam. Možda usput, ako mi zatreba neka funkcionalnost koju program zasad nema. Svodi se na omjer uloženog i dobivenog - ako bi mi neka nova funkcionalnost uštedjela u budućnosti puno vremena ili značajno olakšala posao, onda bih je implementirao, pod uvjetom da to ne traži previše vremena (kako na istraživanje, tako i na programiranje, odnosno implementaciju).

Neki očekivani korak dalje bio bi pretočiti sve to u web-aplikaciju, no moram reći da mi se sviđa ovako kako stvari trenutno funkcioniraju, kad članke mogu pisati u Notepad++-u ili nekom drugom običnom editoru izvodnog kôda (vrlo malo zauzeće memorije, izvrsne performanse, autosave, bojanje sintakse olakšava snalaženje, okviri su odvojeni od glavnog teksta time što su spremljeni u zasebne datoteke), te ujedno sve je lokalno, bez potrebe za web-serverom. Sve što treba je editor kôda, Python uz nekoliko biblioteka, te neki Office za dokumente i tablice.

Jedino što bih još volio imati je "nešto" za brzi pregled i (skupno)uređivanje slika, ali specifično prema mojim potrebama, da mogu vrlo brzo obrezati (višak bjeline, posebno poželjno je obrezivanje jpeg datoteka bez rekomprimiranja) ili "proširiti" slike (ako je proizvod skroz do ruba slike, potrebno je dodati male margine), da mogu jednim klikom smanjiti sliku na 50% ili 25% veličine, da mogu obaviti specifična preimenovanja datoteka i tako neke stvarčice. No, takve stvari će pričekati neka bolja vremena - kad ne budem imao ništa pametnije za raditi.

A vi?

Ako ste preživjeli ovaj članak, voljeli bismo i od vas u komentarima čuti automatizirate li svoje zadatke, što automatizirate, kako, čime automatizirate, a ako još to niste radili, što biste htjeli automatizirati, kad biste bili u mogućnosti to učiniti.