Unexpected initial custom stamps background "color" value

Technical Support WebViewer
, ,
1

WebViewer Version: 8.7.0

“No” to all of these questions:

  • Do you have an issue with a specific file(s)?
  • Can you reproduce using one of our samples or online demos?
  • Are you using the WebViewer server?
  • Does the issue only happen on certain browsers?
  • Is your issue related to a front-end framework?

Is your issue related to annotations? Yes

In a version after 8.4.0 (probably 8.5.0 due to the “new options for font customization on custom stamps” changelog item), the value of Core.Tools.RubberStampCreateTool.CustomStampData.color is unexpected undefined, unless the user interacts with the Background color field in the UI.

We’re roughly retrieving the set of custom stamps in this way:

const tool = docViewer.getTool('AnnotationCreateRubberStamp');

tool.addEventListener('stampsUpdated', () => {
    console.log(tool.getCustomStamps());
});
2

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:

Guides:APIs:Forums:

3

It’s also worth noting that the data type of color when set has changed from a Annotations.Color.Core object to a hex string. Was that (breaking) change intentional?

4

Even more problematic, initializing the set of custom stamps via documentViewer.getTool('AnnotationCreateRubberStamp').setCustomStamps() with the new data structure does not work.

Specifically, the old data structure on 8.4.0 looks like:

{
    "title": "Draft",
    "subtitle": "[$currentUser] DD/MM/YYYY h:mm a",
    "id": "5817b718-3169-575b-dabf-f807ca60b0e9",
    "color": {
        "R": 79,
        "G": 153,
        "B": 100,
        "A": 1
    }
}

The new data structure looks like:

{
    "title": "Draft",
    "subtitle": "[$currentUser] DD/MM/YYYY h:mm A",
    "id": "5b4f56d9-e38e-b5bc-18d7-bc4149ba7ce4",
    "font": "Helvetica",
    "bold": true,
    "italic": false,
    "underline": false,
    "strikeout": false,
    "textColor": {
        "R": 255,
        "G": 255,
        "B": 255,
        "A": 1
    },
    "color": "#4F9964"
}

When setCustomStamps is invoked with a stamp in the new data structure, it results in an blank stamp with only a background color and no text.

5

Hi Nick,

Just so I under your concerns, you’ve saying that:

  1. Custom buttons with no set color, the color field is returning undefined
  2. You’re experiencing breaking changes as the color field is of type hex, not type Core.Annotations. Color
  3. Setting the field textColor with a rgba object results in the text not displaying

Are you looking for explanations of these changes or fixes?

Best Regards,
Zach Serviss
Web Development Support Engineer
PDFTron Systems, Inc.

6

For general context, we implemented a feature that persists user-created custom stamps to browser local storage.

Custom buttons with no set color, the color field is returning undefined

If you create a custom stamp and do not interact with this “Background color” field:

Screen Shot 2022-08-05 at 6.07.45 PM

the data structure returned from getCustomStamps has color: undefined, which is problematic and does not match the (green) default.

You’re experiencing breaking changes as the color field is of type hex, not type Core.Annotations.Color

In the scenario where you do interact with the “Background color” field (i.e. click the blue color), the data structure returned from getCustomStamps has color: "#2A85D0", which is a breaking change.

Previously, in v8.4.0, this was a Color object.

Setting the field textColor with a rgba object results in the text not displaying

I’m unsure, so let’s disregard this question for now.

Here is another question: What is the expected input to setCustomStamps? It seems this has not been updated to support the additional font style properties added in a recent version. Is that expected?

7

Yup I can confirm that if someone doesn’t select a new color and just goes with the default green, it won’t be set. I will add that bug to our backlog.

I can also confirm that yes, since 8.5 we’ve been returning the hex string, not the color object as expected. Currently investing if this is intentional or not since the documents do not reflect this change happening so thank you for pointing this out.

Currently investigating what the expected input should be. Again the documents have not been updated to reflect the new fields introduced in 8.5.

For now I can recommend for color fields to use the Color object.
ex:
color: new instance.Core.Annotations.Color('#D65656')
or
color: new instance.Core.Annotations.Color(255,0,0,1)

Best Regards,
Zach Serviss
Web Development Support Engineer
PDFTron Systems, Inc.

1 Like