yang686526

merging dwfs into one dwg messes up drawing
merging dwfs into one dwg messes up drawing
hi,
i'm trying to merge several dwf files into one dwg file. the dwf files (1.dwf, 2.dwf, 3.dwf) were extracted from original.dwg. after merging, out.dwg is the result - it seems like the dwf files were not placed correctly on top of each other, and this messes up the final drawing (compare original.dwg to out.dwg).
i've tried 2 methods for extracting parts of the dwg files into several dwf files:
making some layers invisible, and exporting only the visible layers - this worked fine when merging the dwfs back to the original dwg; however, this was not adequate for my needs (since the output dwfs could still be very large in some cases).
extracting only a number of entities at a time - for example, if the drawing has 5000 entities, i would remove 4000 entities each time (using the erase method), and leave only 1000 entities before exporting them to a dwf (thus creating 5 dwf files containing 1000 entities each). however, when merging the files back to one dwg, the problem i've detailed above occurred.
is this something i should handle when exporting to dwf? or rather when importing back to dwg?
attached files
i keep debugging this issue, and it seems that cdwfexportimpl::setplottingspace is causing the problem:
at the end of the method, it calls poverallview->setview.
in my case, for each dwf created, setview receives different coordinates, which output dwfs of different sizes (and this is what messes up the dwg when merging it from the various dwfs).
so i'm trying to use different plot types for the input layout, but the best result i had so far is klayout, which outputs dwfs of the same size (coordinates), but they only display a zoomed-in part of the original dwg (i'm trying to output the drawing as in zoomextents, and not just a part of it).
last edited by yaron.budowski@c4-security.com; 22nd february 2009 at 09:15 amfff">.
ok, i'm close to a solution, but i still need some help:
is there any method that returns the dimensions of the drawing - not getgeomextents, since it calculates it based on the currently active/non-erased entities, and this is what causing the different sized dwfs (since each dwf contains different non-erased entities, getgeomextents returns different coordinates each time).
i have a solution, but it's a bit of a hack:
i've modified the dwfexport code:
added a new value for the dwexportparams class - overrideextents (of type odgeextents3d).
in the method cdwfexportimpl::setplotsettingstolayout, in case the plot type of the layout is kextents, and in case overrideextents parameter is not null, use that value instead of calling getgeomextents.
this way i can provide dwfimport the correct coordinates, before i start removing any of the elements.
you may modify layout plot settings before export, to use current window and fixed scale.
vladimir
quote:
originally posted by vkalinin
you may modify layout plot settings before export, to use current window and fixed scale.
much better (and doesn't require recompliation of dwf export).
by the way, is there another way to retrieve drawing size without using getgeomextents? since this function consumes a lot of ram..
there are extmin/extmax database variables, but for some drawings they may be wrong, if database was modified and oddbdatabase::updateext() was not called
vladimir