Created attachment 128968 [details] [review] [PATCH 1/3] STL 3D models, ASCII and binary Those are common file formats for 3D printing with RepRap-like desktop FDM 3D printers. Used by multiple applications, so not 1-app specific. See https://github.com/kliment/Printrun/issues/796 for context. Authored by me and Rock Storm, split into 3 commits for authorship and stl/gcode separation. Git repo with those patches can be found at https://github.com/hroncok/shared-mime-info-3dprint
Created attachment 128969 [details] [review] [PATCH 2/3] Update STL specification
Created attachment 128970 [details] [review] [PATCH 3/3] Add G-code specification
Comment on attachment 128969 [details] [review] [PATCH 2/3] Update STL specification Review of attachment 128969 [details] [review]: ----------------------------------------------------------------- Please merge into the previous patch. ::: freedesktop.org.xml.in @@ +6930,4 @@ > </mime-type> > > <!-- 3D models and GCODEs --> > + <mime-type type="model/stl-binary"> If this mime-type is registered, add a link to the registration in the commit message, otherwise use: model/vnd.stl-binary @@ +6934,3 @@ > <_comment>STL 3D model (binary)</_comment> > + <acronym>STL</acronym> > + <expanded-acronym>STereoLithography</expanded-acronym> Not an acronym, you can remove that. @@ +6938,5 @@ > <generic-icon name="binary"/> > <glob pattern="*.stl"/> > </mime-type> > > + <mime-type type="model/stl-ascii"> Ditto. ::: tests/list @@ +600,4 @@ > test-secret-key.skr application/pgp-keys ooo > test-secret-key.asc application/pgp-keys xoo > > +<<<<<<< HEAD That's really not supposed to be here.
Comment on attachment 128970 [details] [review] [PATCH 3/3] Add G-code specification Review of attachment 128970 [details] [review]: ----------------------------------------------------------------- ::: freedesktop.org.xml.in @@ +6956,5 @@ > + <_comment>G-code file</_comment> > + <sub-class-of type="text/plain"/> > + <generic-icon name="text-x-generic"/> > + <magic priority="10"> > + <match type="string" value=";" offset="0"/> The magic is far too short, remove it.
Created attachment 128977 [details] [review] [PATCH 1/2] Add STL 3D models, ASCII and binary
Created attachment 128978 [details] [review] [PATCH 2/2] Add G-code specification
Thanks for the feedback and the <<<<<<< HEAD catch (sorry about that, must have lost it while rebasing). Attached new set of patches (only 2 this time).
Comment on attachment 128977 [details] [review] [PATCH 1/2] Add STL 3D models, ASCII and binary Review of attachment 128977 [details] [review]: ----------------------------------------------------------------- ::: freedesktop.org.xml.in @@ +6932,5 @@ > + <!-- 3D models and GCODEs --> > + <mime-type type="model/vnd.stl-binary"> > + <_comment>STL 3D model (binary)</_comment> > + <sub-class-of type="application/octet-stream"/> > + <generic-icon name="binary"/> This in an invalid value: ./freedesktop.org.xml:39757: element generic-icon: validity error : Value "binary" for attribute name of generic-icon is not among the enumerated set <generic-icon name="binary"/> See how to run the test suite in the HACKING file.
More test suite: binary.stl, 'data' test: expected model/vnd.stl-binary, got text/plain ascii.stl, 'name' test: expected model/vnd.stl-ascii, got model/vnd.stl-binary binary.stl, 'name' test: expected model/vnd.stl-ascii, got model/vnd.stl-binary binary.stl, 'file' test: expected model/vnd.stl-ascii, got model/vnd.stl-binary ascii.stl, 'file' test: expected model/vnd.stl-binary, got model/vnd.stl-ascii test.gcode, 'data' test: expected application/x-gcode, got text/plain 0 errors, 1188 comparisons, 203 failed (197 expected)
Created attachment 128989 [details] [review] [PATCH] Add STL 3D models, ASCII and binary and GCODEs Alright. Now the tests should pass.
Created attachment 129022 [details] [review] Add mime-type for STL 3D models and GCODE with help from Miro Hrončok <miro@hroncok.cz>
Attachment 129022 [details] pushed as 13f6032 - Add mime-type for STL 3D models and GCODE
Note that I changed the mime-types, after doing a bit more research into the registration trees. We can only use vnd when there is a registered vendor.
Thank You Bastien for your reviews and changes.
Hello, one of our members using Archlinux noticed that the Windows 10 installation ISO is wrongly detected as model/stl-binary in KDE DolphinFM(kmimetypefinder5), I wonder if the cause is on the overly ambiguous magic of this mime-type?
(In reply to Ｖ字龍(Vdragon) from comment #15) > Hello, one of our members using Archlinux noticed that the Windows 10 > installation ISO is wrongly detected as model/stl-binary in KDE > DolphinFM(kmimetypefinder5), I wonder if the cause is on the overly > ambiguous magic of this mime-type? Hi, this is really interesting. If it has the file extension '.iso' it should have never been recognized as an STL. Could you share this file? Or at least the first, say 300, bytes? Thanks.
Created attachment 135423 [details] The first 300 bytes of Win10_1709_Chinese(Traditional)_x64.iso
(In reply to Rock Storm from comment #16) > Hi, this is really interesting. If it has the file extension '.iso' it > should have never been recognized as an STL. Could you share this file? Or > at least the first, say 300, bytes? Thanks. The head of the file is all 0x0 until offset 0x8000
This file can be downloaded from https://www.microsoft.com/en-US/software-download/windows10ISO by selecting "Chinese Traditional" in the "Select the product language"
(In reply to Rock Storm from comment #16) > If it has the file extension '.iso' it > should have never been recognized as an STL. Could you share this file? This is what I get on a latest openSUSE Tumbleweed for any ISO image: $ XDG_UTILS_DEBUG_LEVEL=1 xdg-mime query filetype image.iso Running kmimetypefinder5 "/home/user/image.iso" model/x.stl-binary $ kmimetypefinder5 image.iso model/x.stl-binary $ kmimetypefinder5 -f image.iso application/zip $ kmimetypefinder5 --version kmimetypefinder 5.12.4
(In reply to Theo from comment #20) > $ kmimetypefinder5 -f image.iso > application/zip That's a copy and paste mistake. It should read $ kmimetypefinder5 -f image.iso application/x-cd-image
Reopened because this patch has apparently broken the detection of ISO 9660 image files as reported first in comment #15 seven months ago.
(In reply to Theo from comment #22) > Reopened because this patch has apparently broken the detection of ISO 9660 > image files as reported first in comment #15 seven months ago. Which was already fixed in the patch from bug 106330.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.