Hallo,

ich wundere mich: seit Version 3.4 kann LibreOffice Writer nicht mehr mit importieren EPS umgehen. Statt eines plazierten EPS wird beim Druck oder Export nur ein leerer Rahmen ausgegeben.

Offenbar scheint das außer mir niemand zu stören. Wie sonst kann es sein, dass dieser Bug seit Jahren bestehen bleibt.

Noch seltsamer: in LibreOffice Calc gibt es das Problem nicht. Ebensowenig wie in Openoffice.

Leider kann ich nicht programmieren, sonst hätte ich mitgeholfen.

Ist es so ungewöhnlich EPS in Writer Dokumente einbinden zu wollen?
SVG, JPEG oder PNG führt leider nicht zu brauchbaren Ergebnissen.

Fadenschein

Man sollte bei LO immer den direkten Export wählen, weil es dann strukturierte PDFs gibt. Der Umweg über den Druckdialog gewährleistet dies nicht.

Und womit? Affinity Photo macht aus eps

die svg-Datei


Links die Ecke sieht schon etwas anders aus Wenn das schon bei so eifachen Formen passiert ...

Meine Beispiele wurden mit dem hier von gfhfkgfhfk am 21.02.19 17:59 eingestellten eps-Beispiel gemacht. Ich kann darin kein Preview erkennen und da das erzeugte pdf noch kleiner ist (1.738 Byte) wird doert auch kein Preview drin sein. Die Darstellung an der Oberfläche macht wohl LO selbst.

TDF Bug 64161 - PDF: EPS images don't get exported when writing a PDF file (Status: RESOLVED FIXED)

TDF Bug 67464 - Request for built-in EPS rendering ... (Status: NEW)

TDF Bug 67465 - EPS rendering: locating pstoedit on Mac a problem

TDF Bug 113333 (Images-EPS) - [META] EPS (Encapsulated PostScript) bugs and enhancements (Status: NEW)

LibreOffice: Ask LibreOffice: How to export PDF with EPS image in writer [closed]

Lesens- und beachtenswert, was dort in den Bugs bzw. auf der Ask LibreOffice-Seite steht.
Ebenso auch LibreOffice's Wiki/Hilfeseiten zu EPS und was da zu eingebettetem EPS/Preview/Drucken gesagt wird, habe ich obig bereits genannt.

Der Grund, dass es so geht, dürfte Bug 67464 fixed sein.

Sorry. Fehler. Korrektur:
Streiche: Bug 67464
Setze: Bug 64161

Dieser kühne Schluss bedarf einer Erläuterung! Die Bemerkung von gfhfkgfhfk bezieht sich auf die allgemeine Erstellung von PDFs. EPS-Dateien gehen weder beim Druck noch beim direkten Export in LO. Da ist nichts RESOLVED FIXED.
Wenigstens kann das gerne gescholtene OpenOffice mit EPS-Dateien umgehen

Siehe zuvor Gesagtes und grad' nochmal Wiederholtes. 64161 ist RESOLVED FIXED. Bug 67464 und der Mac-Spezifische Bug 67465 sind beide auf NEW und noch nicht resolved fixed.

Können beide. Nur kann LibreOffice auf dem Mac es offenbar nur eingeschränkt. Warum? Weil ein sog. "Regression-Bug" vorliegt. Was ist das? Ein sog. Regression-Bug ist ein Bug, der mal zuvor gefixt war bzw. zuvor ging es, und durch irgendeine Änderung aus Versehen wieder aufgerissen worden ist, und seitdem geht's nicht mehr. Steht alles in den Bugs und deren Diskussion drin.

OpenOffice ist zudem auch nicht ohne Bugs bei EPS (ist der Bug-Liste ebenfalls zu entnehmen, welcher da offen ist bzw. welchen man da geerbt hat). Nur mit dem Unterschied, dass OpenOffice ein total altes und totes Pferd ist ("Wenn Du merkst, dass Du ein totes Pferd reitest, dann steig' ab!") und Du davon ausgehen kannst, dass das Ding erst recht nicht mehr gefixt wird, zudem ist es eine einzige wandelnde Fehler-Burg nebst offenen Sicherheits-Bugs, wo kein Entwickler da ist, der das wohl je fixen wird. Die Entwicklung findet bei LibreOffice statt, nicht bei OpenOffice (weder gibt es da noch eine Projektleitung, die hat vor einiger zeit das Handtuch geschmissen, noch überhaupt nennenswert Entwickler, die da noch irgendeinen Handschlag tun). Bei LibreOffice haste wenigstens die Chance, dass es gefixt wird, bei OpenOffice bzgl. seiner Fehler und meilenweiten Rückstände nicht. Zudem ist die gesamte PDF-Verarbeitung bei LibreOffice seit der 5.4-Version auf neue, bessere Füße gestellt worden (LibreOffice nutzt seitdem Google Chromiums PDFium , siehe dazu auch die betreffenden Blog-Einträge des Entwicklers , , ), – bei OpenOffice nicht (wird wohl auch nie). Auch SVG-Support ist massiv verbessert worden in LibreOffice. EPS wird etwas stiefmütterlich betrachtet, weil einerseits das Hauptaugenmerk auf SVG liegt, massiv verbessert und ausgebaut worden ist und weiterhin werden wird, EPS andererseits weniger gebraucht wird.

Trotzdem gibt es maßgebliche Entwickler bei LibreOffice, darunter Hauptentwickler Michael Meeks (eher der Linux-Plattform zugehörig bzw. der Firma Collabora , welche LibreOffce vor allem für Firmen ergänzt und vermarktet), die das massiv ärgert, dass EPS nicht völlig rund läuft und sich da sogar ein Regression die Mac-Plattform betreffend eingeschlichen hat, es gibt offenbar sogar einen Patch, mindestens einen Workaround, mit dem es funktioniert (steht alles in den Bugs bzw. ist der obig verlinkten Ask LibreOffice-Seite zu entnehmen), und auch Fadenschein weiß das seit 3 Tagen.

Ich habe den Mac-spezifischen Bug TDF Bug 67465 - EPS rendering: locating pstoedit on Mac a problem vor 3 Tagen auf die Liste der Mac-spezifischen Bugs unter

TDF Bug 42082 (MacOS-Wishlist) - [META] Make LibreOffice shine and glow on OS X

als Blocker gesetzt. Damit er darüber nicht aus den Augen verloren geht und somit erneute Aufmerksamkeit bekommt bei den Entwicklern, auf dass sich jemand mit Mac-Programmierkenntnissen dort erbarmt und Zeit findet (es gibt dort leider zu wenig Entwickler mit Mac-Programmierkenntnissen und Lust und Zeit, die meisten Entwickler dort kommen aus dem Linux- und Windows-Lager – wenn ein/zwei/drei Leute von euch also coden können und Lust haben und sich irgendwie nutzbringend einbringen können, damit es dort Mac-betreffend schneller vorangeht, dann beteiligt euch dort bitte und bringt euch ein!), das endlich mal zu fixen bzw. einen Patch upstream zu committen.

Fadenschein weiß das alles, kennt die genannten Bugs, kennt die Links nebst den dort aufgezeigten Ursachen und Workaround, mit ihm habe ich vor 3 Tagen bereits ausführlich mehrfach darüber korrespondiert.
Habe mich deshalb absichtlich bisher hier nicht zu Wort gemeldet und zurückgehalten.

Darauf bezog ich mich nicht, denn generell ist es sinnvoller den internen PDF Export zu wählen, weil so die Dokumentenstrukturen erzeugt werden können. LO erzeugt Inhaltsverzeichnisse im PDF, Links, etc. aber das funktioniert nur dann zuverlässig, wenn die Software das direkt macht. Es ist zwar möglich in die PS-Ausgabe des Programms spezielle Steuercodes zu integrieren, so dass der Drucker-Treiber bei einem PDF-Export in der Lage sein kann, das auch zu gewährleisten. Der PS-Code \special kann eingefügt werden (keine Ahnung ob das LO so macht, ich kenne es von LaTeX so) und enthält die notwendigen Informationen.

Apropso EPSF, PDF und SVG sind nicht gleichwertig für Grafiken. Ein EPSF kann echten Programmcode enthalten und nicht nur beschreibende Inhalte wie ein PDF oder SVG. Das wurde in der Vergangenheit fast nie genutzt. Mir sind nur spezielle Fonts (Type 3) bekannt die diese Eigenschaft ausnutzen, z.B. um eine Änderung der Glyphs im Text zu ermöglichen. D.h. nicht alle Glyphs eines Buchstaben sehen gleich aus.

Es gibt sicher viele Anwendungsfälle, aber ich hab' die letzten 8 Jahre keine strukturierten PDFs gebraucht.
Insofern wäre es mir lieber, LO könnte auch mit der PDF-Erzeugung per Druckdialog plazierte PDFs korrekt ausgeben...

Mein Thread-Fazit ist jedenfalls:
- Der von Sierk erwähnte EPS Workaround ist mir zu speziell.
- Die SVG Alternative hat für mich den Nachteil, dass die Qualität des SVG nach meiner Beobachtung sehr stark vom Wohl und Wehe des erzeugenden Programms abhängt.
- Ich verwende daher zukünftig plazierte PDFs statt EPSs und wechsele von OO zu LO.
- Ich hoffe, dass in LO irgendwann zukünftig sowohl das EPS Handling wieder hinreichend funktioniert, als auch die PDF Erzeugung über den Druckdialog.

Vor allem aber:
Ich danke allen und insbesondere Sierk für die große Unterstützung und die interessanten Beiträge.

EPSF ist ein aussterbendes Format, und man sollte generell PDFs verwenden. Ein Beispiel früher hatte man in LaTeX (meint das TeX Programm mit dem LaTeX Makropaket) immer EPSF importiert, um Vektorgrafiken benutzen zu können. Das neuere pdfLaTeX (meint pdfTeX mit LaTeX Makropaket) akzeptiert nur noch PDFs. Es gibt für die Kommandozeile Werkzeuge mit denen man problemlos ein EPSF in ein PDF umwandeln kann. Ausnahme sind die raren EPSFs mit Programmcode. Du wirst also Deinen Workflow auf aktuellere Datenformate umstellen müssen.

Woran macht man eigentlich fest, dass ein Format aussterbend ist? LaTeX ist sicher kein Maßstab. Ich habe auf meinem Rechner diverse EPS-Dateien, die im letzten Jahr erstellt wurden und die ich so bekommen habe. Aussterbend?
Der Vorteil von PDF ist für mich, dass es einfach mit Vorschau aus EPS erzeugt werden kann und dann brauchbar nutzbar im derzeitigen LO ist.

Danke für diesen Thread und dieses Fazit. So sehe ich es auch und so werde ich es auch handhaben, wenn ich denn mal an EPS in LO vorbei komme.

U.a. auch

Wikipedia (de): Encapsulated PostScript

sagt:

Auch

Ask-LibreOffice-Thread (der mit dem von Fadenschein als für ihn nicht gangbare Weg des Workaround-Vorschlags betreffend der Installation des wohl zum Funktionieren benötigten ps2edit via MacPorts oder Homebrew) bzw. diese erste Antwort sagt bereits 2013:

Auch Apple hat sich mit MacOS X schon lange wegbewegt bzgl. PostScript und hin zu PDF, für die Bildschirmausgabe weg von NeXTSteps Display PostScript hin zu Quartz bzw. Quartz 2D auf Basis von PDF statt PostScript. Und hat Jahre später dann auch sein bis dahin unter der Haube standardmäßig PostScript verarbeitendes Drucksystem CUPS (welches von der ganzen restlichen Unix-/Linux-Welt ja ebenfalls verwendet wird und die dieser Entwicklung dann zwangsweise gefolgt ist) nachgezogen und intern umgestellt weg von PostScript und hin zu PDF:

GitHub: Apple: Adding CUPS filters for using PDF as standard print job format #2897 :



Aber ein korrektes Beispiel (er sagt ja selber: "Ein Beispiel…") von vielen.

[OT]

Ich möchte hier an dieser Stelle hiermit gerne die Gelegenheit nutzen (ich könnte dafür auch einen eigenen Thread im MTN-Entwickler-Forum aufmachen, wäre vielleicht sinnvoller, vielleicht tue ich das sogar noch, aber ich denke, dieser kurze Spot reicht evtl. auch schon), um das hier nochmal kurz in den Vordergrund zu rücken und dafür zu werben:

Auch wenn der eine oder andere Bug bzw. die Mac-Plattform betreffende Bug bzw. Regression-Bug so wie der hier in Rede Stehende den einen oder anderen drückt und schmerzt: man kann es beheben – es braucht nur jemanden, eine menschliche Person, einen Entwickler, der es konkret kann und macht bzw. umsetzt, einen, der das Können, die Zeit und die Lust dazu hat.

Habe ja obig bereits was gesagt: wer mithelfen will und kann, dass es schnell/schneller/bald behoben wird, erst recht auf der ihm ans Herz gewachsenen Mac-Plattform, der sei ermuntert, sich da einzubringen und mitzuhelfen, es gibt dort einfach zu wenige Mac-Entwickler (die Masse sind eher interessierte Linux- bzw. Windows-Entwickler, interessierte Mac-Entwickler sind dort leider in der Minderzahl und unterrepräsentiert). Warum eigentlich? Das muss doch nicht so bleiben, es gibt doch viele Mac-Entwickler (auch hier in der MTN-Community gibt es ja den Einen oder Anderen). Wo sind die? Warum interessieren sich so wenige von denen für so ein gutes Projekt? Es wäre doch in ihrem eigenen Sinne, dass die Mac-Plattform auch dort gut repräsentiert ist und Mac-entwicklerseitig reges Interesse und reger Zuspruch dafür da ist.

Jede zusätzliche Mac-Kraft, am Besten mit entspr. Programmierkenntnissen und macOS-Know-How ausgestattet, die sich da positiv einbringt, hilft, hilft der Beschleunigung und Verbesserung, hilft, dass LibreOffice auf dem Mac weniger stiefmütterlich dasteht, weil zu wenige Mac-Entwickler da sind, die sich dafür interessieren und darum kümmern können und auch wollen.

Siehe dazu auch entspr. Kommentar #6 im LO-Bug Bug 42082 (MacOS-Wishlist) - [META] Make LibreOffice shine and glow on OS X ):

Gibt es hier in der MTN-Community den Einen oder Anderen, der sich da diesbzgl. einbringen könnte, um mitzuhelfen?

gfhfkgfhfk:

Was ist mit Dir zum Beispiel? Könntest Du? Würdest Du? Hättest Bock?
[/OT]

sierkb
Deine Anmerkungen vom 24.02.19, 03:32 hatte ich so (auch in dem Umfang) erwartet, aber sie helfen doch nicht wirklich weiter. Der von dir erwähnte Mac-spezifische Bug "TDF Bug 67465 - EPS rendering: locating pstoedit on Mac a problem" stammt von 2013, der letzte inhaltliche Eintrag von 2016. Das Thema scheint beerdigt zu sein.
Der von dir erwähnte EPS Workaround ist auch mir zu speziell. Ich habe hier mit macports u.ä. bisher nichts gemacht.
Selbst der Weg über PDF ist ja in LO nicht ohne: nur der direkte Export als PDF erzeugt wirklich scharfe Bilder, der direkte Druck (oder Druck als PDF) hat Kantenunschärfen (jedenfalls bei mir), also ein Umweg.

Es ist bekannt, dass in LO nur wenige Entwickler im Mac-Bereich tätig sind. Dann muss man vielleicht irgendwann einen Strich ziehen und festlegen, was man unterstützt und was nicht. Ewig lang offene Bugreports helfen nicht. Aber das angebotene sollte schon ordentlich sein.

Übrigens setze ich natürlich LibreOffice ein und nicht AOO (das mit Vektor-PDF nichts anfangen kann), kann mir das Sticheln aber manchmal nicht verkneifen. EPS bzw Vektor-PDF in Text-Dokumenten habe ich viel zu selten. Da stören mich diese Unzulänglichkeiten nicht. Wichtiger für mich ist das Vertrauen in die OO-Datenformate. Sie werden auch in vielen Jahren noch lesbar sein (im Gegensatz zu Apple-Formaten).

Soweit ich mich erinnere (und ich bin schon seit System 6.0.8 dabei), ist die Entscheidung für PDF in OSX gefallen, weil PS lizenzbehaftet war und PDF nicht.

Eine Prognose, welche Dateiformate obsolet werden, bleibt eine Prognose. Da ist sehr viel Kaffeesatzlesen dabei. Und welches Format wie lange lebt, wird sicher nicht von den 8% Mac/Unix-Anwendern entschieden, sondern eher im Bereich der 92% Rest.
Ich habe ja nur festgestellt, das ich diverse EPS-Dateien auf meinem Rechner habe, die in 2018 erstellt wurden.

Siehe dazu auch:

TDF Bug 34836 - PDF export does not export EPS images (Status: RESOLVED INVALID)
Q:

Insbesondere
Comment #17 ,
Comment #19 ,
Comment #26 ,
Comment #30 ,
Comment #40 ,
Comment #43 ,
Comment #44 ,
Comment #48 ,
Comment #49

Es ist halt insgesamt ein recht komplexes, schwieriges Thema, und der Bug ist komplex und schwierig an der Wurzel zu packen ohne negative Seiteneffekte, siehe Comment #44 von Michael Meeks.

[OT]

Warum ist das so? Warum interessieren sich so wenig Mac-Entwickler für sowas?
Muss doch nicht sein. Und schon gar nicht so bleiben.
Q:

Prinzip Hoffnung halt. Die Hoffnung stirbt halt zuletzt. Oder auch negativ gesprochen: die Mac-Community bekommt halt, was sie sich verdient. Wenn sich halt aus ihrem Kreise niemand dafür interessiert, niemand bereit ist mitzumachen bzw. zu wenige, dann kränkelt es halt für ihre Lieblingsplattform und hinkt den anderen Plattformen hinterher. Man kann nicht immer erwarten, dass andere für einen die Kohlen aus dem Feuer holen und sich dann an den gedeckten Tisch setzen und sich dann erwartungsvoll beschweren, dass es nicht so läuft, wie man es gerne hätte. Zumal die Firmen, die da involviert sind und sich da mit Geld und eigenen bezahlten Entwicklern einbringen, auch eher die Windows- und Linux-Plattform als primäre Kunden- und Ziel-Plattformen im Auge haben. Und wo sind da die mitmachenden Firmen aus dem Apple- und Mac-Umfeld? Glänzen mit Abwesenheit und Desinteresse. Warum? Und Spenden? Vielleicht mal zielgerichtete Spenden, um mehr Mac-Entwickler zu locken und zu gewinnen.

Dank Michael Meeks' , Firma Collabora existiert LibreOffice als LibreOffice Vanilla für 9,99€ und Collabora Office für 32,99€ wenigstens im Mac AppStore bzw. mit Collabora Online als Cloud-Lösung, darüber kommt also u.a. Geld rein. Aber offenbar interessiert sich die Mac-Community insgesamt so wenig für LibreOffice auf dem Mac, dass seine Firma keinen erhöhten Bedarf sieht, mehr Mac-Entwickler einzustellen, vermute ich. Zumal Collabora historisch bedingt eher Linux-affin ist: Michael Meeks (Ex-GNOME, Ex-Ximian, Ex-Suse) nebst Ex-LibreOffice-Entwickler-Team von Suse Linux.
Schaut man sich an, welche Firmen im Advisory Board von The Document Foundation (die Foundation, die das LibreOffice-Projekt betreut) sitzen und Sponsoren sind und sich da auch teilweise mit eigenen Entwicklern einbringen

The Document Foundation: Advisory Board: Composition of the Advisory Board

so wird auch da deutlich: wo sind da Firmen, deren Hauptinteresse und Stammklientel Macs, Mac-Anwender sind? Außer Google sehe ich da leider niemanden, der da überhaupt infrage käme, und auch bei Google liegt die Priorität bzgl. der Interessenlage und Klientel sicher so: Linux, Windows, und dann erst: Mac.
Und die freie Mac-Community mit ihren zahllosen freien Mac-Entwicklern? Hält sich zurück – warum? Siehe oben bereits Angesprochenes.

Sehr löblich.

Solange es produktiv ist und nicht destruktiv, ist es ja in Ordung. Mir gefällt auch Einiges nicht. Aber ich meckere nicht nur, sondern versuche mich, so gut ich kann und mir möglich ist, einzubringen, auf dass es besser werde.
So ist u.a. auch Bug #42082 entstanden. Und er hat sich, ohne, dass ich es vorhatte und ahnte, über die Zeit zum Meta-Bug entwickelt bzw. wurde dazu auserkoren.

So wird es vielen gehen. Deshalb wohl auch die seit einiger Zeit wenige bzw. null Aktivität in den obig genannten Bugs.

Zustimmung.
[/OT]

So habe ich es auch in Erinnerung.

Eben. Und wenn Du Dir die Historie von EPS mal vornimmst, dann ist EPS offenbar nie bei genau diesem von Dir geschätzten 92%-Rest bzw. der Mehrheit angekommen und war/ist wohl stets und bis zum heutigen Tag mit weiter abnehmender Tendenz ein Ding dieser von Dir geschätzten 8%-Minderheit, u.a. auch, weil es offenbar im Handling nicht ganz unproblematisch war/ist:

Wikipedia (en): Encapsulated PostScript


Evtl. gehörst Du damit dann bzw. der, von dem sie sind, noch zu genau jener von Dir gemeinten 8%-Minderheit?

Das Format wird nicht mehr gepflegt, zu dem passt es nicht zum PDF Workflow, den Adobe mittlerweile fest etabliert hat. Denn EPSF erlaubt es Programme zu enthalten, das ist bei PDF nicht möglich.

Siehe zum Thema "EPS ist ein sterbendes Format" bestätigend u.a. auch:

Techspired (18.12.2018): Things You Need to Know About the EPS File Format , Absatz Disadvantages, letzter Satz.

Ebenso dazu u.a. auch

publisher.ch: Vor- und Nachteile der Bildformate
Unsere Lieblings-Website zu InDesign, indesignsecrets.com , hat sich vor Kurzem zu den einzelnen Bildformaten geäussert und gibt Empfehlungen ab, wann man als Layouter welches Format am besten verwendet. :

Q:

etc.

Zu dieser Seite fällt mir nur ein, dass EPSF noch nie mehrseitige Dokumente unterstützt hat. Ein EPSF enthält eine BoundingBox und die PS-Befehl für eine neue Seite ist ausdrücklich verboten. Dazu gab es in der Vergangenheit mit den Previews in EPSFs immer Probleme, weil die meisten Programme nur die Plattform eigenen Formate unterstützen. D.h. Mac Programme nur PICT, PC Programme nur TIFFs und die wenigsten EPSI, obwohl eigentlich jedes Programm alle Formate hätte unterstützen sollen.

Zum Abschied muss ich schon nochmal eine Lanze für EPS brechen:

10 Herrliche Jahre lang hatten wir unsere Wortmarke und unser Adressfeld als EPS unverändert und unveränderbar in unserer odt-Briefvorlage plaziert und es hat in OO bis heute hervorragend funktioniert.

Aber ich räume ein... wahrscheinlich sind es nicht einmal besagte 8%

Hallo.

Ich befürchte, die zehn Jahre wären mit der Wortmarke und dem Adressfeld als PDF nicht weniger herrlich gewesen ...
Ich sehe keinen einzigen Vorteil von EPS.

Das war am Ende ja eine erstaunlich einfache Lösung des Problems.

Gruß Wolfgang

Na ja, - ein bisschen weniger herrlich ist es mit PDF und LO ja schon. Denn zumindest kann ich nicht direkt drucken und auch kein PDF per Druckdialog erzeugen, sondern muss immer den Weg über PDF Export gehen.
Angesichts der sonstigen Vorteile von LO zu OO ist das aber in Ordnung.

Oben wurde schon mal SVG vorgeschlagen. Umwandeln EPS in SVG kann z.B. die Affinity-Software, es gibt aber auch Online-Konverter (Google hilft).
Ich habe das gerade noch einmal getestet: sowohl in der Oberfläche als auch im Druck keinerlei Kantenunschärfe. Damit würdest du das direkte Exportieren in PDF sparen und könntest direkt drucken.

Inkscape wäre eine weitere freie Software, die das hinbekommt.

Da es hier ausschließlich um ein EPS-Problem mit LO geht, fände ich es nett, den Threadtitel entsprechend anzupassen.

Stimmt, aber ohne ghostscript kann es kein EPS importieren und soweit ich weiss, benötigt Inkscape X11. Das würde ich mir nicht antun.

GhostScript als PostScript-Prozessor.
Es ist obig, unter den LO-Bugs und Workarounds zudem ja auch pstoedit genannt worden. Oder ImageMagick. Um EPS zu wandeln. LO prüft deren Vorhandensein und greift drauf zurück, wenn es sie im Path findet. Unter macOS findet es sie aber nicht. Deshalb greift der Versuch ins Leere. Deshalb wird's nicht gewandelt. Deshalb wird's nicht angezegt. Der Workaround wäre, es zu installieren, wenigstens pstoedit zu installieren (z.B. via MacPorts oder Homebrew oedr per Tarball) und in $PATh aufzunehmen. Damit LO es finden und nutzen und das EPS endlich wandeln kann. Wollt ihr aber ja nicht, den Weg wollt ihr ja nicht gehen, das sei euch zu kompliziert (ist es eigentlich nicht), habt ihr obig gemeint. Das wäre aber der Weg raus aus der Misere und erstmal die Lösung. Bis LO es nativ kann und auch auf dem Mac kein pstoedit mehr benötigt und anfragt. Wenn man unbedingt an EPS festhaten will statt stattdessen das anempohlene SVG zu verwenden.

Es gibt auch eine inoffizielle/halboffizielle/leicht veraltet offizielle Non-X11-Version von Inkscape für den Mac (gtk2-quartz-basiert statt gtk2-X11), welche nativ läuft und kein X11 braucht.

Stimmt. Soviel auch zum Thema: passenden Thread-Titel wählen

Und du meinst wirklich, für eine Wortmarke lohnt sich der Aufwand?

Und dann empfehle ich dir, mal nach "eps clipart" in Google zu suchen. Du wirst dich wundern, wieviele (auch aktuelle) Fundstellen für dieses "sterbende" Format auftauchen

Danke bmonno, das werde ich sicher auch nochmal testen. Ich hatte bislang bei Versuchen festgestellt, dass sich SVGs immer leicht vom Original unterscheiden. Art und Maß der Unterschiede hängen vom erzeugenden Programm ab. Das Format EPS war diesbezüglich konsistenter.

Das entscheidest Du für Dich selber. Du siehst ja, wie die LO-Entwickler, die da bislang dran waren, bisher entschieden haben und was Michael Meeks dazu gesagt hat in Bezug auf Aufwand, das zu fixen. Die Bugs sind also nicht ohne Grund noch offen, Aufwand bzw. das Verhältnis von Aufwand und Nutzen spielen bei aller Ärgerlichkeit dort dann wohl durchaus eine Rolle in der Bewertung, wenn man zugrunde legt, dass auch dort die Leute wissen, welchen Stellenwert und welche Verbreitung EPS im tatsächlichen Gebrauch heute noch hat (auch dort ist man sich klar über die von Dir besagten 8% versus 92%).

Das Internet ist groß. Da findet man viel – viel Sinniges, viel Unsinniges – und im Zweifel alles, es ist wie ein großer, großer Ozean bzw. ein großes, großes Gefäß, da ist alles drin. Das ist also kein Kriterium.
Bzgl. des sterbenden Formats habe nicht ich diese Einschätzung und Bewertung ins Leben gerufen, das haben andere, ich habe sie hier nur widergegeben und bin damit noch nicht mal der Erste gewesen, der es auf den Tisch des Hauses gelegt hat – der Erste, der es in dieser Diskussion auf den Tisch des Hauses gelegt hat, ist meines Wissens gfhfkgfhfk gewesen, ich habe, um es entweder zu widerlegen oder zu bestätigen, nur andere Stimmen genannt, die ihm mit der Aussage rechtgeben (und ich habe auf die Schnelle zumindest keine Stimme gefunden, die ihm da widersprochen hat sondern sofort nur Stimmen gefunden, die die gleichen, nein, dieselben Worte gefunden haben wie er und ihm da rechtgeben). Und die 8% versus 92% hast Du selber obig auf den Tisch des Hauses gelegt.
Nimm einfach die traurige Wahrheit an, das es halt so ist – so schmerzvoll die Erkenntnis für Dich und fadenschein auch sein mag und dass Dein Satz

in Bezug auf EPS halt mindestens stimmt und hier bei allem in Rede stehenden, grad' auch in Bezug aufs Bugfixing und das Verhältnis von Aufwand versus Nutzen, zugrundegelegt werden kann.

Ich hatte noch einige EPS-Files mit Affinity Designer probiert und bei visueller Prüfung auch bei komplexeren EPS-Dateien keine Abweichungen gesehen. Das mag natürlich im Druck anders sein.
Die von mir weiter oben festgestellte Abweichung im Beispiel-EPS aus dem Thread scheint ein Bug in Affinity zu sein. Bei mehreren Online-Konvertierungen gab es die Abweichung nicht.
Es kommt natürlich auf die Zahl und Komplexität deiner EPS-Files an, ob sich das ganze lohnt. Die Konvertierung in PDF ist einfacher, dafür die Arbeit damit mit einem Zwischenschritt belastet.

Eins noch: in einem Natur-Windows-10 sieht das ganze noch viel erbärmlicher aus, habe ich zwischendurch auch angetestet, aber schnell abgebrochen

Wie stellt ihr euch das "sterben" des EPS-Formates denn vor?
Denkt ihr ernsthaft, wenn ein Dateiformat gestorben ist, es dann auch zeitnah aus dem [www] verschwindet? Leider nein... Ihr werdet immer EPS-Dateien o.ä. ausgestorbene bzw. aussterbende Dateiformate zu hauf im Netz finden. Und das auch noch nach Jahrzehnten.

Auch das 2018/19... noch EPS-Dateien erstellt werden (können) heißt dies nicht, dass man es tun sollte...
Da ist meistens nur die Unwissenheit der User und der alternativ-Formate schuld...

@fadenschein
Interessant wäre noch zu wissen wer euere Wortmarke damals als EPS erstellt hat?
Hättet ihr gewusst das EPS-Dateien sowohl Pixel- als auch Vektordaten enthalten können, wärt ihr damals vielleicht schon auf das SVG-Format gewechselt und diese Problematik wäre nie entstanden...

Wenn ab jetzt aber mit einer SVG-Datei gearbeitet wird, muss diese doch nur EINMAL auf die Position und Größe der vorher platzierten EPS-Datei (Wortmarke) angepasst werden und dann hast du ruhe, oder?
Denke das ist etwas weniger aufwand als alle Entwickler auf LO - Mac-basis reaktivieren zu wollen um die funktion wieder oder überhaupt zu re/aktivieren.

Vielleicht sollten die Anhänger des "sterbenden" EPS mal eine Seite von Adobe aufrufen:

Da findet man Vektorgrafiken, pro Stück 63,99€. Alle Grafiken, die ich geprüft habe (und das waren einige), werden im Format AI/EPS angeboten, keine in SVG/PDF. Wahrscheinlich gilt für Adobe auch
iFreak777: Soweit ich das in Erinnerung habe, enthält das EPS von fadenschein nur Verktordaten.

Ja, das ist mir bewusst. Habe gegenteiliges so auch nicht kommuniziert. Nur würde ich für "meine" Wortmarke ein Format wählen das ausschließlich Vektordaten kann...

zu deinem Link: Nur weil bei Dateityp: AI/EPS steht, heist das noch lange nicht das du auch ein EPS bekommst beim kauf... Das ist wohl eher den frühen Vektorbildern geschuldet, dass dort noch EPS steht.

Das EPS habe ich selbst erstellt und zwar so, dass es ausschließlich Vektordaten enthält.
Bei meinen bisherigen SVG Tests war es so, dass Rundungen der Vektoren und Abstände teilweise vom Original abgewichen sind. Zugegeben - nur wenn man sich recht nah herangezoomt hat. Da das beim EPS nicht der Fall war, hatte ich EPS bevorzugt.
Aber wie erwähnt werde ich jetzt SVG nochmals einer genaueren Untersuchung unterziehen, weil meine letzten Tests schon wieder 3 Jahre her sind.

Nochmal zur klarstellung:
Ich habe von anfang an gewusst, dass DEIN (fadenschein) EPS ausschließlich Vekordaten enthält.
Nur wenn ich eine Wortmarke erstelle und beim Export bin und ich mir überlege weches Format ich wähle, würde ich pers. kein Format wählen das beides (Pixel & Vektoren) kann, sondern halt ein .ai oder .svg o.ä..

Dumme Frage: kann SVG 4c und Sonderfarben?
Wenn nicht, ist das bereits vor der Geburt gestorben und man muß auf PDF ausweichen.
Wenn doch, kann man es zumindest versuchen ob es einem hilft wenn man mit anderen Formaten Probleme hat. Os kommt halt immer drauf an, in welcher Umgebung und für welchen Zweck man arbeitet. Einfach zu behaupten, ein Dateiformat sei gestorben hilft leider niemanden der genau damit ein Problem hat

Wie kommst du denn da drauf? Du kannst ja mal eins kaufen. Wenn Adobe PDF u.ä. auch anbieten würden, würden sie das schon aus Marketinggründen in der Übersicht anzeigen (wie andere). Mir scheint, Adobe kümmert sich weniger um Wikipedia als um die Wünsche ihrer Kunden

Mit 4c meinst Du was genau? Mit Sonderfarben meinst Du was genau?

Wo habe ich geschrieben das man ein PDF u.ä. bekommt beim kauf? Das hast du jetzt so dazugedichtet...
Ich wollte lediglich damit sagen das du zum größten teil .ai-Dateien bekommen wirst wie auch an erster Stelle angegeben...

Ich hatte damals das Format gewählt, das meinen Inhalt unverfälscht am besten darstellt. Außerdem konnte damals auch LO plazierte EPS problemlos verarbeiten. Warum sollte es ein Gegenargument sein, dass das Format außer den von mir benötigten Vektoren auch Pixel kann? Viel stärker wiegt doch, ob das gewählte Format den Inhalt korrekt darstellen und in der Weiterverarbeitung problemlos ist (was damals für EPS in beiden Punkten der Fall war und sowohl bei SVG als auch bei PDF nicht zutraf).

Stimmt, das mit PDF hast du nicht geschrieben. Habe ich falsch interpretiert
Aber, wenn in einem Shop steht AI/EPS, dann bekommst du immer mindestens die Wahl zwischen den Formaten, meistens beide. Ansonsten würde dort nur AI stehen, wenn man nur AI bekommen kann. Sonst würde man grob gegen alle Vorschriften, selbst in den USA verstoßen.

So, jetzt hab' ich mal wieder getestet.
Die Empfehlung war ja, statt EPS das Format SVG in Libreoffice zu verwenden.

Ich habe also meine Wortmarke in Affinity Designer erstellt und als SVG exportiert.

Sehr schade:
Libreoffice skaliert das SVG beim Import völlig willkürlich.
Die ursprünglich 11 pt hohe Wortmarke ist fast seitenfüllend in Libreoffice.
Trotzdem behauptet Libreoffice unter 'Eigenschaften' des SVG, dass die Skalierung bei 100% läge.

Hat jemand einen Tipps, was da schief gelaufen sein könnte?
Kann jemand ein SVG in Libreoffice so importieren, dass die ursprüngliche Größe erhalten bleibt?

Danke für Tipps
Fadenschein

Hier nochmals der Test in Bildern.
Das mit dem SVG und LibreOffice ist einfach Schrott.

So sieht das ganze in LibreOffice aus.
Die ursprünglich 12 pt große Wortmarke wird beim Import viel zu groß skaliert.


Wenn ich das dann als PDF ausgebe, sieht es von weitem noch gut aus (abgesehen von der falschen Skalierung):


Sobald man näher heranzoomt, sieht man, dass das SVG Format bei weitem nicht so gut ist, wie das gute alte EPS. Dort wären die in Pfade umgewandelten Buchstaben nicht mit Ecken (polygonal):

Schön, dass es dich immer noch beschäftigt
Ich konnte es nicht glauben, kann es jetzt aber nur bestätigen.
Allerdings scheint es nicht am SVG-Format zu liegen, sondern eher am MacOS (derzeit bei mir HighSierra).
Ich habe Text "Times" in Affinitiy Designer eingegeben (12 P), in Pfad umgewandelt und sowohl als EPS als auch als SVG exportiert. Das SVG hatte das von dir erwähnte polygonale Aussehen, das EPS nicht. Dann habe ich mit einem Online-Konverter (https://convertio.co/de/eps-svg/) das EPS in SVG gewandelt. Das SVG war ebenso hübsch wie das EPS (nichts mit polygonal). Wenn man das dann einfügt in LibreOffice (Größe war richtig) und als PDF druckt, hat man wieder ... das polygonale Aussehen.
SVG taugt anscheinend also auch nichts unter MacOS. Schade.

Nach meiner Beobachtung liegt es nicht an MacOS.
Hier habe ich Text als Pfad in einem .svg aus Affinity Designer exportiert und danach in Affinity Designer importiert.
Die Pfade sehen unverändert wie die Textvorlage aus:

Das gleiche .svg habe ich in LibreOffice importiert und per 'PDF exportieren' als PDF ausgegeben.
Man sieht deutlich, dass das 'X' deformiert ist und die beiden '4' unterschiedlich aussehen:

Zum Vergleich habe ich den gleichen Text als .eps exportiert und in das alte vielgescholtene OpenOffice importiert.
Das habe ich dann als PDF ausgegeben (per Druckdialog) und siehe da - tadellos: