TASK PDF Convert bug (SPR 1167419) looking for automation alternatives

[mp3-250]

Not really a TASK only related issue, but we were using the "PDF batch convert" TASK, which is based on the "save as PDF" method and one of our engineers noticed a bug. imagine my shock

The PDF file is actually different from what you see on the screen as described below: some dimensions lose one of their arrows and sometimes the dimension is difficult to read or become completely misleading depending on the drawing.
Apparently not all dimensions with a customized arrow are influenced. For this reason I have to assume that our TASK convertion is completely unreliable at this point and find a valid alternative.

SPR 1167419

Status: Open

Customer Impact: Medium

Summary: When only one of the dimension arrows is the default setting, the arrow disappears when saving as PDF file.

♫ sad violin BGM ♩

As a temporary workaround I am asking all engineers to switch from "TASK PDF batch convert" to "TASK batch print" using the free CUBE PDF printer they already use for manual PDF output.
Unfortunatelly the file output is not fully automatic and our engineers are required to push a button to confirm the file convertion in PDF. With hundred of file in the print queue it means that your desktop will be filled with the same amount of confirmation windows waiting to save every PDF file.

I am looking for a PDF printer that does not require user input with a only pre defined local output path.
Microsoft PDF and Cube PDF does not offer this kind of feature and user input is mandatory.

I looked for some alternatives and I found.
- PDF distiller (Acrobat PDF Printer) : probably requires one Acrobat (not reader) license per user? (not sure)
- Cube PDF virtual printer (200,000 JPY per year subscription up to 100 users + customization for our needs)

I remember in my UG/NX early days (like 20yrs ago), we did not have the luxury of PDF output so I had to export in HPGL the print files and batch convert them to PDF using Ghostscript via an intermediate format (Postscript IIRC) .
Probably nowadays the process could be more straightforward with a simpler way to emulate a PDF printer for Solidworks batch printing.

I am open to suggestion. Please consider that we have almost 100 workstations to take care of including software install, configuration and future support...

[AlexLachance]

I know this isn't of much help concidering the cost implied, but we use CustomTools to generate our PDF and DXF on every save and we used to use it to batch process projects.

Most likely, you could achieve the same result without CustomTools, by adding rules in your batch processing, but then that implies for your drawings to follow these rules that have been given.

For instance here's how we work. If it says *DXF, it means anything that ends with DXF. if it says SHEET* it means anything that begins with SHEET*
In a drawing:
If there is one or multiple sheet containing Sheet* inside them, merge them as one PDF named as the file name.
If there is one or multiple sheet containing the word *DXF inside them, create seperate DXF of each sheet containg *DXF and name them using a combination of file name + sheet name.
If there is one or multiple sheet that do not contain any of *DXF or Sheet*, create each PDF of each sheet seperately, naming them with a combination of the file name + sheet-name.
If there is one or multiple sheet that contain the word *COLOR* inside it, have that sheet printed in color.


There is also a process that creates a binder of all the PDF's of a processed assembly using similar rules.

[mp3-250]

I know this isn't of much help concidering the cost implied, but we use CustomTools to generate our PDF and DXF on every save and we used to use it to batch process projects.

Most likely, you could achieve the same result without CustomTools, by adding rules in your batch processing, but then that implies for your drawings to follow these rules that have been given.

For instance here's how we work. If it says *DXF, it means anything that ends with DXF. if it says SHEET* it means anything that begins with SHEET*
In a drawing:
If there is one or multiple sheet containing Sheet* inside them, merge them as one PDF named as the file name.
If there is one or multiple sheet containing the word *DXF inside them, create seperate DXF of each sheet containg *DXF and name them using a combination of file name + sheet name.
If there is one or multiple sheet that do not contain any of *DXF or Sheet*, create each PDF of each sheet seperately, naming them with a combination of the file name + sheet-name.
If there is one or multiple sheet that contain the word *COLOR* inside it, have that sheet printed in color.


There is also a process that creates a binder of all the PDF's of a processed assembly using similar rules.

I do not know CustomTools, but if it uses the SW "Save as engine" to generate the PDFs its output is likely to be unreliable from what I am observing about our issue.
On the other hand the "Print engine" in SW seems more robust and the PDF output is WYSIWYG. No drawing artifacts observed at the moment.

[bnemec]

We have not used the TASK or Batch Save PDF, we have a home brew publishing Add-in for PDM, so this may not apply. But, since from your description it sounds like the problem is in the SaveAs PDF routine I'm going to throw this out there.

I'd say 98% of our "bad pdf" problems since the publish add-in was finished have been due to the views' Display Style not set to "High quality". I do not know why SW doesn't default those new views to "Use parent style" they seem to default to "Draft Quality". The first views are automatically set to High Quality.

Anyway, when it comes to the Save As PDF not looking like what SW is displaying, every case that I can recall was solved by making sure all the views' Display Style are set to "High quality", or "Use parent style" assuming the parent is set to "High quality."

We're on 2019SP4

[mp3-250]

We have not used the TASK or Batch Save PDF, we have a home brew publishing Add-in for PDM, so this may not apply. But, since from your description it sounds like the problem is in the SaveAs PDF routine I'm going to throw this out there.

I'd say 98% of our "bad pdf" problems since the publish add-in was finished have been due to the views' Display Style not set to "High quality". I do not know why SW doesn't default those new views to "Use parent style" they seem to default to "Draft Quality". The first views are automatically set to High Quality.

Anyway, when it comes to the Save As PDF not looking like what SW is displaying, every case that I can recall was solved by making sure all the views' Display Style are set to "High quality", or "Use parent style" assuming the parent is set to "High quality."

We're on 2019SP4

image.png

Thank you for sharing your experience. I come to the same conclusion that the save as routine has something wrong and SW does not have the time/will to fix those basic functions.
I would like to invite their developers in our company and explain to our engineers how their CAD is not able to output a PDF that correspond to the 2D drawing without missing entities ad how this is acceptable.

I will check the view quality setting.

PS Be careful before "updating" to 2020/2021 as the detailing mode could bite you.
At least for what I understand you are on a english release so the recent (2021 onward) trend to localize legacy variable that used to be in english ending up breaking all your files, templates and libraries is not going to hurt you too much. (not really sure)

[AlexLachance]

We have not used the TASK or Batch Save PDF, we have a home brew publishing Add-in for PDM, so this may not apply. But, since from your description it sounds like the problem is in the SaveAs PDF routine I'm going to throw this out there.

I'd say 98% of our "bad pdf" problems since the publish add-in was finished have been due to the views' Display Style not set to "High quality". I do not know why SW doesn't default those new views to "Use parent style" they seem to default to "Draft Quality". The first views are automatically set to High Quality.

Anyway, when it comes to the Save As PDF not looking like what SW is displaying, every case that I can recall was solved by making sure all the views' Display Style are set to "High quality", or "Use parent style" assuming the parent is set to "High quality."

We're on 2019SP4

image.png

Now that you mention that, I remember we ran into a similar problem, and the impact even went as far as to our DXF. That was a mess to deal with lol

[bnemec]

Now that you mention that, I remember we ran into a similar problem, and the impact even went as far as to our DXF. That was a mess to deal with lol

Interesting. DXF for laser or some CNC comes from your drawing? Our dxfs for laser and CNC wood routing have always been saved from the model not the drawing.

[AlexLachance]

Interesting. DXF for laser or some CNC comes from your drawing? Our dxfs for laser and CNC wood routing have always been saved from the model not the drawing.

Yes, we create a page with an empty template that contains the unfolded view at a scale 1:1. There's a button from CustomTools that does it automatically for us.

When the DXF is generated, it is generated by CustomTools and CustomTools has the rest needed for the generation.

Admittedly, it is quite a "hefty" task, but it was the solution that we came up with that would best fit our needs, and also in concideration of the limitations we had that came from:

-SolidWorks
-CustomTools
-Our ERP
-The shop floor
-The ever evolving world of consumption


We were also using SolidWorks to batch-process projects a while back, rather then have all the DXF/PDF generation done at the save of a file. If I were to have the free time to take our current process and adapt it to the current and future situation, rather then the past one, that would be awesome! As I've spoke previously on here, we went from a company that is specialized in custom-made, to a company that is slowly developping "standards", while also keeping the strength of it's custom-made and the innovations we do.

10 years ago, we were producing 2 trailers a week with one shop, now we're approaching 8 trailers a week in one shop, while having 2 other factories that are still in the "past". We plan to modernize them but it's not something that can be rushed.

[mp3-250]

We have not used the TASK or Batch Save PDF, we have a home brew publishing Add-in for PDM, so this may not apply. But, since from your description it sounds like the problem is in the SaveAs PDF routine I'm going to throw this out there.

I'd say 98% of our "bad pdf" problems since the publish add-in was finished have been due to the views' Display Style not set to "High quality". I do not know why SW doesn't default those new views to "Use parent style" they seem to default to "Draft Quality". The first views are automatically set to High Quality.

Anyway, when it comes to the Save As PDF not looking like what SW is displaying, every case that I can recall was solved by making sure all the views' Display Style are set to "High quality", or "Use parent style" assuming the parent is set to "High quality."

We're on 2019SP4

image.png

I hoped it was a "draft quality" related problem, but the drawing I checked is already set to high quality.
The problem is rooted in the "saveas PDF" routine inside Solidworks.

[bnemec]

I hoped it was a "draft quality" related problem, but the drawing I checked is already set to high quality.
The problem is rooted in the "saveas PDF" routine inside Solidworks.

Bummer. Bugs suck because the work arounds are seldom without undesirable side effects making everything a compromise. Then if and when there's a fix we have to remember to undo the workaround, but it's become engrained into a process now we don't know how to stop doing the workaround.

Only other thing I can think of is we had to fidget with the export PDF settings as well, but I don't recall what for exactly. The settings that were significant I added to the add-in code so that they get set each time it runs. Here's what we have.

Rereading your initial post and the snowballing effort to the work around of using some batch print reminds me of why we switched from Printing PDFs to Saving PDFs. Sometimes the least bad work around is not where the root cause is. I mean, if the SaveAs PDF is the root cause, sometimes the least bad work around isn't to stop using SaveAs PDF but rather avoid the process that causes the problem. Forgive the suggestion, but is it possible to not alter the dimension arrows, thereby avoiding the bug?

[mp3-250]

After 1 month I have managed to put up a test task for automated pdf printing.

the pdf printer works and generate correct PDFs from SOLIDWORKS print interface, but often fails if launched as TASK on the same files. (around 4% of my test sample)
with FAIL I mean that a PDF is generated by task, but it is bogus. it affects only some files while the rest has zero issues.

Task uses an old printout2 method, I have updated the script to printout3 but nothing changes. same files same error.
Debug the sw files is also useless as they print correctly within SW and I cannot ask my engineers to cope with that AGAIN after the convert PDF fiasco In the op.
I am considering to update the script to use printout4 method as last resort, but it changed a lot and I basically have to remake the whole task print script... without sufficient programming skills.

[mp3-250]

Bummer. Bugs suck because the work arounds are seldom without undesirable side effects making everything a compromise. Then if and when there's a fix we have to remember to undo the workaround, but it's become engrained into a process now we don't know how to stop doing the workaround.

Only other thing I can think of is we had to fidget with the export PDF settings as well, but I don't recall what for exactly. The settings that were significant I added to the add-in code so that they get set each time it runs. Here's what we have.
image.png

Rereading your initial post and the snowballing effort to the work around of using some batch print reminds me of why we switched from Printing PDFs to Saving PDFs. Sometimes the least bad work around is not where the root cause is. I mean, if the SaveAs PDF is the root cause, sometimes the least bad work around isn't to stop using SaveAs PDF but rather avoid the process that causes the problem. Forgive the suggestion, but is it possible to not alter the dimension arrows, thereby avoiding the bug?

Sorry for my late reply.
The workaround for the save PDF is basically check the properties of EVERY dimension with custom arrows in the drawing, reset them, set them again, check if the random bug has gone or it is still there and repeat the process as necessary.
Not very nice.

[mp3-250]

After 1 month of research I have put together a way to solve the unreliable saveas PDF issue printing in PDF.

To recap I tested 100+ files converted with task and I found the following issues:
・ dimension arrows sometimes disappears depending on a not yet solved bug in the dimension dialog
・if Arial Unicode MS is not present anymore in the OS the PDF task returns an error (a dialog that requires user input appears) stops midway and output garbage PDF (text only no vector graphics)
・our DETAIL label (not in english) disappears from PDFs
・saveas PDF fidelty is not so good: line fonts, note arrows sizes and other small detail are off compared to what you see on the screen in solidworks

Solution:
1. PDF printer to output files automatically (3rd party software required)
2. Modification to the TASK Print script in its default form to output 100% scale and sheet size based on sheet template only, wrong page setup must be bypassed.