XML
Von: Ѕсһоrѕсһ (abgemeldet), 18.6.2007 13:10 Uhr
Servus,

nach der Umstellung von Apache FOP Version 0.20.5 auf Version 0.93 hat Apache für verschiedene Schriften, u. a. für eine Barcodeschriftart MRV Code128M, ein 'Missing metrics-version attribute' angemeckert. Mittels des Befehls (aus Gründen der Lesbarkeit des Beitrags ausnahmsweise auf <pre >-Tag verzichtet)

java -cp jar\fop.jar;jar\avalon-framework.jar;jar\xml-apis.jar; \
jar\xercesImpl.jar;jar\xalan.jar org.apache.fop.fonts.apps.TTFReader \
"mrvcode0.ttf" "mrvcode0.xml"

habe ich die Metrics-Datei neu erstellt. Die aber weist leider einen Fehler auf: Ein damit erzeugter Barcode wird um ca. ein Drittel der Schriftgrösse zu weit nach oben gedruckt. Ich habe bislang zwei Workarounds gefunden, diesen Fehler zu umgehen:

In der erzeugten Metrics-Datei kann ich manuell den Wert für <ascender>3000</ascender> von 3000 auf 4800 hochsetzen. Funktioniert, ist aber nicht eben dokumentationsfreudig. Muss die Metrics-Datei aus irgendeinem Grunde neu erstellt werden, dürften die Kollegen erst einmal sehr lange wie der Ochs vorm fehlgedruckten Dokument stehen, bevor sie irgendwo in den Untiefen der Doku (wer liest sowas eigentlich?) diesen Kniff finden.

Alternativ kann ich die Schrift belassen, wie sie ist und stattdessen bei jeder Verwendung der Schriftart ein margin-top="nnpt" setzen. Dies ist zwar wesentlich dokumentationsfreudiger, aber abgesehen davon, dass ich dann nahezu jedes Template anfassen muss, ist nicht sichergestellt, dass das auch immer funktioniert (insbesondere dann nicht, wenn in einer Zeile diese Barcode- und eine andere Schriftart zusammen verwendet werden).

Sonderlich zukunftssicher sind also beide Workarounds nicht, es wäre sehr dankbar, wenn jemand eine dauerhaftere Lösung wüsste
Schorsch



  1. Antwort von Ѕсһоrѕсһ (abgemeldet) 0
    Mögliche Alternative
    Mittlerweile bin ich von dritter Seite auf die Möglichkeit aufmerksam gemacht worden, statt Barcodes selbst zu erzeugen und den generierten Text in einer Barcode-Schriftart zu drucken, diesen mittels der FOP-Erweiterung Barcode4J http://barcode4j.krysalis.org/1.0/fop-ext.html von FOP selbst erzeugen zu lassen.

    Dies würde allerdings möglicherweise einen gewaltigen (wenn auch einmaligen) Aufwand erfordern. Sicher, die xsl-Sourcen anzupassen ist ein überschaubarer Aufwand, auch die verschiedenen Quellen, die den xml-Code erzeugen, referieren zur Erzeugung der verschiedenen (EAN) Codes 128 letzlich auf eine einzige Bibliotheksfunktion, die ohne Schaden für Drittanwendungen so angepasst werden könnte, dass sie nicht den modifizierten Barcode, sondern den als Parameter übergebenen Text unverändert zurückgeben.

    Aber wenn die Ergebnisse des neuen Verfahrens optisch nicht hundertprozentig (oder wenigstens 98%) deckungsgleich mit den bisherigen Ergebnissen sind, muss ich jedes einzelne kundenspezifische Etikett (und ich habe fast nur kundenspezifische Etiketten) von den Kunden neu zertifizieren lassen. Himmel, mich grausts.

    Ich wäre also nach wie vor sehr dankbar, wenn jemand für meine ursprüngliche Fragestellung eine Lösung wüsste.

    Gruss
    Schorsch