Hallo,
ich "evaluiere" seid einiger Zeit Scribus für unsere Anforderungen.
Wir betreiben einen Flashseite wo nach Auswahl des Produkts ein par Motive, Hintergründe, etc. gewählt werden können.
Nach Abschluss der Bestellung kommt eine XML raus, die InDesign dann einliest und aus PDF und PSD den Output zusammenpuzzelt.
Flash ist tot, daher neuer Shop und in dem Zusammenhang auch mal neue Ausgabelogiken.
Dafür fand ich Scribus total interessant. Leider scheint es hier Grenzen zu geben :-(
1.) Bei den PDF Dateien die ich importiere verschluckt sich Scribus hin und wieder. Dies äußert sich durch "schlechte Transparenzen" von Grafiken (teils Graustufen statt Transparenz o.ä.), Rahmen um Grafiken, leicht abweichende Farben bei Bildern, etc. Diese PDF sind erstellet mit Adobe Produkten und ich kann nichts mangelhaftes erkennen. Wenn ich diese bspw. mit "pdf2ps" in eine PS Datei konvertiere passt auch alles. Aber dann werden Sie so groß. Lege ich Sie als Bildrahmen in die Ebene Hintergrund, passt ebenfalls alles prima. Aber dann ist die Datei wieder riesig und der Hintergrund eben kein Vektor sondern (vermutlich) ein Binäres Bild. Es ist auch nicht bei alle PDF, nur bei "umfangreichen".
2.) Platziere ich die PDF oder PS Dateien mit Scripter, macht er mir die immer am Anfang des Dokumentes als eine neue A4 Seite. Das Dokument hat zwei Seiten A3 Quer. Setze ich Bilder, Textrahmen, etc. landen die ganz normal auf der aktiven Seite. Ich habe alle Funktionen versucht: placeEPS, placeSVG und placeVectorFile.
Getestet auf OS X 10.13 mit Scribus 1.5.3 und 1.5.4 und auf Ubuntu 16.04 mit Scribus 1.5.3 ausm ppa:scribus/ppa.
Ghostscript auf OS X mit homebrew installiert, auf Ubuntu ja irgendwie automatisch aus den deps oder so.
Ich finde Scribus eine tolle Sache, gerade mit dem Scripter.
Aber so können wir es leider nicht vewenden und müssten bei InDesign mit Scripts bleiben :-(
Vielen Dank für Ratschläge
Grenzen von Scribus und Scripter
Re: Grenzen von Scribus und Scripter
scribus ist open source / freie software.
es gibt ein paar leute die sich aufopfern, code produzieren, neue features programmieren, das projekt au laufen halten...
aber wenn wir längerfristig eine professionnelle software haben wollen, brauchen wir kommerzielle anwender, die mehr als nur benutzer sind.
leider ist mir nur ein fall bekannt, wo ein unternehmer konsequent an patches für scribus gearbeitet hat.
(und, herlich gesagt, es sind sie, die es möglich gemacht haben, scribus aus der kommandozeile brauchbar zu machen!)
ihr zahlt viel geld an adobe, aber bei der evaluation von scribus, sehe ich nicht den willen in scribus zu inverstieren...
scribus ist gratis, dann können wir das geld in der entwicklung vom neuen shop stecken... oder?
das kann nicht gut gehen...
nicht wenn alle so handeln.
und zur sache: ich bin mich nicht sicher, ob die beste lösung ist, PDF einzulesen...
aber wir haben zu wenig details über das projekt, um zu beurteilen...
(wenn möglich, würde ich die quell-dateien in .sla umwandeln... ist es machbar?)
sorry, dass ich keine fertige lösung hervorzaubern kann...
ciao
a.l.e
es gibt ein paar leute die sich aufopfern, code produzieren, neue features programmieren, das projekt au laufen halten...
aber wenn wir längerfristig eine professionnelle software haben wollen, brauchen wir kommerzielle anwender, die mehr als nur benutzer sind.
leider ist mir nur ein fall bekannt, wo ein unternehmer konsequent an patches für scribus gearbeitet hat.
(und, herlich gesagt, es sind sie, die es möglich gemacht haben, scribus aus der kommandozeile brauchbar zu machen!)
ihr zahlt viel geld an adobe, aber bei der evaluation von scribus, sehe ich nicht den willen in scribus zu inverstieren...
scribus ist gratis, dann können wir das geld in der entwicklung vom neuen shop stecken... oder?
das kann nicht gut gehen...
nicht wenn alle so handeln.
und zur sache: ich bin mich nicht sicher, ob die beste lösung ist, PDF einzulesen...
aber wir haben zu wenig details über das projekt, um zu beurteilen...
(wenn möglich, würde ich die quell-dateien in .sla umwandeln... ist es machbar?)
sorry, dass ich keine fertige lösung hervorzaubern kann...
ciao
a.l.e
Re: Grenzen von Scribus und Scripter
Wer sagt denn das man nicht bereit wäre in Scribus zu investieren?!
Ich glaube mein Chef wäre sofort bereit da auch Geld und Kapazität locker zu machen.
Ich persönlich würde sehr gerne mehr Open Source in den Betrieben sehen.
Aber man bekommt da eben keine verbindlichen Termine, Garantien, usw. es sei denn man kauft wieder Service (Beispiel: Canonical/Ubuntu)
Und darum geht es dem Unternehmer halt leider. Verbindlichkeit, Termine, "Business"...
Und um Adobe Produkte kommst du schlicht nicht drum herum. Wir bekommen von allen Seiten (Kunden und Agenturen) nur Photoshop und InDesign Dateien. Das ist wie Windoof, da kommst du auch nicht dran vorbei im Berufsleben.
Aber zum Thema. Ich darf leider keine PDF Dateien rausgeben, da diese "Eigentum" unseres Kunden sind.
Wenn ich diese jedoch "optimiere", bspw. mit Acrobat oder auch Ghostcript ist (fast) alles gut.
Scribus kommt also offensichtlich mit so Transparenzen und Überlagerungen nicht klar.
Was nutzt denn Scribus zum einlesen von PDF? Ghostscript?
Was ist denn deiner Meinung nach die bessere Wahl als PDF als Hintergrund? Als Bild?! Das macht die Dateien so riesig.
Wie meinst du die Quell-Dateien in sla Umwandeln?! Die bekommen wir von einer Grafik-Agentur als PDF, InDesign oder Photoshop, je nach dem...
Danke!
Ich glaube mein Chef wäre sofort bereit da auch Geld und Kapazität locker zu machen.
Ich persönlich würde sehr gerne mehr Open Source in den Betrieben sehen.
Aber man bekommt da eben keine verbindlichen Termine, Garantien, usw. es sei denn man kauft wieder Service (Beispiel: Canonical/Ubuntu)
Und darum geht es dem Unternehmer halt leider. Verbindlichkeit, Termine, "Business"...
Und um Adobe Produkte kommst du schlicht nicht drum herum. Wir bekommen von allen Seiten (Kunden und Agenturen) nur Photoshop und InDesign Dateien. Das ist wie Windoof, da kommst du auch nicht dran vorbei im Berufsleben.
Aber zum Thema. Ich darf leider keine PDF Dateien rausgeben, da diese "Eigentum" unseres Kunden sind.
Wenn ich diese jedoch "optimiere", bspw. mit Acrobat oder auch Ghostcript ist (fast) alles gut.
Scribus kommt also offensichtlich mit so Transparenzen und Überlagerungen nicht klar.
Was nutzt denn Scribus zum einlesen von PDF? Ghostscript?
Was ist denn deiner Meinung nach die bessere Wahl als PDF als Hintergrund? Als Bild?! Das macht die Dateien so riesig.
Wie meinst du die Quell-Dateien in sla Umwandeln?! Die bekommen wir von einer Grafik-Agentur als PDF, InDesign oder Photoshop, je nach dem...
Danke!
Re: Grenzen von Scribus und Scripter
... jetzt sehe ich den willen in scribus zu investieren... vorher war er (für mich) nicht sichtbar...
es war auch nicht klar, woher die PDF herkommen...
für indesign dateien, gibt's den umweg über IDML...
unter umständen besser (und einfacher zu verbessern) als PDF.
unter umständen ist doch PDF besser...
für PSD dateien, ich glaube scribus braucht eine "standard" library um sie zu importieren.
viel, aber nicht alles, kann importiert werden.
für PDF dateien, ja, ihr musst sie wahrscheinlich zuerst "flatten"...
wenn für die PDFs über "file > import > get vector file..." gehst, dann benutzt scribus poppler und eigene bindings. es sollte nich allzuschwierig, patches zu programmieren, für poppler und/oder für scribus.
wenn du in einen bildrahmen ladest, dann wird ghostscript gebraucht... und wenn du dort eine bitmap-datei erzeugst, sollten keine unterschiede zum original auftauchen.
und wegen termine und garantien: es wäre sehr schön, wenn das team ein bisschen mehr versprechen könnte, ich bin hier mit dir voll einverstanden.
aber wenn ihr scribus selber compiliert, braucht ihr sie nicht wirklich...
einfach mit der eigene version arbeiten, und warten bis die änderungen in der hauptversion einfliessen.
wenn ihr ein plan habt oder ein "produktionsgrund" geltend lässt (zb.: "diese PDF datei wird nicht korrekt gelesen"), es gibt gute chancen, dass patches ziemlich schnell akzeptiert werden... zum teil braucht's ein bisschen hartnäckigkeit (und eine dicke haut...), aber meistens geht's ziemlich gut!
zugegeben: das scribus projekt ist nicht das einfachste, um code beizusteuern... aber wenn keine neue kräfte kommen, wird sich auch nichts ändern...
ciao
a.l.e
es war auch nicht klar, woher die PDF herkommen...
für indesign dateien, gibt's den umweg über IDML...
unter umständen besser (und einfacher zu verbessern) als PDF.
unter umständen ist doch PDF besser...
für PSD dateien, ich glaube scribus braucht eine "standard" library um sie zu importieren.
viel, aber nicht alles, kann importiert werden.
für PDF dateien, ja, ihr musst sie wahrscheinlich zuerst "flatten"...
wenn für die PDFs über "file > import > get vector file..." gehst, dann benutzt scribus poppler und eigene bindings. es sollte nich allzuschwierig, patches zu programmieren, für poppler und/oder für scribus.
wenn du in einen bildrahmen ladest, dann wird ghostscript gebraucht... und wenn du dort eine bitmap-datei erzeugst, sollten keine unterschiede zum original auftauchen.
und wegen termine und garantien: es wäre sehr schön, wenn das team ein bisschen mehr versprechen könnte, ich bin hier mit dir voll einverstanden.
aber wenn ihr scribus selber compiliert, braucht ihr sie nicht wirklich...
einfach mit der eigene version arbeiten, und warten bis die änderungen in der hauptversion einfliessen.
wenn ihr ein plan habt oder ein "produktionsgrund" geltend lässt (zb.: "diese PDF datei wird nicht korrekt gelesen"), es gibt gute chancen, dass patches ziemlich schnell akzeptiert werden... zum teil braucht's ein bisschen hartnäckigkeit (und eine dicke haut...), aber meistens geht's ziemlich gut!
zugegeben: das scribus projekt ist nicht das einfachste, um code beizusteuern... aber wenn keine neue kräfte kommen, wird sich auch nichts ändern...
ciao
a.l.e
Re: Grenzen von Scribus und Scripter
Ich muss/möchte dieses Thema leider nochmal bemühen.
Nach dem wir jetzt schon mit diversen "Experten" nach Lösungen gesucht haben, drehe ich mich im Kreis...
Der Anwendungsfall ist wirklich denkbar einfach. Kunde wählt im Shop ein par Faktoren (Format, Hintergrundmotiv und Texte).
Scribus-Scripter erstellt eine Datei in dem Format, platziert das Hintergrundmotiv und setzt darauf die Texte.
Klappt auch alles wirklich ohne Probleme! Bis auf die Tatsache, dass die Hintergrundmotive an Farbe und Qualität verlieren.
Die Hintergrundmotive werden von Agenturen bereits als PDF geliefert und stammen aus den diversen Adobe Programmen.
Ich habe alles probiert, PDF als Vektor importieren (sieht am schlimmsten aus), PDF in Bildrahmen laden (geht so, Farbe schlecht), auf diversen Wegen (mogrify/convert, ghostscript, ImageMagic direkt aus Python heraus, ...) Bilder auf der PDF gemacht (TIF). Es ist farblich einfach schlecht und manchmal fehlen auch Transparenzen, sind Pfade nur teilweise oder viel zu grob (stufig), alle möglichen Kombis an Postscript und EPS getestet (viel zu groß und Probleme bleiben) etc.
Wenn ich die PDF Dateien in InDesign platziere und ausgebe ist alles super!
Nicht falsch verstehen, ich bin kein Adobe-Jünger und würde gerne OpenSource nutzen und unterstützen.
Aber scheinbar haben alle die OpenSourcer aus dem Bereich nicht die Qualität und Bandbreite and PDF lesen/schreiben
Was ist denn generell ratsam für Druckausgaben, wenn PDF als Hintergrundmotiv genutzt werden soll?
Flatten? Generell zu Bild konvertieren? Wenn ja zu was? TIF?
Wir würde auch echt "Beratungshonorare" Zahlen, o.ä. aber das Thema scheint eine Sackgasse!
Edit: Vergessen eine Datei anzuhängen! Habe die gröbsten Probleme mal zusammengefasst. Links jeweils Scribus Import oder Ausgabe, rechts Original PDF. (Ich darf halt aus vertraglichen Gründen mit unserem Kunden keine kompletten Motive oder gar Dateien raus geben.)
Nach dem wir jetzt schon mit diversen "Experten" nach Lösungen gesucht haben, drehe ich mich im Kreis...
Der Anwendungsfall ist wirklich denkbar einfach. Kunde wählt im Shop ein par Faktoren (Format, Hintergrundmotiv und Texte).
Scribus-Scripter erstellt eine Datei in dem Format, platziert das Hintergrundmotiv und setzt darauf die Texte.
Klappt auch alles wirklich ohne Probleme! Bis auf die Tatsache, dass die Hintergrundmotive an Farbe und Qualität verlieren.
Die Hintergrundmotive werden von Agenturen bereits als PDF geliefert und stammen aus den diversen Adobe Programmen.
Ich habe alles probiert, PDF als Vektor importieren (sieht am schlimmsten aus), PDF in Bildrahmen laden (geht so, Farbe schlecht), auf diversen Wegen (mogrify/convert, ghostscript, ImageMagic direkt aus Python heraus, ...) Bilder auf der PDF gemacht (TIF). Es ist farblich einfach schlecht und manchmal fehlen auch Transparenzen, sind Pfade nur teilweise oder viel zu grob (stufig), alle möglichen Kombis an Postscript und EPS getestet (viel zu groß und Probleme bleiben) etc.
Wenn ich die PDF Dateien in InDesign platziere und ausgebe ist alles super!
Nicht falsch verstehen, ich bin kein Adobe-Jünger und würde gerne OpenSource nutzen und unterstützen.
Aber scheinbar haben alle die OpenSourcer aus dem Bereich nicht die Qualität und Bandbreite and PDF lesen/schreiben
Was ist denn generell ratsam für Druckausgaben, wenn PDF als Hintergrundmotiv genutzt werden soll?
Flatten? Generell zu Bild konvertieren? Wenn ja zu was? TIF?
Wir würde auch echt "Beratungshonorare" Zahlen, o.ä. aber das Thema scheint eine Sackgasse!
Edit: Vergessen eine Datei anzuhängen! Habe die gröbsten Probleme mal zusammengefasst. Links jeweils Scribus Import oder Ausgabe, rechts Original PDF. (Ich darf halt aus vertraglichen Gründen mit unserem Kunden keine kompletten Motive oder gar Dateien raus geben.)
- Dateianhänge
-
- Dateifehler PDF-Scribus.pdf
- (909.47 KiB) 786-mal heruntergeladen
Re: Grenzen von Scribus und Scripter
kannst du bitte, eine beispiel pdf-datei hochladen die bei dir nicht gut genug importiert wird?
dann können wir selber testen...
dann können wir selber testen...
Re: Grenzen von Scribus und Scripter
Moin!
Julius
Auch, wenn du beim PDF-Export das PDF einbetten lässt? Dann sollte Scribus meines Wissens das eingebettete PDF nicht ändern.heidru hat geschrieben:PDF in Bildrahmen laden (geht so, Farbe schlecht)
Julius
Scribus 1.4.7 und 1.5.4 (Entwicklungszweig) unter Ubuntu 18.04
Um Mithilfe beim Deutsch-sprachigen Scribus-Wiki wird gebeten!
Die aktuellen Versionen von Scribus:
Um Mithilfe beim Deutsch-sprachigen Scribus-Wiki wird gebeten!
Die aktuellen Versionen von Scribus: