Hier gibt es entweder einen langjährigen Fehler oder eine große Unklarheit wie man das einstellt:
Auf meinem Windows-PC habe ich mich mehrfach geärgert, dass ein Link ins Internet mit Labelangebe (Anchor, Target) schön geht, aber nicht lokal. Beispielsweise geht, https://vishia.org/fbg/docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgModule.html#stm geht nicht: file:///home/D/vishia/fbg/docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgModule.html mit Angabe Target: htm. Im content.xml steht <text:p text:style-name="Text"> <text:a xlink:type="simple" xlink:href="https://vishia.org/fbg/docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgMdlStates.html"; text:style-name="Internet_20_link" text:visited-style-name="Visited_20_Internet_20_Link">>></text:a> <text:a xlink:type="simple" xlink:href="../../docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgMdlStates.html" text:style-name="cJ" text:visited-style-name="cJ">OdgMdlStates</text:a> <text:s text:c="1"/>is referred in <text:a xlink:type="simple" xlink:href="https://vishia.org/fbg/docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgModule.html#stm"; text:style-name="Internet_20_link" text:visited-style-name="Visited_20_Internet_20_Link">>></text:a> <text:a xlink:type="simple" xlink:href="../../docuSrcJava_FBcl/org/vishia/fbcl/readOdg/OdgModule.html#stm" text:style-name="cJ" text:visited-style-name="cJ">OdgModule#stm</text:a> <text:s text:c="1"/>as instance for each module for StateMachine’s stuff.</text:p> Den content.xml habe ich zugegebenerweise selbst erzeugt, aber er wird genauso wie normal im Loffc writer verarbeitet Funktioiert vollständig und die Erscheinung ist auchg genau so, wenn ich im LibreOffice direkt arbeitet. Fühle mich unschuldig, mehrmals dort drübergeschaut. Der Background für's selbst generieren ist: https://vishia.org/LibreOffc/html/Videos_LOffcZmL.html Im XML Fällt auf: Beim lokalen link fehlt das file:// weil der path relativ ist. In beiden Fällen steht aber das target hinter dem ".html#target" obwohl im LibreOffice "Edit-Hyperlink" Dialogbox es einmal als "Internet" und beim lokalen Link als "Document" angezeigt wird. Der file ist lokal natürlich vorhanden! Und das Label/Target darinnen auch. Es ist das gleiche File lokal wie im Internet. Folgt eine etwas ausführlichere Usecase-Beschreibung, was ich damit bezwecken will: Die Anwendung dessen ist: Ich schreibe Softwaredoku in LibreOffice, die übergeordnete Doku, und habe daher links zur automatisch generierten javadoc dort drin. Die Javadoc lässt sich nach Änderung der Java-Quellen ganz leicht jeweils neu generieren- ein Knopfdruck. Es wäre nun gut, aus dem LibreOffice sofort mit dem lokalem Link testen zu können, ob alles passt, insbesondere ein möglicherweise komplexes Target gefunden wird. Kritisch und interessant ist das bei Operations (mit Argumenten), die verlinkt sind. Da ist FEINARBEIT. Aber nein, das Target geht nicht. Um zu testen, muss ich zuerst die geänderten Javadoc Files alle ins Internet stellen. In zip packen, hochladen, im Server über SSH Konsole entzippen. Das dauert ca. 2..5 min mit Konzentration, geht also nicht im schnellen Arbeits-flow, sondern nur als End-Aktion, schauen ob alles passt. Beim Arbeiten auf Linux-Debian12 Xfce ist es dann noch viel schlimmer geworden. Anstelle des Browsers öffnet der Mousepad. Als Suchanfrage ins Internet nach dem "Mousepad öffnen" problem bin ich schnell fündig geworden, bspw. https://www.reddit.com/r/linuxmint/comments/snl9z9/libreoffice_in_linux_mint_opening_clickable_urls/ 4 Jahre alt, und der Schreiber denkt, es wäre ein mint Problem. https://ask.libreoffice.org/t/accessing-local-files-in-the-html-file-is-not-working/110742 Hier ist mir nicht klar, ob es darum geht einen link zu öffnen, oder einen html-File in LOffice. Allerdings steht hier ein wichtiger Hinweise drin, Zitat: Side note: Links should include the transfer protocol. For local files that should be “file:” Möglicherweise ist aber für das Transfer-Protokoll "file://" richtiger, vs. "https://";, der "//" ist der Trenner und anzugeben. Mit dieser side note, die Schreibweise kenne ich schon lange, habe ich ggf. das erste mal verstanden, wie Linux mit sowas umgeht, wo Windows die Extension benutzt. Also ".html" öffent dort den standard-Browser, und der schaut dann erst auf das Transferprotokoll. Im Zusammenspiel mit LOffc und Linux ist das wahrscheinlich so, dass das linux das Transferprotokoll gesagt bekommt, und bei https:// den Standardbrowser öffent, (funzt). und bei file:// eben leider den Mousepad (Texteditior) öffenet, dabei aber das Target missachtet. Im linux habe ich in den Settings-Preferred Applications geblättert, (was bei Xfce "Default Applications" heißt), damit bin ich aber NICHT klar gekommen, sorry, wenn es da bei MIMEType einen Eintrag file:// geben würde oder https:// dann könnte ich mir den Rest denken. Mir erschließt sich das aber bisher nicht. Das Thema mit den nicht funktionierenden lokalen Label-links trage ich seit 2 Jahren vor mir her. Aber möglicherweise ist das Problem häufiger auch bei Anderen präsent, nur leider nicht in einem entsprechenden Fokus wie diverse calc-Zellen-Probleme. Was mich interessieren würde, vielleicht kann man das als allg. Doku irgendwo anbringen: Wie funktioniert generell der Weg vom Anklicken eines Links im LibreOffice bis zum Empfänger. Es muss dabei das Betriebssystem informiert werden. Das ruft eine exe mit dem Link, und die verarbeitet dann den link. Dieser Weg muss klar sein. Wie die Exe umgeht (der Browser öffnet im Internet oder auch lokal), ist dann nicht mehr Teil der Erklärung, denn das ist Sache der Executable (des Browsers oder irgendein beliebig anderes programm). Wenn ich aus dem odt ein pdf erzeuge, wird im Linux beim lokalen Link auch der Mousepad geöffnet. D.h. dies ist kein Loffc Problem sondern ein Problem des Betriebssystems. Ich als Enduser mit absoluten Programmierkenntnissen aber unzureichenden Kenntnissen wo man bei debian Xfce einstellen muss, finde das nicht, habe keine Zeit und bin genervt. Warum steht in der Dialogbox zum "Edit-Hyperlink" bei "Internet" das Target hinten an "....html#target", beim lokalen Link "Document" ist es aber getrennt in einem "Target"-Feld? Warum wird das in der Dialogbox ungleich behandelt? Das hat sicherlich eine Historie, hat sich mal einer so gewünscht ???? aber mich irritiert es, mal so, mal so. Das Target müsste zum Aufruf-pfad zugehören. Allerdings würde dann der Mousepad eine Datei "/path/to.html#target" suchen und also nicht finden. Evtl. ist das der Grund. Also macht es sinn. Dieser Gedanke kam mir erst jetzt. Dann müsste das target der 2. parameter des Aufrufs eines cmd sein! Dann könnte ich ein kleines Shell-script schreiben (Oder windows-Batch-file), was den Aufruf auf den Browser umlenkt. D,h, das Target-problem wäre damit finit lösbar! Und erklärbar! Damit verbleibt das problem, wie wird im OS der Aufruf des Links organisiert, speziell in Linux? Doch halt, es ist doch wieder anders: Die im Linux generierte pdf im Windows geöffnet (mit PDF XChange Viewer) fragt: "Die Anwendung versucht .... Vertrauen sie..." und gibt dabei den vollen Pfad inclusive hinten "#stm" als target an, (auch beim Hover erscheint das Target), =>öffnet den File im Browser aber dann doch wieder ohne auf das Target zu gehen. Es scheint also so zu sein, dass der Browser der schuldige ist und bei file:// die target Angabe missachtet. Browser ist bei mir dort Opera, andere jetzt nicht probiert. Da ich das problem schon so lange vor mir her trage, und vermute, auch Andere könnten es haben, sagen nur nichts, ist die mail etwas länger geworden, sorry. Ich möchte auch eindeutig erklären, und nicht kurze Snippets hinwerfen wie oft in solchen Anfragen. Kann jemand dazu was sagen Grüße von Hartmut Schorrig -- 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
