SG.hu·

OpenOffice támogatás a Microsofttól

A szoftvercég egyik európai partnere nyílt forráskódú konverteren dolgozik, amely közelebb hozná az egymással rivalizáló Office csomagokat, mégpedig a fájlformátumokban rejlő különbségek áthidalásával.

A vállalat továbbra is tartja magát azon állításához, miszerint nem tapasztalnak növekvő érdeklődést a szintén nyílt OpenOffice szoftver iránt, ám a hozzájuk beérkezett kormányzati kérések miatt mégis saját konvertert készítenek, hogy ezzel segítség elő a nagyobb kompatibilitást. Ez a kiegészítésként készülő, ingyen letölthető program lehetővé tenné az OpenDocument formátumok használatát a Microsoft Office alatt és fordítva.

Közleményükből kiderül, hogy a konvertert egy francia partnerük, a Clever Age készíti, mégpedig a nyílt forráskódú szoftvereket fejlesztők körében igen népszerű SourceForge.Net portálon keresztül. Már meg is jelent az Open XML Translator prototípusa, amely lehetővé teszi a kétirányú konvertálást, vagyis különösebb vesződség nélkül használhatjuk az egymással nem kompatibilis szabványokat. Igaz, arra nem tettek ígéretet, hogy a konvertálás minden esetben probléma nélkül végrehajtható lesz, ám az alkalmazással a régebbi Office verziókat is bevonhatjuk a fordítgatásba.

"Folyamatosan olyan visszajelzéseket kapunk, miszerint a vásárlók homogenitás helyett különbözőséget, változatosságot és természetesen átjárhatóságot kívánnak. Néhányan közülük pedig egyenesen azt szeretnék, ha mi is erre koncentrálnánk, hogy biztosítsuk a termék magas színvonalát" - magyarázta Tom Robertson, az interoperabilitásért és szabványokért felelős igazgató. Ezzel a kijelentéssel az egyes kormányzatok részéről érkezett megkeresésekre utalt: nemrég Belgium is az OpenDocument mellett foglalt állást, követve ezzel Massachusetts állam és az Európai Unió példáját. Egyre nagyobb igény mutatkozik tehát a kompatibilitás iránt, és ezt már a szoftvercég sem hagyhatta figyelmen kívül. Korábban erre nem voltak hajlandóak és úgy tűnt, hogy igyekeznek megakadályozni bármilyen együttműködést a saját és a konkurens szabvány között.

A konvertáló alkalmazás igazi nemzetközi projekt keretében készül, hiszen a francia fejlesztés tesztelését az indiai Aztecsoft végzi, a német Dialogika pedig azt vizsgálja meg, hogy a szoftver eleget tesz-e az Európai Bizottság által támasztott feltételeknek. A prototípussal egyelőre ODF dokumentumokat konvertálhatunk Open XML formátumba, használatához .Net keretrendszer szükségeltetik.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© turul162006. 07. 09.. 19:17||#72
Tudnál mutatni egy msdn-es linket, hogy MS milyen formában támogatja ezt?
Egyébként a Sun JAVA párti (meglepõ mi).
És valamivel konkrétabban, megmondani mit is szeretnél te csinálni monoval ?

mono XML

CLI
Amint látod van CLI támogatás.
Akkor mi a baj ?
© Hierogli2006. 07. 09.. 15:59||#71
Hm, egyszeruen az OO Mono tamogatasanak hianya...
© turul162006. 07. 09.. 15:48||#70
Nem értem, hogy jön ez ide, valamelyikünk félre olvashatott valamit.
Én ezt akartam mondani:
Szerinted milyen óriási, technikai akadálya lehet annak, hogy mono (C#) , megirt kódot hozzá hegeszél ? Vagy abban írj egy konvertert stb..
© Hierogli2006. 07. 09.. 15:35||#69
Hatekonysagi okokbol. Mint ahogy assemblyben sem kezdek neki egy RTS jateknak...
© turul162006. 07. 09.. 15:19||#68
"Irhatok hozza mondjuk mono alatt formatum exportereket/importereket?"
Miért ne tehetnéd?
© Hierogli2006. 07. 09.. 14:12||#67
Nos, a word programozhatosagat eleg jol peldazza ez a .NET-ben irt project... Tud ilyet az OO? Irhatok hozza mondjuk mono alatt formatum exportereket/importereket?
© turul162006. 07. 09.. 10:52||#66
Nekem Anjuta felidegesített nagyon (fejlesztõi értenek a bug gyártáshoz), de sokat használtam. Most gvim -re esküszök. Ami leginkább, csak egy text editor, de mégis jobban bejön, mint bármilyen csilivilli ide. vimbook (Olvasd el az elsõ 25 oldalt, engem megyõzött 😊, az ábrák kicsit roszak ebben a pdf-ben)

A Delphi nek nem az a célja, hogy gyors legyen az alkalmazás, azok az alkalmazások amiket Delfiben érdemes írni nem lesznek anyival gyorsabbak C-ben megirva, hogy megérje. (Több a fejlesztési idõ, mint, amit használat során veszítesz) Delfi arra van kitalálva, hogy DB kiszedsz/beraksz dolgokat, és ilyen alkalmazásokat, kurva gyorsan lehet benne hegeszteni. (Titkárnõ nem biztos, hogy vágja az SQL nyelvet pl. ,és neki ez jó kis frontend lesz..)
© Caro2006. 07. 09.. 10:17||#65
Hallottam a Kylix-ról, és szerintem meg is van a szépsége a Pascal alapú nyelveknek, ha gyors kódot szeretnénk, akkor a gép agyával kell gondolkodni, és ahhoz a C áll a legközelebb.
Én most Anjutában fejlesztek.
© turul162006. 07. 09.. 09:36||#64
"mennyi GUI elem közül lehet választani", nem a számuk számít, meg mellesleg Delphi/Kylix -ben a nem, mind igazi gui elem, pl. ha DirectX-es progit akkarsz irni, egy DirectX ikont behuztál a formra és onnantol kezdve mehetett a dolog. 😊
Borlan VCL(/CLX), cuccok gyakran könyen kezelhetõnek bizonyulnak, de nem egy simma win32api hiváshoz vezetnek a methodusok, elég sokat kellhetett trüközniük, hogy valami jót kihozzanak. (Mellesleg, most látom kihoztánk .NET -es be is a Borland cuccot)
Probálj meg, egy komolyabb formot gyártani és megoldani az átméretezésekori viselkedést.. GTK-val sokkal egyszerübb.
(Delphi technologiák elõrhetõek Linux alá is, és némely része nyilt forrás kóddal is)
© Caro2006. 07. 09.. 06:02||#63
Lehet, hogy felelõtlen kijelentés volt 😊
Csak régen egy ideig Delphiztem, és ott láttam, hogy mennyi GUI elem közül lehet választani, viszont mikor Glade-et indítok, ezek nagyon lecsökkennek.
Mélyen nem mentem bele a dolgokba, nem szoktam GUI-kat programozni.