Drucken mit definiertem Maßstab

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Slowhand_47
User
Beiträge: 4
Registriert: Samstag 14. August 2010, 14:42

Hallo,

ich möchte mir ein kleines Programm zum Drucken und Bearbeiten von Flügelprofilen in Python schreiben. Grundanforderung ist, dass ich mehrere auf dem Bildschirm dargestellte Kurven in einem exakt vorgegebenen Maßstab drucken kann. Die Profildaten einzulesen und z.B. in einem Tkinter-Canvas (direkt oder über Matplotlib) darzustellen war kein Problem. Nun stellt sich mir die Frage, wie ich diese am besten auf den Drucker bekomme.

Da das direkte Ansprechen des Druckers wohl nicht ganz so einfach sein wird (bzw. ziemlich plattformspezifisch, und eine Cross-Plattform-Lösung für mindestens Linux und Win32 wäre mir lieber), wäre ich auch schon mit einer Ausgabe in eine Bilddatei mit definierten DPI zufrieden. Für's DPI-genaue Ausdrucken einer solchen Datei gibt es auf jeder Plattform genug Programme, so dass ich mir dieses Problem zunächst nicht aufladen müsste.

Da Tkinter ja nur nach Postscript exportieren kann (was für Linux nicht so schlecht, für Win32 aber eher nicht geeignet ist), habe ich mir mal Matplotlib angesehen. Hier kann ich für eine Figure die Größe auf Papier in Inch vorgeben. Allerdings ist dies ja die Gesamtgröße inklusive Achsen und Legende etc.. Ich suche dagegen eine Möglichkeit, die Größe des eigentlichen Graphen vorzugeben (also sicherzustellen, dass z.B. der Abstand zweier Ticks auf einer Achse genau einer bestimmten Anzahl Pixel entspricht).

Nochmal zum Verständnis: Ich habe eine Sammlung von (x,y)-Tupeln, die von x=0.0 bis x=1.0 die Form eines Flügelprofils definieren. Dies möchte ich nun auf Anwendervorgabe skalieren (z.B. Länge des Profils = 25.4 cm = 10 inch) und in eine Bilddatei übertragen (z.B. mit 300 DPI, d.h. es würde sich eine Graphikdatei mit 3000 Pixeln Breite ergeben).

Prinzipiell könnte ich das sicherlich mit PIL lösen, müsste dann aber Dinge wie z.B. die Interpolation zwischen den Stützpunkten meiner Kurve selbst implementieren. Mit Tkinter und/oder Matplotlib muss ich mich um sowas nicht mehr kümmern, da die Kurven automatisch über B-Splines o.ä. interpoliert werden. Dort fehlt mir dann aber der Schritt, um zu einer maßstabsgetreuen Bilddatei zu kommen.

Ich hoffe, dass mein Problem soweit verständlich ist. Noch mehr hoffe ich natürlich, dass es irgendwo schon passende Python-Module gibt, die mir die Arbeit erleichtern. Irgendwelche Ideen?

Gruß
Jan
BlackJack

Slowhand_47: Wenn es ausreicht ein PDF zu erzeugen, wäre ReportLab vielleicht eine Idee. Schau mal im User guide ab Kapitel “2.14 Bezier curves” ob das was für Dich wäre.

Je nachdem wie eigenständig die Software sein soll, könnte man sie vielleicht als Plugin für Inkscape implementieren!?

Oder Du müsstest mal schauen, was die üblichen GUI-Toolkits bieten.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ich persönlich bin ja Fan davon, Sachen in PostScript zu programmieren, das kann man mittels Ghostscript auch nach PDF exportieren. ALternativ würde mir auch TikZ einfallen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

das Problem ist aber IMHO immer der Endanwender, der druckt.

IMHO gibt es kein Programm / keinen Druckdialog mehr, der es _nicht_ anbietet, dass Bild auf Seitengröße (z.B. A4 abzgl. nicht-bedruckbarer Rand) skaliert.

Beim Adobe Reader ist es AFAIK Voreinstellung, dass das PDF auf Papiergröße skaliert wird. Gut, kann man umgehen, indem man das PDF direkt in A4 anlegt und ausreichend Seitenrand berücksichtigt. Scheitert aber schon dann, wenn jemand z.B. US Letter Papier hat.

Gruß, noisefloor
Slowhand_47
User
Beiträge: 4
Registriert: Samstag 14. August 2010, 14:42

PDF als Zwischenformat wäre natürlich auch eine Idee, da sieht Report Lab ja gar nicht mal so schlecht aus. Und dass der Adobe Reader immer per Default auf Seitengröße zoomt, hat sich inzwischen auch unter Modellbauern (potentielle Anwendergruppe) herumgesprochen.

Sieht aber insgesamt so aus als ob ich Bildschirmdarstellung und Export unabhängig voneinander gestalten müsste. Ich hatte ja insgeheim gehofft, dass ich ein GUI-Toolkit oder eine darauf aufbauende Lib finde, die mir einen direkten Export ermöglichen. Ist aber vielleicht sogar vom Design her sinnvoller, wenn man beides gleich getrennt hält.

Gruß
Jan
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

ReportLab ist auch gut. Aber die PDFs haben immer eine Auflösung von 72 DPI - die ist fix.

Gruß, noisefloor
BlackJack

@noisefloor: Du meinst Pixelgrafiken innerhalb des PDFs!? Denn PDF ist ja Vektorgraphik und die hat keine DPI.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

BlackJack hat geschrieben:@noisefloor: Du meinst Pixelgrafiken innerhalb des PDFs!?
Und wenn wäre das dann wohl eine Eigenart von reportlab. Denn bei anderen Tools kann man beliebig hoch aufgelöste Bilder in ein PDF einbinden ;-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

ok, unklar ausgedrückt: ReportLab generiert nur PDFs mit 72 DPI (das pdf-Format an sich kann natürlich auch höhere Auflösungen). Auch wenn man in Reportlab Bilder mit höherer DPI-Zahl einbindet werden diese so skaliert, als hätten sie 72 DPI. Für hochauflösende Sachen (z.B. PDFs mit 300 DPI für die professionelle Druckvorstufe) ist ReportLab also nix.

Gruß, noisefloor
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Slowhand_47 hat geschrieben:Sieht aber insgesamt so aus als ob ich Bildschirmdarstellung und Export unabhängig voneinander gestalten müsste. Ich hatte ja insgeheim gehofft, dass ich ein GUI-Toolkit oder eine darauf aufbauende Lib finde, die mir einen direkten Export ermöglichen. Ist aber vielleicht sogar vom Design her sinnvoller, wenn man beides gleich getrennt hält.
Evtl hast du Glück mit WPF(Windows-.NET), dass du da direkt auf XPS (Microsofts Anti-PDF) zeichnen kannst (kenne mich damit allerdings nicht wirklich aus). Unter OSX ist das ganze ziemlich einfach, aber ich vermute mal das hilft dir beides nicht weiter.
BlackJack

@noisefloor: ReportLabs kann Pixelgrafiken mit beliebigen Auflösungen in PDFs einbetten und in beliebigen Grössen darstellen. Beim Einbetten bleiben die kompletten Pixeldaten erhalten. Man kann also sehr wohl PDFs erstellen, die für hochaufgelöste Drucke geeignet sind.

Wenn man selbst keine Abmessungen für die Bildgrösse angibt, dann werden sie aus den Pixelabmessungen auf Grundlage von 72 DPI berechnet. Egal ob im Bildformat eine Auflösung in DPI hinterlegt ist oder nicht. Da muss man dann halt selbst Abmessungen vorgeben. Entweder basierend auf der absoluten Grösse, die man als Ergebnis haben möchte, oder man rechnet in der Bilddatei vorhandene DPI-Angaben zusammen mit den Pixelausmassen in eine reale Grösse um.
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

@BlackJack: Ah, ok. Gut zu Wissen. :-)

Also ist es 2nur" so, dass der Inhalt, der mit ReportLabs Funktionen selbst (Schrift, grafische Elemente etc.) in 72 DPI ins PDF gebaut werden.

Gruß, noisefloor
BlackJack

@noisefloor: Schrift betrifft das überhaupt nicht und Grafik auch nur bei *Pixelgrafik*.

Ich weiss aus der Art wie Du die Sätze formulierst nicht so recht, ob Du die Problematik so richtig verstanden hast. PDFs selber haben keine "DPI", die sind frei skalierbar. Der Benutzer des PDFs kann frei wählen in welcher DPI-Auflösung das Dokument ge"render"t werden soll.

Das einzige Problem was ReportLab hat, ist dass für die automatische Grösse der *Darstellung* einer Pixelgrafik immer angenommen wird die Grafik hätte 72 DPI. Es werden trotzdem immer alle Pixel 1:1 in das PDF eingebettet. Bei einer Grafik mit zum Beispiel 300 DPI haben sollte, wird die halt etwas mehr als 4× so gross dargestellt als sie nach DPI und Pixeldaten eigentlich sein sollte.
Slowhand_47
User
Beiträge: 4
Registriert: Samstag 14. August 2010, 14:42

Darii hat geschrieben:Evtl hast du Glück mit WPF(Windows-.NET), dass du da direkt auf XPS (Microsofts Anti-PDF) zeichnen kannst (kenne mich damit allerdings nicht wirklich aus). Unter OSX ist das ganze ziemlich einfach, aber ich vermute mal das hilft dir beides nicht weiter.
Nicht wirklich, da ich selbst nur unter Linux unterwegs bin. Wenn das Programm auch unter W32 und/oder OSX läuft: o.k., aber das ist kein Designziel. Für Windows gibt es schon genug Alternativen.

Ich denke, ich werde das Interpolieren der Daten und das Zeichnen auf den Bildschirm bzw. auf Papier wirklich auftrennen. Eine nette Spline-Interpolation kann ja auch SciPy erledigen (oder vielleicht ein anderes leichtgewichtigeres Modul?). Die Ausgabe der feininterpolierten Daten in einen Tkinter-Canvas oder eine Datei per PIL oder ReportLab implementiere ich dann lieber jeweils separat.

Gruß
Jan
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

@BlackJack: Ich bin mir auch nicht sicher, ob wir vom gleichen ReportLab reden. ;-)

Also, im Ernst & ausführlich: Wenn man mit Platypus ein Dokument anlegt oder eine Canvas anlegt, dann hat es eine vordefinierte Größe. Bei A4 Portrait z.B. 595x842. Das entspricht einer Auflösung von 72 DPI. Heißt, man kann innerhalb diese Punkte-Raster Objekte (Text, Grafikelemente etc.) platzieren - aber auch nur mit dieser Genauigkeit. Ob das für ein Flügprofil reicht oder nicht - keine Ahnung.
Beim Drucken kann man dann skalieren, in dem Rahmen, was der Drucker hergibt. Oder, man rendert es in eine anderes Dateiformat.

Gruß, noisefloor
BlackJack

@noisefloor: Das "Raster" entspricht der DTP-Definition von der Masseinheit point (pt) 1 pt = 1/72 inch. Mit dieser Masseinheit arbeitet PDF (von PostScript "geerbt"). Wenn man aber nur Koordinaten in ganzen Point angeben könnte, wäre PDF ziemlich nutzlos. Man kann selbstverständlich alle Koordinaten als Fliesskommazahlen angeben. Du kannst also so genau platzieren, skalieren, usw. wie es Fliesskommazahlen halt hergeben.

`reportlab.lib.units` enthält ein paar Konstanten damit man Grössen und Längen auch in für Normalsterbliche gebräuchlichere Einheiten umrechnen kann. Wenn man zum Beispiel eine Linienstärke mit 0.2 mm angeben möchte liegt das unterhalb der 72 DPI-Auflösung:

Code: Alles auswählen

In [109]: reportlab.lib.units.toLength('0.2 mm')
Out[109]: 0.56692913385826782
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

@BlackJack: Ah, ok. Ich war gedanklich immer nur bei Integern, wenn es um Maße in pt geht. Was natürlich ein blöder Denkfehler von mir war, weil ich bei Maßen in mm oder cm in ReportLab natürlich auch floats benutze.

Gruß, noisefloor
Antworten