vielen Dank für die ausführliche Antwort!! Ja, ich hatte mit überlegt, ein Cropping in LOSA einzubauen, aber es ist, wie Du's sagst: Egal wie man vorgeht, es werden immer 2 Ghostscript oder Inkscape-Aufrufe benötigt. Es gibt ja sogar die Möglichkeit, Inkscape mit --verb Befehlen zu steuern. Crop eines SVG ginge dann so:
Aber das ruft Inkscape mit GUI auf, arbeitet und schließt sich und wenn man es mit einer PDF lät, dann kommt man nicht um manuelle Dialoge rum. Aber könnte vielleicht für bestimmte SVG Operationen nützlich sein. Muss mal nach einer --verb liste schauen. (Gefunden: http://how-to.wikia.com/wiki/How_to_use_Inkscape_in_commandline_mode/List_of_verbs ) Find ich übrigens fantastisch, dass Du Dich für die Weiterentwicklung von Ghostscript eingesetzt hast. Das unkorrekte Cropping scheint sehr von der internen Struktur des PDF abzuhängen. Sibelius erzeugte Klammern scheinen zu gehen.
Übrigens, kannst Du Dich noch an den LibreOffice Bug mit den verzerrten Pfaden erinnern? Ist ein gemeldeter Bug, der aber irgendwie leider nicht weiter verfolgt wird. Hier war ein Martin der Ursache schon ganz gut auf der Spur (Rundungs-Fehler), aber seitdem ist nichts mehr passiert. https://bugs.documentfoundation.org/show_bug.cgi?id=96892
Grüße Kai
musikai
hat folgende Bilder an diesen Beitrag angehängt
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden!
f1t1180p10374n606.png
nun, da ich mir Deine Anleitung mal genauer angeschaut habe, sind mir noch 2 Dinge aufgefallen: 1. Bei der Erstellung des Fonts mit Fontforge hast Du durch die Reihenfolge, in der Du vorgegangen bist Glück mit den Font-Namen gehabt. Da Du erst eine Kopie des Fonts gemacht hast und diesen dann in FontForge geladen hast, hat FontForge automatisch den Dateinamen als Font-Namen eingerichtet. Glück gehabt! Hättest Du den Original-Font geladen und erst beim Speichern einen anderen Namen vergeben, dann wäre der Font-Name der alte geblieben und hätte beim Installieren für Komplikationen gesorgt. Dann hätte man in Font-Forge erst die Font-Namen entsprechend ändern müssen. Ist aber alles halb so wild, da Dein WorkFlow ja genau angeben ist und Du ja die Fonts sowieso bereitstellst. Also nur zur Sicherheit, gell. 2. betrifft Ghostscript. Du zeigst ja 2 Wege auf. Der erste erfordert ja ein installiertes Ghostscript, oder? Müsste also auch noch installiert werden. Und bist Du Dir sicher, dass Dein 2.Weg KEIN Ghostscript verlangt? Denn Du fütterst Inkscape ja mit einer ps und dann mit einer eps. Hast Du das schonmal ohne installiertem Ghostscript probiert? Denn soviel ich weiß, greift Inkscape für diese Prozesse auf Ghostscript zu.
So, hoffe, Dich nicht unnötig zu verwirren. Übrigens installiert und benutzt FreePDF auch RedMon.
Hallo Kai, danke für Deine Rückmeldungen. Mich beschleicht das dumpfe Gefühl, dass wir wohl die beiden Einzigen sind, die den Wunsch hegen, Capella-Vektor-Noten in ein Textverarbeitungsprogramm zu bringen. Solange uns der Forumsmoderator nicht abklemmt, führe ich über unsere Erkenntnisse mit Dir gerne einen öffentlichen "Mono-Dialog" [wink].
zu 1. Nein, das war pure Absicht! Ursprünglich wollte ich den richtig in "Windows Latin (ANSI)" codierten "cap3_win.ttf" unter dem Fontnamen "cap3_win" parallel zum originalen "capella3" installieren. Doch das hätte wieder etliche Einstellungen in Capella notwendig gemacht. Zu kompliziert! Wenn man den Dateinamen eines Fonts umbenennt wird nicht automatisch der Fontname auch umbenannt. In FontForge kann man zwar auch einen anderen Fontnamen vergeben, aber das habe ich bewusst nicht gemacht. Denn es ist das Einfachste, den Font mit dem Dateinamen "cap3_win.ttf" (aber mit Fontnamen "capella3" über den Originalen "capella3" zu installieren. Der Normalnutzer merkt nichts davon wenn "capella3.ttf" durch "cap3_win.ttf" ersetzt wird. Aber später für Inkscape und "cap4_uni.ttf" macht das den entscheidenden Unterschied.
zu 2. Stimmt, der erste Weg würde Ghostscript erfordern. Doch da diese Druckmethode aus mir unerklärlichen Gründen manchmal nicht funktioniert, habe ich sie in der Anleitung nicht mehr detailliert beschrieben und somit die Installtion von Ghostscript herausgenommen (ich könnte es wieder in den Anhang tun). Aber, Upps! Du hast recht! Inkscape benötigt offenbar tatsächlich Ghostscript, um EPS Dateien zu öffnen. Vielen Dank für den wichtigen Hinweis! Da bei mir Ghostscript sowieso installiert ist, habe ich das nicht bemerkt. Das kann man überprüfen, indem man das Ghostscript Verzeichnis schnell mal umbenennt, dann funktioniert der letzte Schritt zur Erzeugung der SVG (EPS-->SVG) nicht mehr. (Nicht nachmachen! Das hat bei mir den Druckerport vermurkst und erforderte eine Port-Neuinstallation.) Was man damit aber gleichzeitig auch zeigen kann, ist, dass Inkscape für die Erzeugung der EPS Datei offenbar ohne Ghostscript auskommt und die Bounding Box ist korrekt. Und nur zum Importieren von EPS greift Inkscape dann auf Ghostscript zu. Oje... Und wie Du oben schon erwähnt hast, kann Inkscape nicht per Kommandozeile ohne GUI "croppen" und die -verbs funktionieren nur mit GUI. Ein Teufelskreis...
Mist! Dann muss die Ghostscript-Installation halt wieder in die Anleitung rein. Aber am Rest ändert das nichts. Offenbar hat es noch niemand versucht, gemäß der Anleitung zu installieren, oder sich niemand getraut, sich zu beschweren.
Edit: Variante 2 geht doch ohne Ghostscript! [smile] Anstatt das EPS wieder in Inkscape zu laden (wofür Inkscape Ghostscript benötigt) kann man auch das PDF laden lassen. Dafür benötigt Inkscape offenbar kein Ghostscript. Werde in der Anleitung die Python-Skriptzeile anpassen.
Ach gut, dass Variante 2 auch ohne Ghostscript geht. Jetzt schlag mich net, aber bin grad auf was merkwürdiges gestoßen: Seitdem ich das neue Inkscap0.92 installiert habe, geht ps und eps import ohne Ghostscript!! Es steht nirgendwas davon in den Release Notes. Aber ich habe extra Ghostscipt deinstalliert und es ging weiterhin (während alle anderen Programme die GS benutzen nicht mehr gingen.)
Zitat von Theo Mich beschleicht das dumpfe Gefühl, dass wir wohl die beiden Einzigen sind, die den Wunsch hegen, Capella-Vektor-Noten in ein Textverarbeitungsprogramm zu bringen.
Da trügt dich dein Gefühl wohl nicht ... und ich denke, das hat auch einen Grund: auch wenn ich eine Vektorgrafik stufenlos skalieren kann, so hat das m. E. doch den Nachteil, dass damit auch die Rastralgröße geändert wird.
Mit etwas "Rechenaufwand" lässt sich auch eine Pixelgrafik passend in ein Textdokument einsetzen. Dieser "Rechenaufwand" mag zunächst angesichts der freien Skalierbarkeit einer Vektorgrafik überflüssig erscheinen, aber er sorgt dafür, dass die Notenbeispiele dann alle dieselbe Rastralgröße beibehalten.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Für mich persönlich geht's auch gar nicht um Capella. Viele der angesprochenen Bereiche sind allgemeingültig für die verschiedensten Notensatz-Programme, die keinen vernünftigen Vektor-Export haben.
Klar kann man auch mit Rastergrafiken arbeiten. In ausreichernder DPI-Einstellung ja kein Problem. Allerdings sehen Vektorgrafiken im PDF trotzdem besser aus, sind kleiner, und man kann jedes Element bearbeiten. Dein genanntes Argument gleichbleibender Rastralgröße erschließt sich mir leider nicht. Kannst doch alle Vektor-Grafiken gleichartig skalieren. Für ein perfektes Layout am Ende muss man sich natürlich bei Vektorgrafiken die gleichen Gedanken machen wie bei Rastergrafiken.
@musikai, bist mir zuvorgekommen [wink] Stimme Dir zu.
@acco-boy, wenn Capella die Möglichkeit nicht bietet (wie z.T. andere Notationsprogramme), ein Notenheftchen mit Vektor-Noten (anstatt mit pixelierter Rastergrafik) zu erstellen, warum sollte man sich dann nicht einen "Workaround" basteln, der noch den Vorteil hat, das Heftchen mit den Grafiken andere Leute machen zu lassen, die z.B. keinen Publisher haben?
Wenn ich die aus Capella exportierte Grafik 1:1 in die Textverarbeitung einsetze, habe ich die gleiche Rastralgröße wie in Capella. Wenn ich skaliere wird diese entsprechend größer oder kleiner. Das hat Skalieren so an sich... Wieso soll das bei einer Pixelgrafik anders sein? Das verstehe ich nicht.
Ich glaube, da haben wir uns missverstanden. Es ging mir nicht darum, eure Arbeit (“Workaround&ldquo in Frage zu stellen, sondern ich habe nur versucht, aus meiner Sicht zu erklären, warum sich so wenige an dieser Diskussion beteiligen. Da gibt es für mich im wesentlichen 2 Gründe:
1. technisch zu anspruchsvoll 2. zu aufwändig, geht auch einfacher
Den zweiten habe ich versucht, am Beispiel „kleine Notenausschnitte in einem Textdokument“ darzustellen (war wohl nicht deutlich genug). Da muss vorher klar sein, wie breit die werden sollen, da sich bei nachträglichem Anpassen (proportional natürlich) die Rastralgröße ändert (das gilt selbstverständlich sowohl für Vektoren als auch für Raster). Wenn ich also alles bereits beim Notensatz berücksichtige, benötige ich nur noch einen Grafikexport mit „ausreichend dpi“.
Wenn ich natürlich komplette Stücke exportieren und dann skalieren möchte, sieht die Sache etwas anders aus. In diese Situation bin ich allerdings noch nicht gekommen, das mache ich immer im Notensatzprogramm (vorher überlegen, welches Format das Ergebnis haben soll und passende Rastralgröße wählen).
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
@acco-boy, eigentlich bin ich nicht überrascht über wenig Teilnahme. Wer technisch etwas beitragen wollte, müsste sich mit den Problemen detailliert beschäftigen, das kann/will nicht jeder. Deswegen gibt es ja bei der Software "Entwickler" und "Nutzer". Und die, die teilgenommen haben, haben eh den Publisher [wink]
zu 1. Stimme Dir (teilweise) zu. Es geht ja für den Anwender nicht darum, jedes Detail des Workarounds verstehen zu müssen, sondern bestimmten Instruktionen einfach zu folgen. Klar, das kann man von einem absoluten Computer-Laien nicht unbedingt verlangen. Aber verwenden solche ein Notationsprogramm? Und ja, aller Zusatzaufwand müsste/sollte nicht sein. Es läge an den Programm-Entwicklern (Capella oder anderen), einen Vektor-Export bereits zur Verfügung zu stellen.
zu 2. zu aufwändig, nein; aufwändiger, ja; aber ein einmaliger Aufwand bei der Installation. Zum Erzeugen der Vektorgrafiken sind es vermutlich gleichviel oder noch weniger Klicks als zum Export einer Rastergrafik. Geht auch einfacher? Bei gleicher Qualität und Kompaktheit glaube ich nicht. Mit eingebundenen PNGs, TIFs oder BMPs wirst Du nur mit sehr großen Dateien (sehr hohen dpi) vernünftige Druckqualität erreichen. Was sind für Dich "ausreichend dpi", 300, 600, 1200 dpi? Warum sollte ich etwas, was ich in Vektoren darstellen und einbinden kann in Pixel aufrastern? Das lasse ich dann am Schluss beim Drucken den Drucker machen, mit 1200 oder 2400 oder mehr dpi [wink]
Wieso muss ich vorher die Breite eines Notenausschnitts wissen? Der wird exportiert und 1:1 eingebunden, fertig. Wenn im Notationsprogramm alle Stücke und Notenauschnitte die gleiche Rastralgröße haben, dann ist das nachher im Textverarbeitungsprogramm auch so. Wenn ich dort eine Grafik skaliere, muss ich natürlich alle anderen gleich skalieren damit alle wieder gleich groß aussehen (falls das überhaupt erwünscht ist).
Zitat von Theo zu 1. Stimme Dir (teilweise) zu. Es geht ja für den Anwender nicht darum, jedes Detail des Workarounds verstehen zu müssen, sondern bestimmten Instruktionen einfach zu folgen. Klar, das kann man von einem absoluten Computer-Laien nicht unbedingt verlangen. Aber verwenden solche ein Notationsprogramm? Und ja, aller Zusatzaufwand müsste/sollte nicht sein. Es läge an den Programm-Entwicklern (Capella oder anderen), einen Vektor-Export bereits zur Verfügung zu stellen.
afuer: Ich wundere mich eh, wie viel z. B. bei Capella die Script-Programmierer übernehmen (müssen?).
Zitat von Theo Zum Erzeugen der Vektorgrafiken sind es vermutlich gleichviel oder noch weniger Klicks als zum Export einer Rastergrafik. Geht auch einfacher? Bei gleicher Qualität und Kompaktheit glaube ich nicht. Mit eingebundenen PNGs, TIFs oder BMPs wirst Du nur mit sehr großen Dateien (sehr hohen dpi) vernünftige Druckqualität erreichen. Was sind für Dich "ausreichend dpi", 300, 600, 1200 dpi?
Ausreichend dpi = 1200. Anzahl der Klicks: Das hängt wohl stark vom Programm ab. Ich z. B. brauche nur Ausschnitte definieren, die dann alle in einem Rutsch in gleicher Qualität exportiert werden. Und über Kompaktheit habe ich mir noch nie Gedanken machen müssen. Vielleicht liegt das einfach daran, dass ich fast alles ausschließlich im Notensatzprogramm mache.
Zitat von Theo Wieso muss ich vorher die Breite eines Notenausschnitts wissen? Der wird exportiert und 1:1 eingebunden, fertig. Wenn im Notationsprogramm alle Stücke und Notenauschnitte die gleiche Rastralgröße haben, dann ist das nachher im Textverarbeitungsprogramm auch so. Wenn ich dort eine Grafik skaliere, muss ich natürlich alle anderen gleich skalieren damit alle wieder gleich groß aussehen (falls das überhaupt erwünscht ist).
Damit er exakt passt. Zugegeben, das kommt auf den Anwendungsfall an. Wenn jede Breite akzeptiert wird, ist es egal. Ich aber wünsche mir in einem zweispaltigen Layout ein Notenbeispiel z. B. mit einer Breite von einer Spalte (oder zwei Spalten + Spaltenabstand). Passt das Notenbeispiel da nicht und es muss nachher skaliert werden ... das hatten wir schon.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Ich glaub auch, daß es natürlich eine Themen-Insel ist, die wenige interessiert. Für Capella haben wir jetzt 2 Lösungen: Theo's, die am Anfang mehr Einrichtungs-Arbeit verlangt und verwendbare SVGs erzeugt, und meine kompakte Lösung, mit der sich auch arbeiten läßt (hier: http://notensatz.forumprofi.de/index.php?topic=1180.msg10049#msg10049)
Zitat von acco-boy Ich z. B. brauche nur Ausschnitte definieren, die dann alle in einem Rutsch in gleicher Qualität exportiert werden.
Das ist natürlich wirklich eine echt coole Funktion, wenn ich es richtig verstehe. Du kannst mehrere Grafik-Export-Auschnitte definieren, die auch mit dem Dokument gespeichert werden? Hut ab! Ich bin echt super gespannt auf Primus2. Vieles was ich bisher so gelesen und gesehen habe, gefällt mir sehr gut.
Allerdings hilft das Capella-Anwendern natürlich nix.
Zitat von musikai Das ist natürlich wirklich eine echt coole Funktion, wenn ich es richtig verstehe. Du kannst mehrere Grafik-Export-Auschnitte definieren, die auch mit dem Dokument gespeichert werden?
Ja, so ist es.
Zitat von musikai Ich bin echt super gespannt auf Primus2.
Und ich erst.
Zitat von musikai Allerdings hilft das Capella-Anwendern natürlich nix.
Wie wahr, wie wahr.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
...Software "lebt"... Sorry, schon wieder... Nachdem jetzt im Januar 2017 Inkscape 0.92 herausgekommen ist, kann es nun offenbar auch mit non-Unicode-Fonts umgehen. [smile] Tja, damit war und ist das ganze Theater mit "capella3"/"capella4" und FontForge überflüssig. Doch als neue Überraschung oder "Feature" baut Inkscape jetzt neu einen Hintergrund ein (warum auch immer?), der so groß wie die gedruckte Seite ist. Damit werden die EPS und SVG nicht auf den eigentlichen Inhalt "gecroppt". Jetzt braucht's da wieder ein Workaround. Unglaublich! *Seufz*, ist nicht Sisyphos der Schutzpatron der Softwareentwickler?
Mich hat immer gewundert, warum Du für Inkscape Fonts herstellen musstest. Bei mir konnte auch Inkscape 0.91 die Capella Noten immer korrekt mit dem originalen Capella3.ttf anzeigen. Genauso wie 0.92. Das Problem mit dem Croppen ist natürlich blö. Wurde das bei Dir immer bei der .ps nach eps Konvertierung mit Inkscape erledigt, oder? Ich habe ja früher erwähnt, dass Inkscape 0.92 nun plötzlich ps ohne Ghostscript importieren kann. Vielleicht hatte Ghostscript das cropping erledigt.
Du hattest Deine PDF aus Capella mit FreePDF gedruckt und dann in Inkscape importiert?! Und Du arbeitest unter Ubuntu? Dann war das alles nur wieder eine Windows-Sache? Daher vielleicht der Unterschied in Inkscape0.91? Wenn ich in Win7/64 und Inkscape 0.91 direkt mit dem capella3.ttf etwas "schreiben" wollte, wurde der bei mir nicht dargestellt, sondern durch den Standard-Font ersetzt. In Inkscape 0.92 geht's jetzt. Es bleibt sehr verwirrend.
Die Ursache vom Nicht-Croppen ist allerdings inzwischen geklärt. [smile] Ich hatte ausnahmsweise auf einem anderen Rechner aus CapellaReader8 gedruckt. Und der führt im SVG zu einer braunen Hintergrundseite und noch einer weißen Hintergrundseite darüber, weswegen nicht "richtig" gecroppt werden kann. Völlig unsinnig! Also darf man nur aus Capella7.1 drucken! Oje, das lässt aber schon befürchten, dass es dann mit Capella8 vermutlich genauso wie beim CapellaReader8 sein wird?! Aber das dauert ja noch eine ganze Weile... spätestens dann hören wir uns wieder [wink]
Notensatzforum
»
Unterforen
»
capella-Forum
»
[gelöst] Noten im Vektorformat in Textverarbeitungsprogramm
Thema drucken
12.01.2017 23:30
t, dann kommt man nicht um manuelle Dialoge rum. Aber könnte vielleicht für bestimmte SVG Operationen nützlich sein. Muss mal nach einer --verb liste schauen. (Gefunden: 
Antworten
über den Originalen "capella3" zu installieren. Der Normalnutzer merkt nichts davon wenn "capella3.ttf" durch "cap3_win.ttf" ersetzt wird. Aber später für Inkscape und "cap4_uni.ttf" macht das den entscheidenden Unterschied.
afuer: Ich wundere mich eh, wie viel z. B. bei Capella die Script-Programmierer übernehmen (müssen?).
