yang686526

dwf printing problems
dwf printing problems
i've written a simple control that can view or print drawings, but i'm getting problems when printing certain dwfs. i've based my code heavily on onprint from the odamfcapp sample but i'm getting an assert in the call to getgeomextents:
code:
else if (plottype == oddbplotsettings::kextents || (plottype == oddbplotsettings::klimits && !isplanview))
{
odgeextents3d extents;
if (playout->getblocktablerecordid().safeopenobject()->getgeomextents(extents) == eok)
{
viewtarget = (extents.minpoint() + extents.maxpoint().asvector()) / 2.;
extents.transformby(worldtoeye);
fieldwidth = fabs(extents.maxpoint().x - extents.minpoint().x);
fieldheight = fabs(extents.maxpoint().y - extents.minpoint().y);
}
}
i'm new to the library and don't understand everything going on in onprint. it looks like the layout in my dwf has an invalid paper space block? do i need to call setblocktablerecordid first?
i also noticed that if i import the dwf into odamfcapp and click the model_space block in the tree, i get the same assert:
expression: "extents.isvalidextents()"
file: "../../../../../include/ge/geextents3d.h"
line: 295
the problem dwfs were converted from dxfs by my own version of oddwfexportex. maybe i missed something when exporting the dwf?
i would really appreciate it if anyone could advise me how to fix this.
stuart
attached files
which dd version are you using?
vladimir
hi,
it is not printing problem. i have found that some dbpolyline objects in drawing have only one point. getgeomextents method incorrectly treat this situation and return invalid extents for object. i dont know how dwf was created, but it seems that dbpolyline with one vertex is invalid - if you call import dwf command and audit in mfcapp, it show some errors like acdbpolyline has only 1 vertices...
possibly, it is a bug in dwf import. we will add some additional comments late.
indeed, dwf import incorrectlty treats pline with 1 vertex read from dwf. it should add this single vertex twice.
i'm not sure if that pline is valid for dwf, but viewers treat it ok, so should we.
fix will be available in 14.02
vladimir
thank you for your comments alexander.
i created the dwf by converting one of our dxf files using very similar code to the oddwfexportex sample. i've attached the original dxf if that's any help.
these dxfs are generated by my company's cad application (not autocad) but i think they are pretty simple and don't use any advanced dxf features. my project has been to write a converter that generates dwfs and a viewer for both the dxfs and dwfs.
do you know of a work-around i could add to my dwf export code? by the way, i'm using v1.13.2 of the library.
thanks,
stuart
attached files (79.9 kb, 6 views)

hi,
dd has problem with reading of your dxf. i have found that dxf has characters with code 0 inside. i am not sure that situation is valid for dxf. possibly, it is bug in your app.
3
simplex
4
here is \0 character, (autocad save null string)
0
endtab
also i have found new dd bug - endless loop in \0\0 string processing. it will be fixed in next release.
quote:
originally posted by s.cresswell
do you know of a work-around i could add to my dwf export code? by the way, i'm using v1.13.2 of the library.
you may add second (duplicate) vertex to the polylines containing single vertex, before exporting dwf or in the process.
vladimir
thank you for all your help. i will look at the issue with nulls.
regarding the polylines with 1 vertex... do you know how they got into the dwf in the first place? i can't see any strange polylines in the original dxf file.
also, i am doing an audit/fix before exporting the dwf, so shouldn't this be correcting any problems with the polylines?
i've been trying a few things in my viewer code this morning. i added an audit/fix after importing the dwf and this does appear to fix my printing problems (but of course the audit slows things down a bit).
do you know why audit/fix doesn't fix the polylines when i export?
stuart
indeed, in the original dxf all the polylines are valid.
perhaps the bug is somewhere in export. how do you export dwf?
the first polyline with single vertex in dwf has coordinates (1073738279,18279).
vladimir
quote:
originally posted by wvk
indeed, in the original dxf all the polylines are valid.
perhaps the bug is somewhere in export. how do you export dwf?
the first polyline with single vertex in dwf has coordinates (1073738279,18279).
here are the most important bits of my export code. as you can see, it's very similar to oddwfexportex. i just use readfile() to load the dxf, then exportdwf().
i've also found that i can reproduce the problem using odamfcapp. if i open the dxf, do a "zoom extents" and then export to dwf, it has the same polyline problems.
code:
pdb = theapp.m_svcs.readfile(lpszinfile, true, 0);
oddbauditinfo ainfo;
ainfo.setfixerrors(true);
ainfo.setprintdest(oddbauditinfo::ksilent);
pdb->auditdatabase(&ainfo);
dwexportparams params;
params.pdb = pdb;
params.sdwffilename = lpszoutfile;
params.background = crdwfbackground;
params.ppalette = odcmacadpalette(crdwfbackground);
params.binkedarea = false;
params.bcolormapoptimize = false;
params.format = dw_compressed_binary;
params.version = ndwf_v55;
oddbviewporttableptr pvptbl = pdb->getviewporttableid().safeopenobject();
oddbobjectid id = pvptbl->getactiveviewportid();
if (id)
{
oddbviewporttablerecordptr prec = id.safeopenobject(oddb::kforwrite);
prec->zoomextents();
}
exportdwf(params);
in my viewer, i'm now doing an audit/fix before printing. this appears to correct the polyline problems and getgeomextents no longer asserts. however, i noticed that the extents returned by getgeomextents look like they are twice as wide as the actual extents. so, when the dwf is printed, it only occupies half of the paper. i think i've tracked the problem down to the length of a text entity (the one that begins, "modelled on...").
again, this can be reproduced in odamfcapp. first remove the null in the text style, so that it can't interfere. then, open the dxf in odamfcapp and check the extents of the "modelled on..." entity (they are 4, 204 to 185, 207). now, do a "zoom extents" and export to dwf. re-import the dwf and re-check the extents of the text entity (they are now twice as wide: 5, 204 to 545, 213).
do you know why this is happening?
stuart
last edited by s.cresswell; 8th february 2006 at 09:56 amfff">.
ah!, so it's our export that generates these plines. we'll look into it, thanks..
vladimir
quote:
originally posted by wvk
ah!, so it's our export that generates these plines. we'll look into it, thanks..
thank you vladimir. do you have any thoughts on how i might work-around the text extents problem?
unfortunately i cannot suggest any workaround. let our dwf export guru look into the problem, and perhaps he will suggest something. anyway all these bugs will be fixed in 1.14.02, that is scheduled for the end of the month.
vladimir
it was discovered that polylines with single vertex are correct in dwf, therefore, the only bug is in import.
currently, the only workaround would be auditing the file after import, as you already did.
vladimir