add simple label printing function

[powermik]

Add two links to show_part_info.php to generate labels for printing with a label printer with basic part info and a qr-code

[ubruhin]

Vielen Dank für deinen Code! Ich könnte mir vorstellen, dass wir das in die Version 0.4.0 aufnehmen werden. Ich hätte aber noch ein paar Fragen, da ich selber keinen Labeldrucker habe ;-)

Diese zwei neuen Seiten kann man dann einfach über die Druckfunktion des Browsers mit einem Labeldrucker ausdrucken, und die Seite wird schön auf das Label eingepasst (Position und Zoom)?

Wie sieht es denn aus wenn man mehrere Labels auf einmal drucken möchte, z.B. alle Lagerorte mit einem Klick ausdrucken. Müsste man da einen PDF Export machen, mit je einer Seite pro Label?

Und dann gibt es ja bestimmt noch verschiedene Label Formate, ich nehme an dein Code ist genau auf das Format deiner Labels angepasst?

Im QR-Code ist ja die ganze URL zum Artikel drin. Ich nehme an, dein Scanner kann dann direkt auf die jeweilige Seite weiterleiten? Ich denke mal das würden wir jedoch nicht so übernehmen, ein String wie "Part-ID=###" wäre bestimmt sinnvoller, es gibt ja auch andere Möglichkeiten als nur die Weiterleitung im Browser.

Ich habe mal zwei Screenshots gemacht, dann muss nicht jeder den Code selber ausprobieren, der das Resultat sehen möchte :-)

[powermik]

Hallo!

Ich habe part-db erst vorgestern entdeckt und einfach mal installiert und ein paar Produkte testweise angelegt und ich habe sofort das Druckenfeature vermisst.

Ich besitze einen Brother QL-700 und mit etwas Feintuning bei den Druckeinstellungen (und jetzt noch etwas nachjustieren im css....) passen die kleinen Labels auf 62x40mm und die grossen quer auf 62x90mm. Da dass Drucken eines Label bei mir nur wenige Sekunden dauert und nicht so oft neue Labels dazukommen werden, ist Mehrfachexport für mich kein Thema. Ich würde einfach alle Labels in eine Datei drucken und nachher alle auf einmal.

Alle Lagerorte mit einem Klick oder wie (ich jetzt im Issues gesehen habe...) eine oder mehrere Seite(n) für einen Lagerort könnte man auch per HTML-Seite erledigen wäre eigentlich auch relativ einfach zu implementieren

Ich finde schon dass die ganze URL Sinn macht: QR-Code mit dem Handy gescannt - auf Rausnehmen geklickt -> fertig. Keine Extra-App oder Logik am Handy notwendig

[weinbauer73]

Ich habe selbst einen Dymo Labelwriter 310 hier. Da die Labelwriter von CUPS nur halbherzig zusammenarbeiten, habe ich in einem anderen Projekt ein für ein Label passendes PPD erstellt und lasse die Aufkleber als PDF erstellen und ausdrucken. PPDs für Dymo Labelwriter 320 und 400 existieren, für andere Labeldrucker wie meinen könnte man es anpassen. Unter Windows ist das vorgehen ähnlich, halt nur über die Druckfunktion des Clienten.

[ubruhin]

Okay, ich lass das hier mal so stehen, ich habe momentan sowieso nicht die Zeit, dieses Feature einzubauen. Ausserdem wäre das ja eher was für dich, @weinbauer73, da du ja selbst einen solchen Drucker besitzt.

[sandboxgangster]

Drucker ist bei mir auch noch in Planung, aber erst wen die Barcode Geschichte fertig ist, zum Export in eine PDF bei Chrome kann man dem DL des PDFs mitgeben das es beim Offnen gedruckt wird ob das bei den anderen Browsern geht ka. aber das würde das Druckproblem Lösen. So wollte ich das auch mit den Barcodes machen PDF generieren per PHP (benötigt mod-pdf)(das PDF Format kann das, QR geht auch), ansonsten gibt es keine kostenlosen, OpenSource Lösungen die man Problemlos einbinden kann.

@ubruhin finde deine Lösung auch besser man könnte das ja über die config einstelbar machen, so wie ich es jetzt rausgelesen habe ist die ID bei allen Lösungen drinnen, und den rest der URL setzt man dann in der config so wie man es braucht.

[ubruhin]

Nun, die URL im QR- ist sicher nützlich, um mit einem QR-Code-Lese-App auf einem Smartphone direkt zur Bauteil-Seite eines gescannten Bauteiles zu kommen. Allerdings sehe ich da das Problem, dass wir Entwickler dann nie mehr die URL unserer Seiten ändern dürfen, weil sonst alle Anwender all Ihre Labels neu ausdrucken müssen. Ich finde, wer dieses Feature wirklich braucht, der kann (muss) sich das halt selber zusammenbasteln, mit dem Risiko dass mit einem Update von Part-DB möglicherweise alle Labels unbrauchbar gemacht werden. Offiziell darf so ein Feature allerdings nicht in Part-DB angeboten werden finde ich (damit schneiden wir uns nur ins eigene Bein).

Gibt es keine Apps, mit denen man gescannte QR- oder Barcodes direkt in ein Eingabefeld im Browser ausgeben kann? Dann wäre das Problem gelöst...

Wenn wir QR- oder Barcodes offiziell in Part-DB unterstützen, muss es natürlich auch eine extra Seite geben, mit der man sehr schnell (mit einem Scanner gescannte) Bauteile anzeigen, einbuchen, abbuchen usw. kann. Also eine Seite, extra für den Umgang mit dem Scanner. Mit dem Smartphone kann man diese Seite dann allerdings eben nur nutzen, wenn es eine App gibt, die die Ausgabe eines gescannten Codes direkt in ein Eingabefeld im Browser schreiben kann.

In den Code selbst gehören grundsätzlich nur zwei (drei) Informationen:

• um was es sich handelt (Bauteil, Lagerort, Baugruppe,...)
• und die ID dieses Elementes
• (und am Schluss ein 0x13 [Enter] um das HTML-Formular abzuschicken)

also z.B. ein String der Form "PART-44\r", "STORELOC-12345\r" o.Ä., oder (z.B. für Barcodes die nur Zahlen erlauben) kann die erste Information auch durch eine Zahl codiert werden, z.B. "001" für "Bauteil", "002" für "Lagerort" usw. Wobei solche Barcodes vermutlich eh nicht geeignet sind, da man dann wohl kein 0x13 am Ende anhängen kann...

Auf dem Label selbst dürfen natürlich noch mehr Informationen stehen (Bauteilnamen usw.), im Code haben solche Informationen allerdings nichts zu suchen.

[sandboxgangster]

Beim Barcode ist das egal mit dem ENTER das kann man bei jedem Scanner konfigurieren das er das macht.

Es gibt aber auch Barcode Arten die das können, da macht der Scanner das per Anweisung im Barcode.

[ubruhin]

Ah ok, das ist ja noch besser :-)

Sollte man dann vielleicht am besten Codes definieren, die nur aus Ziffern bestehen (z.B. die ersten zwei/drei/vier Ziffern definieren ob Bauteil, Baugruppe, Lagerort usw., und hintendran die ID), damit nachher jeder erdenkliche Code verwendet werden kann? Also der Benutzer kann dann selber entscheiden welchen Code er verwenden möchte (in der config.php definieren). Meint ihr das wäre eine gute Idee?

[powermik]

ups, des sollte ein eigener Pullrequest werden...

[powermik]

Zum QR-Code/Barcode: Nur die ID in den QR-Code zu kodieren würde den QR-Code kleiner machen und damit auch die Labels handlicher. Eigene App würde ich dann als HTML5-Seite mit Javascript erledigen, siehe als Beispiel: http://www.webqr.com Das Problem dabei ist dass getUserMedia im Moment keine Möglichkeit bietet die Kamera auszuwählen mit der gescannt wird und bei meinem Handy die Frontkamera standardmässig ausgewählt ist. Auch der Browser (in dem Fall Chrome) bietet leider keine Einstellungsmöglichkeit welche Kamera verwendet wird.

[weinbauer73]

Ob in dem QR-Code auch die URL vorhanden sein sollte, könnte man ja auch in der Konfiguration ablegen. Mir schwebt dabei nicht nur die Verwendung "zu Hause", sondern auch in einem größeren Kontext vor. Mal schauen, was mir mein Labelwriter ermöglicht. Wenn der Code steht, könnte man auch Etiketten für Baugruppen anfertigen, was eventuell zu A5 oder A4-Etiketten führen würde.

[ubruhin]

@powermik Das wäre genau das, was ich gesucht habe :-) Nur schade dass man die Kamera (noch) nicht auswählen kann...

@weinbauer73 Naja ich wüsste nicht, was das definieren der URL in der config bringen soll? Das Problem ist ja, dass ein ausgedruckter QR-Code ab dem Moment des Ausdruckens eine URL gespeichert hat, die sich nicht mehr ändern kann. Wir Entwickler dürften dann nie mehr die URL unserer Seiten ändern, sonst funktionieren die QR-Codes aller Part-DB Benutzer nicht mehr. Das würde wohl sofort zu Reklamationen führen ;-)

Eigentlich wäre ein Abtippen des Barcodes von Hand (wegen fehlendem Scanner auf dem Smartphone) ja auch eine (vorübergehende) Möglichkeit. In das Eingabefeld, in das der Scanner schreiben würde, kann man ja den Code auch von Hand eintippen wenns sein muss. Wenn wir nur Zahlencodes verwenden geht das auch relativ schnell, die Codes sollten ja nicht allzu lange werden bei einem Hobby-Lager mit höchstens ein paar tausend Bauteilen (also max. 4-stellige IDs). Der entsprechende Code steht ja jeweils direkt unter dem Barcode in Klartext. Wäre aber natürlich nur ein Workaround, solange es keine bessere Variante gibt...

[weinbauer73]

Einmal würde das Fehlen der URL nur die ID in den QR-Code bringen, was dann in jeglicher Form weiterverarbeitet werden kann. Zum anderen gibt es mod_rewrite beim Apache und ähnliches bei anderen Webservern.

Meine Idee dabei ist, die komplette URL für Serviceberichte zu Baugruppen zu nutzen. Das ist bisher nicht in Part-DB vorgesehen, könnte aber später hinzugefügt werden. So könnte man ein Errata zu der Baugruppe erstellen, was zu einer Überarbeitung führen könnte.

[ubruhin]

Um die Zahlencodes möglichst kurz zu halten, würde sich übrigens die folgende Variante anbieten: Die erste Stelle definiert, um was es sich handelt:

• 1 = Bauteil
• 2 = Baugruppe
• 3 = Lagerort
• usw.

Direkt hinter der ersten Stelle (ohne Trennzeichen) folgt dann die ID des entsprechenden Bauteiles/Baugruppe/wasauchimmer. Beispiele:

• Code "123" ist das Bauteil mit der ID 23
• Code "39" ist der Lagerort mit der ID 9

Bei einem Hobby-Lager mit maximal 9'999 Bauteilen ist der Code für ein Bauteil maximal 5-stellig, bei max. 999 Bauteilen sogar nur maximal 4-stellig. Das kann man auch von Hand noch sehr gut abtippen.

Sollte (aus was für einem Grund auch immer) eine Stelle für die Art des Elementes nicht mehr reichen, kann man z.B. die 9 reservieren, um noch eine zweite Stelle für die Art des Elementes zu benutzen. Also wenn am Anfang eine 9 kommt, muss auch noch die zweite Stelle herangezogen werden, um zu entscheiden um was für ein Element es sich handelt. Die ID beginnt dann erst ab der dritten Stelle. Das lässt sich auch beliebig erweitern, so dass es theoretisch unbeschränkt viele Arten von Elementen geben darf. So bleiben wir flexibel, und gleichzeitig sind die wichtigsten Codes möglichst kurz.

[ubruhin]

Hmm also Servicehefte ist wohl vor allem was für Firmen, und ich denke nicht dass Firmen mit einem Smartphone QR-Codes scannen gehen. Firmen haben doch entweder Scanner in Verbindung mit einem Computer, oder mobile Scanner (die aber vermutlich auf ein ganz bestimmtes Lagerverwaltungssystem zugeschnitten sind nehme ich an? Damit wären diese sowieso nicht mit Part-DB nutzbar). Und wenn Scanner in Verbindung mit einem PC eingesetzt werden, brauchen wir keine QR-Codes, dann genügen normale Barcodes (die wie schon erwähnt auch noch platzsparender sind) und eine entsprechende Oberfläche am PC (in unserem Fall eine Webseite) wo man mit dem Scanner reinschreibt. Und diese Oberfläche kann noch viel mehr als nur zur Bauteil-Seite weiterzuleiten, man kann direkt Einbuchen, Abbuchen, Bauteile zu einer Baugruppe hinzufügen lassen, zum Bestellen vormerken usw.

Meine Meinung ist also zusammengefasst: QR-Codes sind nett für den Hobby-Anwender, weil man sich mit einer 0815 Smartphone App direkt zur Seite eines mit der Kamera fotografierten Labels eines Bauteiles weiterleiten lassen kann. Im professionellen Bereich wird das (mMn) kaum gefragt sein, da arbeitet man mit richtigen Scannern. Und dann gibt es den Nachteil, dass sich die URLs von Part-DB nicht ändern dürfen (und wenn doch, muss es z.B. mit der .htacces wieder korrigiert werden). Alles in Allem ist es für mich fragwürdig, ob so ein Feature offiziell in Part-DB angeboten werden soll. Eine professionelle Lösung hingegen (mit normalen Barcodes) lässt sich ohne Weiteres auf saubere Art implementieren (mit dem einzigen Nachteil, dass es schlecht mit einem Smartphone als Scanner verwendbar ist [zumindest solange es keine Part-DB App gibt]).

Darüber lässt sich aber streiten... ;-)

[powermik]

Die Idee mit den Prefixes bei der Part-ID gefällt mir und ich habs gleich mal eingebaut

in der .htaccess im Hauptverzeichnis, einziges Problem ist mir RewriteBase, ich habe keine Ahnung wie man dass ohne fix setzen hinbekommt:

RewriteBase /partdb/Part-DB RewriteRule ^id/1(._)$ show_partinfo.php?pid=$1 [R] RewriteRule ^id/2(.)$ show_device_parts.php?device_id=$1 [R]

/id/11 macht einen redirect auf /show_part_info.php?pid=1

Macht auch die URL im QR-Code gleich kürzer und die /id/[CODE] "Suchfunktion" ist auch gleich für 1D-Barcodescanner verwendbar

[powermik]

RewriteBase /partdb/Part-DB RewriteRule ^id/10_([0-9]+)$ show_partinfo.php?pid=$1 [R] RewriteRule ^id/20([0-9]+)$ show_device_parts.php?device_id=$1 [R]

ignoriert auch führende Nullen: 1000000000001 -> pid=1 - für Barcodes mit fixer Länge

[ubruhin]

Übrigens, was noch gar nicht berücksichtigt wurde (zumindest Ich habs erst jetzt gemerkt):

Gegen einen Umzug der Part-DB auf einen anderen Server (andere URL) hilft auch keine .htaccess mehr, dann kommt man nicht mehr drum herum alle existierenden QR-Codes neu auszudrucken.

Kommt natürlich sehr selten vor, möglich wäre es aber schon dass z.B. jemand zuerst einen Server im LAN verwendet, und später auf einen Server eines Hosters wechselt um die Part-DB auch ausserhalb vom eigenen LAN verwenden zu können (oder auch umgekehrt).

Gerade wenn die Benutzerverwaltung kommt (mit Login), wird es übrigens vermutlich einige Leute geben, die dann vom LAN ins Internet ziehen (mich vermutlich eingeschlossen).

[weinbauer73]

Auf dem eigenen Server oder im eigenen Netz hilft dann ein Redirect in der htaccess, ansonsten wäre in einer App das manuelle Ändern der Basis-URL notwendig. Man könnte ja auch ein Barcode nehmen, der die Basis-URL enthält und an der Lagerstätte (z.B. Regal) angebracht wäre. Der zweite Barcode direkt in der Ablage würde zum Ziel führen. So würde man nur einen Aufkleber ändern.

[ubruhin]

Auf dem eigenen Server oder im eigenen Netz hilft dann ein Redirect in der htaccess

Dazu muss aber der alte Server nach wie vor vorhanden sein. Wenn ich Part-DB vom LAN ins Internet verschiebe, stelle ich meinen alten Server ab, da ich den dann nicht mehr brauche. Eine Weiterleitung ist damit nicht mehr möglich.

ansonsten wäre in einer App das manuelle Ändern der Basis-URL notwendig

Genau das wäre der Favorit aller Lösungen. Wenn es eine eigene Part-DB App gibt, brauchen wir keine QR-Codes mit Internetadressen, sondern dann genügen die ganz normalen Barcodes, die unabhängig von der URL der Part-DB sind. In dieser App stellt man dann die Basis-URL von Part-DB einmal ein, und fertig. Ändert die URL von Part-DB, muss man nur die Basis-URL im App anpassen und alles passt wieder.

Eine eigene App zu entwickeln gibt aber viel Arbeit und wird daher höchstwahrscheinlich in absehbarer Zeit nicht möglich sein (es sei denn, es findet sich ein erfahrener App Entwickler der Zeit hat). Als Alternative zu einer eigenen App ist ja eben genau dieser Pull Request, dank der URL im QR-Code kann man jede 0815 QR-Code-Lese-App verwenden, um die QR-Codes zu scannen. Die App öffnet dann direkt die Seite des gescannten Bauteiles im Browser. Hätten wir eine eigene App, wäre dieser Pull Request (in dieser Form, also mit der URL im QR-Code) und damit auch die ganze Diskussion überflüssig.

Man könnte ja auch ein Barcode nehmen, der die Basis-URL enthält und an der Lagerstätte (z.B. Regal) angebracht wäre. Der zweite Barcode direkt in der Ablage würde zum Ziel führen. So würde man nur einen Aufkleber ändern.

Das bringt aber nichts, damit sind die 0815 QR-Code-Lese-Apps nutzlos.

Tut mir leid dass ich mich hier so gegen die QR-Code Lösung wehre. Aber ein Barcode, mit dem man ein Bauteil beschriftet, muss doch möglichst (unendlich) lange gültig sein. Es darf nicht sein, dass durch eine Änderung am System die Barcodes plötzlich alle ungültig werden. Um das zu verhindern, dürfen im Barcode nunmal nur konstante Informationen gespeichert werden (die ID). Variable Informationen (z.B. eine URL) hingegen, haben in einem Barcode nichts zu suchen. Man gibt ja auch nie sein Alter an wenn diese Information länger erhalten bleiben soll. Stattdessen gibt man immer das Geburtsdatum/Jahrgang an, auch wenn man dann das Alter erstmal "mühsam" berechnen muss. Dafur funktioniert das auch ein paar Jahre später noch, die Angabe des Alters ist spätestens nach einem Jahr nicht mehr gültig ;-)

[powermik]

Nach nochmaligem Überlegen und Drucken einiger Testlabels bin ich jetzt bei folgendem Workflow:

Export der Daten im CSV-Format, erstellen eines Seriendokuments im http://www.glabels.org/ und als Url z.b. http:///Part-DB/id/11 dort macht der Apache ein Redirect auf show_part_info.php?pid=1 Prefix 1 ist wie vorgeschlagen von ubruhin "Part", 11 ist also das Part mit der ID 1

RewriteBase /partdb/Part-DB RewriteRule ^id/10_([0-9]+)$ show_partinfo.php?pid=$1 [R] RewriteRule ^id/20([0-9]+)$ show_device_parts.php?device_id=$1 [R]

Auf die Art kann man Labels mit QR-Code und absoluter URL oder Labels mit Strichcode drucken. Parallel dazu hab ich eine kleine HTML-Seite ala webqr.com gebastelt und testweise im QR-Code auch nur beispielsweise "11" kodiert und als Formulareingabe verwendet.

Gibt es eigentlich keine Übersicht welche Bauteile in einer Location liegen? mit der Ansicht, CSV-Export/Import in ein Labelprogramm wäre Issue #5 auch gleich erledigt.

[ubruhin]

Gibt es eigentlich keine Übersicht welche Bauteile in einer Location liegen?

siehe Issue #2