[de-discuss] Lokale Links zu html Seiten werden nicht mit Anchor geöffnet, in Linux sogar nur mit dem Text editor

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">&gt;&gt;</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">&gt;&gt;</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: discuss+unsubscribe@de.libreoffice.org
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