Cura: [3.4.1] Scaling issues

[pick013]

I'm trying to scale an stl file in Cura 3.4.1 and it is not doing what is needed. I uncheck the uniform scaling option then attempt to scale the object 123% X plane, 123% Y plane and leave the Z plane at 100%. Cura then does weird things and generates whole different scaling in each of the planes.

Application Version Cura 3.4.1

Platform Windows 10

Printer Both Anet A8S and Tevo Tarantula

Steps to Reproduce Open file
click on object to rotate
click on scale to scale object
uncheck "Uniform Scaling"
enter 123 in both X and Y slots, leave Z at 100
Cura then automatically adjusts X and Y to odd scale values...117.67 X value and 104.53 Y value...leaving Z value at 100

Actual Results

Expected results In Cura 3.2.1 scaling works as needed....123% X plane, 123% Y plane, 100% Z plane....

Additional Information

[diegopradogesto]

This is a known issue to us and we are working on it currently. Thanks for reporting.

[printingotb]

I noticed this too. Until there is a fix, it seems that if you do the math and enter X, Y and Z in mm instead, it works better. The % will still show wrong, but the mm are correct. At least for me.

[alexbaucom17]

This is also an issue for me. Glad to see the team is working on it.

@printingotb Your suggestion works for me as well. Thanks!

[probotico]

Hi there,

same bug here, solved by scaling first rotating later on latest version 3.4.1
pain in the ass, please work this out.

glad to help anytime.
video proof:
https://youtu.be/W02AWSGFhjo

[ctmakro]

samebug. isn't this supposed to be fixed first before everything?

[Ghostkeeper]

We decided to wait with this until we can transition to transformations via the Trimesh library. Trimesh should simplify this sort of thing for us.

isn't this supposed to be fixed first before everything?

Before the bug that causes CuraEngine to run at 100% CPU while not slicing? Before implementing translations for Cura 3.5? Before the firmware update uploading the wrong binary to the printer? No. Plenty of things are considered more important than the percentage calculation of non-uniform scaling after rotation being inaccurate. Especially since it's a fairly hairy problem to fix.

[aschor]

hi, Just updated from 3.2.1 to 3.6. Just reporting that I fell in that bug in 3.6, it's still there (expected, as bug is not closed. but that is strange when you face it for the first time).

Nota : I can't change any scaling, even before rotating it will screw everything. (I tried only % )

[ackerman76]

This is a complete blocker with some models. You cannot scale xy at one value, percentage or length, then scale z at another, or another length. The checkbox Uniform Scaling unticked is ignored and every update to any box automatically recalculates all other boxes.

There is no work around.

This is frustrating. Now I have to revert from 3.6 to 3.2.1? and lose all my configs and settings for all my printers??

[iaglet]

I noticed the same bug with 3.6.0. If you scale prior to rotation, it does appear to properly scale. It's when you scale after rotation that all goes wonky. If you adjust the size after rotation, that does appear to work (and the corresponding original axis percentage is what changes). But any changes to the percentages after rotation totally corrupts the scaling.

[bmferry]

And it's still broke with 4.0 Beta. I just scale the directions I need to scale, X and Y, visualizing which current directions will BE X and Y after I rotate it.

[ackerman76]

This is complicated because you are inferring too many things with the six boxes.The percentages are limited to fewer decimal places and lower resolution.

You are trying to guess what the user wants to do and you've made it worse over time.

When I want to scale something in X and Y and keep Z at 100%. I have no idea what order to make changes or tick the box. I try entering exact values and it still changes stuff regardless if the box is ticked or not. With the box not ticked, my changes STILL MODIFY OTHER AXIS VALUES... WHY???

It also seems to remember the original orientation of the STL when you load it. For example when the STL loads tall and skinny and I rotate 90 deg from Z down, then it acts completely different.

In my last prints it appears the scaling was correct looking at the model on the build plate, X and Y to 110% and Z remain at 100%; however the displayed scale numbers and percentages were completely wrong! I was guessing trying to see if the model actually changed, of course waiting while it redrew lol.. what must we do, compare and overlay screenshots?

I suggest you step back and simplify this. Make the tick box all or nothing. If you tick the box all are linked and slammed to the same percentage or dimension last entered. If the box is not ticked, nothing is linked at all: all three are independent and will not be auto changed. No more decision tree memory or permanently linking two axes regardless of the tick box, or so it seems.

Ensure the values displayed are what are actually applied to the model.

Pick ONE way to do this and just tell us how to use it. We can easily calculate and enter exact dimensions. Or else make a toggle screen UI that switches between specific modes or makes some fields readonly. Be clear in both implementation and to us users what is going on, specifically: is the new entry mode affected by previous modifications, or are we setting everything anew with these new values?

Thank you kindly!

[nallath]

The problem is that it still doesn't solve the global vs local transformation. It's easy to solve if there is only one model, but what should be done if there are 2 models.
Lets take the following example:
You have one model that is rotated in such a way that x = y, y = z and z =x.
If you scale this on world space x = 50, you should get 100%, 100%, 50%
If you scale this locally (also x =50) you should get 50%, 100%, 100%
The issue is what to do if there are two models, so let's say you add another object which is not modified / rotated in any way.

[radekkpl]

I think problem is not in math, but in field update methods (value change).

If you enter new value in X(mm) then Z(%) is updated
But if you enter new value in X(%) then X(mm) is updated, then Z(%) is updated

So I think (without code checking) Xmm field updates Z% value. and Zmm updates X% value.

[Ghostkeeper]

No, the problem is not that we linked the text fields to the wrong axes. After all, if you perform your test without rotating the object first, then it works fine.

[PrEzi3]

Same issue with Cura 4.0 and 4.1 Beta + provided some repeatable examples incl. STL links in the Ultimaker section for Cura --- see here :
https://community.ultimaker.com/topic/28066-cura-40-41-beta-bug-with-x-y-z-scaling/

[2-k]

So isn't the % the size of the original model so why does adding the same % to XY a few times repeatedly make the model stretch out flat? Used to be based off starting % for me. My models also like to rotate themselves or not lay flat. I'm wondering if this is all a orientation issue, when I move the model it shows it's moved, but the scaling is off and it prints in the original orientation. Preview feature shows them correctly positioned or laying flat but prints different.

[kepbrown]

My work around is to rotate the model to the position I want then export to STL, reopen the exported file and work with it from there. #6487 It works around the issue with support blockers.

[lpenderg]

Still seeing this in 4.3.1.

[g2721]

Seeing this bug in Cura 4.4.1 (MacOS)

[SivaasPlays]

I'm curious how this is still an issue after 2 years?

[nallath]

Because other things have gotten priority.

[gmgossage]

I just updated to Version 4.5.0, and I am still running into this issue.

[mahtDFR]

There's a related internal ticket: CURA-6720

[Ghostkeeper]

@mahtDFR Our main ticket for this is CURA-5611 currently.

[64Florian]

Let me props a "dirty" workaround for this issue :

hem .. In fact I miss some use cases I think :-( ..

[lpenderg]

I don't understand why this is not solved.  Why can they not keep track of how an object has been rotated,

and scale it appropriately?

------ Original Message ------
Received: 02:10 PM CDT, 05/25/2020
From: TFlorian [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Comment [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  Let me props a "dirty" workaround for this issue :


  —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633688433", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633688433", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[64Florian]

@ lpenderg, in fact it's could be not so easy as I was thinking in my moke-up :'(
Tack a "basic 1cmCube.zip" and rotate it 45°

As expected the size on the build plate change (from 10 mm to 14.1421 mm)

Now if I want to increase the size by 150% in one direction ...

If I was good, on my moke-up, the square should be a rectangle ... (15x10x10 and 45° rotate)
(_I have disabled the "Snap scaling" and "Uniform scaling" but while my capture they came back due to a shortcut_)

but it's not the case

Why ? just because you have "lose" the original format of your object ...
But why ?
In fact I think it's to not have to "remember" all transformation of the model (scales/ rotation / ...)

OK Y didn't understand why / how from 150% I'm back to 127.48 % ... but it could be because the "new" object ... hem .. no ... trying to rotate 45° back, it's not the case (I have to rotate 57° more or less)

Note for support and dev team: don't be fooled by my checkbox "Snap scaling" and "Uniform scaling" They are Blue, but it's my shortcut to made partial screenshot on my Mac which react with those checkbox :-/

[lpenderg]

You have a good point.  I am generally scaling things that are aligned with the coordinate axes.  I think the answer for me is the workaround, which is to do all of your scaling at once, either before or after rotating the object, but not both.

------ Original Message ------
Received: 05:14 PM CDT, 05/25/2020
From: TFlorian [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Comment [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  @ lpenderg, in fact it's could be not so easy as I was thinking in my moke-up :'(
     Tack a "basic 1cmCube.zip" and rotate it 45°

     As expected the size on the build plate change (from 10 mm to 14.1421 mm)

  Now if I want to increase the size by 150% in one direction ...

     If I was good, on my moke-up, the square should be a rectangle ... (15x10x10 and 45° rotate)
     (I have disabled the "Snap scaling" and "Uniform scaling" but while my capture they came back due to a shortcut)

  but it's not the case


  Why ? just because you have "lose" the original format of your object ...
     But why ?
     In fact I think it's to not have to "remember" all transformation of the model (scales/ rotation / ...)

  OK Y didn't understand why / how from 150% I'm back to 127.48 % ... but it could be because the "new" object ... hem .. no ... trying to rotate 45° back, it's not the case (I have to rotate 57° more or less)


  Note for support and dev team: don't be fooled by my checkbox "Snap scaling" and "Uniform scaling" They are Blue, but it's my shortcut to made partial screenshot on my Mac which react with those checkbox :-/

  —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633729728", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633729728", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[iaglet]

Generally the issue is not when rotation occurs to a full 90 or 180. The workaround would work there. It is the off angle rotation. For whatever reason the math is not set up because scaling in any axis affects scaling in two of the original axises.

Regards, Stephen W

---

From: lpenderg [e-mail]
Sent: Monday, May 25, 2020 6:53:18 PM
To: Ultimaker/Cura [e-mail]
Cc: iaglet [e-mail]; Comment [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

You have a good point. I am generally scaling things that are aligned with the coordinate axes. I think the answer for me is the workaround, which is to do all of your scaling at once, either before or after rotating the object, but not both.

------ Original Message ------
Received: 05:14 PM CDT, 05/25/2020
From: TFlorian [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Comment [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

@ lpenderg, in fact it's could be not so easy as I was thinking in my moke-up :'(
Tack a "basic 1cmCube.zip" and rotate it 45°

As expected the size on the build plate change (from 10 mm to 14.1421 mm)

Now if I want to increase the size by 150% in one direction ...

If I was good, on my moke-up, the square should be a rectangle ... (15x10x10 and 45° rotate)
(I have disabled the "Snap scaling" and "Uniform scaling" but while my capture they came back due to a shortcut)

but it's not the case

Why ? just because you have "lose" the original format of your object ...
But why ?
In fact I think it's to not have to "remember" all transformation of the model (scales/ rotation / ...)

OK Y didn't understand why / how from 150% I'm back to 127.48 % ... but it could be because the "new" object ... hem .. no ... trying to rotate 45° back, it's not the case (I have to rotate 57° more or less)

Note for support and dev team: don't be fooled by my checkbox "Snap scaling" and "Uniform scaling" They are Blue, but it's my shortcut to made partial screenshot on my Mac which react with those checkbox :-/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633729728", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-633729728", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FUltimaker%2FCura%2Fissues%2F4136%23issuecomment-633736173&data=02%7C01%7C%7C0993e152f70148f7ac5c08d800fe6b09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260439995327409&sdata=ySeezcAi8Ax7Li2yLox3Rgsnb94tD%2BtHRqEKf6K%2BCg4%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAILNGQJ6DDJDMJAZAVR74BLRTLZF5ANCNFSM4FMGQ5CQ&data=02%7C01%7C%7C0993e152f70148f7ac5c08d800fe6b09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260439995327409&sdata=nGOxG2905lQaHsLy0RFrV%2FZfFUQvmbHaGalql2f7A4Q%3D&reserved=0.

[Ghostkeeper]

As far as I know, the currently proposed/planned solution is to make turn the percentages for scaling into an operation that applies the scale and then makes that the new 100%. We're not real happy with it either, but if you look through other applications, a lot of them work that way too.

[mikegee81]

When I change the orientation and modify the scaling, the units and percentage do not align.
I scaled the X axis from 165mm to 200mm and Z-axis increases above 100%.
Following this issue for a fix, thanks.

[Mearman]

Likely the same as #7946

[lpenderg]

Which, in turn, appears to be a dupe of #4136.

------ Original Message ------
Received: 06:49 AM CDT, 06/18/2020
From: Joseph Mearman [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Comment [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  Likely the same as #7946

  —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-645965155", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-645965155", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[Mearman]

@lpenderg this is #4136

[fieldOfView]

In the latest release of Mesh Tools, there is a function to "Apply transformation to mesh". This applies the current scale and rotation to the selected mesh(es) and resets their local coordinate systems. After that, non-uniform scaling should apply to the proper axis (until you rotate the model again). This could be a workaround until the issue is properly fixed in Cura.

[Ghostkeeper]

That is a similar solution as to what we're envisioning for this problem.

[EasifyDev]

Still an issue in 4.6.2, uncheck uniform scaling, change Z axis percentage, X axis value also changes.

[dionrowney]

Still an issue in 4.7!!! Total pain. I have to use another product to scale one direction?

[lpenderg]

Assuming that your object is initially oriented in alignment with the coordinate axes (and most are), you can do any non-uniform scaling before you apply any rotations to the part, so that the scalings are performed to the intended axis or axes.  I've run across a few parts that are initially at funny angles to one or more axes, and about all you can do with those objects is to scale them uniformly.

There isn't a good solution to this issue that doesn't get ugly if objects are rotated to non-orthogonal angles, but what they should probably do is to recompute the individual axis scalings as appropriate whenever an object is rotated after scaling.  That's the only way that scaling can remain usable after something is rotated. 

------ Original Message ------
Received: 08:02 PM CDT, 09/01/2020
From: dionrowney [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Mention [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  Still an issue in 4.7!!! Total pain. I have to use another product to scale one direction?

  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-685216879", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-685216879", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[funx24x7]

It's a bit confusing as to how this problem has been around for over two years. I don't mean to sound overly critical, I'm no programmer and I don't know how Cura works behind the scenes, but this seems to be a non-issue in any other 3D program.

The fact that support blockers can scale based on the orientation of their parent object suggests to me that the solution is hiding in plain sight:

What I'm seeing here is a scale transformation that is affected by an object's rotation. Is the answer not as simple as getting this type of transformation to apply to the correct object?

Furthermore, couldn't you parent the transform handles to an object in a similar way that support blockers are parented to the object they're placed on?

[lpenderg]

It sounds like that could be a good work-around, and also suggests to me that maybe you could fix this by being able to select either world-relative or object-relative scaling.  Pretty much all objects are aligned to one or more of the coordinate axes at design time, so this should work for almost any .STL files you are likely to come across.

------ Original Message ------
Received: 04:49 PM CDT, 09/08/2020
From: funx24x7 [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Mention [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  It's a bit confusing as to how this problem has been around for over two years. I don't mean to sound overly critical, I'm no programmer and I don't know how Cura works behind the scenes, but this seems to be a non-issue in any other 3D program.

  The fact that support blockers can scale based on the orientation of their parent object suggests to me that the solution is hiding in plain sight:



  What I'm seeing here is a scale transformation that is affected by an object's rotation. Is the answer not as simple as getting this type of transformation to apply to the correct object?

  Furthermore, couldn't you parent the transform handles to an object in a similar way that support blockers are parented to the object they're placed on?

  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-689154937", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-689154937", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[Ghostkeeper]

The issue also occurs without there being a support mesh present in the scene. Support meshes are a bit special because they share the transformation applied to their parent objects, but the issue itself with non-uniform scaling and rotation has nothing to do with that relation.

The reason why this is a non-issue in other 3D applications is, in my belief, because they either have a scale function that is directly applied (resetting the scale factor to 100% afterwards) or because they don't allow nonuniform scaling, or because they keep rotation and scale in a fixed order. Most applications have option 1 here or some flavour of it, and that's probably explicitly chosen to make implementation easier.

[CarnageMarkus]

I still have this scaling issue in 4.7.1 , If I rotate object, from it's initial position and start scaling it by one axis at the time. All other axes start chaging. If I rotate object back to it's original position, scaling works as expected.

This issue is here and coming back for solid two years now....
I have worked with 3D modeling software for years, I think you should introduce local and global transformations. That would solve quite few headeaches for you. People will learn to leverage it in time...

[lpenderg]

Yay!  So this should be resolved in the next release, I hope...

------ Original Message ------
Received: 10:37 AM CDT, 10/13/2020
From: Remco Burema [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Mention [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  Closed #4136 via Ultimaker/Uranium#646.

  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#event-3872077141", "url": "https://github.com/Ultimaker/Cura/issues/4136#event-3872077141", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[rburema]

@lpenderg We're currently on schedule for 4.8. Unless QA thinks this fix is bad enough that we should revert it, we're at least getting the solution now provided yes :-)

[lpenderg]

That's great, glad that it's finally fixed... again.  :^)

------ Original Message ------
Received: 12:40 PM CDT, 10/13/2020
From: Remco Burema [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Mention [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  @lpenderg We're currently on schedule for 4.8. Unless QA thinks this fix is bad enough that we should revert it, we're at least getting the solution now provided yes :-)

  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-707902194", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-707902194", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[nallath]

Turns out that we thought that our previous solution didn't work, but it actually did.... It was just that someone commented out the solution because of another bug (instead of fixing the other bug).

Sigh...

[lpenderg]

Sigh, indeed...

------ Original Message ------
Received: 02:30 AM CDT, 10/14/2020
From: Jaime van Kessel [e-mail]
To: Ultimaker/Cura [e-mail]
Cc: lpenderg [e-mail], Mention [e-mail]
Subject: Re: [Ultimaker/Cura] [3.4.1] Scaling issues (#4136)

  Turns out that we thought that our previous solution didn't work, but it actually did.... It was just that someone commented out the solution because of another bug (instead of fixing the other bug).

  Sigh...

  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
   [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-708217115", "url": "https://github.com/Ultimaker/Cura/issues/4136#issuecomment-708217115", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]