Einheitliche Vektorformate

Welche Bildformate unterstützt werden, hängt bei Papyrus von der jeweiligen Plattform ab. Das ist auch nicht ungewöhnlich; schließlich macht Mac OS X es sehr einfach mit EPS und PDF umzugehen, wo MS Windows natürlich das eigene Vektorformat WMF unterstützt.

Leider muss ich mich als Papyrus-Nutzer nun entscheiden, ob ich unter Windows mit WMF oder unter Mac OS X mit EPS oder PDF arbeiten will. Nach Formaten ist diese Entscheidung nicht so schwer - EPS und PDF sind deutlich überlegen - aber diese werden dann unter Windows nicht angezeigt. Hier würde ich mir im Idealfall wünschen, dass zumindest EPS als Vektorformat auch unter Windows unterstützt wird. Vielleicht lässt sich dass ja mit Ghostscript erreichen.

Leider musste ich außerdem feststellen, dass unter Mac OS X eingebettete PDF-Files gerastert werden, wenn man aus Papyrus ein PDF exportiert. Das ist natürlich sehr schade, weil so der Vorteil des Vektorformats verlorengeht. Wie schwierig wäre es, die PDF-Bilder so in das PDF-Generat einzubetten, dass sie weiterhin als Vektorgrafik vorliegen?

Viele Grüße,

Jochen

Hallo, oh, ja, mach das mal, setz Dich mit Bill Gates bzw. seinem Nachfolger in Verbindung, daß die das in Windows einbauen. .-)

Das ist z.Zt unmöglich, da Papyrus die Bilder mit dem Werkzeugen des Betriebssystems bearbeitet. und PDF ist kein Bildformat, das ist nur ein Container, in dem wiederum das Bildchen als Bitmap drinliegt.

Grüße…

Scherzkeks! :wink:

Ich denke Du hattest es schon so verstanden, aber ich meinte natürlich, dass sich Ghostscript ja auch in Papyrus einbauen lässt. Oder gibt es da ein Problem, dass ich nicht sehe?

Das so leider nicht ganz richtig. Man kann in ein PDF Bitmap-Bilder einbetten, aber in erster Linie ist PDF (wie Postscript) eine stackbasierte Programmiersprache die u. a. auch Text- und Vektoroperationen beinhaltet. Eine in Vektordaten vorliegende Zeichung kann also mit PDF ohne Rasterung und ohne Verluste kodiert werden. Mac OS X versteht PDF vor allem deshalb so gut, weil die Grafikbibliothek “Quartz” eine API realisiert, die den PDF Grafikoperationen nachempfunden ist. Man kann die PDF-Grafikoperationen unter Mac OS X quasi direkt am Bildschirm darstellen oder umgekehrt die Bildschirmdarstellung relativ einfach in ein PDF kodieren.

Ich habe von einem “PDF-Bild” gesprochen, weil Papyrus unter Mac OS X PDF als “Bildformat” anbietet und in Dokumente einbettet. Das ist erstmal nicht anders als bei z. B. Nisus Writer, Mellel, Pages - im Unterschied zu jenem rastert Papyrus aber eingebettete PDF-Dateien. Dass es nicht unmöglich ist PDF-Dateien “as is” einzubetten beweist hier klar die Konkurrenz: Alle drei oben genannten Programme betten die PDF-Datei ohne vorherige Rasterung ein.

Wenn das einbetten von PDF-Bildern jetzt eine Cross-Plattform-Funktion von Papyrus wäre und deshalb unter Windows und Mac OS X gerastert werden würde, dann würde ich es ja verstehen. Dem ist aber nicht so. PDF-Bilder sind ein Papyrus Mac Feature.

Grüße,

Jochen

PDF-Bilder sind ein von Papyrus genutztes Mac Feature.

Natürlich kann man alle möglichen Sachen einbauen, aber ich halte Pap zugute, daß es eben nicht die DVD-große eierlegende Wollmilchsau ist, sondern einfach die Sachen nutzt, die das Betriebsystem vorhält.

Grüße…

Es ist ein “Papyrus für Mac”-Feature im Gegensatz zu einem “Papyrus für Windows”-Feature. Dabei ist es ein Implementierungsdetail, dass dieses Feature unter Mac OS X besonders einfach zu verwirklichen ist. Wieso können es denn die anderen Mac OS X Schreibprogramme PDFs ungerastert ausgeben? Sind die alle aufgebläht? Ist z. B. Mellel oder Nisus Writer aufgebläht? Wie will man das denn im Einzelfall entscheiden? Bei Open Ofiice ist es für mich klar - es ist schnarchlangsam und gigantisch groß. Bei MS Office merkt man es durch die vollkommen überfrachtete UI.

Das eierlegende Wollmilchsau-Argument zieht für mich in so einem Fall wie hier überhaupt nicht. Es ginge dabei schließlich um eine gewisse konzeptionelle Reinheit, Schlankheit und der Wille Ressourcen zu sparen - um gutes Softwaredesign eben, welches R.O.M. ja auch für sich beansprucht. Wäre Papyrus eine schlecht designte Software (und ich sage nicht und glaube nicht dass es das ist!) dann könnte es sein, dass es aufgrund von früheren Implementierungsentscheidungen praktisch unmöglich ist von einer PDF-Rasterung zu einer Nicht-PDF-Rasterung (beim PDF-Export) zu wechseln. Beispielsweise durch die voreilige Implementierungsannahme, alle Abbildungen wären pixelbasiert. In so einem Fall könnte ich als Kunde nicht gelten lassen, dass Papyrus sonst aufgebläht werden würde - im Gegenteil: In so einem Fall wäre Papyrus schon aufgebläht; es wäre eine Software, bei der man mit Klebstreifen und Kitt einen Vektorbildaufsatz drangepropft hat ohne dass es in das urprüngliche Softwaredesign passte.

Grüße,

Jochen

Hallo,

Ich habe das rein aus Interesse ausprobiert- hoffentlich habe ich da nichts falsch verstanden! Also: Ich suchte mir eine .eps Datei im Internet, hab die gespeichert, öffnen mit Irfanview- Fehlanzeige. Invalid Eps file, try AFPL Ghostscript-plugin… seltsam, Irfanview kann sonst alles.

Nächster Versuch: öffnen mit Paintshop Pro X: funktioniert! Ich habe die Grafik dann von PSP kopiert und sowohl in Softmaker Office als auch in Papyrus eingefügt- das funktioniert ebenfalls.

Allerdings sagt mir der Bildkatalog, dass das jetzt eine .emf Datei ist. Also irgendwo auf dem Weg von PSP zu Papyrus wird daraus ein emf. Softmaker Office zeigt keine Information über das Format an, will aber das Bild als .wmf exportieren. Ich weiß nicht, ob euch das irgendwie weiterhilft, fest steht auf jeden Fall, ich kann sowohl ein .eps in Windows XP anzeigen als auch in Papyrus hineinkopieren.

Alfred

Mich interessiert ja, inwieweit vorgesehen ist, SVG-Dateiformatunterstützung in Papyrus einzubetten.

Bisher exportiere ich die Vektorgrafiken, die ich mit Inkscape erstelle, als wmf/emf-Datei und binde sie in das Papyrusdokument ein.

Geht auch weiterhin so. Ist nur eine Interessensfrage.

viele Grüße

Das ist entweder ein Bug oder eine Unzulänglichkeit des PDF-Exportmoduls.

Wenn Du auf die Vorteile der internen PDF-Ausgabe verzichten kannst (Lesezeichen/Inhaltsverzeichnis, anklickbare Links und Querverweise, Notizen etc.), dann exportiere das Dokument lieber über den Druckdialog. In diesem Fall übernimmt das Betriebssystem die PDF-Erzeugung und es bleiben alle Vektorinformationen erhalten.

Die Rasterung geschieht aber erst beim PDF-Export des Dokuments. Wenn Du das Dokument druckst oder über den Druckdialog als PDF speicherst, bleibt die Vektorinformation erhalten – genauso wie bei Nisus, Mellel und Pages. Die Rasterung ist mit hoher Sicherheit ein Fehler im internen PDF-Export oder eine Unzulänglichkeit desselben.

Chronologisch müsste man also sagen:

GEM-Bilder sind ein von Papyrus genutzes Atari-Feature.

MET-Bilder sind ein von Papyrus genutzes OS/2-Feature.

WMF- und EMF-Bilder sind ein von Papyrus genutzes Windows-Feature.

Von diesen Vektorformaten hat GEM wahrscheinlich am meisten Arbeit gemacht, denn das Atari-TOS hatte keine Funktionen, um Vektorgrafiken mal eben per Systemfunktion anzuzeigen. Die GEM-Vektordateien mussten schön Befehl für Befehl abgearbeitet und interpretiert werden.

In den meisten Fällen ist das ja auch vernünftig, aber im Bereich der Vektorgrafik eben sehr ärgerlich. Bei Bitmapgrafiken hat papyrus ja auch eigene Importfilter, warum also nicht für wenigstens ein brauchbares Vektorformat?

Ich schreibe z.B. hauptsächlich wissenschaftlich-technische Texte mit einem geschätzten Vektorgrafikanteil von 90%. Die Quelle dieser Vektorgrafiken sind meistens Windows-Programme, sodass sie als WMF oder EMF im Dokument landen. Sobald ich ein solches Dokument am Mac öffne, zeigt es nur noch graue Rechtecke anstelle der Bilder. Und da ich täglich mehrmals zwischen den Systemen wechsle, ist dieses Verhalten gelinde gesagt sehr ärgerlich.

Und hast Du mal ordentlich reingezoomt, um zu prüfen, ob das EMF noch eine Vektorgrafik ist? Auch EMF und WMF können nämlich Bitmaps enthalten.

[quote title=glucose schrieb am So, 22 Februar 2009 17:01]

Mir ist der Unterschied zwischen Vektorgrafik und Bitmap bekannt, aber ich arbeite nicht grafisch, das sind für mich nur technische Randnotizen… ich habe das Papyrusdokument mit dem emf in Originalgröße und stark gezoomt hier hochgeladen… ist das jetzt eine Vektorgrafik oder Bitmap? Ich nehme an, dass bei einer berechneten Vektorgrafik die Auflösung immer im Bereich der einzelnen Bildpixel bleiben müßte, also wäre das hier eine Bitmap??

papyrus emf grafik.pap (933 KB)

Ich arbeite auch nicht grafisch und trotzdem ist die Beibehaltung der Vektorinformation für mich wichtig. Zum einen ist die Qualität beim Druck immer bestmöglich und zum anderen bleibt eine technische Grafik nach der Umwandlung in PDF durchsuchbar. Ich kann also z.B. bei Diagrammen nach Achsbeschriftungen suchen oder nach Bezeichnungen in der Legende. Außerdem haben einfache Vektorgrafiken meistens einen geringeren Platzbedarf beim Speichern. Das ist zwar bei heutigen Datenträgergrößen nicht mehr besonders relevant, aber beim Versenden per E-Mail spielt es schon noch eine Rolle, ob ein Dokument wegen enthaltener Grafiken 5 MByte oder 0,5 MByte groß ist.

Ich dachte, du kennst den Unterschied zwischen Vektorgrafik und Bitmap? :wink:

In dem Dokument ist eindeutig eine Bitmap enthalten (verpackt als EMF), wie man leicht an den Pixeltreppen erkennen kann. Wahrscheinlich hättest du beim Einfügen aus der Zwischenablage auch ein anderes Bitmapformat wählen können (über „Inhalte einfügen“).

Hier ist das gleiche Logo (aber in deutsch) mal als richtige Vektorgrafik in das Dokument eingebettet.

papyrus emf vektorgrafik.pap (92.1 KB)

Hmmm… Der Vergleich hinkt, die beiden Bilder sind ganz bestimmt nicht gleich groß. Außerdem, hat die angebliche Vektorgrafik die gleichen Pixeltreppen, vor allem, wenn man sich die in der selben Größe vorstellt!

Zum Vergleich hier im Bild die beiden nebeneinander (Vergleiche den Kreis, B, e…)

Der deutsche Flughafen sieht zugegebenermaßen besser aus! :smiley:

ja, so langsam kämpfen wir uns zum Problem durch. glucoses Beispiel hat eine echte Vektorgrafik drin. Ich weiß nicht, was Du gemacht hast, auf jeden Fall hast Du, wenn Du das Bildchen von glucose importiert hast, es wieder in ein Bitmap gewandelt.

Also fehlt im Handbuch eine Seite: wie importiere ich was, damit es so bleibt wie es war? oder so ähnlich. Und das ist auch das Problem mit den ganzen Formaten, weil viele Formate nur Container sind, in die man alles mögliche reinpacken kann, dazu dann das Betriebssystem, welchens manchmal auch schon in der Zwischenablage wandelt…etc.

Wir müssen uns also irgendein Format raussuchen und zu Ulli sagen: Das soll rein und das soll in allen PapVersionen bearbeitbar sein. Nun die Frage, welches soll es werden? Gibt nämlich gar nicht so viele, die auf allen Betriebsystemen problemlos und ohne Lizenzen laufen. Und was soll dann mit den anderen Formaten werden? Alle konvertieren?

So, wie ich es im Hinterkopf habe, arbeitet Pap intern mit png. Bitmap. Es müsste also wieder ein Vektorkonverter eingebaut werden, der das dann zum Exportieren wieder wandelt.

Ich mach sowas vorher einfach mit einer Bildverarbeitung, und hole dann das Bild als Bitmap so rein, wie es sein soll. Das ist der beste Weg, und auch der einzige der auf allen Systemen klappt.

Grüße…

ja, so langsam kämpfen wir uns zum Problem durch. glucoses Beispiel hat eine echte Vektorgrafik drin. Ich weiß nicht, was Du gemacht hast, auf jeden Fall hast Du, wenn Du das Bildchen von glucose importiert hast, es wieder in ein Bitmap gewandelt.

[/quote]

Was ich gemacht habe? Naja, ganz einfach- Glucose hat ein .pap Dokument hochgeladen! Also einfach mit Papyrus geöffnet, was sonst? Alles andere erledigt Papyrus und mein Windows ganz von alleine, ohne mein Eingreifen…

Die Pixeltreppen bei der Vektrografik sind auf das schlechte Rendering von Windows zurückzuführen. Sie werden allerdings nicht größer, wenn man die Grafik hochskaliert oder die Zoomstufe erhöht – im Gegensatz zu der Bitmap. Hier ein vergleich bei ca. 600% Vergrößerung:

pixel_vektor.png

Tja und da soll dann Ulli aus Berlin helfen :), das gleiche hab ich gemacht, und da ist es eine Vektorgrafik geblieben. Wenn Du die Datei öffnest und die Bildgröße -nicht den Zoom- mal auf 10% und mal auf 400% änderst, sollten immer nur Treppchen mit einem Bildschirmpixel zu sehen sein. Oder wir müssen tief ins System einsteigen: ist bei Dir Cleartype oder Aliasing oder wie das auch immer heist: „Systemschriften glätten“ eingeschaltet?, das könnte auch solche Sachen verhunzen.

Grüße…

Bild 2013-01-27 um 22.05.19.jpg

Beim Import in Papyrus wurde nichts verändert. Die kleinen Treppchen in alfreds Bildschirmfoto sind auf die ganz normale Bildschirmdarstellung von Windows zurückzuführen.

Beim Import als Datei ist das alles relativ klar. Die Zwischenablage ist aber nicht immer vorhersehbar. Hier müsste man einfach empfehlen, immer über “Inhalte einfügen” zu gehen, wenn man sicher sein will, welches Datenformat im Dokument landet.

So ziemlich alle aktuellen Vektorformate können auch Bitmaps enthalten.

PDF und/oder SVG.

Außer bei der Kombination PDF+MacOSX braucht man auf jedem Betriebssystem ein Importmodul, das die Vektordaten auf den Bildschirm/Drucker/PDF-Datei bringen (rendern) kann.

Zum Beispiel. Solange man nur auf einer Plattform arbeitet, kann man ja bei dem nativen Format des Betriebssystems bleiben. Aber für den Datenaustausch wäre ein übergreifendes Format sehr hilfreich. Dafür würde ich dann auch entsprechende Konvertierungen vornehmen.

Zum Teil muss ich auch jetzt schon unter Windows sehr seltsame Wege gehen, um Darstellungsfehler von EMFs und WMFs in Papyrus zu vermeiden. Ich muss z.B. eine ganze Reihe von Programmen benutzen, deren Zwischenablage ich nicht fehlerfrei direkt in Papyrus einsetzen kann, die ich aber über Umwege in Form von Wordpad, MS Word oder Xact (ein Grafik/Diagramm-Zeichenprogramm) doch noch brauchbar “konvertiert” bekomme.

Bei Bitmaps arbeitet Papyrus intern mit PNG. Allerdings heißt das glücklicherweise nicht, dass z.B. ein JPG beim Import in ein PNG gewandelt wird. Für die Vektorgrafik müsste ein Rendermodul in Papyrus eingebaut werden, das die Grafiken in beliebiger Größe zeichnen kann.