1995. szeptember 1., péntek

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.