MS Publisher importszűrő LibreOffice-hoz

Iroda

Használ valaki MS Publishert? Szeretnénk írni egy importszűrőt a LibreOffice-hoz, hogy be tudja olvasni az MS Publisher fájlokat. Az volna a kérdés, hogy mi lenne a jobb célpont, a Writerbe olvassuk be, vagy inkább a Drawba. Az MS Publisher filozófiájához melyik állna közelebb?

  • 5279 megtekintés

( batyu v | 2012. 01. 05., cs – 19:03 )

Az ötletet üdvözlöm! :-) A kérdés meg nem egyszerű, mert grafikával teletűzdelt 1 oldalas publisher fileok drawba, a több oldalas szöveges/ábrás/táblázatos stuffok meg inkább writerbe illenének. MS office alatt meg ugye nincs is draw, wordhoz meg nincs importfilter, szóval lehet, hogy inkább a draw lenne jó cél.

( Lsh7 v | 2012. 01. 06., p – 07:18 )

Még használok MS publisert A3 naptárak és névjegykártyák készítéséhez.
Most raktam fel a Libot kisérletképpen mivel szeretnék valami szabad szoftvert használni az MS helyett, sajnos a 150 eFT amit kérnek a komplett családért neméri meg azért a pár kiadványért.
Szívesen segítek megnézni a szűrődet vagy bármit.

( nemethl | 2012. 01. 06., p – 13:33 )

A Draw-hoz közelebb áll abban, ahogy oldalakat, rétegeket, illesztővonalakat kezelhetünk, illetve hogy kényelmesebben rajzolhatunk, illetve vághatunk képeket; az Impresshez abban, ahogy az oldalak mellett mesteroldalakat is kezelhetünk, a Writerhez pedig abban, ahogy hasábokat, lábjegyzeteket, szövegdobozokat, kép és szöveg egymás mellé tördelését, stílusokat, tartalomjegyzéket stb. kezelhetünk. Rövid távon jó megoldásnak az tűnik, hogy az egyszerűbb dokumentumok Draw-ba, az összetettebbek (pl. ha már elválasztott szöveg, stílusok, többsoros szövegdobozok fordulnak elő benne) pedig Writerbe töltődnek be, vagy ez választható is. Megfontolandó, hogy a Draw-hoz és az Impress-hez hasonlóan egy rajzoldalak (draw pages) sorozatán alapuló új ODF formátumot kell-e kitalálni. Ennek hátránya, hogy a DTP programoknál is ugyanúgy szükség van a Writer logikájára, ha meghatározatlan méretű szöveget kell betördelni, és a Draw valószínűleg nehezebben ruházható fel a Writer képességeivel, mint fordítva, bár vannak olyanok a (de lehet, hogy csak a szöveges ODF-re vonatkozóan) szabványban, hogy automatikusan jöjjön létre a következő oldalon ugyanazon pozícióban egy keret a szöveg folytatására. Inkább azt tartom reálisnak közepes távon, hogy megvalósítunk minden hiányzó ODT lehetőséget, tehát a szöveges dokumentumét (a DTP kiadványok is inkább strukturált szöveges dokumentumok, mint rajzok), amit a szabvány lehetővé tesz. Ebben pedig benne van a rétegek kezelése is például. A mesteroldalak és az oldalkezelés (oldalak cseréje, másolása, megjelenítése) pedig kiváltható az oldalstílusokkal és oldal méretű keretekkel (az ODT szabvány megengedi, hogy a szöveges dokumentum egy bekezdést se tartalmazzon, csak kereteket) vagy ha az oldalstílusokhoz kereten kívüli bekezdésre van szükség, akkor oldaltörésekkel kombinálva. Ami a Writerbe kellene, az a Navigátor felruházása oldalmásolási képességgel, vagy egy Drawhoz hasonló panellal, plusz a rétegek és kicsit több grafika kezelése. Igazából a Writer és a Draw jobb összeolvasztásáról volna szó, ez fedné le legjobban a DTP igényeit, és még megvalósíthatónak is tűnik.

( gellert | 2012. 01. 09., h – 13:08 )

Szia András, Laci! Én azt gondolom, hogy a Draw és Writer együttes közös tudása kellene ahhoz, hogy egy DTP anyagot össze lehessen LO-ban állítani. Az egyiknek jó a szövegkezelése, a másiknak a rajz képességei. :(

Szerintem egy módon már most is meg lehet csinálni, csak kicsit kacifántos. A megoldás az OLE-objektum beillesztése.

Szóval: A Draw dokumentumot venném alapul, mert az kezel rétegeket, anélkül pedig fölösleges lenne a DTP kísérlet. Szóval a Publisher rajzokat és rétegeket importálnám Draw objektumokként és rétegenként. A szövegeket pedig Writer dokumentumokként hoznám létre, amit OLE-objektumokként illesztenék a Draw dokumentumba. Így megvan a rajz képesség és szöveg képesség is.

Hátrányok: Sok kicsi mellékes fájl, ahány szövegkeret van... Elég nehézkes a szerkesztés, mert külön kell szerkeszteni a szöveget, lévén hogy Draw-ban elég korlátozott. Ja, és fogalmam sincs mit csinálnék a több kereten átfolyó szöveggel...

Ha lenne rétegkezelés Writer-ben, akkor sokkal egyszerűbb lenne, mert akkor fordítva könnyebb lenne elfogadni, hogy a rajzokat kell külön szerkeszteni... Szerintem a LO-t nem DTP-re tervezték... akkor lenne alkalmas rá, ha a Writer és a Draw egy alkalmazás lenne.

Szia András! :) Én szándékosan nem javasoltam...
1. Szerintem érdekelheti a Scribust is, mert nekik sincs még ilyen, és csak kívánság listán van. A forrásfában sem láttam ilyen importálót. Az rémlik, hogy listán írtak már erről, de most nem találok semmi konkrétat.
2. Te hogyan csinálnád? Én nagyon örülnék, ha végül olyan megoldás születne, ahol a Writer-ben megjelennének a rétegek.

Az OOo/LO oldalan varhato hozzavalo kepessegek megjelenese is? Pl. a Publisherben van nevjegykartya varazslo, ami eleve megfelelo meretu dokumentumot allit ossze, utana a nyomtatasnal is felul van definialva egy csomo minden, be lehet allitani, hogy hany kartya legyen egy lapon, meg ilyenek.

Ha ilyen lenne, az kiraly lenne, akkor nem kene csak a Publisher miatt felrakni az Office-t. Azon kivul ugyanis normalis, ertelmesen kezelheto nevjegykartya gyartot meg nem talaltam, pedig kerestem.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sok-sok évvel ezelőtt - ismerős cégénél - volt szerencsém megismerkedni a másik op. rendszer alatt a kanadai gyártású CorelDRAW! programmal (tényleg nem most volt: v3 környéke, ~'92-93).
Nos, ott - tökölés nélkül - minimálisra véve a fekvő A4-es lap margóját, ráfért a szabványos (90x50 mm) névjegykártyákból 12 db. Marhára kevés volt a papírfelesleg... :-) Régi szép idők!
Később persze megjelentek a célalkalmazások (valami márkanév rémlik is: Z.... címkenyomtató, etikett program, tán német?), stb.
Végeredményben ez a módszer a mai napig működik a LO Draw-ban is! :-)
Tudom: a legtöbb köcsög színes nyomtató "visszaugat" a túl kicsi margó miatt, de ezt a jobbaknál (néha napján) felül lehet bírálni, legalábbis emlékeim szerint.

Az OLE sajnos nem jó megoldás. Az így beillesztett szövegkeretek nem tudnak kommunikálni egymással, pl. a szöveg átfolyatásához, de még olyan egyszerű dolgok sem működnek, mint az elválasztás (az elválasztójel és a szöveg között túl nagy térköz van a Draw-ba illesztett OLE-s Writer szövegkeretekben. Hasonlóan a Draw képek és a Writer szövegek között sincs kommunikáció ilyenkor, hiszen az OLE csak egy téglalapot biztosít a beágyazott alkalmazásnak. Az ODF szabvány megengedi rendes (nem OLE) szövegdobozok beillesztését a Draw-ba, de ez jelentősen le van butítva a Draw-ban. Működését tekintve a Draw jóval egyszerűbb, mint a Writer, de hogy hogyan érdemes integrálni a két program felületét, ahhoz bele kell látni a LibreOffice felépítésébe. Az ODT megfelelő egy DTP formátumnak is, ez elkerülte eddig a figyelmem:

„As an alternative, a text document may contain of a single page sequence.”

Ez nem más, mint a Draw és az Impress által is használt, mesteroldalakkal is kombinálható oldalsorozata, tehát a szabvány hosszú távon is lehetővé teszi majd az ODT használatát (ha még nem támogatná, nem teszteltem a oldalsorozatos ODT-t, de valószínűleg még nem tud vele mit kezdeni a Writer).

Tehát ha szigorúan azt nézzük, hogy mi az, amihez nem kell a LibreOffice-on most módosítani, akkor csak az ODT formátum jöhet számításba, és a Writer, mint megjelenítő (oldalnyi keretekkel vagy oldaltörésekkel implementálva az oldalsorozatot, egyébként az oldalsorozat is oldalnyi szövegkeretekkel van megvalósítva az ODF-ben, lásd ott). Mivel azonban nincs végzetes különbség itt (legfeljebb a Draw nem fog rendes tördelt szöveget megjeleníteni, mert nem kezeli ezt a szövegkereten belül), ezért lehetne választható a formátum, vagy a megjelenítő ideiglenesen a nagyon egyszerű dokumentumokhoz, pusztán a szerkesztés egyszerűsítése miatt. Az ODG előnye, hogy azt a Scribus is importálni tudja, de ha rendes megjelenítést akarunk, akkor ezt jelenleg csak az ODT tudja. Jó példa erre, ahogy egy szövegkeretet vágólappal Draw-ba másolunk: stílusok, elválasztás, benne lévő hasábok, képek, minden elvész, csak a bekezdések szövege marad meg (ha nem hasábban volt). A Draw-ban tárolt képeknél sincs tördelésre vonatkozó beállítás. A LibreOffice-t DTP-re kezdték el áttervezni, seregnyi dolog benne van, még ha rejtve is, pl. nemcsak a rajzelemek forgatását, csoportosítást támogatja a Writer, hanem még a dinamikus összekötő vonalakat is rendesen kezeli (kivéve betöltésnél, ahol ezek elcsúsznak valamiért, de megmozgatva az összekötött elemeket, helyre állnak). Ha a Writer felülete közeledne a DTP-hez, pl. az említett oldalsorozatos ODT-k kezelésével, akkor talán az egyéb hiányosságok pótlása is felgyorsulhatna.

Összefoglalva: a szűrő (hosszabb távon) olyan oldalsorozatos ODT-t eredményez, ami a Writerbe betöltve automatikusan megjeleníti majd az oldalválasztó csúszkát, hasonlóan a Draw-hoz és az Impresshez, illetve a DTP programokhoz. Hogy az átjárhatóság milyen lesz a régebbi ODT-k között, ahhoz ezt meg kell tervezni, de nincs olyan nagy különbség: pl. a mesteroldalak az oldalstílusokból vannak levezetve. (Talán ez nézetként is felfogható volna, ha az oldalstílusok is lehetővé tennék az egyéb objektumok oldalhoz való kötését.)

Biztos lehet, de ez sokkal nehezebb szerintem, mert mondjuk 90%-a hiányzik a funkcióknak, fordítva meg 10%. Szabvány vonatkozásában sem tudom, hogy az odg alkalmas-e a célnak. Sejtésem szerint nem, mert tartalomjegyzék, meg ilyenek nem szövegkeret, hanem szöveges dokumentum szintű dolgok, de meg kell nézni.

Itt en arra probaltam kihegyezni a kerdest, hogy pl. a formazasok is elvesznek a szovegnel, ami szerintem nem egy elfogadhato allapot. Nyilvan a tartalomjegyzek nem is feltetlen szukseges egy draw dokumentumban, de azt igenis elvarna az ember, hogy a betu- es bekezdesformazasok megmaradjanak. Nem hiszem, hogy ez olyan nagy elvaras lenne, foleg, hogy a konkurrens termekben mukodik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal