Did you even look at the translation kit docs? -----Original Message----- From: cad-linux-dev-bounce@xxxxxxxxxxxxx [mailto:cad-linux-dev-bounce@xxxxxxxxxxxxx] On Behalf Of Eric Wilhelm Sent: Tuesday, June 08, 2004 10:45 AM To: cad-linux-dev@xxxxxxxxxxxxx Subject: [cad-linux-dev] Re: uber-converter # The following was supposedly scribed by # Lee Harding # on Tuesday 08 June 2004 12:17 pm: >Does is make sense to go through a central format to convert LandXML to >SVG? Of course it doesn't. Why not? From a programming standpoint, it makes a lot of sense. If LandXML->UberFoo=20 is a well-defined translation and UberFoo->SVG is a well-defined translation,=20 what's the difference to a "I just want to convert LandXML into SVG" user? =20 Very little. But if that user were to become an "I just want to convert LandXML into DXF" user, the programmer has to start all over and replace all=20 of the SVG-write code with DXF-write code. >For many conversions a supplier/receiver >chain will do a better job than going through the central exchange. Call it a chain if you want. Point is: if the hub is between 8 nodes, you=20 have 28 chains ready to go (8 choose 2.) >Consider multi-hop conversion like LandXML to PNG (through SVG, or some >other intermediate format) -- isn't it desirable to make this as >painless as possible? Yes! If we have UberFoo->PNG and LandXML->UberFoo, we don't have to go=20 through SVG. Also, note that there is nothing that says something has to go directly=20 through the hub. If you want to make 7 various SVG read/write filters, we=20 could just connect SVG into the hub and it's essentially the same as each of=20 the 7 being spokes (now it's 8+7 spokes, so 15 choose 2 =3D 105!) I imagine=20 that you would get a more feature-filled conversion by not going through the=20 somewhat limited SVG, but I never said pragmatism was bad. --Eric --=20 "You can't win. You can't break even. You can't quit." --Ginsberg's Restatement of the Three Laws of Thermodynamics