per STRG+a aus einem mit Libreoffice erzeugten PDF kopierter Text enthält plötzlich Schreibfehler

Wenn ich Text per STRG+a aus einem mit Libreoffice erzeugten PDF kopiere, enthält der kopierte Text plötzlich Schreibfehler. Woran kann das liegen und wie kann ich das beheben?

Beispiel:

Konfiguration → Konfizguration
beruflich → berufliich
berufliche → berufleiche
finden → finnden
öffentlich → öffeentlich
Muttersprache → Muttlersprache
Pflege → Pfleege
pflegen → pfleigen

Der Fehler ist beliebig reproduzierbar.
Das Original (display und text-container) enthält keine Schreibfehler.
Ich bette die Schriftart vollständig ein.
Das PDF enthält augenscheinlich keine Fehler.
Ich benutze keinerlei Autokorrektur, Rechtschreibkorrektur und ich sammle keine Worte.

Gleiches Problem, andere Version, jemand anders:

Kannst Du einmal
→ so ein Dokument hoch laden und
→ die benutzte Version von LO sowie
→ die Exporteinstellungen der PDF-Datei benennen (Screenshot des Exportdialogs, Reiter “Allgemein”)

Entschuldige die späte Reaktion; ich hatte das PDF vor meinem post hier nicht probeweise mit unterschiedlichen PDF-Viewern geöffnet/getestet. Es tritt nur bei einem bestimmten Viewer auf. Es liegt nicht an LO. Vielen Dank für die rasche Annahme des Problems, die zur Lösung bzw. zur Ursache führte.

Mich freut es, dass du dein Problem schon lösen konntest. Könntest du uns aber trotzdem zumindest sagen, bei welchem PDF-Viewer das Problem aufgetreten ist?

Ich kenne mich mit PDF weniger aus. Aber kategorisch ausschließen, dass das Problem bei LO liegt, würde ich nicht.

Danke :slight_smile:

Ich kopiere über STRG+a so gut wie nie etwas aus einem PDF. Ich wollte eine Tabellenstruktur anhand des kopierten Textes überprüfen. Das Problem tritt aber auch bei zB. wahllos aus dem netz kopierten und per STRG+SHFT+v in ein writer-Dokument eingefügtem Fließtext auf. Der Fehler scheint imho beim Export nach PDF bzw. in der Darstellung des Textes im PDF-Viewer zu entstehen, da der Textcontainer keine Rechtschreibfehler enthält. Der PDF-Viewer ist Sumatra-PDF und Probleme hatte ich bis LibreOffice, Version 24, nie damit.

Die Einstellungen

Standardschriftart: Liberation Serif

Dateieigenschaften:: Schriftarten: vollständig ins Dokument eingebettet; ansonsten keine Änderungen

PDF-Export:: Allgemeine Einstellungen: siehe screenshot

LibreOffice:: 24.8.4.2 (X86_64); Build: bb3cfa12c7b1bf994ecc5649a80400d06cd71002; CPU threads: 6; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: CL threaded

LibreOffice-Einstellungen::Standardprogamm:ja; Java:nein; Makrosicherheit:höchste, ohne Zertifikate; keine Änderungen bei Kompatibilität; Bitmaps reduzieren: 600 dpi

Betriebssystem: Win 10 Pro 19045.4894 (1000.19060.1000.0)

Wie ich das schreibe, fällt mir auf, dass ich die LO-Einstellung Bildreduzierung auf 600 dpi zum ersten Mal benutze. Ich lasse das Schrumpfen sonst vom PDF-Editor machen oder füge nativ Bilder mit 300 dpi ein. Ich schaue an dieser Stelle nochmal genauer hin.

Hier noch die erweiterten Sumatra-Einstellungen:

# For documentation, see Customizing SumatraPDF 3.5.1
Theme = Light
FixedPageUI [
TextColor = #000000
BackgroundColor = #ffffff
SelectionColor = #f5fc0c
WindowMargin = 2 4 2 4
PageSpacing = 4 4
InvertColors = false
HideScrollbars = false
]
ComicBookUI [
WindowMargin = 0 0 0 0
PageSpacing = 4 4
CbxMangaMode = false
]
ChmUI [
UseFixedPageUI = false
]

SelectionHandlers [
]
ExternalViewers [
]

ZoomLevels = 8.33 12.5 18 25 33.33 50 66.67 75 100 125 150 200 300 400 600 800 1000 1200 1600 2000 2400 3200 4800 6400
ZoomIncrement = 0

PrinterDefaults [
PrintScale = shrink
]
ForwardSearch [
HighlightOffset = 0
HighlightWidth = 15
HighlightColor = #6581ff
HighlightPermanent = false
]
Annotations [
HighlightColor = #ffff00
UnderlineColor = #00ff00
SquigglyColor = #ff00ff
StrikeOutColor = #ff0000
FreeTextColor =
FreeTextSize = 12
FreeTextBorderWidth = 1
TextIconColor =
TextIconType =
DefaultAuthor =
]

RememberOpenedFiles = false
RememberStatePerDocument = false
RestoreSession = true
UiLanguage = en
InverseSearchCmdLine = “C:\Program Files\Notepad++\notepad++.exe” -n%l “%f”
EnableTeXEnhancements = true
DefaultDisplayMode = automatic
DefaultZoom = fit page
Shortcuts [
]
EscToExit = false
ReuseInstance = true
ReloadModifiedDocuments = true

MainWindowBackground = #80fff200
FullPathInTitle = true
ShowMenubar = true
ShowToolbar = true
ShowFavorites = false
ShowToc = true
NoHomeTab = true
TocDy = 0
SidebarDx = 0
ToolbarSize = 18
TabWidth = 300
TreeFontSize = 0
TreeFontWeightOffset = 0
TreeFontName = automatic
SmoothScroll = true
ShowStartPage = true
CheckForUpdates = true
WindowState = 1
WindowPos = 508 30 904 1170
UseTabs = true
UseSysColors = false
CustomScreenDPI = 0

FileStates [
]
SessionData [
]
TimeOfLastUpdateCheck = 0 0
OpenCountWeek = 736

# Settings below are not recognized by the current version


EDITH: Das Problem tritt seit heute morgen derzeit nicht mehr auf (obwohl ich seit Auftreten des Problems nichts an den Einstellungen verändert oder das Programm bzw. Windows aktualisiert habe).

Den Wirkmechanismus würde ich dann gerne kennenlernen. LO wird beim öffnen des pdf NICHT gestartet (Ausnahme: jemand lädt es in Draw) sondern der Viewer MUSS das alleine hinbekommen.
.
Ich nehme ausserdem an, dass der Text von SumatraPDF (und anderen Viewern) korrekt angezeigt wird da @amf schrieb:

Das Problem liegt also im Bereich Übergabe ans Clipboard/ evtl dortige Verarbeitung / Weitergabe an das Zielprogramm. Nichts wo das erzeugende Programm eine Rolle spielt, deshalb nutzen wir ja PDF.
.
Was mir auffällt: In allen Beispielen tauchen die Fehler an möglichen Ligaturen oder direkt danach auf: fi, fl, ff
Ohne die Datei ist das nur ein “Schuss ins Blaue”, aber eine fehlerhafte Übergabe von Ligaturen an Textdarstellung halte ich für durchaus möglich und würde auch zu dem englischen Fall passen:

Ansonsten bleibt noch die magische Problemlösung…

Du vielleicht nicht, aber gestern war Patchday bei Microsoft

Die Häufung bei sich nahestehenden Buchstaben ist mir auch aufgefallen, doch ‘Konfizguration’ und ‘pfleigen’ kamen mir nicht wie Ligaturprobleme vor. Ich bin nun erstmal provisorisch von Linux Libertine auf Libertinus, einen aktuellen fork der Libertine, umgestiegen, bis ich mich tiefer eingelesen habe. Die etwas älteren Fremdfonts scheint windows laut netz nicht immer korrekt zu interpretieren. Ich werde meine fonts sortieren müssen in kann-windows und kann-windows-nicht-so-gut. Mit der Libertinus treten die Fehler nicht mehr auf.