WRITER - importierte PDFs ab LO 5.4.X.X unscharf

de-users
#1

Hallo,

folgendes Problem ab LO 5.4.X.X (unter "Windows 7 Home Premium 64-bit"):

[1] Mit LO 5.3.X.X (bis einschließlich LO 5.3.7.1 (Parallelinstallation)) werden in WRITER eingefügte PDFs fehlerlos dargestellt, mit LO 5.4.X.X (bis einschließlich LO 5.4.3.1 (Parallelinstallation)) hingegen sind die eingefügten PDFs im Vergleich zu LO 5.3.X.X sehr deutlich unscharf.
[2] Alle in WRITER eingefügte PDFs wurden mit der PDF-Export-Funktion von CALC beziehungsweise DRAW erzeugt.
[3] WEB-Link zum Download der Beispieldatei "BremsModul.odt": https://www.magentacloud.de/share/wfrp2q71-a

Was mir sonst noch aufgefallen ist:

Bei LO 5.3.X.X ist unter "Format>Bild>Eigenschaften>Zuschneiden" oberhalb der Auswahl "Originalgröße" nur die Bildgröße "XX.XX cmxYY.YYcm" angegeben, bei LO 5.4.X.X hingegen "XX.XX cmxYY.YYcm (96PPI)". Verbesserungsversuche über "Format>Bild>Komprimieren" waren faktisch ohne Wirkung, da sich das "Komprimieren"-Feature wohl nur auf die Formate JPG und PNG bezieht, nicht aber auf PDF.

Beim Scrollen (obiger) Datei unter LO 5.3.X.X hängt LO kurzzeitig bei den Punkten "4 Platine" und "6 Steckplatine" (womit ich persönlich gut leben kann), bei LO 5.4.X.X hingegen tritt dieser Effekt nicht auf, was wohl mit der (automatisch) verringerten Auflösung der PDFs unter LO 5.4.X.X zu tun hat. Unter LO 5.4.X.X habe ich keinen Menüpunkt gefunden, wo man die Auflösung der PDFs manuell wieder hochsetzen könnte. Gibt es diese Möglichkeit überhaupt ?

Kann jemand das Problem nachvollziehen ?

Ich persönlich fände es sehr schade, wenn man das PDF-Import-Feature deshalb in Zukunft nicht mehr (wirklich) nutzen könnte, da es eine wunderbar einfache und sehr flexible Möglichkeit darstellt, Inhalte von z.B. DRAW und/oder CALC in WRITER darzustellen.

In einem früheren Thread wurde mir von Thomas empfohlen doch anstatt dem PDF-Format das SVG-Format zu nutzen. Das habe ich natürlich auch ausprobiert, aber leider wurde LO dabei beim Öffnen der WRITER-Datei um den Faktor 10 (und mehr) langsamer und die SVGs haben sich auch nicht mehr richtig aus dem WRITER-Dokument löschen lassen.

Gruß
Hans-Werner

#2

Hallo Hans-Werner,

ich kann Deine Erkenntnisse bestätigen (unter Windows 10, 64 BIt). Version 5.3.x -> scharfes Bild, Version 5.4.x und 6.0 -> unscharf.

Nun würde ich aus meiner bisherigen Erfahrung mit Bildverarbeitung in allen Programmen sagen: Version 5.3 mit dem "scharfen" Bild ist ungewöhnlich und fällt eigentlich aus der Reihe raus - die Versionen 5.4 und 6.0 verhalten sich wie erwartet;)

Warum? Pixelbilder sind immer nur dann exakt scharf auf dem Bildschirm, wenn sie die Auflösung genau treffen. Einen leichten "Schärfe-Effekt" kann man durch Verkleinerung des Bildes erzielen - umgekehrt aber wird ein Pixel-Bild immer unscharf, wenn es vergrößert wird.

Lässt sich in Deinem Dokument im übrigen nachvollziehen: Deine Bilder sind alle skaliert - 145%/145%  in LO 3.4.x, 145%/146% in nachfolge-LO Versionen, das muss unscharf werden. Die unterschiedlichen Prozentzahlen weisen aber auch darauf hin, dass irgendetwas im Berechnungsallgorythmus geändert wurde. Voraussichtlich die DPI anpasssung - was eventuell auch die schtbare Unterschiede erklären könnte.

Wenn Du übrigens in LO 5.4.x oder 6.0 die Bildgröße auf 100% zurücksetzt (Orginalgröße) - ist das Bild auch schön scharf :wink:

Hilft Dir jetzt nicht viel - am besten gibst Du einen Bug auf mit genau diesen Informationen und Hinweisen und der Beispieldatei - schätze aber, das wird nicht viel ändern.

Eventuell mal über Deinen Arbeitsfluss nachdenken und die Bildgrößen verändern?

Viele Grüße

Thomas

#3

Hallo Thomas,

danke für Deine Überprüfungen und Hinweise.

Für mich ist nur nicht nachvollziehbar, dass das Ungewöhnliche (" ... Version 5.3 mit dem "scharfen" Bild ist ungewöhnlich ...") wieder aufgegeben wurde, wo es doch so wunderbar funktionierte. Davon abgesehen, zu dem damaligen Zeitpunkt hatte ich natürlich nicht den Vergleich zu höheren LO-Versionen und hatte deshalb voller Freude diese neue Möglichkeit genutzt.

Ja, das stimmt, bei 100% sind die Bilder alle scharf. Aber die Möglichkeit unter LO 5.3, die Bilder ohne Schärfeverlust zu vergrößern, war ja die wunderbar neue Möglichkeit, wo man sich beim Entwurf der Ausgangsdatei keinerlei Gedanken machen musste.

Ich habe den Eindruck, dass ab LO 5.4 eine Art PDF-Zwangsskalierung bezüglich der Auflösung eingeführt wurde, damit vielleicht das Scrollen der Datei "flüssig" bleibt ( siehe mein Hinweis auf die 96PPI-Angabe ab LO 5.4 ), die man doch sicherlich auch wieder aufheben oder zumindest durch den Anwender modifizierbar machen könnte.

Mit einem BUG-Report habe ich mich erst mal zurückgehalten, weil mir eben nicht klar ist, ob es ein BUG ist oder ob es so gewollt ist. Mal sehen, ob hier im Forum noch weitere Meinungen zu diesem Thema kommen ...

Gruß
Hans-Werner

------ Originalnachricht ------

#4

Hallo zusammen!
Ich verstehe garnichts mehr: Ich habe ein Makro geschrieben, das einen speziellen Jahreskalender in einer Tabellen-Calculation generiert. Für die Strukturierung der Tabelle habe ich ein Makro, das um einen Bereich eine Umrandung erzeugt. Die Bereiche werden als Namen angegebn, z.B. "$A1:$EG5".  Da die Breite der Monatstabellen variiert, Februar, Schaltjahr,30,31 Tage, möchte ich die Angaben als Position machen, und das geht schief. Die Funktion sieht so aus:

Sub doRahmen(sBereich As String,d As Integer)
'Sub doRahmen(iLOx As Integer,iLOy As Integer,iRUx As Integer,iRUy As Integer,d As Integer)
    Dim oZelle As Object
    oDoc = ThisComponent
    oSheets = oDoc.getSheets()
    zahl = oDoc.getSheets().Count+1
    oTab = oDoc.createInstance("com.sun.star.sheet.Spreadsheet")
       oController      = oDoc.CurrentController
       oSheet           = oController.activesheet
       oZelle             = oSheet.getCellRangeByName(sBereich)
'       oZelle             = oSheet.getCellRangeByPosition(iLOx,iLOy,iRUx,iRUy)
    Dim oLinie1 as new com.sun.star.table.BorderLine
    With oLinie1
        .Color = 16724991
        .outerLineWidth = d
    End With
    Dim oRahmen as new com.sun.star.table.TableBorder
    With oRahmen
        .leftLine = oLinie1
        .isLeftLineValid = True
        .rightLine = oLinie10
        .isRightLineValid = True
        .bottomLine = oLinie1
        .isBottomLineValid = True
        .topLine = oLinie1
        .isTopLineValid = True
    End With
    oZelle.TableBorder = oRahmen
End Sub
 Es funktionert einwandfrei mit der Namensangabe z.B. mit dem Aufruf
doRahmen("$A$1:$EG$2",71)

Benutze ich die in der Prozedur auskommentierten Zeilen, Ortsbestimmung per Position, dann kommt die Fehlermeldun : Prozedur schon wo anders definiert???. Na schön habe ich gedacht, dann setze ich vor das doRahmen noch ein i, also idoRahmen. Ergebnis: gleiche Fehlermeldung. Wat nu?
    doRahmen(0,0,33,1,71)
Ich würde ja akzeptieren wenn die Prozedur bei der Änderung garnicht mehr funktionieren würde, aber die Fehlermeldung kommt schon, wenn man einen Haltepunkt setzt.
Mein System:
Linux Mint 18.2 Sonya 64 Bit
Kernel Linux 4.8.0-53-generic,  x86_64
Mate 1.18.0

Mit freundlichen Grüßen
Günter

#5

Hallo Günter,

ich habe das an einem neuen Calc-Dokument ausprobiert, bei mir funktioniert das. Mein Release: 5.3.4.2. Es würde mich aber sehr wundern, wenn das Release damit zu tun hätte.
Versuche das auch mal ohne das Drumherum deines jetzigen Dokuments in einem neuen Dokument, wenn es dann wie bei mir klappt, wird etwas an deinem sonstigen Code das Problem sein.
Zwei Anmerkungen noch:

  * An einer Stelle hast du im Code, den du geschickt hast, oLinie10
    statt oLinie1; das meldet Basic ordentlich als Fehler
  * zahl und oTab wird offenbar derzeit nicht gebraucht und tut auch
    nichts Sichtbares

Gruß

Gerhard

#6

Hallo Günter,

Die Fehlermeldung muss sich nicht auf den Namen "doRahmen" beziehen - sondern kann im Extremfall auch jeden anderen Bezeichner in dieser Zeile treffen - also auch oLOx, iLOy, iRUx, iRUy oder d.  Das kann im Zweifel auch eine intern definierte Prozedur sein!

Wenn es allerdings beim Gerhard funktioniert, liegt der Fehler wohl woanders....

Bei mir liefert der Code im Übrigen auch keine Fehlermeldung (Win 10, LO 5.3.x) , wäre also interessant, wie Du die Funktion aufrufst?

Viele Grüße

Thomas

#7

Hallo Hans-Werner,

Zusatzinfo:  Unter Linux (Mint 64Bit) und Lo 6.0 Alpha 0 sieht es noch schlimmer aus. Dagegen wäre die Windows-Variante auch unter 5.4 noch als "scharf" zu bezeichnen;)

Also, da ist sicher irgendetwas "faul".

Viele Grüße
Thomas

Hallo Hans-Werner,

ich kann Deine Erkenntnisse bestätigen (unter Windows 10, 64 BIt). Version 5.3.x -> scharfes Bild, Version 5.4.x und 6.0 -> unscharf.

Nun würde ich aus meiner bisherigen Erfahrung mit Bildverarbeitung in allen Programmen sagen: Version 5.3 mit dem "scharfen" Bild ist ungewöhnlich und fällt eigentlich aus der Reihe raus - die Versionen 5.4 und 6.0 verhalten sich wie erwartet;)

Warum? Pixelbilder sind immer nur dann exakt scharf auf dem Bildschirm, wenn sie die Auflösung genau treffen. Einen leichten "Schärfe-Effekt" kann man durch Verkleinerung des Bildes erzielen - umgekehrt aber wird ein Pixel-Bild immer unscharf, wenn es vergrößert wird.

Lässt sich in Deinem Dokument im übrigen nachvollziehen: Deine Bilder sind alle skaliert - 145%/145%  in LO 3.4.x, 145%/146% in nachfolge-LO Versionen, das muss unscharf werden. Die unterschiedlichen Prozentzahlen weisen aber auch darauf hin, dass irgendetwas im Berechnungsallgorythmus geändert wurde. Voraussichtlich die DPI anpasssung - was eventuell auch die schtbare Unterschiede erklären könnte.

Wenn Du übrigens in LO 5.4.x oder 6.0 die Bildgröße auf 100% zurücksetzt (Orginalgröße) - ist das Bild auch schön scharf :wink:

Hilft Dir jetzt nicht viel - am besten gibst Du einen Bug auf mit genau diesen Informationen und Hinweisen und der Beispieldatei - schätze aber, das wird nicht viel ändern.

Eventuell mal über Deinen Arbeitsfluss nachdenken und die Bildgrößen verändern?

Viele Grüße

Thomas

[..]

#8

Hallo Gerhard,

Vielen Dank für Deine schnelle Antwort. Es heißt bei mir auch oLinie1, die 0 ist wohl beim Kopieren dazugekommen. Ich habe jetzt ein ganz neues Dokument erzeugt, mit einem ganz anderen Namen xyz. Als Makro ist außer Main nur noch die Prozedur doRahmen. Dann kann ich einen Haltepunkt setzen, ohne daß etwas passiert. Wenn ich das ausprobieren möchte und unter Main einen Aufruf doRahmen() eintrage, kommt beim Haltepunkt setzen die Fehlermeldung "Libreoffice 5.1.6.2, Symbol doRahmen bereits anders definiert". Das gleiche funktioniert auf einem Notebook mit einem ganz alten Libre-office. Der Fehler passiert auch bei einer leeren  Prozedur, die nur aus "Sub-Zeile" und "End Sub" besteht.Wenn ich den Bereich als String festlege funktioniert es. Aber folgendes Kuriosum.

Der richtige Aufruf wäre doRahmen("$A$1:$K$7",71)

Wenn die Aufrufanweisung aber falsch ist, wie z.B.

doRahmen("") oder doRahmen(71) dann kommt beim setzen eines Haltepunktes die bewußte Fehlermeldung, ganz ohne Aufruf. Ich werde wohl in den sauran Apfel beißen  und eine Umwandlungsfunktion "Position nach Name" schreiben.

Habts eine gute Zeit zusammen

Herzliche Grüße

Günter

#9

Hallo Günter,

ich habe deine Fehlermeldung provozieren können,  wenn die Parameter von doRahmen beim Aufruf anders sind als in der Defintion. Schau also erst einmal penibel deinen Aufruf an, bevor du in deinen sauren Apfel beißt.

Ich schicke unten den vollständigen Code meines Test, den kannst du ja mal in dein Testdok. kopieren und ausprobieren, dann hast du exakt den Fall nachvollzogen, der geht. Ich habe zwei subs für die beiden Fälle, aber inhaltlich nichts geändert außer dem Aktivieren der passenden Zeilen.

Ein anderer Grund für die Meldung könnte sein, dass du in einer anderen Bibliothek eine Funktion gleichen Namens hast, aber das hast du ja durch den Test mit idoRahmen praktisch ausgeschlossen.

Gerhard

Sub Main
doRahmen("B2:C3", 3)
doRahmen2(0,0,33,1,71)

End Sub

Sub doRahmen(sBereich As String,d As Integer)
'Sub doRahmen(iLOx As Integer,iLOy As Integer,iRUx As Integer,iRUy As Integer,d As Integer)
    Dim oZelle As Object
    oDoc = ThisComponent
    oSheets = oDoc.getSheets()
    zahl = oDoc.getSheets().Count+1
''    oTab = oDoc.createInstance("com.sun.star.sheet.Spreadsheet")
       oController      = oDoc.CurrentController
       oSheet           = oController.activesheet
       oZelle             = oSheet.getCellRangeByName(sBereich)
'       oZelle             = oSheet.getCellRangeByPosition(iLOx,iLOy,iRUx,iRUy)
    Dim oLinie1 as new com.sun.star.table.BorderLine
    With oLinie1
        .Color = 16724991
        .outerLineWidth = d
    End With
    Dim oRahmen as new com.sun.star.table.TableBorder
    With oRahmen
        .leftLine = oLinie1
        .isLeftLineValid = True
        .rightLine = oLinie1''0
        .isRightLineValid = True
        .bottomLine = oLinie1
        .isBottomLineValid = True
        .topLine = oLinie1
        .isTopLineValid = True
    End With
    oZelle.TableBorder = oRahmen
End Sub

'Sub doRahmen(sBereich As String,d As Integer)
Sub doRahmen2(iLOx As Integer,iLOy As Integer,iRUx As Integer,iRUy As Integer,d As Integer)
    Dim oZelle As Object
    oDoc = ThisComponent
    oSheets = oDoc.getSheets()
    zahl = oDoc.getSheets().Count+1
    oTab = oDoc.createInstance("com.sun.star.sheet.Spreadsheet")
       oController      = oDoc.CurrentController
       oSheet           = oController.activesheet
'       oZelle             = oSheet.getCellRangeByName(sBereich)
       oZelle             = oSheet.getCellRangeByPosition(iLOx,iLOy,iRUx,iRUy)
    Dim oLinie1 as new com.sun.star.table.BorderLine
    With oLinie1
        .Color = 16724991
        .outerLineWidth = d
    End With
    Dim oRahmen as new com.sun.star.table.TableBorder
    With oRahmen
        .leftLine = oLinie1
        .isLeftLineValid = True
        .rightLine = oLinie1''0
        .isRightLineValid = True
        .bottomLine = oLinie1
        .isBottomLineValid = True
        .topLine = oLinie1
        .isTopLineValid = True
    End With
    oZelle.TableBorder = oRahmen
End Sub

#10

Hallo Thomas,

na, das ist ja schon fast eine "positive Nachricht" in dem Sinne, dass ein BUG-Report vielleicht doch Wirkung zeigen könnte. Dann werde ich mich mal dort anmelden, meine Englisch-Kenntnisse heraus kramen und eine BUG-Report absetzen.

Ich denke, da die PDF-Import-Funktion noch relativ neu in LO ist, sind halt noch ein paar "Kinderkrankheiten zu kurieren" ... aber ich hoffe sehr, dass sie in der Variante und Güte von LO 5.3 erhalten bleibt, denn es ist wirklich ein "easy living", wenn man sich um die Quell-Dokumente der PDFs keine zusätzlichen Gedanken machen muss in dem Sinne: Einfügen, skalieren und fertig ohne den geringsten PDF-Schärfeverlust, egal, in welche Richtung (kleiner oder größer) man in WRITER skaliert ;-)) ...

Ich hatte auch mal jetzt zum Test bei dem PDF-Export 200% angegeben und dann eben im WRITER-Dokument verkleinert - na ja, bissel besser war es schon, aber nichts im Vergleich zu LO 5.3.

Grüße
Hans-Werner

------ Originalnachricht ------

#11

Hallo Günter,

Nein. Die Funktion doRahmen() ist schon ok. Da liegt der Fehler nicht.

Der Fehler ist im Aufruf. Den hast Du uns bisher vorenthalten!

Die Funktion (bei dir sub) doRahmen() hat diverse Parameter definiert. Diese sidn - wenn nicht mit "optional" definiert - bindend.

In deiner ersten Funktion hast Du zwei Parameter definiert - also funktioniert der Aufruf doRahmen("$A$1:$K$7",71) auch.

Rufst Du aber doRahmen("") oder doRahmen(71) auf, so fehlt ja ein Parameter - für LO Basic ist das nun eine neue Funktion - und das geht nicht, weil ja dieser Name schon vergeben ist.

Wenn Du deine Sub also mit 5 Parametern definierst (deine auskommentierte) - dann musst Du auch bei allen Aufrufen 5 Parameter übergeben - sonst geht das nicht!

Viele Grüße

Thomas

#12

Hallo *,

Ich habe die Beispieldatei "BremsModul.odt" in folgenden Parallelinstallationen von LibO geöffnet:

LibreOffice_4.4.7.2_Linux_x86-64  -->  Die eingefügten PDFs werden fehlerlos dargestellt.

LibreOffice_5.0.6.3_Linux_x86-64  -->  Die eingefügten PDFs werden fehlerlos dargestellt.

LibreOffice_5.1.6.2_Linux_x86-64  -->  Die eingefügten PDFs werden fehlerlos dargestellt.

LibreOffice_5.2.7.2_Linux_x86-64  -->  Die eingefügten PDFs werden fehlerlos dargestellt.

LibreOffice_5.3.6.1_Linux_x86-64  -->  Die eingefügten PDFs werden fehlerlos dargestellt.

LibreOffice_5.4.2.2_Linux_x86-64  -->  Die eingefügten PDFs werden _sehr unscharf_ dargestellt.

Gruß,
JPS

#13

Hallo Hans-Werner,

na, das ist ja schon fast eine "positive Nachricht" in dem Sinne, dass
ein BUG-Report vielleicht doch Wirkung zeigen könnte. Dann werde ich
mich mal dort anmelden, meine Englisch-Kenntnisse heraus kramen und eine
BUG-Report absetzen.

bei der Geschichte handelt es sich wohl "lediglich" um einen
Darstellungsfehler. Exportiere ich von LO 5.4.3.1 aus die Datei als
*.pdf-Datei, so werden die Abbildungen scharf dargestellt. Gleiches gilt
dann wohl auch für den Druck.

Ich kann mich entsinnen, dass so etwas mit einfachen *.png-Dateien
(Screenshots) auch früher schon ein Problem war. Ich habe daher immer
die Screenshots so gemacht, dass die Datei 1:1 in meinen Text
(Base-Handbuch) passte.

Gruß

Robert

#14

Hallo Robert,

angeregt durch Deine Versuche habe ich mal eben eine kleine Testreihe mit der Datei "BremsModul.odt" gemacht:

Anzeige: LO 5.3.6.1 -> scharf | LO 5.4.3.1 -> unscharf
Export nach PDF: LO 5.3.6.1 -> scharf | LO 5.4.3.1 -> scharf
Druckvorschau: LO 5.3.6.1 -> scharf | LO 5.4.3.1 -> unscharf
Drucken: LO 5.3.6.1 -> scharf | LO 5.4.3.1 -> unscharf
Drucken nach PDF (via PDF24): LO 5.3.6.1 -> scharf | LO 5.4.3.1 -> unscharf

Das Schöne bei LO 5.3.X ist halt, dass man sich eben keine Gedanken mehr bezüglich der PDF-Quelldatei (Skalierung) machen muss, egal wie man es in WRITER nach-skaliert, kleiner oder größer, es passt in WRITER ohne Schärfeverlust. Es wäre halt schön, wenn diese Eigenschaft in höheren LO-Versionen erhalten bliebe und es wäre in der Handhabung (zumindest in meinen Augen) einfach genial. Vorher hatte ich mich auch mit den anderen Formaten PNG/JPG/... "herumgeplagt" in ähnlicher Weise, wie von Dir beschrieben.

Gruß
Hans-Werner

------ Originalnachricht ------

#15

Hallo JPS,

danke für Deine Testreihe. Zumindest sieht man, das ab LO 5.4.X irgendwie "der Wurm drin ist".

Ich weiß jetzt nicht mehr genau, ab wann bei WRITER die Möglichkeit bestand, als "Bild" auch eine PDF-Datei einzufügen. Ich meine, es war ab LO 5.3.X. Von daher wundert es mich ein wenig, das frühere LO-Versionen mit der Datei zurecht kommen. Aber das muss nicht wirklich etwas bedeuten ...

Gruß
Hans-Werner

------ Originalnachricht ------

#16

Hallo Hans,

das alles liegt wahrscheinlich im Ändern der PDF Rendering Engine in Version 5.4

(siehe auch https://wiki.documentfoundation.org/ReleaseNotes/5.4#Improvements_in_the_PDF_filter )

Verfolgt man die Artikel dort, müsste der Prozess deutlich besser sein als vorher *grins*

VG Thomas

#17

Hallo Thomas,

manchmal überlagern halt in der Programmierung die "ungewollten Nebeneffekte" die "angestrebte Verbesserung", aber bei komplexen Software-Systemen ist Software-Modifikation eben alles andere als trivial, da "lauern an jeder Ecke die kleinen Fehlerteufelchen auf ihren Einsatz" ;-)) ...

Ich bin gerade dabei, den BUG-Report in einigermaßen verständlichem Englisch "zusammenzustöpseln" und dann wird man ja sehen, wie die Reaktion der LO-Entwickler darauf sein wird. Wenn sie das Problem zumindest schon mal reproduzieren können, wäre das ja schon mal was.

Grüße
Hans-Werner

------ Originalnachricht ------

#18

Hallo Hans-Werner,

danke für Deine Testreihe. Zumindest sieht man, das ab LO 5.4.X
irgendwie "der Wurm drin ist".

Ich weiß jetzt nicht mehr genau, ab wann bei WRITER die Möglichkeit
bestand, als "Bild" auch eine PDF-Datei einzufügen. Ich meine, es war ab
LO 5.3.X. Von daher wundert es mich ein wenig, das frühere LO-Versionen
mit der Datei zurecht kommen. Aber das muss nicht wirklich etwas
bedeuten ...

Die importierten *.pdf-Dateien lassen sich bereits ab der Version 4.*
(einwandfrei) lesen. Nur bis zur Version 3.6.7.2 wird das Bild nicht
dargestellt. Das Einfügen als Bild gelingt dann aber erst ab 5.3.* -
warum auch immer.

Gruß

Robert

#19

Hallo Robert,

danke für diese Info, so wäre das auch schon mal abgeklärt. Das wird ja immer besser :-)) ...

Gruß
Hans-Werner

------ Originalnachricht ------

#20

Hallo *,

Die importierten *.pdf-Dateien lassen sich bereits ab der Version 4.*
(einwandfrei) lesen. Nur bis zur Version 3.6.7.2 wird das Bild nicht
dargestellt. Das Einfügen als Bild gelingt dann aber erst ab 5.3.* -
warum auch immer.

Ich habe den Grund dafür: Beim Import wird aus der *.pdf-Datei
zusätzlich eine *.svm-Datei erzeugt. Dadurch ist die
Abwärtskompatibilität bis zur ersten 4.*-Version gesichert. ursprünglich
sollte wohl eine *.png-Datei nebenher erzeugt werden. Beim Entpacken
Deiner Datei ist dann aber eben diese Dateiform sichtbar.

http://vmiklos.hu/blog/lo-insert-pdf-image.html

Gruß

Robert