printing graphs to pdf

[Phil R]

I have a program that prints out a lot of graphs (maybe 20 pages, with 18 graphs per page). At present I send the graphs to a CNiReport onject and then print that by using the CNiReport::Print function, directing to a Win2PDF printer. To set the pdf file name programatically I have to set a registry key for win2pdf. Win2pdf takes some time to create the pdf and I have to single thread through this piece of code so that the registry key doesn't change before I'm finished. This is not good for scalability. I was looking at other methods for creating pdfs - LibHaru is an example, but it seems the CNiReport class will only print to a printer.

I have Visual Studio 2010 with the latest Measurement STudio and the legacy support.

Is there a better way to print graphs?

Thanks

[Jackie_B]

Hi Phil,

How are you generating your graphs? There are many options for saving files programatically without needing to go into the registry. The following are some examples of methods that can be used but it depends on the format in which your graphs are presented.

Workbook.ExportAsFixedFormat Method: Saves a workbook in PDF or XPS format.
Chart.ExportAsFixedFormat Method: Saves the chart in either PDF or XPS format.
Document.ExportAsFixedFormat Method: Saves the document in PDF or XPS format.

Regards,

Jackie

[Phil R]

Jackie:

Thanks. My graphs essentially come from data captured from an NI USB6218 M series daq card. I print 18 of them per page in a 2 cols by 9 rows format. But I do that by using CNiReport.

The Document.ExportAsFixedFormat that you mention looks useful, but I'll have to find a way to get my graphs to a word doc or my Report object to a word doc. It seems that the only output option for a CniReport object is by using the Print method which simply takes a printer name. Or am I missing something here?

Thanks

[Jackie_B]

Hey Phil,

I have looked into this and you are correct in that there is no way to name the PDF file using the CNiReport print function. What are the problems you are experiencing with scalability? Are you running into problems renaming with the registry key currently? Have you considered naming the PDF the same name for each file you print and then programatically renaming them?

Regards,

Jackie

[Phil R]

Well, CNiReport doesn't handle the file names at all, it just prints to a printer. In my case I have Win2pdf installed and use its printer. Its the thing that allows me to set the registry key. The problem for scalability is that it can take as long as 20 seconds for CNiReport to perform the Print function. Whether this is the fault of CNiReport itself or of Win2pdf I don't know. I already set the pdf name programatically - the whole thing is in a program. I couldn't name all the files the same - they'd simply overwrite each other. I also have to keep the registry key set until the print finishes as I don't know at what point Win2pdf accesses the key. I'm looking at using adobe distiller instead of win2df. That has the same registry key option, but it changes the key once its done so I could monitor that.

I was hoping there was an easier solution to this to enable direct printing of my CNiReport to a pdf. As it is it seems less than optimal in that it will only print to a printer defined to Windows.

Thanks

[Jackie_B]

Hey Phil,

This is a much older function in the C++ environment that is no longer developed in. It also seems that the filename was not taken into account, as the original functionality of the CNiReport print function was to print to a printer and no filename is needed for this. At this point, setting the registry key seems like the best workaround for using this function. What I was referring to regarding naming each file the same name and programatically renaming it was that you could print your file to a pdf with a generic name and before you loop back to print another file, you would refer to the file and rename it something such as filename(iteration). This way, you would name another copy before you override the original filename.

Regards,

Jackie

[Phil R]

Not sure why you say C++ is no longer developed in.

Your suggested solution is exactly what I want to avoid - I'm left single threading through the printing process. Also, I run more than one instance of the program, so I'd just end up with a longer wait and not have gained anything - unless I'm missing something.

I'll look intop other solutions. Thanks for your suggestions.

[Jackie_B]

Hey Phil,

At this point, Measurement Studio is being developed in .NET. Though C++ is still supported at this point, it is considered legacy support and will not be developed further in future versions of Measurement Studio. Unfortunately, with the function you are using, your current solution seems to be the best way to go.

Regards,
Jackie