write_image.json
Die JSON-Datei des Beispiels „Bilder auf einer Seite“. Ein Foto, das genau so hineingeht, wie es aus der Kamera kam, und eines mit durchsichtigen Teilen, das sie behält, jedes auf einer Seite in seiner eigenen Größe.
Diese Datei ist eine Anfrage: Eine Anwendung sendet sie über das Netz an den Server, der das PDF erzeugt und zurücksendet. Sie erzeugt dieselbe Seite wie die Rust- und die Python-Fassung dieses Beispiels. Eine Anfrage nennt jede Datei, die sie verwendet, nie ihren Inhalt; der Aufruf trägt die Anfrage und die Dateien zusammen. Eine Schrift, die der Server bereits vorhält, etwa DejaVuSans, wird ohne Anhang genannt. Senden Sie die Anfrage an die Adresse, die die API-Seite angibt.
Diese Anfrage nennt Dateien, die sie nicht trägt: logo.png, photo.jpg. Jede davon reist neben der Anfrage, im selben Aufruf, als mitgelieferter Teil, genau so benannt, wie die Anfrage sie hier nennt — die Beschreibung sagt, welcher Name welche Rolle spielt, Sie benennen Ihre Dateien also, wie Sie möchten. Eine Anfrage, die eine Datei nennt, von der der Aufruf nichts trägt, wird abgelehnt.
Wofür dieses Beispiel da ist
Ein Foto, das einmal komprimiert und dann von dem, was es ins Dokument gesetzt hat, ein zweites Mal komprimiert wurde, kommt weich heraus, fleckig an den Kanten und schwerer als das Original. Das ist die häufigste Art, wie ein gutes Bild zwischen Kamera und Drucker verdorben wird, und nichts in der fertigen Datei verrät, dass es geschehen ist.
Was dieses Beispiel zeigt
- Ein unverändert durchgereichtes Foto, nie ein zweites Mal komprimiert.
- Ein Bild, dessen durchsichtige Teile noch durchsichtig sind.
- Eine Seite, auf die Größe des Bildes zugeschnitten, damit nichts skaliert wird.