search

Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.08k stars 2.06k forks source link

Different GPX behavior without explicit MIME declaration #5009

Closed stuartpb closed 5 years ago

stuartpb commented 5 years ago

Application Version: 3.6.0

Platform: Not reported

Printer: Qidi Tech I

See stuartpb/repligreater#2 - a user reported that the profile in that repo was exhibiting different behavior (but not outright fixed/broken, if I understand the report correctly) when the line "file_formats": "application/x3g", is added to the profile.

This suggests there's a bug in Cura and/or https://github.com/Ghostkeeper/X3GWriter that's causing jobs to go down a separate code path based on the presence or absence of the file_formats declaration with extrinsic implications that aren't clearly demarcated. (Is Cura integrating X3G handling into core or something like that?)

nallath commented 5 years ago

By default the "file_formats" is set to ""text/x-gcode;application/x-stl-ascii;application/x-stl-binary;application/x-wavefront-obj;application/x3g". So if you try to save a file, it will use this list to figure out what type to use. If you subsequently override it with the x3g type, it will change what is done (Use the x3g file writer instead of the g-code one)

Ghostkeeper commented 5 years ago

Thanks for the heads-up. I've done some investigation and posted my findings in stuartpb/repligreater#2 since it contains the most information. We'll close this one as a duplicate.

I'm suspecting that this issue is more with X3GWriter to GPX interplay rather than with Cura.