Ich habe jetzt hier 1500 Falzflyer liegen bei denen ich an 2 Stellen die Falschdarstellung der Ligatur "fi" übersehen habe. Inkscape stellt das als "f " dar. Es unterschlägt also das i. Jetzt liegt das Kind im Brunnen, muß ich mit leben. Aber wie vermeide ich eine Wiederholung dieses Fehlers, und das Auftreten von ähnlichen.
Inkscape 1.0.2 (e86c870879, 2021-01-15) Debian Bullseye, verwendete Schrift Roboto aus den Debian Quellen.
Ich nehme an, *in* Inkscape sieht alles gut aus, aber im PDF-Export aus Inkscape nicht? Und Du hast es auch schon mit einer aktuellen Version versucht?
Nein, schon in Inkscape wird die Ligatur falsch dargestellt.
Ich überlege aber gerade wie sich das Ganze so abgespielt hat. Ausgangspunkt war ein bestehendes *.docx, geändert durch eine Vereinskollegin in der Vereinscloud, nextcloudinstanz. Beim pdf export hat es da einige Grafiken zerlegt, deswegen war ich da noch mit LibreOffice aktiv. Damit hat der pdf export etwas ausgeworfen mit dem man weiterarbeiten konnte. Das pdf als erste Ebene geöffnet, oder in die erste Ebene importiert, die Hintergrundgrafik neu gestaltet, den Text markiert und auf eine neue Ebene kopiert, strg+v strg+c. Bilder und Grafiken liegen auch auf eigenen Ebenen. Irgendwo auf dem Weg hat es dann die Ligatur zerlegt. Die Schrift in Pfade kam dann erst zum Schluß. Das waren meine ersten Gehversuche mit Inkscape, neben dem Flyer wurde noch ein Formular und Beachflags gestaltet, CAD Arbeiten erledigt und Lötarbeiten samt Fehlersuche beim OpenBikeSensor durchgezogen. Alles nach der Schichtarbeit. Scribus, für die Aufbereitung als Druckvorlage in CMYK, hat mir auch noch ein paar Stolpersteine beschert. So wirklich kann ich gar nicht sagen in welchem Schritt der Fehler aufgetreten ist. Auffällig ist das nur die Ligatur "fi" betroffen ist, wobei ich jetzt nicht überblicke ob weitere Ligaturen im Text vorkommen.
Ich werd wohl den ganzen Weg noch einmal gehen müßen und jeden einzelnen Schritt kontrollieren.
Ja, so richtig weiß ich da auch nicht, an welcher Stelle es gehakt haben mag. Ich würde Dir jedoch empfehlen wollen, die Grafiken in Inkscape zu gestalten und die Texte in Scribus, und das Ganze in Scribus zusammenzuführen und von dort zu exportieren.
Und eine aktuelle Inkscape-Version zu verwenden, natürlich.
Und ich hab mich schon gefreut daß ich mit Inkscape so halbwegs klar komm. Scribus ist noch ein Buch mit sieben Siegeln für mich. Hilft aber wohl nichts.
Und das mit der aktuellen Version, tja, der Fluch von Debian stable.
So, erneuter Versuch mit der aktuellen Appimageversion. In LibreOffice sieht alles gut aus. Im exportierten PDF ist alles da wo es hingehört. Das PDF in Inkscape importiert killt zuverlässig die Ligatur, aus "fi" wird "f ". Also aus "finden" wird "f nden". Schrift in allen Dokumenten "Roboto"
@Moini So versteckt ist das AppImage ja auch wieder nicht. Da sammelt sich nur langsam ein wilder Haufen an AppImages an, RawTherapee wird gar direkt aus den Quellen übersetzt. Nach leidvoller Erfahrung mit testing/sid, ist nicht schön wenn man was liefern sollte und die Kiste will nicht, bin ich reumütig zurück auf stable. Die Frage nach den beiden Importmethoden hat mich auf eine Idee gebracht. Die interne Methode killt die Ligaturen, Import mit Poppler/Cairo funktioniert dagegen wie gewünscht. Sowohl bei der Debianversion, wie auch dem AppImage. In beiden Fällen führt die interne Methode zu dem Verlust von Teilen der Ligatur.
@Polygon ?? Du sprichst in Rätseln zu mir, beziehungsweise mir sind die Unterschiede nicht bekannt.
In dem Fall habe ich eine wichtige Aufgabe für Dich: Bitte teste, sobald Du Zeit hast, auch die Entwicklerversion mit Deiner Datei. Der poppler-Import soll nämlich demnächst entsorgt werden, und der interne PDF-Import wurde intensiv überarbeitet. Es wäre gut, wenn wir mögliche Fehler vor der Veröffentlichung raussieben könnten.
Heh, das mit der Unterführung verstehe ich zwar nicht, aber wenn es in der Entwicklerversion auch mit dem internen Import funktioniert, besteht ja Hoffnung! (geplante Veröffentlichung ist allerdings erst im Juni/Juli).
Ältere Leute, die sich mal mit der seit 2K Jahren vorherrschenden Religion befasst haben, kennen das eher als "führe mich nicht in Versuchung". Egal, das nächste AppImage ist aktiv. Wir werden noch in der Windowshölle schmoren, wenn das so weiter geht.
@rostgerradler Ich bin mir jetzt nicht mehr so sicher, das wir vom selben Font reden. Ich meine den hier:
Die 2 oberen ersetzen alle unteren. Variable meint hier Du kannst, wenn die Software es erlaubt nahtlose Übergänge zwischen den Schnitten. In diesem Paket von Guhgle find ich allerdings keine Ligaturen. Deshalb meine Zweifel.
Ich habe jetzt hier 1500 Falzflyer liegen bei denen ich an 2 Stellen die Falschdarstellung der Ligatur "fi" übersehen habe. Inkscape stellt das als "f " dar. Es unterschlägt also das i. Jetzt liegt das Kind im Brunnen, muß ich mit leben. Aber wie vermeide ich eine Wiederholung dieses Fehlers, und das Auftreten von ähnlichen.
Inkscape 1.0.2 (e86c870879, 2021-01-15) Debian Bullseye, verwendete Schrift Roboto aus den Debian Quellen.
Grüße
Robert
Eh, wie blöd ... :-(
Ich nehme an, *in* Inkscape sieht alles gut aus, aber im PDF-Export aus Inkscape nicht? Und Du hast es auch schon mit einer aktuellen Version versucht?
Hast Du den Text nicht in Pfade umgewandelt?
Nein, schon in Inkscape wird die Ligatur falsch dargestellt.
Ich überlege aber gerade wie sich das Ganze so abgespielt hat. Ausgangspunkt war ein bestehendes *.docx, geändert durch eine Vereinskollegin in der Vereinscloud, nextcloudinstanz. Beim pdf export hat es da einige Grafiken zerlegt, deswegen war ich da noch mit LibreOffice aktiv. Damit hat der pdf export etwas ausgeworfen mit dem man weiterarbeiten konnte. Das pdf als erste Ebene geöffnet, oder in die erste Ebene importiert, die Hintergrundgrafik neu gestaltet, den Text markiert und auf eine neue Ebene kopiert, strg+v strg+c. Bilder und Grafiken liegen auch auf eigenen Ebenen.
Irgendwo auf dem Weg hat es dann die Ligatur zerlegt.
Die Schrift in Pfade kam dann erst zum Schluß.
Das waren meine ersten Gehversuche mit Inkscape, neben dem Flyer wurde noch ein Formular und Beachflags gestaltet, CAD Arbeiten erledigt und Lötarbeiten samt Fehlersuche beim OpenBikeSensor durchgezogen. Alles nach der Schichtarbeit. Scribus, für die Aufbereitung als Druckvorlage in CMYK, hat mir auch noch ein paar Stolpersteine beschert.
So wirklich kann ich gar nicht sagen in welchem Schritt der Fehler aufgetreten ist.
Auffällig ist das nur die Ligatur "fi" betroffen ist, wobei ich jetzt nicht überblicke ob weitere Ligaturen im Text vorkommen.
Ich werd wohl den ganzen Weg noch einmal gehen müßen und jeden einzelnen Schritt kontrollieren.
Ja, so richtig weiß ich da auch nicht, an welcher Stelle es gehakt haben mag. Ich würde Dir jedoch empfehlen wollen, die Grafiken in Inkscape zu gestalten und die Texte in Scribus, und das Ganze in Scribus zusammenzuführen und von dort zu exportieren.
Und eine aktuelle Inkscape-Version zu verwenden, natürlich.
Und ich hab mich schon gefreut daß ich mit Inkscape so halbwegs klar komm. Scribus ist noch ein Buch mit sieben Siegeln für mich. Hilft aber wohl nichts.
Und das mit der aktuellen Version, tja, der Fluch von Debian stable.
So, erneuter Versuch mit der aktuellen Appimageversion. In LibreOffice sieht alles gut aus. Im exportierten PDF ist alles da wo es hingehört. Das PDF in Inkscape importiert killt zuverlässig die Ligatur, aus "fi" wird "f ". Also aus "finden" wird "f nden". Schrift in allen Dokumenten "Roboto"
Ah, Du hast das AppImage gefunden. Schade, dass das Importieren die Ligaturen abmurkst. Welche der beiden Importmethoden nimmst Du denn?
Ist das der Static Font oder die Variable Version?
@Moini So versteckt ist das AppImage ja auch wieder nicht. Da sammelt sich nur langsam ein wilder Haufen an AppImages an, RawTherapee wird gar direkt aus den Quellen übersetzt. Nach leidvoller Erfahrung mit testing/sid, ist nicht schön wenn man was liefern sollte und die Kiste will nicht, bin ich reumütig zurück auf stable.
Die Frage nach den beiden Importmethoden hat mich auf eine Idee gebracht. Die interne Methode killt die Ligaturen, Import mit Poppler/Cairo funktioniert dagegen wie gewünscht. Sowohl bei der Debianversion, wie auch dem AppImage. In beiden Fällen führt die interne Methode zu dem Verlust von Teilen der Ligatur.
@Polygon ?? Du sprichst in Rätseln zu mir, beziehungsweise mir sind die Unterschiede nicht bekannt.
Okay, super.
In dem Fall habe ich eine wichtige Aufgabe für Dich: Bitte teste, sobald Du Zeit hast, auch die Entwicklerversion mit Deiner Datei. Der poppler-Import soll nämlich demnächst entsorgt werden, und der interne PDF-Import wurde intensiv überarbeitet. Es wäre gut, wenn wir mögliche Fehler vor der Veröffentlichung raussieben könnten.
@Moini ja danke, jetzt willst du mich noch in der Unterführung suchen.
Bei der Version Inkscape 1.3-dev (009e769, 2023-03-24) scheint alles zu passen. Zumindest habe ich auf den ersten Blick keine Fehler gefunden.
Heh, das mit der Unterführung verstehe ich zwar nicht, aber wenn es in der Entwicklerversion auch mit dem internen Import funktioniert, besteht ja Hoffnung! (geplante Veröffentlichung ist allerdings erst im Juni/Juli).
Ältere Leute, die sich mal mit der seit 2K Jahren vorherrschenden Religion befasst haben, kennen das eher als "führe mich nicht in Versuchung". Egal, das nächste AppImage ist aktiv. Wir werden noch in der Windowshölle schmoren, wenn das so weiter geht.
Konnte mich nicht zwischen Teufel- und Engelemoji entscheiden ... ;-) Viel Spaß beim Ausprobieren, sind ein paar tolle neue Sachen drin.
@rostgerradler Ich bin mir jetzt nicht mehr so sicher, das wir vom selben Font reden. Ich meine den hier:
Die 2 oberen ersetzen alle unteren. Variable meint hier Du kannst, wenn die Software es erlaubt nahtlose Übergänge zwischen den Schnitten. In diesem Paket von Guhgle find ich allerdings keine Ligaturen. Deshalb meine Zweifel.
Ein
findet schon mal nix
liefert eine recht lange Liste an .ttf .otf .svg .woff .woff2 .eot