A szoftverházak között nagy a konkurenciaharc. Ennek az az eredménye, hogy a felhasználó jó néhány alkalmas szoftvert találhat, amennyiben meg tudja fogalmazni igényeit. A csúcsszoftverek minõsége gyakorlatilag kifogástalan, a megvalósítandó feladat is adott, érdemes tehát elgondolkozni, mielõtt áttérünk egy jobbnak mondott, vagy újabb verzióra, érdemes-e csak a reklámnak engedve eldobni bejáratott programjainkat egy verziófrissítés miatt, vagy áttérni a legaktuálisabb konkurens termékre. A válasz az esetek 80 százalékában nem, hiszen ha összehasonlítjuk egy téma három-négy piacvezetõ termékét, általában nem találunk figyelemreméltó különbségeket.
A kiadványszerkesztés érdekes kivétel. Itt is dúl a háború, tehát van bõven választék, de a vezetõ szerepet játszó cégek nem egymás leutánzását és túllicitálását tûzték ki célul, hanem mindegyik halad a maga egyéni útján, saját elképzelései szerint fejlesztve programjait. A vezetõ kiadványszerkesztõk használata, logikája alapvetõen különbözik egymástól, ezért a rangsorolás majdnem lehetetlen. Érdemes kipróbálni egy-egy alkalomra a QuarkXPress-t, a PageMaker-t és a PC-s Ventura-t. A felsorolt programok teljesítménye gyakorlatilag azonos, mégis fanatikus hívei vannak egyik vagy másik szoftvernek, akik semmi pénzért nem térnének át a konkurens termékre. A következõkben tehát nem a QuarkXPress-hívõket szertném rábeszélni a PageMaker-re, hanem inkább a döntés elõtt állóknak szertnék segítséget adni.
Megszokhattuk, hogy legalább évente, de néha sûrûbben hibajavításra kerül sor minden egyes témában. A PageMaker elõzõ verziója 1990-ben került forgalomba, és egészen a QuarkXPress megjelenéséig nem volt szükség verziófrissítésre, hibajavításra. Tökéletesen mûködött, kiadványszerkesztõ létére irodai szövegszerkesztõket megszégyenítõ funkciókat építettek bele, mint pl. gyors szövegelõállításra egy külön szövegeditort, amit Story Editor-nak neveztek el, önálló táblázatkészítõ modult (Table Editor), automatikus tartalomjegyzék- és tárgymutató generálás, ha a könyv fejezeteit más-más filek-ba mentettük, automatikusan összeszedte õket, új oldalszámozás, tartalomjegyzék- és tárgymutató frissítés után képekkel együtt nyomtatta ki a kész könyvet, színes printelés nem PostScript printeren is, hibátlan import- és exportfilterek, stb.
Az 5.0-ás verzióra csakis azért volt szükség, mert általános igényként jelentkezett a színrebontás. Ezt a funkciót is sikerült elsõre, tökéletesen megvalósítani, ami azért nem volt kis feladat, mert a grafikai-tipográfiai munkára alkalmasnak kikiáltott operációs rendszerek nem fejlõdtek együtt a szakma igényeivel. Amióta megjelent a PM5, a Quark négy verziófrissítésként reklámozott hibajavítást ért meg (3.1, 3.11, 3.3, 3.31). A grafikus operációs rendszerek tipográfiai pontatlanságával gyakorlatilag nem lehet mit kezdeni, itt gondolok arra, hogy a betûméret soha nem lesz annyi a kimeneti egységen, mint amennyit a programban definiáltunk, de errõl nem az alkalmazás tehet. (Hibátlanul elkészített betûkészlettel az eltérés jelentõsen csökkenthetõ!) Ami megoldható, az a kiadványban alkalmazott objektumok, -képek szövegek- pozícójának pontos megjelenítése és printelése. Ennek viszont nagy ára van: újra kell írni a printertámogató modult, és a pontos képernyõs megjelenítésre sem használhatóak a rendszerszintû objektumok, erõforrások. Egy-egy jól mûködõ programban tehát újra kell írni a feladatot érintõ, a rendszerben egyszer már meglévõ de pontatlansága miatt használhatalan erõforrásokat. A PM lemezein ezért saját printerdefiníciós fájlokat találhatunk, amit csak PostScript printelés esetén indokolt telepíteni, márpedig a PostScript a színrebontás feltétele, tehát kötelezõ. A PM nagyon érzékeny a printertámogató szoftvermodulra. ha nem a sajátján kersztül, hanem pl. printerhez vagy a rendszerhez adott modulon keresztül akarjuk használni, figyelmeztet, majd csodálkozhatunk a végeredményen. Ha viszont élünk a lehetõséggel, és telepítjük a PM PostScript printerjét, semmilyen problémánk nem adódhat, mivel ezzel a modullal a többi program is nagyszerûen együttmûködik. (A grafikis felület alatt általában csak egy PostScript printertámogatás van üzembe helyezve, ami printelés elõtt az alkalmazásban megjelenik, csak egy olyan fejléc, ahol pl. papírméretet és más apróságokat definiálhatunk át, a kiválasztott printer típusától függõen más-más lehetõségeket kapva. A munka közbeni rendszerelszállásokat nem programhiba, hanem jellemzõen az alkalmazott betûkészlet hibája okozza. Jellemzõ a printelés során a sikertelen TrueType - PostScript konverzió, ugyanis a TrueType betûkészlet alaphelyzetben nem printelhetõ PostScript-en, konverzióra van szükség, ami a kiválasztott printermodul feladata. Mivel a hibát nem a printemodul hanem az alkalmazott betû okozza, megoldás az Adobe Type 1 betûkészlet használata, ahol nincs szükség konverzióra a printelés során, így a printelés ideje drasztikusan csökkenhet, a rendszer stabilitása pedig mind a szerkesztõi-tördelõi munka, mind a printelés során helyreállhat.
A PM elsõre olyan funkciókat tartalmazott, amelyeket a megjelenés idejében még nem feltétlenül indokoltak a piaci elvárások, mégis a fejlesztõk, mintha látták volna a jövõ igényeit, beépítették azokat a programba. Ilyen pl. az, hogy a Pantone, vagy más direkt színskála elemeit nem konvertálja a program CMYK-vá akkor sem, ha az az importált grafikával vagy képpel jön. (A Quark esetében erre elég sokáig kellett várni.) A felhasználót elársztó többi szolgáltatás is valószínüleg aktuális lesz, csak ki kell várni az idejét. Ide sorolandó a nem-PostScript-es színes printelés, valamint az egymást takaró színes szövegek színrebontása, és az, hogy az oldal objektumait egy hasábon belül is körül lehet folyatni mind a négy oldalon, ezért ez a szabadon definiált keretekkel is mûködik. A beimportált grafikát és képet a dokumetum szerves részévé tehetjük, így az eredti kép a tördelés után törölhetõ, így mozgatásnál nem kell a képfile-kal foglakozni, plusz az elõzõleg már említett funkciók, amelyek egyenlõre hiányoznak a konkurens termékekbõl.
Vizsgáljuk meg a program használatát, a konkrét munka során. Elõször is nagyobb a káosz a menüpontokban és a dialógusboxokban mint máshol, hiszen a sok funkciót el kell valahonnan érni. A PM a Quark 3.0 után adta ki 5.0-ás verzióját, ezért a lebegõ eszközök sokoldalúbbak, pl. a "Measurement" funkciójú palettán nem csak a betûtulajdonságok, hanem a bekezdések összes fontos jellemzõje is beállítható, egészen a stílusok kiválasztásáig. A képek és szövegek nem dobozokba, hanem rolószerû vonalak közé helyezhetõk el. Egy ilyen rolón (reluxán) már nem alakítható ki tõbb hasáb, de ezek egynként szabadon elhelyezhetõk a hasábolt oldaltükrõn. Az említett befoglaló objektumokat nem kell külön létrehozni, hanem a kép vagy szövegimport során automatikusan keletkeznek. Ha a kurzort az oldaltükör sarkába tesszük, billentyûkombinációkkal dönthetõ el, hogy a szöveg átfolyhat-e a következõ oldalakra is, ha nem, létrehozza-e a hiányzó oldalakat. Ha az import során a kurzorral boxot húzunk, az behatárolja a szöveg vagy képblokk méreteit, amely természetesen utólag szabadon módosítható, szöveg esetén tovább láncolható. A módszer elõnye, hogy az oldaltükör alját jelzõ utolsó sor alapvonala akár az alsó margó is lehet, (mindig annak kéne lennie) de ettõl a Quark óta elszoktunk, ugyanis a szedésmagasságnyi Quarkos szövegdobozba, amely pont az alsó margóig ér, már nem fér bele az utolsó sor. Hátránya, hogy a befoglaló rolóknak nincs kerete, nem lehet pl. egy kép köré, a képpel együtt mozgó és méretezõdõ keretet definiálni, azt sajnos külön kell ráhúzni. Ez ugyan csoportba foglalható és így együtt mozgatható a képpel, de nem méretezhetõ vele. Mivel nincs külön eszköz a befoglaló objektumok létrehozására, a PM eszközeivel csak szöveg és képfüggetlen kereteket alakíthatunk ki. Az úszópaletták gyakorlatilag azonosak a Quark-éval, ill. a dokumentum oldalakat a képernyõ alján lévõ vékony sorban tudjuk léptetni, ezért nincs Document Layout. A mesteroldal is a PM találmánya. Az itt elhelyezett objektumok a dokumentum oldalakon már nem módosíthatók. A program hajlandó "megenni" egy olyan ASCII szövegfájlt, amelyben a megfelelõ szabályok szerint definiálták az összes betû és bekezdés-tulajdonságot. Így a szövegimport után egybõl komplettre formázott, kész dokumentumot kapunk (egy ASCII szövegszerkesztõ termelékenyebb és olcsóbb mint a PM). A munkaasztal, így a munkaasztalon elhelyezett képek sem vándorolnak a dokumentum oldalakkal, mert a görgetés hatására a papírokat nem áthúzzuk a munkaasztalon hanem "lapozgatjuk".
Érdekes lehet a kiadványszerkesztõ kiválasztásánál az a szempont is, hogy a program mennyi szabad kezet ad a tördelõnek a munka során. A Ventúra egy nyûgös öreg vénlány, annak ellenére, hogy a Corel átrendezte a felületét. A Quark teljesen kritikátlan, "amit csinálsz azt kapod" stílusban mindent elsõre megenged, és végrehajt. A PM a kettõ közötti kompromisszum. Nagyon kevés a programban a megkötés, ezek is a tipográfia és a grafika szabályait szolgálják. Ennek ellenére elég nagy alkotószabadságot biztosít ahhoz, hogy a felhasználó ne érezze úgy, hogy a program az orránál fogva vezeti, és csak azt hajlandó végrehajtani, amivel "õ" (a program) is egyetért.
A PM nagy elõnye a szolgáltatásaiban és hibátlanságában nyilvánul meg. Ennek nagy ára van, és ezért a program ma (még) nem piacvezetõ, csak a második helyen "kullog" a Quark után. Az újraprogramozott, és ezért hibátlanul mûködõ, egyébként rendszerszintû feladatok miatt a program sokkal nagyobb, lomhább mint hanyag fiatal testvére. A termelékenység pedig ma fontosabb szempont mint a minõség. A PageMakert gyártó Aldus céget megvette az Adobe. Ismerve az új tulajdonos profizmusát, a következõ verzió komoly kihívást jelenthet minden hasonló terméknek. Különösen azért, mert az Adobe így egy komplett DTP csomagot kínál majd. Ha a PageMaker meg tudja elõzni a Quarkot, akkor az Adobe a maga piacán éppoly egyeduralkodó lehet, mint amilyen gigász a Microsoft.
8 új film egyben
-
egyszerre készült el 8 új film, amiben a Metró felüetet akartam részletesen
bemutatni. Így utólag nem látom értelmét, mert a Metró felületet a külső
alkalm...
11 éve