C'est très beau. Chouette collaboration 
!
Arg, as-tu pu faire le rapprochement avec quels emails tu as interagi pour en arriver là ?
Ha mince, désolé. Et tu ne te souviens pas de quels échanges ça pourrait venir ?
Wep, ils sont dans l'annuaire des fournisseurs ... en tant que fournisseurs de service.
C'est bon signe ce message. Tu devrais pouvoir récupérer ta chaîne !
C'est YT qui a fermé le compte.
Ce compte a été clôturé en raison du non-respect du règlement de la communauté YouTube.
A mon avis ils s'en servent plutôt pour faire des actions avec en usant de la crédibilité du compte. Les vidéos, je pense qu'ils s'en fichent.
Top !
Y a un petit côté gâteau :)
C'est l'image que tu as mis juste au dessus dans la question ?
xyloweb ça devrait pas faire de différence.
Il ne devrait pas non plus y avoir une différence entre une image uploadée dans les créations ou dans les questions, d'ailleurs ... c'est le même code 
.
xyloweb si, il y a une lecture de l'EXIF pour y trouver l'orientation de l'image. Mais c'est pareil entre vitrine des créations et corps de descriptif des questions.
En effet, il faudrait le fichier qui pose problème pour faire des essais.
Pour que l'erreur s'affiche en anglais, c'est que c'est une erreur que doit renvoyer ImageMagic ou la lib PHP qui essaye d'en extraire la taille
xyloweb Docker sur la version en prod, non. C'est le job encore inachevée (faute de temps) qui est en cours sur la migration. Mais donc sur la branche migration-sf5, il y a le moyen d'installer avec un docker.
Quentin Xaillé si tu peux envoyer les images à boris @ lairdubois.fr
Quentin Xaillé merci.
De ce que je vois, ton image n'est tout simplement pas au format un JPEG.
C'est une image encodée au format WebP. Format qui n'est pas pris en charge ici pour le moment.
Mettre l'extension .jpg ne suffit pas à en faire un JPEG 
Il te faudra convertir tes images WebP en JPEG.
Après, de mon côté, j'ai le même message d'erreur que je place l'image dans les créations que dans les questions ...
Hmm, une image carrée de 1440px, avec le format WebP, c'est étrange que ça soit une photo directement prise au téléphone, ça me semble petit. A moins que les dernière version d'Android enregistrent directement en WebP maintenant ...
Mais bon, le plus étrange, c'est surtout qu'elle soit encodée au format WebP et que le fichier ait l'extension .jpg ....
1440px x 1440px, c'est la taille d'image utilisé sur Instagram. Je dis ça, je dis rien ...
C'est chouette !
Je veux bien le fichier alors.
Clique sur le bouton Signaler un bug en bas de l'écran OpenCutList. Ca devrait te pré-rédiger un email auquel tu pourras joindre le fichier.
écrit à opencutlist @ lairdubois.fr alors ...
(L'avantage de l'autre côté, c'est que j'avais des infos en plus. Mais tant pis).
Et si tu indiques un coût, ça reste cohérent ?
Tu pourras voir demain que oui 
Hmm, c'est pas faux. Et c'est parce que tu es dans la cas particulier où le reste fait exactement la taille de la barre standard qui a un prix...
Du coup, comme il recherche le prix sur la section + taille, il trouve un prix pour le reste ...
C'est épineux, pke en soit, je vois pas de solution simple. A part mettre tes reste à 3001mm de long et être bien certain de ne pas mettre de valeur au prix générique.
Parce que dans d'autre cas, les reste on veut bien qu'ils aient une valeur.
Ceci m'a semblé tout aussi normal de penser à celui qui veut connaitre le coût de son projet en remettant le reste dans la balance.
Après, j'avoue que dans mon imaginaire le plus fou, j'ai penser à tout sauf au reste qui fait exactement la même taille que le barre standard. Et donc j'avais prévu que le reste pouvait être compter ou pas juste en usant ou non du prix général.
Encore une fois chacun use de l'outils à sa manière et il est ainsi difficile d'en imaginer un truc qui colle à 100% des cas.
Là où j'ai imaginé des reste/chutes. Tu y a vu un stock de pièces entières.
Sinon, je pense créer une matière spéciale pour mon reste/stock avec un prix à zéro…
Je vois pas bien comment tu compte faire en sorte que ton calepinage jongle avec deux matières ... ?
La solution la plus versatile serait en l'état qu'OpenCutList ne prenne en compte pour les restes que le prix linéaire général et non les prix par section/longueur.
Le 3001mm pour ton reste me semble moins bidouille :)
Sinon, sur la v4.0, ça ne prendra que le prix général pour les restes.
Le tout est avant tout de laisser le choix à l'utilisateur. Imposer qu'un reste n'ait pas de coût est aussi imposer qu'un reste est une chute déjà payée. Mais dans le principe, ça peut aussi être un stock fini qui a lui aussi besoin d'être intégré dans le calcul du coût du projet.
Et c'est ce choix que j'avais voulu mettre en place en omettant le cas particulier du reste qui fait la taille exact d'une barre standard.
De mon point de vue, réduire automatiquement le prix d'un devis pke on tape dans son stock de chutes est "con". Parce que le prochain projet similaire n'aura pas de même stock et devra donc être réévalué. Le stock déjà là est la marge de manoeuvre de l'artisan pour jouer sur son offre commerciale et pour rééquilibrer là où il aura perdu sur un autre point du projet.
Que dirait un client qui te recommande le même objet si ce dernier a pris 20%, pke ce nouveau projet tu peux pas le prendre dans un stock payé par un précédent projet ?
L’idéal serait de pouvoir faire le choix dans la configuration du reste au sens OCL…
Bah, c'était prévu comme ça. Comme je dis. L'important c'est d'avoir le choix. Mais j'avais oublié le cas où le reste fait la même taille et section qu'une barre standard.
Pour la 4.0, ça sera comme prévu. Le reste ne lira son prix potentiel que sur le prix global (sans dimension) défini sur la matière. Et ainsi on aura bien le choix de mettre ou non un prix aux restes.
Je le redis, mais en l'état de la 3.x, tu peux simplement mettre tes restes à 3001mm et ne pas définir de prix global et tes restes seront bien "gratuits" :P
Les 3001mm ne changeront pas vraiment le calepinage mais feront en sorte que les restes sont bien distincts des barres standards. Tout en restant dans la même matière.
J'crois qu'on dit la même chose depuis le début. J'ajoute juste qu'un reste ne doit pas être obligatoirement gratuit d'où l'intérêt de permettre les deux choix.
De rien :)
je suis ravi d’apprendre que dans la version 4 on aura le choix d’affecter ou pas un prix à un reste
Et comme dit hier, donner le choix est le but le but depuis le début. Donc rien de neuf dans la v4 là dessus. C'est avant tout un fix. Dans la v3, il suffit juste de ne pas mettre exactement la même taille aux restes qu'aux barres standard pour contourner le cas mal anticipé.
contribuer au projet en faisant un don
Merci !
Merci Yves pour ce retour. Content que ce module te serve autant !
Oui, c'est ça. Je suis le seul à avoir travaillé dessus et j'airai maintenant du mal à trouver beaucoup de temps à y consacrer pour le faire évoluer.
Joli Erci