Recherche avancée

Sur d’autres sites (9316)

• Recalculate the position of a larger object to re-align two different sized objects after rotation

  26 août 2022, par CRAIG

  I have 2 images I am placing on top of a 1080X1920 canvas.

  


  One is a rectangle that is 800x400 and it is sitting on the 1080X1920 canvas with top left coordinates of x=140 and y=1200

  


  

  


  Then I have another image that is the same size of the canvas 1080X1920, but also has a rectangle on it at the exact same coordinates as the first rectangle. I am overlaying this 1080X1920 image at x=0 and y=0 on the canvas so that the rectangle already in this image lines up perfectly with the rectangle that is already placed on the canvas.

  


  

  


  My problem is, I need to apply a rotation to both of these and the black and red rectangles need to match up in positioning AFTER the rotation is applied. Could be any rotation, but let's say it is a 15 degree rotation.

  


  When each element is placed on the canvas and then the 15 degree rotation is applied, the rectangles no longer align because of the difference in image size and the offset in rotation as they both rotate around the center point which looks to be my only option in this case.

  


  

  


  So I am hoping to sort out a formula I can use that would rectify the positioning of the 1080X1920 image so that the object already embedded in that image lines up with separately overlaid image.

  


  There are of course other ways to deal with this problem, but right now, they would make things quite a bit more difficult, so I wanted to see if this was possible to calculate first.

  


  I have tried several ways to calculate this, but am not super mathematically proficient, so I am grasping at straws at best.

  


  Oh and because I am not extremely mathematically proficient, any dumbing-down of mathematical terms is appreciated. ;)

  


  Oh and possibly this post answers this question, but I can't wrap my head around whether or not it does, so if someone can let me know if it does, I will try harder to understand and apply it to my particular case.

  


  How to recalculate the coordinates of a point after scaling and rotation ?

  


• Anomalie #4623 : Styles des fieldset dans l’espace privé

  17 avril 2021, par RastaPopoulos ♥

  Alors c’est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.

  Je détaille l’argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n’est pas grave si ce n’est que de la déco. Alors qu’un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s’agit d’une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.

  Pour les barres horizontales, là aussi c’était voulu de les enlever, afin d’alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d’œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n’en rajoute pas dans ce domaine.

  Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c’est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c’est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu’on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.

• Préférence donnée à mp4 sur webm quand le fichier mp4 est chargé en tant que conversion d’un fichier webm

  21 janvier 2016

  Bonjour,
  le site AlterInfos - América latina (www.alterinfos.org) utilise depuis un an le plugin "Lecteur multimédia HTML5 pour MediaSPIP" qui marche super bien. Merci.
  Jusqu’à présent, les vidéos étaient surtout au format mp4. Mais dans un article récent, les vidéos ont été téléversés au format webm (VP9+Opus), puis, à partir de ces vidéos de référence, une conversion en mp4 a aussi été téléversée. Quand on visualise les vidéos dans Firefox (43, Debian Jessie 64) ou dans Chromium, c’est toujours le fichier mp4 qui est visualisé. Si on met la vidéo au format webm seulement, la vidéo est visualisée dans ce format.
  Ce n’est donc pas un problème de compatibilité du navigateur, mais plutôt peut-être que le fichier "conversion" (mp4) est traité avant le fichier "original" (webm). Si on regarde le code source de la page, le lien vers le mp4 apparaît avant celui en webm.
  Téléverser d’abord le fichier en mp4 puis charger ensuite en tant que "conversion du document" le fichier en webm règle le problème : c’est désormais le fichier en webm qui est joué "par défaut" quand on visualise la vidéo.
  Mais il me semble que ce serait plus logique que ce soit le document de référence et non sa conversion qui soit joué par défaut quand on visualise une vidéo.
  Ça permettrait aussi de choisir la vidéo qu’on souhaite diffuser "par défaut" (dans notre cas, la vidéo webm est beaucoup plus légère [car VP9 et opus], donc c’est assez logique de vouloir que ce soit la vidéo par défaut…
  Cordialement,
  Nicolas