Replies: 6 comments
-
This sounds great! I have been collecting known label settings (as they are shared here in GH) for various printers, so if you choose to go the route of presets, I can get those in any format that is useful to you |
Beta Was this translation helpful? Give feedback.
-
I admit I don't grok JSON, but I can puzzle it out well enough with examples. I think the idea is excellent. It would support using multiple types printers without having to screenshot the various existing boxes and re-enter by hand. I also like the idea of the known good settings/sharability of the JSON templates so we all aren't trying to re-invent the wheel when it comes to label settings. With our Dymo printer it took a lot of reading though comments on Github and trial and error to get it right. |
Beta Was this translation helpful? Give feedback.
-
The labels definitely need an overhaul. I have adjusted the labels.blade.php file and updated the CSS in order to get the layout and barcode to display correctly on my dymo labels. I know this fix has worked for some, but not others. I think because labels are generally small its hard to fit a lot of content there. Having a QR code and 2D Barcode on the same label is near impossible. I would propose having 2 label types, one for 3D Barcodes and 1 for 2D, each with its own template / layout. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to let you know that we're using a custom patch since forever, that creates one big PDF including all the Labels we need, to print them on a label printer. Maybe that is a use-case for other people too. And I'm here to say I appreciate a better default label printing. (Current label patches are now blowing in my face due to old laravel vs security-advisories, when I've got to update some dependencies for the label PDFs.) |
Beta Was this translation helpful? Give feedback.
-
Labels is definitely the most frustrating part for me. To the point where I just go make my own QR codes and do my own editing around them. Personally I use a Rollo printer and I prefer larger labels but no matter the browser/settings I use, large labels just don't work right now. One thing I know for sure, other than the direct label issues themselves, is that it would be nice to see a 'test' label (QR / barcode with dummy text) that is generated when modifying the settings (or the JSON in this case). It is kind of a pain to adjust settings then having to fly to the asset page, generate a label and see what change has occurred, if anything. |
Beta Was this translation helpful? Give feedback.
-
Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. |
Beta Was this translation helpful? Give feedback.
-
I had spent some time making hand-drawn notes, and I realized it actually makes more sense to just outline my thought here before I start building anything, so people can contribute their thoughts.
Labels have always been a real challenge for Snipe-IT, largely because everybody's browsers are different, everybody's settings are different, and the printers and labels everyone uses vary wildly. (Literally even the style of printer+labels.... regular printer with sheets of labels versus a P-touch, Dymo, etc that doesn't want page breaks, and so on.)
We've tried to solve this issue in the past by expanding the labels options, which sort of worked, but LDAP and labels end up being about 80% of our support load, which is kind of bonkers.
I am loathe to add a new feature before v5, but we don't really have a choice I don't think.
So... getting to the point. Here's what I'm proposing to try and more broadly address the finickiness of labels across the boards, and hopefully provide a feature of real value which benefits the community:
I propose that we switch to a JSON format for label settings. Users that don't grok JSON can still enter form fields, but the individual label settings fields go away, and a new JSON field emerges. (We would obviously create a migration that turns your current settings into your own customized JSON entry.)
The UI would change slightly, allowing you to create multiple labels (and name them), or import "known good" ones. You'd have a choice between keeping the same UI with form fields where you set padding, etc - or toggling to paste in (or possibly import) your own JSON. Something - very roughly - like this:
or if you click "use JSON"
In v5, as we continue to expand on this, hopefully we'll even be able to make it so you can generate a test page right from the labels page.
My plan is to create two new tables - one that is a sort of "blessed" presets table, and one that contains the variations you come up with (and name).
I haven't decided yet exactly how that "blessed presets" table gets populated. I would hate to have to write a migration for every new "This 100% works on a DYMO XYZ". Maybe we create a separate repo that only contains tested label templates, and maybe we let people import them. Or maybe we keep a directory of JSON files right in the Snipe-IT repo itself. I haven't gotten that far yet, but this seems to me to be the best way moving forward. It allows flexibility and - more importantly - the sharing of "known good" defaults in a way that is less painful than filling in 100 form fields, but also allows you change them (without changing the known good version) if you decide you need to drop a font size because you want to enable a new field in the labels that you didn't have before and will make it so that the old version no longer fits.
I'd love your thoughts.
Beta Was this translation helpful? Give feedback.
All reactions