Skip to main content

Hey all,


I’m looking for some clarification on the behaviour of absoluteRenderBounds when a node is close to the border of the frame. To demonstrate, I have a simple Figma file that has a node with a drop shadow effect:

Screenshot 2023-10-12 at 9.46.46 AM


Using the GET file endpoint, I see the following when I parse this node:


absoluteBoundingBox = {x: 125.0, y: 84.0, width: 375.0, height: 90.0}

absoluteRenderBounds = {x: 25, y: -24.0, width: 575.0, height: 290.0}


These results make sense and are consistent with the image representing that node when I download it with the GET Image endpoint.


However if move the node to the top left of the frame, so that the drop shadow effect is clipped by the frame, I get this when parsing the node:


absoluteBoundingBox = {x: -353.0, y: -260.0, width: 375.0, height: 90.0}

absoluteRenderBounds = {x: -353.0, y: -260.0, width 475.0, height: 182.0}


The render bounds in this case are responding to the clipping of the frame, however the downloaded image for the node is the same as before, and remains unclipped at 575x290. I’m struggling with this inconsistency, since the render bounds and the actual image bounds are now different and I’ve lost the context to know exactly where the image is positioned inside the bounding box area. To clarify further, what I was hoping for in this case is this instead:

absoluteBoundingBox = {x: -353.0, y: -260.0, width: 375.0, height: 90.0}

absoluteRenderBounds = {x: -453.0, y: -368.0, width 575.0, height: 290.0}


I can understand that the render bounds are responding to what’s actually happening in the file. I’m wondering though if the lost context can be found somewhere else, in other properties, or perhaps if there is a setting or request parameter that I’m overlooking that can help me out. I think I can work around this by looking at the actual image size and comparing it to the render bounds and frame bounds. But this will require some painful extra math and backtracking in my code that would be nice to avoid.


Hopefully this makes sense, thanks for any advice.

Just to be clear, this is the image representing the node that I download using the GET Image endpoint (in both cases), since you’re not able to embed two images in the initial post:

Screenshot 2023-10-12 at 9.51.19 AM

Yeah, the absoluteRenderBounds are going to be affected if the parent node clips contents.


If you already have the actual image size, you can derive the unclipped render bounds by finding one corner of the absoluteRenderBounds inside the parent node and then using the width/height to calculate the top-left corner of the unclipped render bounds.

Thanks for the quick response. That should work for sure, more or less how I was imagining a work around. I’m parsing the node id at the same time as I parse the bounds and don’t have the image yet at that point, so this will require a second pass through the tree which I was hoping to avoid. Just wanted to make sure I wasn’t missing something else.

Reply


Terms & ConditionsCookie settings