yang686526

pdfexport not working for oddbpolyfacemesh
pdfexport not working for oddbpolyfacemesh
hi,
i tried exporting attached file (it has one oddbpolyfacemesh entity) using odamfcapp. it generates a blank pdf file with black background. is this a bug? any work around?
thanks.
attached files
hi,
i have test it with mfcapp's pdf export v 2.2.0. export generates pdf file with box inside. i used default pdf export dialog parameters (just enter file name and click export). so i cannot reproduce problem.
i need more information - toolkit version... could you reproduce it with mfcapp? export input parameters also...
thanks.
hi,
i am using odamfcapp sample application (dwgdirect 2.2.0.0) and dd_pdfexport_2.02_8.dll
i am using all default pdf export dialog parameters. i did some more testing and was able export other mesh files successfully. but the attached file(cube.dwg) produces blank page with black background. i will keep on testing and will let you know if find exact reason for this incorrect behaviour.
thx.
hi alexander,
i did more testing and found that the pdf export creates incorrect document when the render mode is set to kflatshaded or kgouraudshaded. the related code segment from 2dexportdevice.cpp in update() function is:
code:
if(pview->mode() > odgsview::khiddenline && pview->isvisible())
{
pview->hide();
prenderview->show();
numshadedvps ++;
}
else
{
prenderview->hide();
}
please let me know if there is any work around available.
thx.
last edited by sjaiswal@hachisoft.com; 29th january 2007 at 12:39 pmfff">.
bug in pdf with layers?
hi,
i found another incorrect behaviour in pdf export. i am able to reprduce it with odamfcapp. to see this behaviour follow these steps:
1. open attached "layertrouble.dwg" file in odamfcapp. (the file has two layers: "0"-on, and "layer1"-off)
2. use file->export to pdf option. browse to output file. select "enable layer support (pdf v1.5) option
3. click on export.
4. open exported pdf file. as you can see "layer1" is listed in layers list eventhough it was off. also the line drawn is actually on layer "0" but it gets exported as if it was on "layer1".
any quick fix for this incorrect behaviour? any suggestions highly appreciated.
thx.
attached files (23.4 kb, 7 views)
(2.2 kb, 6 views)

hi,
about layers... pdfexport has parameter
bool pdfexportparams::busehlr;
// is software vector hidden-line removing used for corresponding viewports
it was added in one of last releases. i found that it hasn't initialization in constructor ( first defect ). it should be initialized to false. this is minor problem.
also layer support mechanism will be broken if busehlr is set to true. please, set busehlr to false and test layers functionality again. changing of pdfexport only cannot solve this problem. this is conflict of two different functionalities.
thank you for bug report, it was surprise for me
hi alexander,
thanks for your reply. as you have suggested, i have put busehlr = false in constructor for pdfexportparams and set busehlr to false when passing pdfexprotparams to exportpdf(). but it does not fix the problem completely.
to see this behaviour follow these steps:
1. open attached "layertrouble2.dwg" file in odamfcapp. (the file has two layers: "0"-on, and "layer1"-on)
2. use file->export to pdf option. browse to output file. select "enable layer support (pdf v1.5)" option
3. click on export.
4. open exported pdf file. turn off layer "0" and "layer1". concentric circles are still shown eventhough it was on layer "0".
this has something to do with "initial entities" passed to pdfexport. pdfexport is not assigning proper layer to entities until it is atleast changed once from ""(empty string) to "layername". all entities before this step does not get assigned to any layer. any quick fix for this?
thanks again,
samir
attached files (22.2 kb, 5 views)
(3.4 kb, 5 views)

hi,
i reproduce it. i'll email to you fix.
great. it works perfectly. thank you very much.
samir.
alexander,
can you please post the fix up here or email it over to me also. i think that is probably the same problem we are having with some files.
thanks,
updated pdfexport sources.
attached files (57.9 kb, 12 views)

quote:
originally posted by alexander rumyantsev
updated pdfexport sources.
can i get updated pdfexport sources. it looks like bug has been re-introduced in latest 2.3.1
it is generating black background files again for abve mentioned examples.
thanks.
hi jaisam
latest version of toolkit is 2.4. all update changes from zip were added to 2.4 (& to 2.3.1). and it seems that pdfexport has minor differences between 2.3.1 to 2.4.
i also tested cube.dwg with 2.4. attachment is mfcapp's pdfexport output. i got the same results for 2.3.1 mfcapp.
hi alexander,
i am using dwgdirect 2.3.1.0 and "export to pdf.." from file menu. when i export using all default parameters, i am getting black background pdf generated from cube.dwg. the active viewport has "gourard shaded" render mode.
note: the black background pdf gets generated for "gourard shaded", "flat shaded", and "flat shaded with edges". all other render modes generate correct pdf file. i am using adobe reader 8.1 to view pdf files.
let me know if you need any other information to reproduce this error. also, i couldn't know that "how can i confirm that i am using correct version of pdfexport?"
original cube.dwg and generated cube.pdf are attached in .zip file.
thanks,
samir
attached files (13.5 kb, 4 views)

last edited by sjaiswal@hachisoft.com; 9th july 2007 at 09:05 amfff">.
hi,
correct pdf is pdf_export from our release zips. i used 2.3.1 vc8 dll .zips for testing of cube.dwg. i cannot reproduce defect. mfcapp generates bitmap with opengl device help in the gourard shaded", "flat shaded", and "flat shaded with edges" modes and insert it to pdf like image. i saw that your pdf has bitmap inside pdf, but it is black. do you have valid results for rendering with opengl device in mfcapp? it uses the same code. could you upload your pdf_export.drx ? i'll check it here.