Das war erstmal vollkommen erfolgreich, DANKE Heiko für die Tips: > Ein paar Antworten (und sicher mehr Fragen) gibt es vielleicht unter > https://bugs.documentfoundation.org/show_bug.cgi?id=81829. Wir haben > aber spezielle Kommandos zum seitenweisen Blättern, die nur nicht > standardmäßig auf Seite hoch/runter gelegt sind. Suche nach > .uno:PageDown / .uno:PageUp - oder benutze den Navigator.
Ich habe in "tools-customize-keyboard" die PgDn und PgUp TASTE UMGELEITET anstatt auf "next Page" auf "To Next Page" bzw. adäquat "To Previous Page". Damit springt die Anzeige bei PgDn/Up jeweils an den Anfang der Seite, die dann oben bündig Seitenrand = Anzeigebereichsrand dargestellt wird. Feinjustieren ist nicht möglich (damit wird etwas Rand angezeigt, das ist Platzvergeudung), aber halt nur etwas. Das ist ok. Als UNO wird dabei .uno:GoToNextPage und .uno:GoToPrevPage verwendet, wie meine Accelerator key konvertierung zeigt, link: https://vishia.org/LibreOffc/pdf/KeyAcclText-2026-01-15.pdf PgDn "To Next Page" ==>.uno:GoToNextPage Shift- PgDn "Select to Next Page" ==>.uno:PageDownSel PgUp "To Previous Page" ==>.uno:GoToPrevPage Shift- PgUp "Select to Previous Page" ==>.uno:PageUpSel Die Shift PgUp/Dn ist unverändert. Was welche uno-Funktion macht bzw. welche Zuordnung es zwischen dem englischem Bedientext und dem uno-cmd gibt - reine Probiersache. Kann man das irgendwo übersichtlich nachlesen? Ein Nachteil: In der Zweiseitenansicht im Durchblättermodus muss man immer zweimal PgDn drücken. Da er erst noch nach rechts springt. Besser wäre: Die Funktion der PgUp/Dn sollte abhängig vom Zoom-View Modus sein, aber das ist für Release 2032 oder 2048 :-( Ich habe überlegt, ob ich die Originalfunktion PgUp/Dn damit überschreibe (was ich getan habe) oder nicht. Die originale PgUp/Dn ist (meiner Meinung nach) in keinem View nutzbringend. Auch nicht im Scrollmode. Denn beim Korrekturlesen scrolle ich mit dem Finger am Mausrad oder auf dem Mousepad schiebend, die Augen folgen dem Finger, die Ansicht am Display ist dazwischen und folgt genau. Das ist Haptik! Als UX - User eXperience Denkweise - immer mit zu beachten. Dagegen, bei Pgdn/Up wechselt plötzlich die Ansicht, das Auge muss sich neu orientieren, das bringt alles nichts. Dem wiedersprechend steht in Im Seitenblättermodus sieht das (aus meiner Sicht) ganz anders aus. Denn da erwarte ich als Konstante der Orientierung auf dem Bildschim jeweils den Kopf der nächsten Seite. Als Haptik-Feedback. Mit dieser kleinen Änderung wäre sowohl die der Buzilla 81829 (https://bugs.documentfoundation.org/show_bug.cgi?id=81829) als auch der dort verlinkte neuere 171252. erledigbar. Ich habe das Gefühl, in etwa ist das gleiche Verhalten wie ich angemahnt habe, dort gemeint. Wenn ein User von der Fn-Taste spricht mit der er probiert, unbeachtet der Tatsache, dass Fn keine allgemeingültige Kombitaste ist, dann zeigt dass, das die Bugzilla-Einträge oft nur sehr raw / roh sind, unüberlegt. Genauso ist es dumm, jeweils das Betriebssystem als beeinflussend vorauszusetzen. Es gibt zwar einige Bugs, die betriebssystem-affin sind, die meisten aber nicht. Bzw. hier geht es ja eigentlich nicht um bugs, sondern um features, OS-independent. Das nur zu den Bugzilla einträgen. Es liest sich sehr aufwändig. Daher wäre es allg. überlegt besser, Dinge vorher immer in einer nationalsprachigen discuss-Seite oder irgendwelchen Foren zu klären, bevor bugzilla damit vollgespamt wird. ... ? ... irgendwo in den Comments stand auch, dass der Seitenumbruch insbesondere angeschaut werden können sollte, daher der Rest der letzten und der Anfang der Folgeseite. Das könnte ein Spezialfall für Handhabung sein. Der wäre allerdings abgegolten, wenn bei .uno:GoToNextPage / Prev es feinjustierbar wäre, wo im view der Seitenanfang dargestellt wird. M.E. dürfte das auch nicht zu schwierig zu programmieren sein. Ich versuche demnächst mal meine Experience dort kurz bündig mit unterzubringen, oder besser einen neuen gut formulierten Bugzilla Eintrag anlegen, dort auf die alten verweisen, die dann geschlossen werden sollten. Aber ich würde gern noch andere User Feedbacks hier abwarten!!! Ansonsten aber, ich habe an die replizierte mail von Heiko unten wieder meinen relativ langen Gesamt-Text angehängt. Sonst bleibt unklar worum es insgesamt geht. Der Aufhängepunkt war ursprünglich: Scroll Denken vs. Page-Denken. Auch das muss man doch mal sagen dürfen. User-Feedback ist wichtig. Die übliche Verkürzung auf das "gemeinhin nur notwendige" verkürzt am Ende unser Denken. Nur eine darf heutzutage akzeptiert unendlich lang quasseln: Die KI /AI. :-(( Wichtig ist immer, die Strukturierung von Texten. In einer nur-Text mail hat man da aber nicht so viel Möglichkeiten. Vielleicht ist da auch bei mir noch Verbesserungspotenzial. Ich arbeite dran. Was sagen andere zu dem Thema? Hartmut Schorrig, LbreOffice User & Enthusiast Heiko Tietze schrieb am 01.07.2026 10:33 (GMT +00:00): > Ein paar Antworten (und sicher mehr Fragen) gibt es vielleicht unter > https://bugs.documentfoundation.org/show_bug.cgi?id=81829. Wir haben > aber spezielle Kommandos zum seitenweisen Blättern, die nur nicht > standardmäßig auf Seite hoch/runter gelegt sind. Suche nach > .uno:PageDown / .uno:PageUp - oder benutze den Navigator. > > > On 01.07.26 11:37, [email protected] wrote: >> Aus aktuellem Anlass - habe mich für eine kurze Zeit mich entschieden - nie >> wieder LibreOffice, Asciidoc + html ist doch besser - (nur für kurze Zeit), >> das folgende Requirement... > > -- > Dr. Heiko Tietze, UX-Architect and UI-Designer > Tel: +49 30 5557992-63 | Mail: [email protected] > The Document Foundation, Winterfeldtstraße 52, 10781 Berlin, DE > Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts > Legal details: https://www.documentfoundation.org/imprint > > > -- > Liste abmelden mit E-Mail an: [email protected] > Probleme? > https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ > Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de > Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ > Datenschutzerklärung: https://www.documentfoundation.org/privacy > Voriger Erläuterungen von mir: Aus aktuellem Anlass - habe mich für eine kurze Zeit mich entschieden - nie wieder LibreOffice, Asciidoc + html ist doch besser - (nur für kurze Zeit), das folgende Requirement: Die Tasten PgUp und PgDn (evtl mit Zusatztaste ctrl, ode alt) müssen immer genau eine Seite blättern, bzw. zwei Seiten bei Doppelseitenansicht, und den Inhalt ab dem Kopf der Seite (ohne Ränder, feinjustierbar) anzeigen. Als Begründung eine längere Abhandlung. Damit wird der Use-case genügend gut beschrieben, so dass er auch für denjenigen nachvollziehbar werden könnte, der das Requirement nicht versteht. Nichts ist so schlimm wie ein kurz dahingeschmissenes (hätte beinahe das 'm' vergessen) Requirement aus der Anforderung des heutigen fix-fix-Denkens, dabei aneinander-vorbei-Redens. Ich möchte ggf. eine kurze oder längere Diskussion / Stellungnahme aus verschiedenen Blickwinkeln. Danach werde ich (oder jemand anderes) das Requirement in bugzilla in englisch kurz formulieren. Die ausführliche Begründung sollte auch in Englisch irgendwie verlinkt dort lesbar sein, meine ich. Zugrunde liegende use case-Beschreibung: Das Problem hat sich bei mir zugezogen (verschärft), weil das Schieben im LibreOffice unter Debian 13 KDE auch nach neu booten immer mit einem Nachlauf-hicks verbunden ist. Mit Nachlauf-hicks meine ich folgendes: Man schiebt, schaut, naja, dann nach 1 Sekunde ca. hicks, die Ansicht springt auf eine andere Stelle, ca. 1/2 oder 1/3 Seite woanders. Ursache mag sein, der Renderer braucht etwas länger, und hat nach 1 Sekunde eine neue Information, und plaziert neu. Mit dieser Verhaltensweise ist es aber UNMÖGLICH, ein Dokument durchzuschauen und eine bestimmte Stelle aufzufinden. Abhilfe wäre das Print-View (ctrl-sh-O). Hierbei wirkt nicht pgUp/Dn wie erwartet sondern up/down (einfache Pfeiltasten). Aber das Umschalten zwischen dem print-preview und der richtigen Stelle zum editieren gestaltet sich auch oft etwas komplex. Die Nutzung des print-preview zum durchblättern ist also eine Notlösung. Eine noch allgemeinere Beschreibung mit etwas Polemik: Die nunmehr seit ca. 30 Jahren gewohnte Ansicht im html-Webbrowser hat uns zum Scroll-Denken verführt, auch schon ausgenutzt von Social-Medie Plattformen. Immer weiter scrollen zeigt immer wieder interessantes neues (um den User auf der Seite festzuhalten). Dabei verlorengegangen ist die Seitenstruktur bzw. vielleicht sogar das sinnvolle strukturierte Denken. Beispielsweise sind technische Dokus in pdf oft NICHT auf Seiten orientiert, sondern trotz pdf auf scrollen ausgerichtet. Tabellen fangen rechts unten an, sind dann links oben auf der nächsten Seite fortgesetzt, obwohl sie Überblick bieten sollten. Im pdf-Viewer Scrollmodus fällt das nicht weiter negativ auf. Früher war mal ein Display mit 640x480 pixel nur scrollweise nutzbar. Daher ist der html-Browser damals auch darauf orientiert gewesen. Bei gedruckten Dokumenten hatte man seitenorientiert geschrieben, oft sogar in Spalten. Der Browser hat zu Anfang sowas gar nicht unterstützt, und das ist bis heute so geblieben. Heute kann ich aber auch am 14..15" Display ein pdf doppelseitig anschauen, mdst. als Überblick. Auf einem üblich verfügbaren größerem Monitor sowieso. Selbst am Handy macht die Seitenansicht Sinn, wenn die Seite in zwei Spalten geschrieben ist, je eine Spalte passt auf die vertikale Breite, und man schiebt die nächste Spalte und dann seite nach rechts und links zurück. D.h. die Seitenorientierung eines Dokumentes sollte wieder in die Erinnerung kommen !!! Mit der Seitenorientierung kann eine technische Doku (auch anderes) schön übersichtlich präsentiert werden, damit man mit Durchblättern wichtige Infos findet. Mit entsprechenden passend angeordneten Bildern, Überschriften immer am Seitenanfang, nur Zwischenüberschriften dann in der Mitte, wenn der Inhalt keine Seite füllt. Beim Schreiben des Dokumentes kann man sogar darauf achten, die Menge des Inhaltes so zu wählen, dass die Seitenorientierung passt (Sätze kürzen wenn nur ein kleiner Rest eine extra Seite braucht). Maß der Dinge ist eine auch gedruckt lesbare Doku, in Zweiseitenansicht am normalgroßen Monitor genau so ausschauend. Eine weitere Anmerkung in diesem Zusammenhang: Bücher haben immer die ungerade Seite rechts. Seitenansichten sind nicht immer und nicht vordergründig darauf orientiert. Einige pdf-Viewer können den Bookmode gar nicht. Bei anderen muss man ihn erst mühevoll suchen und einschalten. Auch hier ist wahrscheinlich Wissen und Handlung verloren gegangen. Früher gab es auch gedruckte Dokumentationen, die A4 Größe Landscape hatten, dann pro Seite in 3..4 Spalten geschrieben waren, mit Doppelseitenansicht zwar etwas breit viel Platz auf dem Arbeitsplatz/Schreibtisch gebraucht haben, aber einen guten Überblick geliefert haben. Mit einem großen Monitor ist auch das darstellbar. Mit dieser längeren Darstellung möchte ich Verständnis für die Seitenorientierung als Use-case anregen. Leider errodiert dieses Wissen, insbesondere bei manchen nur auf Bildschirm orientierten Spezialisten der Sotware (negativ gemeint) ohne genügenden PraxisBezug. Daher die Anforderung, einfache Tastenbedienung zu haben, um im Dokument zu blättern. Wenn die Seite nicht vollständig auf den Bildschirm passt, ist dennoch IMMER auf die nächste Seite oben orientiert zu blättern. Denn bei der Seitenübersicht konzentriert man sich of auf den Seitenanfang. Unten ist evtl kaum etwas wichtiges. Runter scrollen ist schnell gemacht. Und PgUp/Dn stellt dann wieder zurück auf die gewohnte Seitenanfang-Sicht. Eine Feinjustierung, bei welcher Seiten-cm vertikal dargestellt wird, sollte jedenfalls möglich sein: Denn: ich brauche keinen leeren Rand betrachten, wenn das Display doch nur 14" hat, sondern will möglichst viel bis nach unten sehen. -- Liste abmelden mit E-Mail an: [email protected] Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
