Hilfe Diskussion:Bilder

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Diese Seite dient der Diskussion über Inhalt und Gestaltung der Seite Hilfe:Bilder.

Fragen zum Hochladen oder Sonstigem können in der Wikipedia:Redaktion Bilder, rechtliche Fragen in Wikipedia:Urheberrechtsfragen gestellt werden.

Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 50 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.
Archivübersicht Archiv
Wie wird ein Archiv angelegt?

Falsche Formulierung auf Hilfeseite[Quelltext bearbeiten]

_hochkant=1.02272727 entspricht 220px
_hochkant=1.02272728 ergibt einen Sprung auf 230px

Der zweite Satz von „Zu beachten ist, dass der Faktor bei Dezimalbrüchen mit Punkt anstatt Komma angegeben werden muss (Beispiel: 1.8 anstatt 1,8). Die mögliche Schrittweite ist ein Zehntel“ ist falsch. Die Grenze für das Umschalten von 220px auf 230px liegt bei ((230px+220px)/2)/220px -> 225px/220px was einen Wert von 1.0227272727272727 ergibt. Im Quelltext zu dem nebenstehenden Beispiel sieht man, das der Bereich an dem Umgeschaltet wird von der Software exakt berechnet wird (PHP rechnet da intern wohl mit Real). Erst nach der Berechung mit exakten Werten rundet die Software auf 10px. --SummerStreichelnNote 13:07, 14. Mär. 2018 (CET)

Wohl nicht; intern wird mit voller Genauigkeit gerechnet, aber auf das Endergebnis bezogen.
Ist mini im Spiel, gelten die 10px hinterher, ansonsten nur die (abgeschnittenen) Zehntel.
Mir scheint die Hilfeseite richtig; aber die Zusammenhänge sind komplex und das gesamte Unterfangen hier wenig zielführend.
VG --PerfektesChaos 14:57, 14. Mär. 2018 (CET)
Der Satz „Die mögliche Schrittweite [des Paramter Hochkant] ist ein Zehntel“ ist definitv falsch. Nebenstehend siehst du, das ein Hunderstmillionstel ausreichen kann. --SummerStreichelnNote 15:35, 14. Mär. 2018 (CET)
PS: die Zusammenhänge sind hier nicht Komplex ... das ist im Gegenteil popelig einfach. Die Software akzeptiert viele Stellen hinter dem Komma, rechnet damit exakt und ganz am Ende vor der Ausgabe des Ergebnis rundet sie auf volle Zehner. Ich würde das sogar gute Programmierung nennen. -- SummerStreichelnNote 15:40, 14. Mär. 2018 (CET)
Das gilt alles nur für mini, bei nicht-mini greifen die Zehntel.
Die mini wiederum hängen von der Benutzereinstellung ab; diese kann zurzeit 120, 150, 180, 200, 220, 250, 300, 400px betragen, was sich im Lauf der Jahre aber ändern könnte.
Damit der Bild-Cache im Server nicht lauter Vorschaubilder halten muss, wird auf ganze Zehner abgeschnitten (nicht gerundet, wenn ich den Algorithmus recht erinnere; unter dem Maximalwert den nächstkleineren).
Deine Rechnerei gilt erstmal nur für dich persönlich, weil du offenkundig 220px eingestellt hast. Leser mit anderer Einstellung sehen aber eine andere Breite und bekommen ggf. andere Ergebnisse.
Die ganzen Zehntel gelten für nicht-mini, dann wird die Höhe betrachtet, dann das Ergebnis auf ganze Pixel gesetzt.
Diese gesamte Rumrechnerei hier und im Abschnitt drüber läuft völlig am Zweck des hochkant vorbei und ist für die Katz. Dem Artikel bringt es nichts.
Die internen Berechnungsmodalitäten haben sich in den letzten anderthalb Jahrzehten immer mal wieder etwas geändert und können auch zukünftig betreffend Rundung usw. anders laufen. Es ist absolut sinnlos, hier mit Nachkommastellen den halben Pixeln nachzujagen.
VG --PerfektesChaos 16:09, 14. Mär. 2018 (CET)

(Nach links Ausgerückt)

Als Wiederholung damit keine Missverständnisse aufkommen: Der Satz „Die mögliche Schrittweite [des Parameter Hochkant] ist ein Zehntel“ ist definitiv falsch. Defintiv wird ein Wert mir vielen Stellen hinter dem Komma (Dezimalpunkt) eingelesen und zur Berechnung herangezogen. Und kompliziert wird es nur, weil du es kompliziert machst.

  • Du verkomplizierst das ganze, indem du persönliche Benutzereinstellungen betrachtest. Lass das weg. Macht die einfache Sache nur kompliziert.
  • Du schreibst von Server-Cache etc. Alles nur komplexes Zeug. Die am heimischen Bildschirm angezeigte Bildgröße wird nicht vom physischen Bildparametern sondern von den Paramtern width/height des img-Tags bestimmt. Pures HTML das von der Wikisoftware generiert wird. Simpel
  • Das Bild der Messingfigur (heute auch auf der Hauptseite) habe ich in diesem Thread zweimal mit dem Parameter mini eingebunden um dir zu zeigen, das der Parameter Hochkant mindestens bis zur 8ten Stelle hinterm Komma ausgewertet wird. Im Thread darüber habe ich das Bild fünfmal eingebunden - vier davon OHNE den Parameter mini. Damit wäre wohl klar, das deine Vermutung bezüglich des Parameters mini falsch sind.

Wirf alle komplizierten Gedanken über Bord und beschränk dich auf das Einfache. Dann ist klar, dass das Handbuch falsch ist. --SummerStreichelnNote 16:52, 14. Mär. 2018 (CET)

@PC: Also ich habe als IP logischerweise nicht irgendwas eingestellt, und ich sehe die nebenstehenden Bilder in unterschiedlicher Grüße. 129.13.72.197 17:39, 14. Mär. 2018 (CET)

@Benutzer:PerfektesChaos: da Worte dich nicht überzeugen, versuch ich es mal mit einer hoffentlich selbstredenden Tabelle (Effekt bei Standardeinstellung sichtbar):

Hochkantwert Bild
2.0 2.0
2.02273 2.02273
2.06819 2.06819
2.1 2.1
2.11364 2.11364
2.15910 2.15910
2.2 2.2
2.20455 2.20455
2.25001 2.25001
2.29546 2.29546
2.3 2.3
2.34091 2.34091
2.38637 2.38637
2.4 2.4

Die Hochkantwerte mit 5 Nachkommastellen wurden wie oben beschrieben berechent und liegen genau an der Schwelle, an der das Bild vergrößert wird. Substrahiert man von dem jeweiligen Wert 0.00001, dann wird das Bild sprunghaft kleiner. --SummerStreichelnNote 12:22, 15. Mär. 2018 (CET)

Ich sehe hier nirgends einen Unterschied, die Bilder sind alle jeweils exakt gleich breit, sowohl die beiden oben anfangs, als auch die in der Tabelle (natürlich nur innerhalb der jeweiligen Gruppe). Solche merkbefreiten Spielereien dienen nichts sinnvollem, das hängt primär von den persönlichen Einstellungen, von den Browsereinstellungen, dem Ausgabegerät und sonstwas ab, wer meint damit irgendwas für alle gleich machen zu können, oder auch nur ein "schönes Seitenlayout" generell hinzubekommen, der hat den Schuss nicht gehört. Grüße vom Sänger ♫ (Reden) 14:08, 9. Mai 2018 (CEST)

Skalierung der Bildgrößen auf eine Nachkommastelle zu wenig[Quelltext bearbeiten]

Overlord-Plan mit kombinierter Bomberoffensive Juni 1944:
Schweinfurt (karierte Schraffur in der deutschen Mitte) war das einzige primäre Angriffsziel (Primary) der Alliierten in Bayern
Overlord-Plan mit kombinierter Bomberoffensive Juni 1944:
Schweinfurt (karierte Schraffur in der deutschen Mitte) war das einzige primäre Angriffsziel (Primary) der Alliierten in Bayern

Wiederholt wurden im Artikel Schweinfurt bei der Skalierung der Bildgrößen zweistellige Nachkommastellen (linkes Bild) durch eine halbautomatische Ersetzung auf eine Stelle reduziert (rechtes Bild). Dadurch wurde im langen Artikel das Layout vieler Bilder zerstört und ich musste per Hand alles wieder reparieren.

An diesem Beispiel erkennt man zweifellos zwei Dinge:

1.: Für eine gute Bildgestaltung benötigt man 2 Nachkommastellen

2.: Die halbautomatische Ersetzung sollte entsprechend geändert werden

Grüße --Kim117 (Diskussion) 21:29, 7. Mai 2018 (CEST)

Bitte hilf mir auf dei Sprünge: Ich sehe keinen wesentlichen Unterschied zwischen den beiden Bildern. --Digamma (Diskussion) 22:14, 7. Mai 2018 (CEST)
Der Unterschied liegt allein bei der Bildlegende: links kompakt im Kasten mit 3 Zeilen, rechts zerrissen in 5 Zeilen, wobei die Überschrift in 2 Zeilen aufgespaltet wurde. Also eine doppelte Verschlechterung: 1. Grafik, mit unnötigen Platzverbrauch, was bei Bildern auf der linken Seite weitere Zerstörungen des Layouts nach sich ziehen kann, durch Versetzung der nachfolgenden Abschnitts-Überschrift nach rechts oder bei nachfolgenden blauen Listen-Punkten, die dann ins Bild hineingehen. 2.: Die Bildlegende wird unübersichtlicher und schwerer lesbar. Fazit: durch halbautomatische Reduzierung auf eine Nachkommastelle kann im schlimmsten Fall sogar ein ganzer, grafisch ausgefeilter Artikel formal ruiniert werden. --Kim117 (Diskussion) 08:00, 8. Mai 2018 (CEST)
Ich sehe unangemeldet und angemeldet zwei völlig verschiedene Unterschiede, angemeldet geht es um 2 vs. 3 Zeilen Bildunterschrift, unangemeldet waren es iirc 5 vs. 6 Zeilen. Von der Lesbarkeit des Karte selber her war unangemeldet eher nix zu erkennen, angemeldet geht es so. Das Problem mit der Darstellung von Bildern ist die Abhängigkeit von persönlichen Einstellungen und den Endgeräten, da von der Darstellung auf dem eigenen Bildschirm/Tablet/Wischhandy auf allgemeine Aussagen zu schließen, ist i.d.R. eher nicht möglich. Grüße vom Sänger ♫ (Reden) 08:29, 8. Mai 2018 (CEST)

Hallo Benutzer:Kim117, es ist schon ein witziger Zufall. Im Abschnitt #Falsche Formulierung auf Hilfeseite hier drüber habe ich mir den Mund fusselig geredet, das die Wikisoftware den Parameter hochkant mehr als nur eine Stelle hinter dem Komma auswertet (auch wenn mir da bis dato nicht zugestimmt wurde, hat jedenfalls niemand revertiert als ich die falsch Aussage auf der Hilfeseite löschte. Und nun sehe ich, das du genau diesen Parameter auf ein Hundertstel ausreizt.

Zu deinem Problem: über den Parameter hochkant kannst du, sofern der Benutzer Standardeinstellungen belassen hat, die exakte Darstellungsbreite eines Bildes vorgeben. Indirekt gibt du damit auch die Breite vor, die für die Bildunterschrift zur Verfügung steht. Da kannst aber leider über die Breite des Textfelds NICHT die Zeilenumbrüche exakt steuern. Der Grund: die Umbrüche werden im wesentlichen über den Zeichenfont gesteuert. Und der ist von Betriebssystem, Browser und Vorlieben des Benutzers abhängig.

Anders formuliert: wo du drei Zeilen siehst, erscheinen bei anderen Benutzern nur zwei oder auch vier Zeilen. Du kannst etwas mit erzwungenen Zeilenumbrüchen (<br />) und geschützten Leerzeichen (&nbsp;) arbeiten ... alles andere ist aussichtslos (es gibt noch etwas härtere Tricks ... aber die machen alle Probleme). --SummerStreichelnNote 14:37, 8. Mai 2018 (CEST)

@Lómelinde: an dich die Bitte, Kürzen von Hundertstelangaben wie hier zu unterlassen. Ich denke, es ist inzwischen nachgewiesen das die Hundertstelangaben bei Hochkant einen Effekt haben (können). Du solltest es einfach respektieren, wenn andere das Hundertstel verwenden wollen. --SummerStreichelnNote 14:54, 8. Mai 2018 (CEST)

Ich tue das nicht. --Liebe Grüße, Lómelinde Diskussion 15:14, 8. Mai 2018 (CEST)

Um mich als Programmierer des hochkant-Parameters mal einzumischen: Ihr könnt beliebig viele Nachkommastellen reinschreiben, die werden auch berücksichtigt. Aber: Das damit erstellt Thumbnail wird immer auf eine glatte Zehnerzahl gerundet: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.. So meine damalige Begründung, die auch im PHP-Code von Linker.php zu finden ist. Mit anderen Worten: 300 Pixel * 0,75 (der Standard von hochkant) = 225 Pixel, gerundet zu 230 Pixel. Ohne Rundung besteht einfach die Gefahr, dass der Thumbnail-Cache mit unendlich vielen Werten "zugemüllt" wird. Im übrigen pflichte ich Summer bei: Bitte versucht nicht, pixelgenau Bild und Bildunterschrift in Einklang zu bringen. Dafür ist das Web nicht ausgelegt. Zu viele Faktoren spielen bei der Darstellung eine Rolle: Schriftart, Browser, Betriebssystem, benutzerspezifische Thumbnailgröße, mobile Darstellung usw. — Raymond Disk. 15:33, 8. Mai 2018 (CEST)

Auch das tue ich nicht. Die Umstellung erfolgt per Skript und nicht auf meinen speziellen Wunsch oder nach meinen Vorlieben oder einer zusätzlichen persönlichen Konfiguration.
Ich hatte aufgezeigt, wie man Bildlegenden anders gestalten kann, wenn es tatsächlich eine Legende zu der Abbildung und eben nicht die normalerweise zu erwartende Bildbeschreibung sein soll. Für mich gehört da nur ein sehr kurzer Text hin, der beschreibt was das für ein Bild ist Was das Bild darstellt = Übersichtskarte der Bomberoffensive im Juni 1944.
Ich kürze da aber tatsächlich manchmal bewusst und beabsichtigt den Text und verpacke einen Teil in ref-Tags, damit die Bildlegende nicht so unansehnlich überquillt. Was beim einen gut aussehen mag zeigt bei anderen Murks an. Und überfüllte Bildlegenden empfinge ich als sehr störend. --Liebe Grüße, Lómelinde Diskussion 15:52, 8. Mai 2018 (CEST)
Ich sah bisher angemeldet wie unangemeldet bei extrem unterschiedlichsten persönlichen Schriftgrößeneinstellungen in meinen beiden Notebooks mit sehr unterschiedlichen Bildschirmgrößen und bei unterschiedlichen PC's in diversen Stadtbüchereien bei einer Bildlegende mit zwei Nachkommastellen immer überall das exakt selbe Layout, mit selben Zeilenumbruch. Abweichungen gibt es offensichtlich demnach nur in selteneren Fällen, die dann nicht als Maßstab dienen sollten (und mobile Geräte sollten sowieso nur eine Nebenrolle spielen, da man es im Webdesign nun mal nicht allen Recht machen kann). Und auch im seltenen, obigen Fall waren es 2 vs. 3 bzw. 5 vs. 6 Zeilen. Also selbst hier bei zwei Nachkommastellen ein besseres Ergebnis als bei einer. Die Sache ist doch eindeutig: zwei können zu besseren Ergebnissen führen, als eine. --Kim117 (Diskussion) 12:09, 9. Mai 2018 (CEST)
Hi Kim117, ich bin ja voll bei dir, das man zwei Stellen bei dem Hochkantparameter verwenden darf (unter Strich ist es übrigends so, das man mit einer Nachkommanstelle 20px Sprünge hat während es bei 2 Nachkommastelle 10px Sprünge sind). Ich möchte dir nur trotz deines Test die 'Illusion' nehmen, dass du Zeilenumbrüche über Breitenangabe des Textfensters steuern kannst. Ein ganz simples Bsp.: ein Brillenträger wählt die Schrift auf seinen Mobile so, das er auch ohne Brille lesen kann. Schon stimmen die Umbrüche nicht mehr. Und ironischerweise gibt man dann genau dem Clientel, das mehr Mühe beim Lesen hat und gute Formatierung am dringensten bräuchte, die schlechteste.
Versteh mich bitte nicht falsch - ich will dich nicht von einer bestimmten Technik überzeugen. Aber HTML-Dokumente geben dem Brower beim Zeilenumbruch viel Spielraum. Sieh meinen Betrag mehr als Hilfestellung oder Anregung denn als Kritik (ich werde ganz sicher nicht in deinen Artikel nacheditieren). --SummerStreichelnNote 12:38, 9. Mai 2018 (CEST)


Fummeleien der Art 1.0 → 1.03 sind sinnfrei.

  • Die Breite eines Miniaturbildes hängt von den Benutzereinstellungen ab; nicht angemeldete Leser erhalten zurzeit 220px (ändert sich ab und zu) und angemeldete können 120px, 150px, …, 250px, 400px einstellen.
  • Die Breite von Texten hängt generell von den Font-Einstellungen bei den Lesern ab; welche Schriftart im Browser vorgegeben, und in welcher Größe, und wie gut sind die Augen des Lesers? Das bedingt die Breite der Buchstaben, und welches Text-Layout sich daraus ergibt, aus deren Aufsummierung.
  • Die Desktop-Skins bewirken teilweise bei identischen Browser-Vorgaben kleine Unterschiede in hier relevanten Details. Insbesondere aber auf Mobilgeräten werden völlig andere Darstellungkonzepte verfolgt, die sich obendrein häufig ändern.
  • Bilder werden in Pixeln px bemessen; Schriftzeichen in Maßeinheiten em und derlei. Das Verhältnis beider Maßeinheiten ist signifikant von Geräten und Betriebssystemen und Browsern abhängig.
  • Der Hochkant-Parameter dient dazu, stark querformatige oder Wolkenkratzer-Bilder in der Basis-Darstellung besser zu präsentieren. Daraus ein Gefrickel zu machen, wie sich die Bildlegende in der Seite präsentieren solle, ist eine missbräuchliche Spielerei. Die eigentliche Aufgabe des Hochkant-Parameters, nämlich das geeignete Seitenverhältnis, wird lediglich von der ersten Dezimalstelle gesteuert (siehe oben: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.)
  • Nichts von all diesen Basteleien wird über die Jahre Bestand haben, weil es keine Anforderung an irgendeine Software gibt, diese pixelgenauen Rechnereien unterstützen zu müssen oder gar zu garantieren. Sie sind deshalb absolut wertlos und führen nur zu überflüssiger Beschäftigung der Bearbeiter und vergeuden die Zeit der Autoren.

VG --PerfektesChaos 13:56, 9. Mai 2018 (CEST)

Aber so was von +1. Wer sich mit solchen merkbefreiten Kinkerlitzchen tatsächlich beschäftigt, sollte dieses absurde Tun dringend überdenken. Grüße vom Sänger ♫ (Reden) 14:04, 9. Mai 2018 (CEST)
@PerfektesChaos @Benutzer:Sänger: ich (und auch Raymond) raten dem Benutzer Kim117 nicht zu seiner Formatierungsmethode zu. Warum man ihm aber unter Heranziehung von Extremwerten (1.0 → 1.03) sinnfreies Arbeiten vor den Kopf knallt und dann auch noch ein praktisch geschrienes +1 hinterher kommt, ist mir nicht begreiflich. Ohne eueren Auftritt wäre es sicher auch gegangen. --SummerStreichelnNote 14:24, 9. Mai 2018 (CEST)
Damit kein Missverständnis entsteht: habe zwei Nachkommastellen nur in einigen Sonderfällen, wie bei obigem Bild mit Übergröße, verwendet. Ansonsten habe ich bei Bildern mit dem Parameter hochkant allermeist überhaupt keinen Zusatz gemacht. Vielleicht beruhte die ganze Diskussion nur auf diesem Irrtum, da ich mich zu wenig deutlich ausgedrückt habe. Grüße --Kim117 (Diskussion) 11:29, 10. Mai 2018 (CEST)
Hi Kim117, wir haben es hier mit zwei Dingen zu tun, die etwas durcheinander gelaufen sind.
1. dein Versuch, Zeilenumbrüche in der Bildunterschrift durch die Bildbreite zu steuern ist nicht sinnlos ... wird aber nicht immer und überall den gewünschten Effekt haben. Siehe z.B. mein 'Brillenargument' weiter oben (deine Tests werden korrekt sein - deine Methode wird aber oft nicht funktionieren wobei 'oft' eine schwer zu definierende Variable ist). Wäre hier etwas ruhigeres Fahrwasser, dann könnte man vernünftig besprechen wie du deinem Ziel trotzdem sehr nahe kommst (wird auch in der Praxis gemacht - aber eher intuitiv). Du gibst alle Zeilenumbrüche der Bildunterschrift per <br> vor und wählst die Zeilenlänge manuell genügend kurz. So kurz, dass sie bei allen vernünftigen Schriftgrößen/-arten nicht noch zusätzlich durch den Brower umgebrochen werden. Intuitiv wird das gelegentlich gemacht, wenn z.B. unter einer Grafik eine Farblegende mit kurzen Zeilen steht. Lässt sich leider nicht ganz einfach beschreiben ... (selten mach ich das selbst und wir können uns gerne auf einer Artikeldisk am konkreten Beispiel besprechen). Man muss aber bei all dem Wissen - man Erhöht durch diese Tricks nur die Wahrscheinlichkeit, das die Umbrüche wie gewünscht dargestellt werden (wenn z.B. ein Benutzer eine Bildbreite von 150px in seinen per. Einstellungen hat, ist dagegen kein Kraut gewachsen).
Noch ein Tipp den du bei 'Sonderformatierung' immer beachten solltest: stell als Test unterschiedlich Wert für die Standartgröße der Vorschaubilder ein ... da fällt die schlechte Formatierung sofort ins Auge.
2. Das zweite Thema ist die Wirkung des Parameter 'Hochkant'. Diesen Parameter als exakte 'Zeilenumbruchshilfe' einzusetzen wird nicht für jeden Brower (Schriftart etc.) funktionieren (als grobe Zeilenumbruchshilfe schon - s.o.). Es ist aber ein toller Parameter um das gesamte Layout zu beeinflussen. Ich erklär nochmal was Raymond (der Programmierer des Hochkantparameters) schrieb: er nimmt den Basiswert der Bildbreite (den Wert aus Einstellungen -> Aussehen -> Standardgröße der Vorschaubilder: - der Standard ist 220px) und multipliziert es mit dem Wert des Parameter 'Hochkant' und verwendet das Ergebnis als neue Bildbreite. Am Ende rundet er noch Bildbreite auf 10px (das ist zur Minderung der Serverlast sehr vernünftig!). Zwei Rechenbeispiele: mit Hochkant 1.0' und 1.1': 220px*1.0=220px; 220px*1.1=242px gerundet 240px. Da der Unterschied zwischen 1.0 und 1.1 ein Zehntel, also 10% beträgt, findet man im Ergebnis auch rund 10% (hier 20px) Unterschied wieder. Raymonds Programm erlaubt aber 10px statt nur 20px! Und wenn du es mit dem Hochkantwert 1.03 durchrechnest (also genau der Wert, den PerfektesChaos oben als sinnfreie Fummelei abtut), dann siehst du, das es gerundete 230px ergibt - man füllt also genau die Lücke von 20px, die zwischen den Hochkantwerten 1.0 und 1.1 liegt. Wem Rechnen nicht so liegt, der kann es auf meiner Ben. bei commons anschauen (siehe dortiges Zitronenbild).
Vereinfacht gesagt: verwendet man nur die erste Stelle hinter dem Komma, macht man 20px Sprünge, verwendet man die zweite Stelle hinterm Komma, macht man 10px Sprünge. Sicher kann man Streiten, ob 10px Sprünge gegenüber 20px Sprüngen sinnvoll sind - vor dem Diskutieren über dem Sinn kommt aber das darstellen der Fakten. Ich persönlich würde dir empfehlen, die zweite Nachkommastelle zu benutzen wenn das Ergebnis bei bloßem Ausprobieren gut aussieht (ich könnte das noch genauer begründen - aber das würde den Rahmen sprengen). Um es nur kurz anzureißen: wer in seinen pers. Einstellungen 400px als Basiswert hat, macht bei der ersten Nachkommastelle 40px Sprünge statt möglichen 10px Sprüngen mit der zweiten Nachkommastelle (Daumenbreite statt Buchstabenbreite) ... das ist dann kein Peanuts mehr.
Aber ganz sicher kannst du dich darauf verlassen, das Raymonds Programm deinen Parameter vernünftig auswertet - selbst wenn du zehn Stellen hinter dem Komma angibst. Und du musst dich nicht rechtfertigen, ob und wie oft du die zweite Nachkommastelle benutzt.
3. nochmal angemerkt: der Ton gefällt mir hier überhaupt nicht. Ganz oben wurde ich mit RTFM (Read the fucking manual; zur Erinnerung - das 'Handbuch' war vor meiner Korrektur nachweislich falsch!) als dummer Junge hingestellt und das gipfelt nun hier im Geschreie vom Sänger. Spart euch das!!! Nach meinem dafür knallt man Benutzern auch nicht eine Methode als Unsinn vor den Latz sondern erklärt warum. Und dazu gehört nun mal, die vermeidlich unsinnigen Herangehensweisen zu besprechen. --SummerStreichelnNote 15:50, 10. Mai 2018 (CEST)
Vielen Dank für Deine ausführliche Erklärung. Zu obigem linken Bild habe ich mal statt dem Parameter 'hochkant' px benutzt. Bei 345px gab es bei mir in allen Schriftgrößen-Einstellungen das gewünschte, selbe Ergebnis, mit 3 Zeilen auf kleinst möglichem Raum. Während bei 344px die Bildlegende auf 5 Zeilen umsprang. Brächte die Verwendung von px gegenüber dem Parameter 'hochkant' irgendwelche Vorteile? Vermutlich nach Deiner Erläuterung nicht. --Kim117 (Diskussion) 17:46, 10. Mai 2018 (CEST)

Bitte um Feedback[Quelltext bearbeiten]

wie vor einiger Zeit im Kurierbeitrag in der Wikipedia bereits angekündigt wurde, beteiligt sich Wikimedia Deutschland mit dem Projekt „Wiki Loves Monuments goes ECHY 2018“ (ECHY steht für „European Cultural Heritage Year“) am Europäischen Jahr des Kulturerbes. Durch dieses Projekt sollen der Fotowettbewerb weiterentwickelt, die Bekanntheit der Arbeit der Freiwilligen erhöht und auf einem Austausch- und Planungsportal zum Europäischen Kulturerbe auf Wikimedia Commons zur Teilnahme und Mitgestaltung eingeladen werden.

Wie dort dargestellt, sieht es ein Projektbaustein vor, dass der Fotowettbewerb Wiki Loves Monuments weiterentwickelt wird. Dazu wird die aktuelle (technische) Entwicklung, Objekte in ungewohnten Darstellungen zu präsentieren, aufgegriffen und u. a. ein Fokus auf 360°-Panoramen gelegt. So wird es im Rahmen von „Wiki Loves Monuments goes ECHY 2018“ folglich auch Sonderpreise für 360°-Panoramen von Kulturerbestätten geben.

Damit solche Panoramen entstehen können, benötigen freiwillige Fotograf_innen den Zugang zu Kulturerbestätten. Um diesen Zugang zu erleichtern, möchte Wikimedia Deutschland ein Unterstützungsdokument bereitstellen, um freiwilligen Fotograf_innen eine Argumentationshilfe an die Hand zu geben und den Besitzenden und (Zugangs-)Verwaltenden von Kulturerbestätten Informationsmaterial zur Verfügung zu stellen und so möglichst Bedenken oder Vorurteile gegenüber Wikipedia, Wikimedia Commons und freien Lizenzen auszuräumen.

Dieses Dokument soll in Form eines Flyers in gedruckter und digitaler Form erscheinen. Für die Textinhalte gibt es einen ersten Entwurf (Google Doc – zum kommentieren ist kein Account/keine Anmeldung vorausgesetzt). Ich würde mich freuen, wenn ihr zu diesem Dokument bis zum 11.06. Kommentare, Verbesserungsvorschläge und Korrekturen hinterlassen könntet. Das Layout und alles weitere zur äußerlichen Erscheinung erfolgt zu einem späteren Zeitpunkt.

Bei Rückfragen stehe ich euch gern zur Verfügung und danke euch schon mal für euer Feedback.

--Jonas Sydow (WMDE) (Diskussion) 11:04, 4. Jun. 2018 (CEST)