Signature_pad: Capturer des données biométriques avec le signe

Cela dépend des données que vous avez exactement en tête, mais je pense que ce serait possible. Il y a ISO/IEC 19794-7:2014 qui "_spécifie les formats d'échange de données pour les données comportementales de signature/signe capturées sous la forme d'une série chronologique multidimensionnelle_", il serait donc génial d'utiliser cette norme au lieu de créer la nôtre . Malheureusement, je n'ai pas accès à ce document et je ne sais pas à quoi ressemble le format :/

Merci beaucoup pour votre réponse! J'attendrai avec impatience cette norme et
Je signalerai ici toute avance que je pourrais obtenir pour une utilisation ultérieure.

El 21/1/2017 10:21, "Szymon Nowak" [email protected] écrit :

Cela dépend des données que vous avez exactement en tête, mais je pense que ce serait
possible. Il y a ISO/IEC 19794-7:2014
http://www.iso.org/iso/catalogue_detail.htm?csnumber=55938 qui " spécifieformats d'échange de données pour les données comportementales de signature/signe capturées dansla forme d'une série chronologique multidimensionnelle ", il serait donc génial de
utiliser cette norme au lieu de créer la nôtre. Malheureusement, je ne
ont accès à ce document et ne savent pas à quoi ressemble réellement le format
Comme :/

—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274250329 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/APdPAIzn5SZW2nwNKDD3evH4ijb_1Mk7ks5rUc4wgaJpZM4LphIH
.

@kalihos Vous pouvez également essayer la dernière version bêta (1.6.0-beta.1), qui a la méthode #toData qui renvoie tous les points regroupés en lignes, mais actuellement, elle ne renvoie que les coordonnées temporelles, x et y pour chaque pointe. Il serait plutôt facile d'y ajouter de la vitesse et de l'accélération, mais je ne pense pas que nous puissions capturer quoi que ce soit d'autre.

Vous pouvez essayer cette version bêta sur la page de démonstration - dessinez n'importe quoi, puis appelez signaturePad.toData() dans la console des outils de développement.

Bien sûr, capturer la vitesse et l'accélération serait génial, et assez
pour garantir légalement que le signataire ne peut pas rejeter l'autorité. Quoi qu'il en soit, le
La nouvelle méthode #toData est un excellent avis pour moi. je vais essayer et donner mon avis
vous.

Merci beaucoup!

2017-01-22 14:35 GMT+01:00 Szymon Nowak [email protected] :

@kalihos https://github.com/kalihos Vous pouvez également essayer la dernière
version bêta (1.6.0-beta.1), qui a la méthode #toData qui renvoie tous
points regroupés en lignes, mais actuellement il ne renvoie que le temps, x et y
coordonnées pour chaque point. Il serait assez facile d'ajouter la vitesse et
l'accélération, mais je ne pense pas que nous puissions capturer quoi que ce soit d'autre.

Vous pouvez essayer cette version bêta sur la page de démonstration
https://szimek.github.io/signature_pad/ - il suffit de dessiner n'importe quoi et ensuite
appelez signaturePad.toData() dans la console des outils de développement.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274331306 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/APdPAH0oBwyertm7moGPS24Fubi33MKOks5rU1sJgaJpZM4LphIH
.

Je suppose que l'accélération et la vitesse pourraient être déduites des horodatages - mais, pour ce que ça vaut, ce serait vraiment bien d'avoir la possibilité d'inclure ces points de données lors de l'appel toData , ou d'avoir une nouvelle méthode pour les imputer .

Au fait, j'adore la bêta. Je l'ai un peu testé et j'ai hâte de pouvoir stocker les données brutes dans la base de données à l'avenir. Super truc! 👍

@JD-Robbs

Au fait, j'adore la bêta.

Merci! :)

Je l'ai un peu testé et j'ai hâte de pouvoir stocker les données brutes dans la base de données à l'avenir.

C'est exactement pourquoi je préférerais utiliser une norme existante pour stocker ce genre de choses. Une fois que les gens commenceront à le stocker dans leur base de données, il sera difficile de le modifier dans les prochaines versions. À l'origine, il était censé être privé et utilisé uniquement pour dessiner du SVG et aider aux tests unitaires.

Je me demande simplement quelle vitesse et quelle accélération devraient être pour le premier point de chaque ligne - 0 ou null/undefined ?

J'ai essayé votre excellente version bêta, et elle fonctionne très bien ! Comme vous l'avez dit, ce serait fantastique d'avoir en plus la vitesse et l'accélération disponibles. Dans le point légal, je pense que ce n'est pas pertinent d'avoir 0 ou null/undefined pour le premier point, car il ne servirait qu'à comparer un signe avec un autre précédemment enregistré, ainsi n'importe qui peut vérifier si c'est la même personne qui a signé les deux fois . Mais, techniquement parlant, il serait peut-être préférable de définir l'accélération pour le premier point sur 0. Je pense qu'il serait plus facile de stocker le tableau complet, car un 0 est toujours un format plus facile à exporter vers un fichier... sinon nous serions stocker "null-5-3-7-2...", et cela semble un peu déroutant à mon avis...

Respect de la norme, comme je l'ai dit, j'essaie d'obtenir des informations détaillées à ce sujet, mais les grandes différences juridiques de complexité entre les différents pays n'aident pas du tout... Par exemple, en Espagne, il n'y a pas de certification légale sur ce genre de signe "manuscrit numériquement", mais c'est accepté. Mais, contrairement au signe manuscrit traditionnel ou au signe certifié numérique, c'est vous qui devez démontrer que votre processus est correct et vous pouvez garantir l'authenticité du signe, mais basé sur un ordre juridique espagnol (http:// noticias.juridicas.com/base_datos/Admin/l59-2003.html - désolé, uniquement en espagnol).

Re-bonjour!

Je ne peux de toute façon pas accéder au document standard, mais j'ai examiné la loi espagnole et vos données actuellement capturées sont plus que correctes. Seules les données telles que les points de pression et l'inclinaison sont impossibles à saisir à partir d'un appareil normal, mais elles ne sont pas totalement nécessaires. Quoi qu'il en soit, la vitesse et l'accélération seraient incroyables pour s'assurer que l'utilisateur ne rejette pas son propre signe. Je démarre mon développement en intégrant votre composant. Si vous ajoutez de telles données supplémentaires dans un proche avenir, j'essaierai d'adapter les données dans ma base de données. Ça marche vraiment super...

Merci beaucoup!

Je suppose que si un point a déjà une vitesse et une accélération, alors il n'a plus vraiment besoin de temps. Je vais essayer de le mettre à jour, même si cela peut prendre un certain temps. Peut-être que quelqu'un veut créer un PR ? 😉

@szimek

C'est exactement pourquoi je préférerais utiliser une norme existante pour stocker ce genre de choses. Une fois que les gens commenceront à le stocker dans leur base de données, il sera difficile de le modifier dans les prochaines versions. À l'origine, il était censé être privé et utilisé uniquement pour dessiner du SVG et aider aux tests unitaires.

C'est un très bon point - je n'ai même pas pensé aussi loin avec toute mon excitation (bien que je stocke toujours des BLOB, c'est bien d'avoir également les informations biométriques brutes). Je suppose que toute future version sera toujours basée sur les informations de base concernant les coordonnées et le temps - par conséquent, je suppose qu'il pourrait toujours y avoir un chemin de mise à niveau/conversion si les choses changeaient (par exemple, mesures/échelles). Mais, encore une fois, je ne suis pas vraiment au courant de la façon dont tout est mis en œuvre.

Je me demande simplement quelle vitesse et quelle accélération devraient être pour le premier point de chaque ligne - 0 ou null/undefined?

Je suppose que la vitesse serait de 0 et l'accélération du delta au deuxième point ? Quoique, alors, quelle serait l'accélération du dernier point ? Peut-être que les deux devraient être 0 - pas sûr.

Je suppose que si un point a déjà une vitesse et une accélération, alors il n'a plus vraiment besoin de temps. Je vais essayer de le mettre à jour, même si cela peut prendre un certain temps. Peut-être que quelqu'un veut créer un PR ? 😉

Alternativement, je pense que le comportement toData et fromData pourrait rester tel quel (juste pour garder les données requises au strict minimum).

Au lieu de cela, il pourrait peut-être y avoir une méthode supplémentaire sur le prototype qui peut transformer la sortie de toData en {x: number, y: number, time: number, velocity: number, acceleration: number}[] .

Peut-être que tu as raison. Je pourrais déduire cette information à partir du temps,
pensé qu'il pourrait être plus facile de comparer deux signes. Mais oui, ça surchargerait
l'objet sans en avoir besoin. Je vais travailler avec votre version bêta actuelle.
C'est parfait tel quel !

El 24/1/2017 18:20, "Szymon Nowak" [email protected] écrit :

Je suppose que si un point a déjà une vitesse et une accélération, alors ce n'est pas le cas
vraiment besoin de temps. Je vais essayer de le mettre à jour, même si cela peut prendre un certain temps
tandis que. Peut-être que quelqu'un veut créer un PR ? 😉

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-274872842 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/APdPAG5bKRA4vv9_uqT563KiR1eqpZ_hks5rVjLCgaJpZM4LphIH
.

+1 à ce sujet.
C'est une bonne information pour accomplir l'ISO 19794-7.

@javenosa Avez-vous des informations sur les données/formats ISO 19794-7 réellement spécifiés ?

Coordonnée X du stylo (augmente lors du déplacement vers la droite)
Coordonnée Y du stylo (augmente lorsqu'il se déplace vers le haut)
Coord Z du stylet (incrémentation lorsque l'ascenseur se déplace entre l'appareil et le stylet, cela ne s'applique pas ici)
Vitesse horizontale (différence entre les vitesses)
Vitesse verticale (différence entre les vitesses)
Accélération horizontale
Accélération verticale
Temps
Différence de temps
Pression
Angle (cela ne s'applique pas ici)

Avec votre plugin, vous pouvez obtenir le plus d'éléments de cette liste.

https://image.slidesharecdn.com/onlinesignaturerecognition-130201011136-phpapp02/95/online-signature-recognition-16-638.jpg?cb=1359681345

@javenosa Merci ! S'il y a quelqu'un qui veut faire des relations publiques pour ajouter des vitesses horizontales et verticales, une accélération et une différence de temps, ce serait génial 😉 Comme vous l'avez dit, nous ne pouvons pas vraiment obtenir la coord Z, la pression ou l'angle.

Une différence est que dans le canevas HTML, la coord Y augmente lors du déplacement vers le bas. Je ne sais pas s'il est logique de le changer pour se conformer à la spécification, car ce sera un peu ennuyeux d'utiliser ces données puis de dessiner sur une toile et vous aurez probablement besoin de connaître la hauteur de la toile pour savoir quoi soustraire de...

Je me demande également si nous devrions également avoir une autre méthode (ou une option pour #toData ) qui renvoie également la couleur du stylo et les largeurs max/min par ligne. Ce n'est pas vraiment nécessaire pour les données biométriques de signature, alors peut-être qu'elles pourront être ajoutées ultérieurement, si suffisamment de personnes s'en plaignent.

Je pense que la pression peut être obtenue sur le bon appareil (bien sûr, avec un support de pression, iPhone 6s, iPhone 6s Plus, iPhone 7, iPhone 7 Plus, etc.).

Je n'avais aucune idée qu'il est possible d'obtenir ces valeurs en JS, c'est assez génial.

Bien qu'en regardant le code source de https://pressurejs.com , il ne semble pas trivial à mettre en œuvre et je ne suis pas sûr que cela vaille la peine d'ajouter du code, alors peut-être qu'il peut être reporté pour l'instant et éventuellement ajouté dans les prochaines versions.

Oui, pressurejs est une alternative (je copie juste la version de l'iphone de leur site hahah).
Je comprends votre point de vue, logique saine.

J'ai testé pressurejs, et il semble toujours dire que l'appareil n'est pas pris en charge (j'ai essayé avec un trackpad Macbook normal, un iPhone...). Quoi qu'il en soit, en regardant les informations de spécification de @javenosa , je pense que nous stockons actuellement toutes les informations nécessaires dans la base de données avec la méthode toData, sauf peut-être la pression (difficile à obtenir sans un appareil Wacom ou similaire) et l'angle (similaire au précédent) . J'utilise actuellement votre excellent plugin dans mon application, et cela fonctionne bien. Et, si j'ai besoin plus tard d'analyser une signature, je peux lire des informations biométriques et obtenir des données supplémentaires comme la vitesse ou l'accélération. Je pense qu'il n'est pas nécessaire de stocker des informations redondantes...

@kalihos Si nous décidons de sauter la pression pour l'instant, alors vous avez raison de dire que toutes les autres données (c'est-à-dire les vitesses et les accélérations) peuvent être dérivées du temps. Peut-être que pour l'instant, il serait plus simple de ne renvoyer que l'heure et de fournir un script dans le fichier README qui peut le convertir en quelque chose qui contient ces données supplémentaires.

Je me demande simplement si nous devons également renvoyer la taille du canevas (ou peut-être de meilleures coordonnées max/min X et Y), afin qu'il soit possible d'inverser les coordonnées Y (0 en bas contre 0 en haut).

@szimek C'est une bonne idée de fournir les coordonnées max/min X et Y. Mais tenez compte du fait que, lors de l'enregistrement au format SVG, ces informations peuvent prêter à confusion en raison de la possibilité de redimensionnement. Ne pensez-vous pas qu'il serait préférable de stocker la signature uniquement au format PNG si vous souhaitez stocker un maximum de X/Y ?

Respectez le script dans le fichier README, oui, c'est une autre bonne idée. Il serait seulement nécessaire d'assurer une comparaison correcte à des fins juridiques (demande légale).

@kalihos Je pensais stocker max/min X et Y uniquement afin qu'il soit possible d'inverser Y pour les données biométriques. Comme @javenosa l'a mentionné précédemment, dans la spécification 0 est en bas, mais dans un canevas 0 est en haut. Si nous souhaitons suivre les spécifications, j'aurais besoin d'un moyen "d'inverser" les coordonnées Y. Bien sûr, max/min X et Y peuvent également être dérivés en itérant sur tous les points renvoyés par la méthode #toData , de sorte qu'il n'est pas nécessaire qu'ils soient renvoyés par #toData lui-même.

@szimek C'est une bonne option pour stocker max/min X et Y, afin que vous puissiez restaurer le canevas complet et que vous puissiez accomplir la spécification. Quoi qu'il en soit, je ne pense pas qu'il soit tout à fait nécessaire de prendre la spécification au pied de la lettre, si vous pouvez garantir l'authenticité de la signature... mais il est juste de la stocker pour qu'elle soit plus "pure" ;)

Une mise à jour pour ceci?
L'accélération et la vitesse seraient une caractéristique étonnante de la méthode "toData".

Merci

@javenosa Je me concentre actuellement sur la publication de la version 1.6 avec le support SVG, mais je n'ai pas beaucoup de temps libre, donc ça progresse plutôt lentement.

si vous voulez le voir en 1.6, les PR sont les bienvenus ;) De plus, il devrait être assez facile d'écrire un script simple qui prend la sortie de toData et ajoute des vitesses et des accélérations - tout ce dont vous avez besoin pour les calculer est le temps diffs, qui sont déjà retournés.

Je ne sais pas comment sont les formules pour calculer la vitesse et l'accélération, si vous pouvez me dire ça, je peux faire un PR.

velocity = change in distance / change in time
acceleration = change in velocity / change in time

Il y a Point#velocityFrom(point) qui vous donnera la vitesse entre 2 points et une fois que vous avez compris, vous pouvez utiliser presque le même code pour calculer l'accélération :

// This one already exists
Point.prototype.velocityFrom = function (start) {
  return (this.time !== start.time) ? this.distanceTo(start) / (this.time - start.time) : 1;
};

// This one should be added
Point.prototype.accelerationFrom = function (start) {
  return (this.time !== start.time) ? this.velocityFrom(start) / (this.time - start.time) : 1;
};

Les deux méthodes devraient probablement renvoyer 0 au lieu de 1 au cas où les heures seraient les mêmes, car la position devrait également être la même...

Projet intéressant ! La norme de biométrie ISO est une norme binaire codée ASN-1 que nous étions sur le point de mettre en œuvre. Heureusement pour nous, une version XML a été publiée en 2015, ce qui est beaucoup plus facile à mettre en œuvre.

En ce qui concerne le poste de javenosa, il convient de mentionner que la plupart des canaux (ils sont appelés canaux dans la norme ISO) sont facultatifs. Seuls x, y et t sont requis et le reste est facultatif. Il peut donc être agréable d'avoir une pression ou des coordonnées Z, un angle, etc., mais ce n'est pas obligatoire pour un ensemble de données biométriques entièrement conforme. De plus, de nombreuses autres valeurs peuvent être calculées ultérieurement à partir des valeurs x, y et t existantes telles que (vitesse, accélération, etc.). Je commencerais donc par un jeu de données des plus basiques : x,y,t ...

@Lonzak Si quelqu'un peut fournir des informations sur l'apparence exacte de la structure de données par rapport à ce à quoi elle ressemble maintenant, ce serait formidable. Parce qu'actuellement, la méthode #toData renvoie les coordonnées x, y et l'heure, donc je suppose qu'il s'agit simplement de transformer la structure actuelle en ce qui est attendu par la norme ISO.

Ouais pas de problème : Jetez un œil au schéma et à l'exemple fourni. Pour la conversion XML<->JS, vous pouvez utiliser jsonix . Mais comme déjà mentionné, il s'agit de la nouvelle norme basée sur XML, l'ancienne version basée sur ASN-1 est beaucoup plus complexe à créer à mon humble avis (DER, encodeur BER avec prise en charge des instructions d'encodage. Nous n'avons trouvé aucun encodeur/décodeur open source prenant en charge cette)...

Bibliothèque géniale @szimek , en l'utilisant dans un projet natif de réaction et c'est lisse comme du beurre!
@kalihos connaissez-vous un bon SDK de reconnaissance de signature/correspondance ?

Désolé, mais je n'ai rien. Je ne l'utilise que pour les documents à faible risque, donc
Je ne m'attends pas à ce que quiconque rejette son propre signe.

El 21/9/2017 23:21, "Mark Vayngrib" [email protected] écrit :

@szimek https://github.com/szimek bibliothèque géniale, en l'utilisant dans une réaction
projet natif et c'est doux comme du beurre !
@kalihos https://github.com/kalihos connaissez-vous une bonne signature
SDK de reconnaissance/correspondance ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-331285500 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/APdPANXnge-rnI2TRuV9w-uqdp8kn_nbks5sktNEgaJpZM4LphIH
.

@szimek j'ai trouvé quelque chose comme ça:
http://stg.jsm.gov.my/documents/372014/372056/MS+ISOIEC+19794-7+2008+-+INFORMATION+TECHNOLOGY+BIOMETRIC+DATA+INTERCHANGE+FORMATS+PART+7+SIGNATURE+SIGN+ TIME+SERIES+DATA-712359.pdf/25a168da-0654-4907-b527-ad808005fe78?version=1.0&previewFileIndex=

@mgierw Merci ! Cependant, maintenant qu'il y a SignaturePad#toData , on pourrait (probablement) écrire un petit script qui prend la sortie de cette fonction et la convertit au format attendu par cette norme. Il n'aurait même pas besoin de faire partie de cette bibliothèque.

Quelque chose comme:

const data = convertToISO(signaturePad.toData());

Si quelqu'un propose une telle bibliothèque, j'ajouterais des informations à ce sujet au fichier README.

Salut,
cette conversation est vraiment intéressante !
quelqu'un a-t-il essayé d'implémenter la norme ISO ?
J'aimerais aider

des nouvelles à ce sujet?

Comme vous parliez de vitesse et d'accélération, qu'en est-il de la force ? Il existe une bibliothèque appelée pressurejs, qui vous permet de mesurer la force du toucher sur les appareils qui le supportent. Je ne suis pas dans ce sujet, donc je ne connais rien à la partie juridique.

@Springrbua v3 de cette bibliothèque prend en charge les événements de pointeur, qui peuvent fournir de telles informations si un périphérique les fournit. Cela devrait donc être possible, mais je ne le prévois pas pour la première version 3.0.0, faute de temps et d'appareils pour le tester.

Merci pour la réponse rapide. Je viens de découvrir pressurejs récemment, j'étais donc curieux de savoir s'il pouvait également être utilisé pour les signatures numériques.

Bibliothèque géniale @szimek , en l'utilisant dans un projet natif de réaction et c'est lisse comme du beurre!

@mvayngrib Comment avez-vous réussi à le faire fonctionner avec RN ?

@ntelkedzhiev J'utilise react -native-signature-pad qui est un wrapper autour de cette bibliothèque. Ou plutôt, j'utilise un fork de ce wrapper, car je voulais récupérer la largeur/hauteur avec l'url de données (https://github.com/tradle/react-native-signature-pad)

@mvayngrib Merci de me l'avoir fait savoir ! Je fais la même chose. J'ai également essayé de mettre à jour https://github.com/kevinstumpf/react-native-signature-pad pour utiliser la nouvelle version mise à jour de ce référentiel, mais cela prendra plus de temps que je n'en ai actuellement. Je pense que tous les modules doivent être placés dans un seul fichier et qu'ils doivent être au format CJS/UMD.

des mises à jour sur ce sujet?

Bonjour, j'ai trouvé une norme d'implémentation biométrique.
https://github.com/biosignin/bsi-core
C'est un peu vieux mais ça peut valoir le coup comme point de départ

Salut! Ce serait un excellent ajout au projet. Des nouvelles à ce sujet ?

tu veux dire comme le pouls, la tension artérielle, la numérotation des pupilles, la température corporelle ?

Le mar. 15 septembre 2020 à 1 h 24 corrrso [email protected] a écrit :

Salut! Ce serait un excellent ajout au projet. Des nouvelles à ce sujet ?

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/szimek/signature_pad/issues/213#issuecomment-692553010 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ
.

--
voici ma signature

tu veux dire comme le pouls, la tension artérielle, la numérotation des pupilles, la température corporelle ?
…
Le mar. 15 sept. 2020 à 1 h 24 corrrso @ . * > a écrit : Salut ! Ce serait un excellent ajout au projet. Des nouvelles à ce sujet ? — Vous recevez ceci parce que vous êtes abonné à ce fil. Répondez directement à cet e-mail, consultez-le sur GitHub < #213 (commentaire) > ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- voici ma signature

Il désigne la pression de course, l'accélération, la vitesse, etc., telles que définies dans les spécifications ISO 19794-7.
Ces données biométriques sont considérées comme utiles pour valider légalement une signature, l'image de la signature seule est insuffisante dans certains pays comme l'Italie et peut-être l'Espagne.

tu veux dire comme le pouls, la tension artérielle, la numérotation des pupilles, la température corporelle ?
…
Le mar. 15 sept. 2020 à 01h24 corrrso _ @ _. * > a écrit : Salut ! Ce serait un excellent ajout au projet. Des nouvelles à ce sujet ? — Vous recevez ceci parce que vous êtes abonné à ce fil. Répondez directement à cet e-mail, consultez-le sur GitHub < #213 (commentaire) > ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AK7MVVQPIVBQFFOLU3NGV4TSF4QCBANCNFSM4C5GCIDQ .
-- voici ma signature

Il désigne la pression de course, l'accélération, la vitesse, etc., telles que définies dans les spécifications ISO 19794-7.
Ces données biométriques sont considérées comme utiles pour valider légalement une signature, l'image de la signature seule est insuffisante dans certains pays comme l'Italie et peut-être l'Espagne.

Ouais. C'est vrai en Espagne est une exigence pour la signature numérique avancée.

J'essaie de faire dans https://github.com/javyxx/signature_pad est une simple modification pour économiser la pression

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/pressure

Salut...

Si quelqu'un est intéressé, j'ai fait dans mon fork une implémentation de base pour capturer la pression lorsqu'elle est disponible et j'ai également implémenté une fonction pour convertir les données capturées à la spécification ISO 19794-7.

Tous les commentaires, tests, corrections ou améliorations sont les bienvenus.

Peut être très intéressant de fusionner avec ce projet de toute façon

J'ai bifurqué votre référentiel pour mettre à jour les dernières modifications apportées au référentiel original de szimek.
Je pense qu'il est intéressant d'ajouter les accélérations AX et AY, qui peuvent se calculer comme la vitesse. (Incrément de la vélocité / temps d'incrément)
Quel est ton opinion?

Quel est ton opinion?

Bonjour Certifirm...

J'ai également essayé d'ajouter les accélérations, mais j'avais des problèmes avec la validation des résultats de données xml. L'ISO spécifie une valeur maximale et parfois j'avais des valeurs supérieures à ce maximum. Il existe un moyen dans l'ISO qui vous permet d'augmenter et de réduire les valeurs, mais ce n'était pas très clair pour moi et je n'ai pas eu plus de temps pour enquêter. Pardon.