Force repaint for clipboard stamp elements

[MaSeife]

I have a question concerning stamp-annotation-elements that were added by copy&paste into a pdf (name contains clipboard). What I found out is that they have an appearance-attribute which has Base64 enconded content. It is some kind of XML-structure (DICT-Element with subelements). I took a look at the content for the same 'image' with different rotations. The 'image'-content remained the same. The only difference I could find was an additional Matrix-Array that was existing, whenever it was not a 'normal' orientation (0 degree). For example for a 90 degree left rotation it was

<ARRAY KEY="Matrix">
<FIXED VAL="0"/>
<FIXED VAL="1"/>
<FIXED VAL="-1"/>
<FIXED VAL="0"/>
<FIXED VAL="55.502362"/>
<FIXED VAL="0"/>
</ARRAY>

So I wanted to be clever and 'simulate' the rotation by decoding the appearance-value, adding a Matrix-Array (in relation to the rotation), encoding it back to Base64 and assigning this new value to the appearance-attribute before the annotations were added back to PDF-XChange. The problem I have: the image/stamp is still shown in 'normal' orientation afterwards - even with the new appearance-value. Is there some kind of trick to force a repaint or something? At first I thought it might be a problem of an old version of PDF-XChange-Editor (we were using some 7.x-version) but it's the same behaviour in a newer version I have tried (10.1.0 - build 380).

In the attached images you can see how the clipboard-Stamp (the about-Dialog was used for it) looks after the insertion into the PDF (as an annotation) and then after the content-processing + rotation. The size and position of the element is as expected, only the orientation and scale of the image is wrong.

Before:

Stamp-Element before.png

Afterwards:

Stamp-Element afterwards.png

For non-clipboard-stamp-elements, where the image content is somewhere in the filesystem, the workaround is to simply clear the content of the stamp-element. Afterwards the stamp is displayed as expected (e.g. rotated the right way). But that doesn't work for clipboard-stamp-elements since the 'image information' is only available within the encoded appearance-Attribute and in that case clearing the content only leads to an empty square.

[Stefan - PDF-XChange]

Hello MaSeife,

I have asked my colleagues from the dev team to take a look at this topic and get back to you as soon as possible!

Kind regards,
Stefan

[MaSeife]

Hi Stefan,

did you get any feedback from the dev team?

Regards,
Markus

[Stefan - PDF-XChange]

Hello Markus,

I can not see a reply - so I've asked once again and will chase this so that I can get you further information as soon as possible!

Kind regards,
Stefan

[MaSeife]

Hi Stefan,

since I got a reminder from our internal bugtracking system concerning the problem I wonder, if you got any feedback from the dev team meanwhile ?

Regards,
Markus

[Stefan - PDF-XChange]

Hello MaSeife,

Apologies for not following up earlier. I have once again asked my colleagues from the dev team to review this and hope to have further information for you within 24h.

p.s. I got a reply back and my colleagues say that they are not 100% sure what operation you are trying to perform there.
What are "clipboard-Stamp" and "non-clipboard-stamp-elements"?

They also told me that when we place a stamp into the clipboard we do not use XML-encoding of the stamp's appearance.
This mechanism is used when exporting stamps to XFDF.

Kind regards,
Stefan

[MaSeife]

Non-clipboard-stamps are stamps that are for example added by pressing the stamp-button in the toolbar. Then you are able to select a 'standard'-stamp like DRAFT or a customized from the palette, where the stamp is basically linked to an image in the filesystem.

But a user can also create clipboard-stamps. E.g. you have some image information in the clipboard (by pressing Alt+print) and add it into the PDF with Ctrl+V. This is also a stamp but it is not linked to some standard image information or image in the filesystem. Instead in this case the image information is stored as Base64 enconded content. That can be seen when exporting the annotations of the page.

When showing the properties of these clipboard-stamp-elements the id starts with clipboard.image. That's why I called them clipboard-stamps.

[Stefan - PDF-XChange]

Hello MaSeife,

Thanks for the clarification! I will ask our devs to take another look at this, however I suspect that you would be better off if you paste the clipboard data via your code, and then rotate it using the tools available in the SDK rather than trying to force the matrix - and the second approach will likely need a lot more reading into the PDF specification too!

I will get our devs attention now and you can expect a follow up from them later!

Kind regards,
Stefan

[MaSeife]

Hi Stefan,

any input from your developers? We still have the problem, even with newer versions of the SDK.

Regards,
Markus

[Sean - PDF-XChange]

Hi MaSeife,

Sorry for the delay in this - I will give the developers a nudge.

Kind regards,