Yes, that's possible in version 5. Here is an easy way to use it:

- create a tool that references the V5 assemblies
- read two file names specified via the command line
- call Diagram.LoadFromFile(param1)
- PdfExporter.Export(param2)
- run that tool from your current application when you need to export to PDF

I hope that helps,
Stoyan

An additional question has posed itself about this PDF exporting with FC.NET 5. Could you please tell me which specific version of PDF (I believe the standard is updated now and then with new features and syntax and so on right?) FC.NET 5 is using.

I'm importing the pdf into another pdf file using a software component called "tallpdf". However, even though it was working fine with 4.3.1, importing the PDF generated by 5 throws an error (a rather obscure one) that I think indicates a compatibility problem. The TallPDF component expects "a dictionary while reader trailer". I've no idea what that means, maybe somebody with PDF experience has? But it seems to me, he's expecting something that isn't there and my guess is that it is expecting another version of the PDF format...

Oh ok, it wasn't there in the 4.3.1 source code (I double checked) so I was assuming too rapidly it wouldn't be there for 5.

Anyway, I've been looking at what might be going wrong, comparing PDF's from 4.3.1 with those from 5. Making sense of the error message I've made a little discovery.

Right at the start of the "cross-reference table" there's a line saying: "0 23"

This, according to acrobat, should indicate the first index and the last index of the elements in the table. Counting 24 items in the table, this seems correct on mindfusion's part. However, I saw that in the PDF from 4.3.1 the latter of the two numbers indicated the length of the table (so the amount of elements) rather than the last index.

Also, in the trailer there's an entry "/Size 23". Which should indicate "the total number of entries in the cross-reference table". So this should be at least 24. Changing this value alone, doesn't solve my problem. But changing both the 23 at the start of the cross-reference table AND the 23 in the trailer to 24 resolves the issue and the TallPDF software component can now read the PDF without problems.

Acrobat reader can handle all of these files without complaining, so I'm thinking the problem might be with TallPDF itself.

I don't have much of an idea about the PDF format, but I now know how to fix the problem for me personally. I just thought I'd mention it to the people more experienced in creating the PDF files. Maybe there's a good reason for those particular numbers?

Yes, the old version writes the same value on the two locations, more specifically the total of items in the cross-reference table.

In code, as far as I see, the new MindFusion.Pdf still does this, only it's now writing the last index instead of the total amount of items. It's using seemingly the same value on both places in the PdfHelper class:

(arg as PdfDocument)._helper.CurrentId(); 

Here's the content of the cross-ref table and trailer for two pdf's I've been using as a reference:

Generated by the 4.3.1 code:

xref
0 18
0000000000 00000 f
0000000017 00000 n
0000000119 00000 n
0000000185 00000 n
0000009617 00000 n
0000010728 00000 n
0000010844 00000 n
0000010960 00000 n
0000011076 00000 n
0000011192 00000 n
0000011308 00000 n
0000011425 00000 n
0000011542 00000 n
0000011659 00000 n
0000011776 00000 n
0000011893 00000 n
0000000541 00000 n
0000012010 00000 n
trailer
<<
/Size 18
/Root 1 0 R
>> 

You can count 18 entries in the table.

Generated by the new 5.x code:

xref
0 13
0000000000 00000 f
0000000017 00000 n
0000000121 00000 n
0000000187 00000 n
0000000469 00000 n
0000000717 00000 n
0000000769 00000 n
0000001017 00000 n
0000001069 00000 n
0000001273 00000 n
0000001503 00000 n
0000001719 00000 n
0000002838 00000 n
0000003138 00000 n
trailer
<<
/Root 1 0 R
/Size 13
>> 

You can count 14 (!) elements in the table

My customisation simply adds 1 to the CurrentID() at both places where it's used in the PdfHelper class.

Hi,

If it's not a secret, could you post your code that uses TallPDF and threw that exception? We will add it to our tests to prevent the problem from happening again.

Thanks,
Stoyan

I also noticed my previous statement "just added 1" is a bit wrong. I'm actually doing this inside the Format method of PdfHelper class in MindFusion.Pdf

                case cFormatEnum.PdfTrailer:
                    System.Diagnostics.Trace.WriteLine("Added one to id in the trailer...");
                    result = (arg is PdfDocument) ? String.Format(Globals.TrailerPattern, (arg as PdfDocument)._helper.CurrentId() + 1, (arg as PdfDocument)._xref_position) : "";
                    break;
                case cFormatEnum.PdfXref:
                    if (arg is PdfDocument)
                    {
                        PdfObject obj = null;
                        Int32 LastId = (arg as PdfDocument)._helper.CurrentId();
                        result += String.Format(Globals.XRefPattern, LastId + 1);
                        System.Diagnostics.Trace.WriteLine(string.Format("{0} + 1 = {1}", LastId, LastId + 1));
                        for (Int32 i = 0; i <= LastId; i++)
                        {
                            obj = (arg as PdfDocument)[i];
                            result += String.Format(Globals.XRefEntryPattern, (obj == null) ? 0 : obj.Offset, 0, (obj == null) ? "f" : "n");
                        }

                    }
                    break;
 

Hello,

Sorry to bring this up again. I'm assuming this problem has been addressed in version 5.1.1. Is this correct? Also, do you know what the first version was this was fixed in?

Thanks!

Aaron