IPXS_PDFVariant

A forum for questions or concerns related to the PDF-XChange Core API SDK

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Tracker Supp-Stefan

Forum rules
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.

When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
Post Reply
omascia
User
Posts: 48
Joined: Thu Mar 11, 2010 7:07 pm

IPXS_PDFVariant

Post by omascia »

How do we create an instance of that interface for the purpose of storing a string through IPXC_DocumentInfo->SetInfoVar() ?
Sasha - Tracker Dev Team
User
Posts: 5522
Joined: Fri Nov 21, 2014 8:27 am
Contact:

Re: IPXS_PDFVariant

Post by Sasha - Tracker Dev Team »

Hello omascia,

As far as I see it would be correct to use https://sdkhelp.pdf-xchange.com/vie ... fo_InfoStr for this.
Here you can look at the small sample on how to use it:
https://sdkhelp.pdf-xchange.com/vie ... ument_Info

Cheers,
Alex
Subscribe at:
https://www.youtube.com/channel/UC-TwAMNi1haxJ1FX3LvB4CQ
omascia
User
Posts: 48
Joined: Thu Mar 11, 2010 7:07 pm

Re: IPXS_PDFVariant

Post by omascia »

No it doesn't fit the need, if I'm not mistaken. That API is meant to read/write well-known properties (controlled by a integer representing which typical info string you want to get/set). See:
https://sdkhelp.pdf-xchange.com/vie ... entInfoKey

What we do is really add custom key information strings containing needed information for later PDF sub processing.
Sasha - Tracker Dev Team
User
Posts: 5522
Joined: Fri Nov 21, 2014 8:27 am
Contact:

Re: IPXS_PDFVariant

Post by Sasha - Tracker Dev Team »

Hello omascia,

Well if you do that manually than that data can be removed by some PDF viewers when saving the document because that's not a documented way of doing that. Though if you really want to do that, then the https://sdkhelp.pdf-xchange.com/view/PXV:IPXS_Inst has the NewVar_ methods that can create new variants from different types.

Cheers,
Alex
Subscribe at:
https://www.youtube.com/channel/UC-TwAMNi1haxJ1FX3LvB4CQ
omascia
User
Posts: 48
Joined: Thu Mar 11, 2010 7:07 pm

Re: IPXS_PDFVariant

Post by omascia »

Thanks. No concern about the added properties being, possibly, removed by some other toolset. They're only meant to survive while the PDF is still within our systems. What happens to copies getting out is not a concern. Thanks for the shortcut to the right interface to initialize variants !
Sasha - Tracker Dev Team
User
Posts: 5522
Joined: Fri Nov 21, 2014 8:27 am
Contact:

Re: IPXS_PDFVariant

Post by Sasha - Tracker Dev Team »

Hello omascia,

Well if that's the case, I am glad that we helped.

Cheers,
Alex
Subscribe at:
https://www.youtube.com/channel/UC-TwAMNi1haxJ1FX3LvB4CQ
omascia
User
Posts: 48
Joined: Thu Mar 11, 2010 7:07 pm

Re: IPXS_PDFVariant

Post by omascia »

I still have questions, though, on IPXS_PDFVariant. More specifically on IPXS::NewVar_String.
https://sdkhelp.pdf-xchange.com/vie ... Var_String
What's the purpose or effect of the bIndirect parameter?

Where do I get my IPXS_Document from, when I have an IPXC_Document to work with?
Okay, this one I got it: https://sdkhelp.pdf-xchange.com/vie ... osDocument
All in all, the steps required to merely add a custom property string to a PDF document while creating it are incredibly overweight for the application programmer compared to what the old API allowed to do. Kind of makes me feel like I had a nice specialized crane to help me build my applications (versions 4, 5, 5.5) and now I have received a big bag of Lego boxes to build the crane instead. :(
User avatar
Lzcat - Tracker Supp
Site Admin
Posts: 677
Joined: Thu Jun 28, 2007 8:42 am

Re: IPXS_PDFVariant

Post by Lzcat - Tracker Supp »

What's the purpose or effect of the bIndirect parameter?
It allow create string as separate (indirect) object in PDF. Please read PDF specification, section Syntax, especially its subsection Objects to know more.
All in all, the steps required to merely add a custom property string to a PDF document while creating it are incredibly overweight for the application programmer compared to what the old API allowed to do. Kind of makes me feel like I had a nice specialized crane to help me build my applications (versions 4, 5, 5.5) and now I have received a big bag of Lego boxes to build the crane instead.
We provide simple functionality to add standard document information properties, and also provide a way to add ANY custom property which you wish (and this is not denied by PDF format). If you need specialized function to add string with custom names to document info you can create it yourself that and it will do what you want, it is not too complex. Why we do not provide such function for you? Answer is very simple - there is a lot of possible options that may be added into document info dictionary, and we have no reason to make a lot of different functions doing almost same things in slightly different way, and which will be used only by several people using our SDK. Therefore we provide 3-levels SDK to deal with PDF: PXV level for interactive viewing/modification, PXC level for standard operations with PDF files when no interactions is needed (or it is realized outside our SDK), and finally PXS level to deal with PDF files and low-level. PXC level is simply set of functions to do some standard operations with PDF files, providing a bit higher level of abstraction to simplify common operations. If it is not enough, you may use low-level API (PXS level) to build your own addition to high-level API.
HTH.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
omascia
User
Posts: 48
Joined: Thu Mar 11, 2010 7:07 pm

Re: IPXS_PDFVariant

Post by omascia »

Lzcat - Tracker Supp wrote:
What's the purpose or effect of the bIndirect parameter?
It allow create string as separate (indirect) object in PDF. Please read PDF specification, section Syntax, especially its subsection Objects to know more.
Hmm. I'm not sure I would use Tracker-Software products if my goal was to learn and program by myself the details of building a PDF file, but I'll have a look at that section to learn wether or not it makes sense for a simple document property string to create it indirect or not.

You might have answered how the older API PXC_SetDocumentInfoExW did things, that would have helped me.
PXC_SetDocumentInfoExW(doc, L"Key", L"Value") was incredibly simple and perfectly working. It was a clever separation between the application programmer job and the library programmer job.

I think you didn't really understood the context of my initial question.
Lzcat - Tracker Supp wrote:
All in all, the steps required to merely add a custom property string to a PDF document while creating it are incredibly overweight for the application programmer compared to what the old API allowed to do. Kind of makes me feel like I had a nice specialized crane to help me build my applications (versions 4, 5, 5.5) and now I have received a big bag of Lego boxes to build the crane instead.
We provide simple functionality to add standard document information properties, and also provide a way to add ANY custom property which you wish (and this is not denied by PDF format). If you need specialized function to add string with custom names to document info you can create it yourself that and it will do what you want, it is not too complex. Why we do not provide such function for you? Answer is very simple - there is a lot of possible options that may be added into document info dictionary, and we have no reason to make a lot of different functions doing almost same things in slightly different way, and which will be used only by several people using our SDK. Therefore we provide 3-levels SDK to deal with PDF: PXV level for interactive viewing/modification, PXC level for standard operations with PDF files when no interactions is needed (or it is realized outside our SDK), and finally PXS level to deal with PDF files and low-level. PXC level is simply set of functions to do some standard operations with PDF files, providing a bit higher level of abstraction to simplify common operations. If it is not enough, you may use low-level API (PXS level) to build your own addition to high-level API.
HTH.
That paragraph should be written in some introduction to the new API. It would be really helpful to newcomers.
But again, PXC_SetDocumentInfoExW(doc, L"Key", L"Value") was available, isn't anymore and it's replacement, though obviously not rocket-science, now gets me to read the PDF specification to re-implement it correctly in the same way it used to work. I'm just saying that, maybe, I wouldn't have had to do this. :)
User avatar
Lzcat - Tracker Supp
Site Admin
Posts: 677
Joined: Thu Jun 28, 2007 8:42 am

Re: IPXS_PDFVariant

Post by Lzcat - Tracker Supp »

You might have answered how the older API PXC_SetDocumentInfoExW did things, that would have helped me.
It convert first string to name, second to pdf string, than took document information dictionary and set them do it using name as key and pdf string as value.
PXC_SetDocumentInfoExW(doc, L"Key", L"Value") was incredibly simple and perfectly working. It was a clever separation between the application programmer job and the library programmer job.
Maybe. But if you need to set something different (not string value) you will be not able to do this. Again, setting something with non-standard name is beyond specification (as far as setting something except string value even with standard name), this is why we do not provide simple functions for this. And yes, we replaced whole API, this is why all old functions are missed, and many of them have no direct replacements, so anyway you will need to make some extra coding when migrate to a new API.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Post Reply