Néhány vektoros grafikus csereformátum

Ezen a lapon megismerjük

Mielőtt a részletekbe belemélyednénk meg kell ismételnünk, hogy az elmondottak csak az általános kép kialakítását célozták meg. Az apróbb részletek irént érdeklődők szerncsés esetben a szoftverek felhasználói kézikönyveiben kapnak eligazítást problémáikra.

DXF (Drawing Interchange Files) formátum.

A formátumot az AutoCAD grafikus szoftverhez dolgozták ki két variánsban: az egyik variáns ASCII karakterekkel tárolja a rajzot, a másik bináris formában. Mivel az ASCII karakterekkel való ábrázolás nyomtatása kényelmesebb és szemléletesebb, ezt fogjuk bemutatni. A bináris forma alkalmazása viszont azért célszerű mert ugyanaz a rajz mintegy 25%-al kisebb tároló kapacitást igényel. Nagyon sok vektoros és raszteres térképező és GIS szoftver képes DXF állományok fogadására (lsd. 5.2 táblázatot) (érdekes módon a fordítottját, azaz a DXF export generálását már kevesebb tudja), ezért is indokolt hogy a megismerkedést ezzel kezdjük.

Mielőtt bármit is mondanánk készítsünk el egy egyszerű AutoCAD rajzot (5.1 ábra) és listázzuk ki DXF megfelelőjét (a listázáshoz kattintson az 5.4 táblázatra).

5.1 ábra a DXF illusztálására szánt egyszerű ábra

Amint látjuk a rajz egyszerűségéhez képest elég hosszú listát kaptunk, pedig igyekeztünk helykimélés céljából a különben egy oszlopban elhelyezkedő adatokat párhuzamos oszlopokba rendezni és összezsugorítani.

A formátum megértéséhez azt kell mindenek előtt tisztáznunk, hogy a lista részekből (szekciókból) áll, melyek mint látni fogjuk különböző tipusúak lehetnek, de bármilyen tipusűak is SECTION karaktersorozattal kezdődnek és ENDSEC szóval végződnek.

A formátum másik egysége a csoport, mely mindössze két sorból áll: az első sor tartalmazz a csoport kódot, a második sor pedig a csoport értéket. A DXF lista nem más mint kölönböző kéttagú csoportok egymásutánja.

A csoport kód minden esetben megadja, hogy értéke milyen jellegű tehát karakteres, hexadecimális, decimális egész vagy lebegőpontos szám, e mellett esetenként fixen, esetenként összevontan utal a jelzett érték mibenlétére.

A DXF fájl részei (szekciói) elhelyezkédés és elnevezés szempontjából egy verzió vonatkozásában kötöttek, de verziószám növekedésével újabb csoportok jelenhetnek meg, például az OBJECTS (objektumok) szekció, mely a többszörös vonalak paraméter hivatkozásait is tartalmazza vagy a CLASSES (osztályok) szekció csak a 13-as verziótól kezdődően található meg a formátumban. Ez a bővítési lehetőség azonban kétélű fegyver, mivel a bővített DXF-eket a régebbi verziók illetve transzformációs programok nem értik. Ezt megkerülendő mind az exportnál mind az importnál lehetőség van arra, hogy a fájl csak az úgy nevezett entitás szekciót tartalmazza.

A mellékelt listán a következő szekciókat találjuk (helykimélés végett a szekciók felvázolását nem oszlop listában adjuk meg, de felhívjuk a figyelmet, hogy a tényleges fájlokban egy sorba csak egy space nélküli karaktersorozat kerül):

0 SECTION 2 HEADER (ide kerülnek azok az autocad változó értékek melyek a rajz készítése során érvényben voltak, sárga hátterü srafozzással emeltük ki a szekciót) 0 ENDSEC (a fejezet vége, amint látjuk valamennyi szekció végét ugyanaz a karakterkombináció jelöli) 0 SECTION 2 TABLES (ide helyeződnek az autocad táblázatok pld. a VPORT, mely megadja a megjelenítő ablakok paramétereit, köztük elsőnek az aktiv ablakot, a LTYPE a vonaltipusok jellemzőivel, a LAYER, mely tartalmazza a fedvényeket és jellemzőiket, a STYLE, mely a betűtipusokat írja le, a VIEW, mely a nézeteket adja meg a szemkoordináta rendszer kezdőpontjának és a vágási síkoknak a paramétereivel, az UCS a felhasználó által definiált koordináta rendszer, az újabb verziókban megjelent egy BLOCK_RECORD táblázat is, mely tartalmazza az előregyártott tömbök és a felhasználói tömbök hivatkozásait, a szekció a rendszertáblázatok bővülésével új elemekkel gazdagodik, bizonyos táblázatok elemeit csökkenthetjük, ha a dxf fájl létrehozása előtt purge utasítást alkalmazunk) 0 ENDSEC (a fejezet vége) 0 SECTION 2 BLOCKS (ebben a fejezetben találhatók a rajzban defineált tömbök, de az újabb verziókban a rajzi egységeket, tehát a modellteret és a papírteret is tömbökben defineálják) 0 ENDSEC (a fejezet vége) 0 SECTION 2 ENTITIES (ez a fejezet tartalmazza a tulajdonképpeni rajzi utasításokat a hozzátartozó koordináta mondatokkal, illetve a tömbök beillesztésére vonatkozó információkat. A tömbök tulajdonságait itt nem ismétli meg csak hivatkozik arra a táblázatra a TABLES fejezetben amelyet a BLOCKS fejezet feltölt a megfelelő rajzi értékekkel) 0 ENDSEC (a fejezet vége) 0 EOF (a fájl vége).

Szerény méretű rajzunk első tekintetre nem indokolja a tekintélyes méretű DXF fájlt. Ha azonban jobban megnézzük az állományt akkor kitűnik, hogy a tulajdonképpeni rajz nem tartalmaz több információt a fájl egy ötödénél, a többi érték akkor is megjelenik, ha csak egy pontot akarunk átvinni, mivel az állapot információk függetlenek a tényleges rajztól és csak a szoftver pillanatnyi beállításait és feltöltési állapotát tükrözik. A fentiekből következik, hogy:

A fentiekből két dolog következik: a DXF konveráló programokat mindíg az adott GIS szoftver adatmodell illetve grafikai színtjén kell megírni, másfelől tudatában kell lennünk annak, hogy a DXF konvertáló programok ezt a követelményt különböző színteken teljesítik.

A problémát még az is bonyolítja, hogy sok szoftver DXF kimenete (erre a lehetőség az AutoCAD-ban is megvan) csak az ENTITIES és EOF fejezeteket tartalmazó csonka DXF fájlokat hoz létre. Természetesen ezektől a DXF-ektől ne várjuk, hogy a rajzokat rétegekbe illetve tömbökbe rendezze. Hogy ez már a legegyszerűbb gyakorlati esetekben milyen nehézségekre vezet azt jól példázza tapasztalatunk arra az esetre, ha a SURFER-ben létrehozott színtvonal rajzot az AutoCAD-ben tovább akarjuk szerkeszteni. A SURFER a földtudományokban széleskörűen használt magasság modellező szoftver, mely közvetlenül rajzi állományokat illetve ezek DXF verziót állítja elő. Sajnos az állományok csonka DXF-ek, ami azt eredményezi, hogy mind a színtvonalak, mind a főszíntvonalak, mind pedig a megírások egy rétegen képződnek le, ezek szerkesztése (stílus változtatás, színváltoztatás, vonalvastagság változtatás, stb.) csak jelentős manuális munkával végezhető el.

Ezek után indokolt, hogy röviden megnézzük, hogy miként írja le a rajzot a DXF az ENTITIES fejezetben (megjegyezzük, hogy a BLOCKS fejezetben a tömbök leírása nagyon hasonló eszközökkel történik, ezért erre nem térünk ki).

2 ENTITIES 0 POLYLINE 8 0 5 31 66 1

Megnyitottuk az entitások fejezetet, majd a 0 csoportkóddal arra mutatunk, hogy milyen tipusú rajzelemről van szó. A kód értéke tehát a rajzelem neve, esetünkben POLYLINE. A 8 csoportkód a réteg név kódja, esetünkben 0. A következő 5 csoportkód sorszámot ad a rajzi entitásnak esetünkben 31, majd a 66 kód arra utal, hogy ha értéke 1, akkor a sokszög (polyline) töréspontjai következnek.

10 0.0 20 0.0 30 0.0 70 1

Annak érdekében, hogy a sík sokszög Z síkja határozott legyen, a fájl megad egy fiktív pontot a sokszög síkjában melynek a 10 kód utáni X és a 20 kód utáni Y koordinátája mindíg zérus, a 30 kód után megadott Z koorinátája pedig megegyezik a sík magasságával, esetünkben ez is zérus. A 70 kód értéke az attribútum milyenségét adja meg, esetünkben 1 azt jelenti, hogy a sokszög zárt.

0 VERTEX 8 0 5 32 10 193.651252 20 44.423076 30 0.0

A továbbiakban már sok az ismétlődés. Megadjuk a rajzelem nevét esetünkben töréspont (VERTEX), rétegét - 0, és sorszámát - 32. Ezután következnek a töréspontok koordinátái, mégpedig 10-es kóddal az X, 20-as kóddal az Y és 30-as kóddal a Z.

Ezután hasonlóképpen felsorolja a fájl a további három töréspontot, figyeljük meg, hogy az 5 kóddal minden töréspontnak új sorszámot ad, majd a sokszögbe tartozó elemek végét a

0 SEQEND 8 0 5 36
kód - érték kombinációk szolgáltatják. A 0 SEQEND kombináció a töréspontok sorozatát zárja le, míg a következő két kombináció a sokszögvonalhoz rendelt, a vonal területét és hosszát megadó úgy nevezett endsequence listás objektum fedvényét és sorszámát írja le.

Következő objektumunk az ábrán látható kör lesz.

0 CIRCLE 8 1 5 37 10 329.249502 20 148.5 30 0.0 40 33.888569
A kód - érték kombinációk itt már könnyen megfejthetők: CIRCLE kör esetében az objektum-tipus értéke, a kör az 1-es rétegen helyezkedik el, sorszáma-azonosítója 37, középponti koordinátái x=329.249502, y=148.5, z=0, sugara pedig (40-es kód) 33.888569.

A következő lépésben a fájl rendelkezik a tömb beszúrásáról.

0 INSERT 8 2 5 4F 2 VIRAG 10 239.415661 20 124.807692 30 0.0 42 0.9 50 50.555022

A 0 műveleti kód INSERT értéke jelzi a műveletet, mely a következő 0 kódig tart. A mondat megadja a beszúrandó tömb rétegét (esetünkben a 2-es réteg) a tömb sorszámát, mely a 4F hexadecimális (16 alapú) szám, a tömb nevét, melyet a rajzoláskor feltett kérdésre megadtunk: VIRAG, a beszúrási pont koordinátáit x=239.415661, y=124.807692, z=0.0, az y irányú méretarány tényezőt: 0.9, az elfordulási szöget: 50.555022.

Amint látjuk ezekből az adatokból a tömb nem állítható helyre, azaz ha csak az ENTITIES fejezetet visszük ki DXF formában úgy a tömbök csak pont formában jelennek meg. Hasonló a helyzet, ha a DXF fájlt konvertáló program csak az ENTITIES fejezetet értelmezi. Ez utóbbi esetben csak akkor tudjuk helyreállítani a teljes rajzi állományt, ha a dxfout parancs előtt felrobbantjuk a tömböt.

A szekcióban eléforduló tobábbi csoportok a VIEWPORT-ot (megjelenítő ablakot) írják le. Ha állományokat és nem nézeteket cserélünk, úgy ezeknek a csoportoknak nincs jelentősége. A DXF fájlok részletei iránt érdeklődők az AutoCAD Alkalmazáshoz Igazítási Kézikönyvből [1] szerezhetnek további információkat.

Mapinfo csereformátum: a MIF fájl.

Version 300
Charset "WindowsLatin1"
Delimiter ","
CoordSys NonEarth Units "m" Bounds (-1721.674038, -1462.576927) (2300.509071, 1700.346158)
Columns 1
  ID Integer
Data

a
193.65125123387 44.423075488545
193.65125123387 194.192308602462
385.18378176613 194.192308602462
385.18378176613 43.576922397538
193.65125123387 44.423075488545
  Pen (1,2,0)
  Brush (1,0,16777215)
  Center 289.4175165 118.8846155
Ellipse 295.360933581753 114.611430502011 363.138071458025 182.388569056704
  Pen (1,2,16711680)
  Brush (1,0,16777215)
Region 2
  4
200.601937598335 156.74070409767
243.444319527335 188.437640479228
240.00374811808 124.323857955659
200.601937598335 156.74070409767
  4
245.807020273766 71.604806323496
292.635592806215 95.79444671219
239.749310847879 124.803047128883
245.807020273766 71.604806323496
  Pen (1,2,255)
  Brush (1,0,16777215)
  Center 222.023129568381 156.380749217443

5.5 táblázat - az 5.1 ábrát leíró MIF fájl

Mielőtt bármiféle magyarázatot fűztünk volna ehhez a csere formátumhoz az 5.5 táblázatban bemutattuk az 5.1 ábrán látható alakzat listáját ebben a formátumban.

A lista úgy készült, hogy az 5.4 táblázat DXF fájlját beolvastuk import DXF utasítással a MapInfo-ba, majd export utasítással MIF fájlt hoztunk létre. A tömböt (két kékszínű csúcsban illeszkedő háromszög) egy objektumként értelmeztük, bár a MapInfoban meg van a lehetőségünk arra is, hogy a két háromszöget külön objektumként kezeljük.

Mielőtt rátérnénk a lista vizsgálatára meg kell jegyeznünk, hogy a MapInfo export egyszerre két fájlt készít az állományból egy MIF fájlt a grafikus elemeknek és egy MID fájlt az attribútumoknak. Mivel jelenleg elsősorban a grafikus adatcsere formátumokkal foglalkozunk, nem fogjuk részletezni a MID fájlt csak utalunk rá, hogy objektum azonosítónként tárolja ASCII formátumban az attribútumokat. A MID fájl opcionális, ha nincs megadva az azt jelenti, hogy minden sora üres. Hogy mégis szólnunk kell róla az egyszerűen azért van, mivel a MID fájlban tárolt táblázat alakját és fejezetét a MIF fájl fejezete határozza meg.

Lássuk ezek után a MIF listát. Már az első ránézésre látszik, hogy a fájl két részből áll: a fejezetből (header), és az adatokból (data).

A header első sora a verziószámot tartalmazza, masodik sora az irásjelkészletet, harmadik sora az elválasztó karaktert. Ez az elválasztó karakter a MID fájlban játszik szerepet. A MID fájl rekordjai sorokból állnak, melyek végén soremelés vagy soremelés kocsivissza karakter áll. Egy soron belül az oszlopokat pedig az itt megadott jellel választják el. A negyedik sor jellemzi a koordináta rendszert, az ötödik sor az oszlopok számát a MID fájlban, a következő sorok pedig (annyi sor ahány oszlopot megadtunk az előző sorban) az oszlopok nevét és tipusát valamint zárójelben a tipus jellemzőit (pld. hány karakter széles) tartalmazza.

Példánk esetében a koordináta rendszer nem valamely a program által ismert lokális földi referencia rendszer ezért a header megadja az általa értelmezett koordináta határokat. Egy oszlopot adtunk meg, melynek neve ID, tipusa pedig Integer.

A DATA szóval kezdődnek a tulajdonképpeni geometriai adatok. A leírásra soron következő grafikus objektum jellegét a következő kilenc kulcsszó valamelyikével közli a fájl: POINT, LINE, POLYLINE, REGION, ARC, TEXT, RECTANGLE, ROUNDED RECTANGLE, ELLIPSE.

Az egyes objektum tipusok részletes ismertetésétől - amennyiben az 5.5 táblázatban nem szerepel - eltekintünk, az érdeklődök az erre vonatkozó információt megtalálják a MapInfo felhasználói kézikönyvében [2].

A zárt sokszögeket REGION kulcsszóval jelöli a rendszer. Egy region egy vagy több területet is tartalmazhat. A területek számát a kulcsszó utáni szám mutatja. A következő sorban lévő szám a töréspontok számát adja meg. Figyeljük meg, hogy zárt poligonokról lévén szó a kezdő és zárópont kétszer szerepel, azaz a töréspontok száma eggyel nagyobb a ténylegesnél. Ezután következnek az x y koordináta párok (elválasztó karakter a space), majd a rajzi milyenséget kifejező opcionális Pen (szélesség, minta, szín). Esetünkben Pen (1,2,0) azt jelenti, hogy a vonalvastagság 1-es egy 1-7 skálán, a vonal minta folytonos, a szín pedig fekete. A szín 24 biten elhelyezkedő RGB érték, azaz mivel a fekete R=0, G=0, B=0 ez binárisan is azt jelenti hogy mind a 24 bit nullákkal van tele, aminek megfelelő tizes alapú szám szintén 0. A következő opcionális kulcsszó a kitöltést vezérlő Brush (minta, kitöltőszín, háttérszín), esetünkben Brush (1,0,16777215). Az 1 kitöltési minta tulajdonképpen azt jelenti, hogy nincs kitöltés, azaz a másodiknak megadott fekete kitöltő szín nem számít, a harmadiknak megadott háttér szín értelmezéséhez képzeljük el hogy az fehér azaz R=255, G=255, B=255. Irjuk fel ezeket a számokat binárisan a megfelelő bájtokba
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
és alakítsuk át a kapott bináris számot tizes rendszerbe egy zsebszámológép segítségével, az eredmény 16777215 lesz, azaz a háttér valóban fehér. Mivel azonban kitöltés nincs a háttérszínnek sincs jelentősége, ezért ezt az értéket sem veszi figyelembe a megfelelően megírt fordítóprogram. Az utolsó opcionális kulcsszó a Center a terület súlypontjának x y koordinátáit tartalmazza, elválasztó jelekként itt is spacek szerepelnek.

Következő új kulcsszavunk ELLIPSE attribútumában két koordináta párral az 5.1 ábra következő objektumát a kört jelöli. A két koordinátapár az ellipszis befoglaló téglalapjának két sarokpontját határozza meg. Az ellipszis tengelyei a MapInfo értelmezésében párhuzamosak a koordináta tengelyekkel. Mivel az ellipszis általánosabb a körnél, a kör is megadható egy olyan speciális ellipszissel, melynek befoglaló téglalapja négyzetté fajul. Az objektumhoz csatolt Pen (1,2,16711680) rajzi kód azt mutatja, hogy a kört a legvékonyabb folytonos vonallal vörös színnel kell rajzolni. Ha ugyanis beírjuk az R=255, G=0, B=0 értékeit bináris formában a megfelelő bytekbe majd az eredményt egy 3 byte hosszú bináris számnak tekintjük és átalakítjuk tizes
1 1 1 1 1 1 1 1
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
számrendszerbe úgy 16711680-at kapunk, ami megegyezik a Pen argumentumában szereplő értékkel. Az ELLIPSE-hez csatolt Brush (1,0,16777215) megegyezzik az előző objektumnál ismertettel, az ott elmondottak itt is érvényesek.

Az utolsó objektumunk is region tipusú az érdekessége, hogy az AutoCAD tömb átalakításával készült s mivel a tömb két háromszögből állt ez is két poligont fog tartalmazni. Másik említendő körülmény, hogy a kék szín, mivel úgy nyerjük, hogy a legalacsonyabb helyértékű azaz a jobboldali byte-ot feltöltjük egyesekkel a többit pedig nullákkal tizes számrendszerbe történő átalakítás után 255 értékkel fejezhető ki ebben a rendszerben.

Összefoglalva elmondhatjuk, hogy a formátum alkalmas egyszerű grafikus objektumok cseréjére, területi objektumokból álló összetett objektumokat is tud kezelni beágyazási hierarchia nélkül (csak az összetett objektumhoz tud attribútumokat rendelni a részekhez nem), e mellett gondoskodik bizonyos rajzi kódok hozzárendeléséről is.

Végül megemlítjük, hogy a formátum csak egy rétegre vonatkozik. Mivel az 5.1 ábra az AuroCad-ban három rétegre készült, a MapInfo választást ajálott fel, hogy három különálló MIF fájlba vigyük ki az adatokat vagy vonjuk össze az objektumokat egy rétegre. Mi az utóbbi eljárást választottuk.

Az Arc/Info ASCII csereformátuma.

Bár az Arc/Info is rendelkezik csereformátummal ez nem ASCII fájl, s ezért kevéssé alkalmas a téma megvilágítására. A grafikus elemek vonatkozásában azonban az Arc/Info képes ASCII állományt is létrehozni az UNGENERETE paranccsal, ezért az alábbiakban ezt a lehetőséget fogjuk röviden áttekinteni.

Az 5.1 ábra rajzát visszavittük az AutoCAD-ba, a tömböt felrobbantottuk, majd DXF-ben bevittük az Arc/Infoba és az alábbi vonal jellegű ASCII fájlt kaptuk, melyet az 5.6 táblázatra történő kattintással tudunk elővarázsolni.

Ismét el kell mondanunk, hogy ez alkalommal is helykimélés okán tördeltük a koordináta párokat három oszlopba, az eredeti fájl egy oszlopba rendezi a koordináta párokat. Amint látjuk a fájl struktúrája végtelenül egyszerű: minden objektum első sorában azonosítója foglal helyet, majd következnek a vonal töréspontjait reprezentáló koordináta párok, az objektumot END kód zárja, egy másik END pedig magát fájlt.

Felmerül a kérdés, hogy miért olyan végtelenül hosszú a második objektum leírása. Erre a válasz egyszerű: mivel a formátum semmiféle objektum tipust sem defineál explicit módon, a második objektum esetében található kör minden egyes "töréspontját" megadja az ArcInfoban szabályozott felbontási finomsággal. Implicit módon természetesen tudjuk, hisz a fájlt igy készítettük hogy az objektumok vonalak. Hasonló módon létrehozhatnánk önálló pontokból álló fedvényt is, ha az eredeti rajzunk önálló pontokat tartalmazott volna, illetve ha nem robbantjuk fel a tömböt hanem azt önálló fedvényen beillesztési pontjával helyettesítjük.

Miután a DXF fájlt bevittük az Arc/Infóba a grafikus réteghez attribútum tábla is csatlakozik, mely többek közt tartalmazza a fájlban megadott rajzi jellemzőket is. Ebből a fájlból is készíthetünk egy ASCII fájlt a TABLES DUMP utasítással, mely esetünkben a következőképpen néz ki (5.7 ábra):


$RECNO 1
F12_1_ID 1
DXF_LAYER 0
DXF_COLOR 7
DXF_THICKN 0.0000
DXF_TYPE CONTINUOUS
DXF_CURVE 0
$RECNO 2
F12_1_ID 2
DXF_LAYER 1
DXF_COLOR 1
DXF_THICKN 0.0000
DXF_TYPE CONTINUOUS
DXF_CURVE 1
$RECNO 3
F12_1_ID 3
DXF_LAYER 2
DXF_COLOR 5
DXF_THICKN 0.0000
DXF_TYPE CONTINUOUS
DXF_CURVE 0
$RECNO 4
F12_1_ID 4
DXF_LAYER 2
DXF_COLOR 5
DXF_THICKN 0.0000
DXF_TYPE CONTINUOUS
DXF_CURVE 0

5.7 táblázat - az 5.1 ábra ARC/Info ASCII csereformátumú attribútum fájlja

Sok magyarázatra a fájl értelmezéséhez nincs szükségünk mindössze azt kell hozzátennünk, hogy F12_1 a grafikus f'ájl neve, $RECNO a record sorszáma az attribútum táblázatban, DXF__CURVE az AutoCad görbe kódja, az 1 érték a körívet jelenti.
Ezek után beláthatjuk, hogy a két fájl felhasználásával gyakorlatilag ki tudjuk használni az eredeti rajz legtöbb jellemzőjét a tömb struktúra kivétlével.

Összefoglalásul megállapíthatjuk a következőket

A legutolsó megállapítással kapcsolatban megjegyzem, hogy ez a feladat természetesen nem csak az átviteli formátumra, de a fogadó szoftverre is vonatkozik. Az eddigi példánkban a rövidített DXF (mely csak az entitásokat tartalmazta) nem tudta átvinni a tömböt, hanem csak a beillesztési pontját. Ha azonban a DXF úgy volna megszerkesztve, hogy az entitások között kiegészítő cimkével ellátva szerepeltetné a tömb geometriai elemeit is, a fogadó szoftver pedig, ha nem képes kezelni a tömböt, figyelmen kívül hagyná a kiegészítő címkét, de értelmezné a címkével jelölt entitásokat, úgy a magasabb logikai színtű rendszerből az alacsonyabb színtű rendszerbe is viszonylag kevés információ vesztéssel lehetne átvinni az adatokat.
 
 


Megjegyzéseit E-mail-en várja a szerző: Dr Sárközy Ferenc