PageMaker 6.0

Nem is olyan régen dicsértem a PageMaker 5.0-ás verzióját, és már itt is van a 6.0, amit az ADOBE magyarországi disztribútorától kaptam kölcsön tesztelésre. Jelenleg még csak egy béta tesztverziót kapnak a forgalmazók, de a PM-et gyártó Adobe már most bejelentette, hogy aki `95 július 17 után vett 5.0-ás verziót, az ingyen megkapja az újat. Ez roppant szimpatikus, mert manapság a verziófejlesztéseknek csak az a lényege, hogy minél gyakrabban húzzák ki a vevõk zsebébõl a szoftver árát. Vagy csak lényegtelen külsõségeket alakítanak át, vagy ingyen járó hibajavításokat hajtanak végre. A program végleges verziója a hamarosan megrendezésre kerülõ APPLE Expo-n megtekinthetõ, vagy beszerezhetõ a viszontforgalmazóknál. A program új verziója igazi profi alkotás, amely a felhasználóról is feltételezi ugyan ezt, pl. a szóhasználata, vagy a nyomdaipart és a tipográfiát egyedülállóan támogató lehetõségei miatt. A 6.0-ás verzió szakmai újdonságai, -és itt a tördelõkre gondolok nem a számítógépes szakemberekre- a DTP piac legkiválóbb termékévé emelik a PM 6.0-át, és gondolva az elõzõ verziókra, bizonyára évekig az is marad, nem kell gyakorta újabb hibajavításokat vásárolni. Ez majd persze a végleges verzióra igaz, egy béta teszt nem lehet hibátlan.

A szoftverrel kapcsolatban nyugodtan lehetnek elvárásai a felhasználónak, nem fog csalódni. Nekem is volt bõven, mert a program kézhezvétele és a tesztelés között eltelt több mint három nap. Ez azért probléma, mert volt idõm gondolkodni a dolgon, és szép számmal alakultak ki kételyeim és elvárásaim a programmal kapcsolatban. Sõt elõre elolvastam a leendõ kézikönyvet is, amit csak utólag, vagy problémák esetén szoktam tenni azért, hogy véleményemben ne befolyásoljon a gyártó szándéknyilatkozata.

Azért kételkedtem az új verzióban, mert a PM-et eddig gyártó ALDUS-t megvette az ADOBE, és az ADOBE-nek eddig nem volt kiadványszerkesztõ programja. Féltem hogy a PM beQuarkosodik, és elveszíti egyéniségét, amely nekem roppant szimpatikus. Felmerült bennem, hogy az amúgy is lassú PM újabb verziója csak multiprocesszoros PowerPC-n, min. 32 MB RAM-mal fog elindulni, mert manapság az a tendencia, hogy az új verziók alá új gépet kell venni. Gondoltam ezt a rendkívül lassú volt ALDUS termék, a FreeHand legutóbbi verziója alapján is. (Ez persze nem mindig volt így, valaha a verziófejlesztés kisebb, gyorsabb, hibátlanabb programokat hozott...) Gondoltam ezt azért is, mert a program CD lemezen jelent meg, és a gyártó szerint nincs rajta minden modul! Féltem, hogy az ADOBE, -az egyéb termékeinek reklámot csinálva,- televágja a PM-et Illusztrátorban és Photoshop-ban megszokott vagy alkalmazott effektekkel, módszerekkel. Ezeknek nem tudok örülni, mert szerintem azoknak a célprogramoknak van alternatívája, amelyek csak egy dolgot tudnak, (pl. tördelni) de azt hibátlanul és hiánytalanul. És végül féltem a manapság eluralkodó káosztól, amely a gyakorlatlan felhasználókat gyakran zsákutcába juttatja a program használata során. Állítólag egy átlagember max. 7 dolog között tudja egyidõben átlátni az összefüggéseket, amely ha mindig csak két dolog kapcsolódik egymáshoz nem is olyan sok, ha több, akkor már baj lehet. Az ADOBE Photoshop 3.0-ás verziójában elég nagy a kavarás, ott túllépték a káoszhatárt a fejlesztõk. Szerencsére ezeket a kételyeket már a béta verzió is eloszlatta, bízhatunk tehát a végleges verzió hibátlanságában.

Voltak is bõven elképzeléseim a hibátlanságra és a hiánytalanságra vonatkozóan. Elõször is, szerettem volna, ha kevesebb programozástechnikai virtuozitást, és több tipográfiát látok a programban, mint a konkurens termékekben. Vajon kommunikálnak-e a programozók azokkal, akik szakmájuk miatt használni fogják a programot? Éppen ezért szerettem volna, ha a betûméretek végre értékelhetõ pontossággal jelennek meg, tudván, hogy ennek a pontossága (elnézést... pontatlansága) rendszerszintû hiba, nem a program okozza. Elvártam továbbá, hogy a PM felejtse el a Panose FontMatching Systemet, mert részint 70%-ban téved, részint 10 percekre növeli a dokumentum megnyitásának idejét. Ez a rendszer tenné azt, hogy ha a munkát elvisszük egy másik gépre, az új rendszerbõl hiányzó betûket behelyettesíti a velük azonossal (azonosnak véltel), akkor is, ha más a hivatkozási nevük. Képzeljük el, hogy megnyitásnál minden dokumentumból hiányzó betût összehasonlít az összes rendszerben lévõ betûvel, egyenként, és amelyik kettõt egyformának véli, -figelembe véve a betûk összes kiolvasható tulajdonságát: csomópontok száma, verzál magasság, lelógószár, befoglaló dobozméret, szélességérték, vastagság, betûcsalád, kvirtszélesség, stb.- azokat összerendeli. Egy tördelõ gépen több száz betû is lehetséges, figyelembe véve a betûstílusokat is. Még szerencse, hogy ki lehet kapcsolni, és ez esetben kapunk -egy a felhasználó által definiálható- összerendelõ táblázatot. A Word-ben van rá lehetõség, hogy erre az esetre integráljuk a betût a dokumentumba. Ez persze lehet hogy barbár módszer, de nem kötelezõ élni vele. Ráadásul csak TrueType betûkkel lehetséges a dolog, ezért az ADOBE érthetõen nem támogatja. Ma még csak így lehet biztosítani a gépek, platformok közötti hibátlan dokumentum-átvitelt. Szerettem volna, ha nyomtatás, színrebontás elõtt, információt kaphatok a beimportált képek színcsatornáiról, nem maradt-e a munkában véletlenül RGB kép. Bár a tördelõprogramok manapság az RGB képeket is gátlástalanul színrebontják, (bár a fekete szinkivonat fedettségére nem kérdeznek rá...) erre a feladatra a Photoshop való. A bekezdések alatti és feletti léniák távolságát alapértelmezés szerint szeretném sortávolság-% helyett mm-ben megadni a sorhoz képest, szeretnék végre választani a PICA és a DIDOT pontrendszer között, (persze ilyen betûméret-pontatlanságok mellett minek...), halál pontos oldaltükörméreteket (alul is), színhelyes megjelenítést, továbbá nagyon sokoldalú kép és szövegimport, munkaoldalon szerkeszthetõ táblázat, esetleg képletszerkesztõ, kilövés szerinti nyomtatási lehetõség ívenként, több mesteroldal (a PM-be eddig csak egy volt lehetséges), oldalbeszúrásnál vagy törlésnél nem szétesõ asszimetrikus oldalpárok voltak a fõbb elképzeléseim.

Nézzük ehhez képest mi teljesült. Elõször is a program szépen futott egy LC-475-ös, nem túl nagyteljesítményû gépen, sõt nem tûnt lassúbbnak a Quark-nál, az alapbeállítás szerint 6 MB szabad memóriát követelve magának. A HDD-n is csak 20 MB helyet foglalt, persze a Quark 7 MB-jához még ez is soknak tûnhet, a PM szolgáltatásai ezt alátámasztják. A PM-be beépítették az OLE 2.0 adatkommunikáció lehetõségét, ami jópofa dolog egy irodában, teljesen fölösleges egy nyomdai elõkészítõ programban. Gondolom senki nem akar színrebonthatatlan hangállományokat, mozgó animációt, vagy folyamatosan frissülõ, néha el-eltûnõ -de ugyancsak színrebonthatatlan- Excel grafikonokat beszúrni a dokumetjébe. OK, akkor ne telepítsük az OLE-t, de a PM OLE nélkül nem indul el! A táblázatkészítõ modulja sem OLE alkalmazásként jelent meg, pedig a kézikönyv szerint az. Lehet hogy csak elfelejtette a telepítõ adminisztrálni? Remélhetõleg az OLE adminisztrációt nem bízza a gyártó a felhasználóra. Most majd lehet vigyázni, hogy a vágópadon átvett elemek vagy állandóan frissülnek, esetleg néha el-eltûnnek, vagy stabilan megmaradnak. Ez utóbbi érdekében használjuk a Paste Special menüpontot képbeillesztésre, mert az EDIT/PASTE alapértelmezésként OLE kapcsolatot fog eredményezni. Még szerencse, hogy kevés a lehetséges adatforrás. Az OLE adatkapcsolat rendkívül nagyteljesítményû gépet feltételez, mert a kapcsolat folyamatos frissítése és fenntartása érdekében a céldokumentummal sokszor együtt fut a forrásprogram! A PM elõzõ verziói stabilak voltak. Ez a tesztverzió gyakran elszállt, de ha hibátlan lenne, nem lehetne béta. Nyilván kijavítják az elszállások okait, amely nem biztos hogy a PM-ben keresendõ. Most pedig nézzünk néhány kellemes meglepetést.

Quarkosoknak újdonság lehet, hogy a FILE/NEW ablakában van álló és fekvõ papír is. Éppen azért van rá szükség, mert apróság. Most igazi újdonságként a szembenálló oldalak mellett megjelent a kétoldalas nyomtatási lehetõség is. Leokézva az elsõ dialógusboxot, beimportálva egy szöveget, az oldaltükör rendkívüli pontatlanságára lettem figyelmes. Az alsó margótól egysor+soremelés+maradék távolságra volt az alsó sor alapvonala! Feltétlenül javítandó hiba, mert ha megfogjuk a szövegredõny alját, és egy kicsit megmozdítjuk, helyreáll a Qaurkot megszégyenítõ rend. Nade húzzák meg programból azt a redõnyt! A grafikák importja miatt félelmetes mennyiségû szûrõt tartalmaz a program. Közvetlenül fogad a PM majd minden létezõ grafikát, akár MAC-en, akár PC-n készült, még az emészthetetlen PC-s Corel-t is lenyeli. És a LINKS menüpontban ott van az információ minden képrõl, milyen színcsatornákat is tartalmaz! Ja, és a szöveg is linkelhetõ, vagy ha változott a forrás, frissíthetõ, akkor is, ha nem OLE objektumként illesztettük be. Ekkor persze áttördelõdik a dokumentum. Tesztem során minden grafikát hibátlanul linkelt a PM, de egy fejléc nélküli EPS vektort szövegként jelenített meg! Aki tehát tudja a PostScript nyelv szabályait, akár át is rajzolhatja, de ez szöveg formájában nem lesz túl tartalmas. Nem tudom, hogy ez hiba, vagy poén. A PM felismeri a Quark XTG szöveget, és be is importálja, de a magyar ékezetek elvesznek. Magyar szabványú idézõjeleknek, helyesírás-ellenõrzõ és elválasztó-modulnak egyenlõre nincs nyoma itt sem. A PM rugalmasan bõvíthetõ a fent említett hiányzó modulokkal, persze ezeket nem fogja a gyártó megírni helyettünk... A program tehát PLUG-IN szerûen bõvíthetõ, sõt ha a Photoshop Plug-In könyvtárát bemásoljuk a PM Plug-In folderjébe, akkor meg is eszi azokat! Dokumentumon belüli képmanipulálásra használható ez a lehetõség, de ne felejtsük el, hogy a PhotoShop pluginok leginkább csak RGB képre alkalmazhatóak, ill. a PM-nek nem feladata a rajzolás és a képfeldolgozás. Más se hiányzik egy tördelõprogramba, csak egy KPT! A szövegexport filter túl kevés, bár a szövegformátumokat illetõen nincs akkora káosz mint a képeknél. A szövegimport rendkívül sokoldalú, szinte gépfüggetlen az egész. Kérdéses a magyar ékezetes betûk helyes importja, ill. a PC-MAC kódkiosztás közötti automatikus konverzó.

A PM-be beépítetek egy kerning és egy tracking editort, -a Quark után szabadon- jóval egyszerûbben használhatóak a speciális betûpárok és az általános betûközök módosítására. Mivel a PM nem dobozolja a szöveget vagy a képet, hanem rolózza (reluxázza, redõnyözi), a keretet úgy kell külön ráhúzni. Egy ok miatt használom a Quarkot: nem lehetett a PM-ben kereteket együtt méretezni a képekkel, szövegekkel utólag. A 6.0-ás verzióban minden csoportba foglalt objektum, keret, szöveg, kép, vonal együtt méretezhetõ! Igazán virtuóz megoldás! Szövegformázásnál a lehetõségek megegyeznek az általánosan kialakulttal, de a szelektált szöveget egy gombnyomással negatívba lehet fordítani, pl. egy sötét háttérrészlet miatt a feketét fehérbe. A szövegformázó dialógusboxokból hiányoltam az APPLY gombot, de nem olyan nagyon, mert a gyakorlott tördelõ úgyis stílusokkal dolgozik. A PM-ben már évek óta lehet a bekezdéseket sorszámozni, vagy jelképekkel megjelölni. Nem oldották meg sem a fattyú, sem az árvasor kezelését, bár itt már végre tipográfiai szaknevén nevezik õket. A programra jellemzõ egyébként, hogy nem körülírja, hanem szakszavakkal illeti a funkciókat. A fattyúsor (orphan) és az özvegysor (widow) kezelésére nem megoldás, hogy néhány sort áthajintok a túloldalra, és a helyüket üresen hagyom. Marad tehát a szóközértékek átdefiniálása és a sorkizárt szedés, egyenlõre gyalog. Ígéretes megoldás, (de még nem tõkéletes) a problémára az egymás melletti hasábok sorainak kiegyenlítése, amely automatizált. De az oldalak között ez nem mûködik. Tetszik a PM-ben, hogy a tapasztalatlan felhasználókat sem hozza pl. olyan kísértésbe, hogy 4-5 betûs iniciálékat gyártson. Itt erre szerencsére nincs lehetõség. De a színkezelése csalódást okozott. Minden további nélkül CMYK-sítható a Pantone színskála, és direkt színné alakítható a CMYK színmodellbõl kikevert szín. Ezt is a Quark után szabadon, de minek. Annyi jót tudok mondani, hogy itt már legalább nem egy gombnyomásra lehet hibásan dönteni, hanem lehulló lista alapján. (Úgy azért mégis nehezebb). OK, konvertáljanak a két színmodell között, mert ez komoly programozástechnikai tudást mutat. De legalább a színmodell-kiválasztás pillanatában ajánlják fel a helyes megoldást, ne bízzák azt a felhasználó idegállapotára! A direkt (spot) színek a printelés elõtt amúgy is CMYK-vá (process-é) konvertálhatóak, (ezért zavaró és fölösleges ugyan ez a színkiválasztásnál) de itt kapunk is egy rendkívül intelligens figyelmeztetést, amely arról szól, hogy nem azt fogjuk kapni process színrebontás után, mint amit Pantone-ként meghatároztunk. Ez nagyon szinpatikus. A direkt színskálákat nem azért találták ki, és alkalmazzák, hogy CMYK-vá konvertálgassuk õket. Gondoljunk csak az arany és az ezüst Pantone színekre... A PM nem is próbál színhelyes lenni a színkiválasztó dialógusboxban (100C+100M az rikító videokék). Erre szoktam azt mondani, hogy akár fekete-fehér képernyõn is dolgozhatunk. Nagyon fontos lenne kijavítani, ha nagyobb piaci részesedést akarnak, vagyis ha nem csak a nyomdász-elit számára gyártják a programot, akik fejbõl tudják, milyen CMYK keverésbõl milyen szín lesz nyomtatásban!

A PM-ben eddig csak egy mesteroldalt lehetett dokumentumonként definiálni. Most már lehet többet is, mint a Quark-ban, de a mesteroldal elmenthetõ -nem dokumentumként, hanem mesteroldalként-, és persze behívható egy másik munkába! Nagyszerû újdonság! A PM-hez adott kiegészítések is nagyon hasznosak. Az automatikus tartalomjegyzék generálása megszégyeníti a Word 6.0-át, nagyszerû a tárgymutató generálás is, amelyeket nem szúr be a munka közepén álló aktuális kurzorpozícióba mint a Word, hanem megvárja amíg elhelyezzük az elsõ vagy az utolsó oldalon. Mindez automatikusan frissül, ha több komplett dokumentumból egy nagy könyvet akarunk készíteni. A fejléc és lábléc is fejezetenként definiálható, anélkül hogy a mesteroldalt kéne használni. A dokumentumba nemcsak kétoldalas-oldalpár, hanem szimpla mesteroldalakat is elhelyezhetünk, mint páros vagy páratlan oldal. Utólagos oldaltörlésnél vagy beszúrásnál nem esnek szét az oldalak akkor sem, ha az oldalpár nem szimmetrikus! A bal margóra ragasztott objektum ott is marad, ha változik az oldal páros vagy páratlan volta! Az oldalt nem csak hasábokra, hanem sorokra is fel lehet osztani. (Illusztrátor...) Ennek akkor veszi hasznát a tördelõ, ha a cikk vége az oldal alja felett, középtájon ér véget több hasábban. Ez együtt használható a hasábkiegyenlítõ funkcióval. Sajnos egy redõnyön belül még mindég nincs több hasáb. Rajzolófunkciói az ésszerûség határian belül maradtak, sokszögeket és csillagokat definiálhatunk. (Illusztrátor...) Már látom amikor spirálokat, árnyékokat, lyukakat, és egyéb satöbbiket lehet csinálni a PM-ben, csak nehogy összeolvadjon az Illusztrátorral és a Photoshoppal! Elõkészítõk, levilágítók! Kilövés szerinti sorrendben lehet nyomtatni (levilágítani) az íveket úgy, hogy a lehetõ legfilmtakarékosabban helyezi el az oldalon a munkát. Megadható az ívekbe helyezett lapok száma (Pages per group), ez alapján módosul a levilágítási sorrend, és az oldalak egymás mellé nyomtatása. Oldalpárokon átmenõ képek vagy címsorok esetén nélkülözhetetlen! (Mi lesz a montírozókkal) A kézikönyv szerint nyomtatásnál ezen kívül figyelembe veszi a program a gerincszélességet, és az ívek egymásba helyezése miatt keletkezõ crep-et (esedéket), és az alapján módosítja az oldalpárméretet, ill. az oldalpárok közötti távolságot. (Mi lesz a kötészettel) Ez utóbbi dolog egy kicsit azért furcsa, mert ha a PM tényleg módosítja a gerinc alapján az egymás mellé kerülõ oldalak távolságát, netán az oldal margóinak pozícióját az oldalon belül, a lemezmásolók valószínûleg nagy bajban lesznek, mert nem fognak tudni semmire ráállni, mert minden oldal más-más pozícióban lesz. Megint egy olyan probléma fog elterjedni, aminek az okát sem a nyomdász, sem a számítógépes elõkészítõ nem fogja tudni. Ez a funkció csak bekötésre, max. összefûzésre kerülõ kisebb irodai irományok printeres nyomtatásánál használható, a nagy nyomdaiparban, újságok -fõleg ha az színes!!!- vagy könyvek tömeges gyártásánál nincs jelentõsége, sõt nem megengedhetõ az oldalviszonyok módosítása, és az esedék levágása sem spórolható meg. Végül támogatja a multimédia alkalmazásokból már megismert és alkalmazott Hypertext szerkesztését, de pont így mûködik a PC-Windows helpje is, ahol egy szövegrészre mutatással más oldalakon lévõ szöveget kereshetünk meg. Talán egyszer itthon is elterjed az információs hálózatokon lehetséges böngészés, azaz webbelés, na nem programok, hanem szöveges információk után. Vagy lehet, hogy a jövõben Drag-and-Drop stílusban lehet help-et, vagy multimédia alkalmazásokat (itt nem a játékokra, hanem a lexikonokra gondolok) írni? A funkció kihasználásához a gyártó kifejezetten ajánlja saját termékét, a NetScape nevû hálózati böngészõt.

Érdemel néhány szót a felújított táblázatkészítõ is, a Table Editor 2.5-ös. Minden könnyen megoldható benne, és igen szép táblázatokat lehet vele készíteni. A cellákon belüli szövegformázás is kifogástalan, pl. külön tabuláció nélkül lehet egymás alá igazítani a tizedeseket. A táblázat elmenthetõ mint EPS vagy PICT formátumú grafika, így akár más termékekbe is beolvasható. Exportálható szövegként is, de nincs olyan nyomdai elõkészítésre alkalmas termék, amelyben szebb táblázatokat lehetne csinálni. (Ha van egyáltalán olyan, ahol akármilyet is lehet, mert a Word nem alkalmas nyomdai munkára).

A PM 6.0 igen komplex alkotás, anélkül hogy a munkát káosz és áttekinthetetlenség nehezítené. Még néhány verziót javíthatnak rajta, de ha a jelenlegi béta verzió kis hibáit kijavítják, a fölösleget eltávolítják, néhány félreérthetõen alkalmazható funkciót automatizálnak pl. a színkezelésben és a színrebontásban, és stabillá teszik a mûködését, (az a gyanúm, hogy nem a PM instabil, hanem az MS OLE 2.0) akkor végre egy olyan program születik, amely eddig páratlan módon -funkcióiban, lehetõségeiben, pontosságában, szóhasználatában- támogatja a szakmát. És itt nem a számítógépes szakemberekre gondolok, hanem a tördelõkre, tipográfusokra, nyomdai elõkészítõkre, nyomdászokra.

A PageMaker 5.0

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.