Beim Export nach PDF wird das Datumsformat auf 10/07/23 eingestellt. Wie bekomme ich 10.07.23

Ich entwerfe mit Writer Pdf Formulare zum Ausfüllen. Das Standardformat für Datum ist dd.mm.yyyy. Man sieht dies auf dem Bild bei Min.Datum (01.01.2020). Im Dropdown Datumsformat kann ich Standard einstellen (hier nicht gezeigt), aber es findet sich kein benutzerdefiniertes Format mit Punkten.

Wenn ich “Standard” habe, wird das Datum bei direkter Eingabe mit Punkten dargestellt. Beim Export nach PDF wird aber offensichtlich das Format falsch übernommen, denn dort ist es immer

wenn vom Dropdown eingefüllt. Mit PDF Analyzer sieht man auch, dass mit Javascript für dieses Feld “dd/mm/yy” verwendet wird AFDate_FormatEx("dd/mm/yy"). Mit einem PDF-Editor direkt im PDF das Format ändern, aber das wird mühsam.

Frage:

Was macht ein Kunde, der nur Writer hat und im PDF deutsches Datumsformat haben will?

Denkbare Notlösung

Ich lasse ein itext-basiertes Programm drüberlaufen, das FormatEx ändert. Ist aber ein Hack.

Mit welcher LO-Version arbeitest Du?

Ich habe einmal mit LO 7.5.5.2 nachgeschaut.
Bei mir stehen da verschiedene Standardeinträge. Und die richten sich nach dem Gebietsschema in den Spracheinstellungen.

Bei einem PDF-Formular wirst Du mit einem speziellen Aufklappfeld wie in Deiner Konstruktion kein Glück haben. PDF-Formulare werden nur mit

  • Schaltfläche
  • Textfeld
  • Markierfeld
  • Optionsfeld
  • Kombinationsfeld
  • Listenfeld
    exportiert. Formatierungen sind da also gar nicht möglich. Aus einem Datumsfeld wird schlicht ein Textfeld. Teste also auch zwischendurch einmal, was denn da überhaupt über kommt.

Ich kann hier jedenfalls in so ein erstelltes Datumsfeld alles möglich eingeben - auch beliebigen Text.

Extras>Optionen>Spracheinstellungen>Sprachen>Gebietsschema: Deutsch(Deutschland) und die Eigenschaften des Datumsfeldes zeigen TT.MM.JJJJ. Ob das irgendwelche Auswirkungen hat weiß ich nicht. Mit meinen PDF-Viewern kann ich beliebiegen Text in ein Datumsfeld eingeben.
Davon mal abgesehen, stört sich wohl niemand am Englischen Format solange es nicht US-Amerikanisch ist.

Mit meinen PDF-Viewern kann ich beliebiegen Text in ein Datumsfeld eingeben.

Das hatte sich schon durch Robert geklärt: es hängt vom Reader ab. Ich bezog mich auf Adobe Reader, der immer noch die Referenzgröße ist und vom Kunden vorgeschrieben.

Davon mal abgesehen, stört sich wohl niemand am Englischen Format solange es nicht US-Amerikanisch ist.

Das ist falsch. Bei Projekten im Sicherheitsbereich (bei mir Medizin, aber auch Flug etc., Verkehr) ist das Datumsformat genau vorgeschrieben, um das sichere Lesen zu gewährleisten.

Im Flugverkehr und in der Medizin gilt das deutsche Datumsformat? Ich hätte zumindest für den Flugverkehr den ISO-Standard erwartet.

“ist (das Datumsformat) vorgeschrieben”. Ich gebe zu, dass ich nur von Medizin eine Ahnung habe.

Das ist sehr schön. Was ich mich in dem Zusammenhang schon lange frage ist: Stellt Acrobat die von LibreOffice erzeugten Forularelemente als typisierte Elemente dar? Also zeigt das Prigramm formatierte Datums- Zeit und Währungsfelder an und (noch wichtiger) weist Acrobat ungültige Eingaben zurück?
Mir kommt ein PDF-“Betrachter”, der fast so fett ist wie diese ganze Office-Suite nicht auf die Platte (auch nicht in der Arztpraxis meiner Frau).

Es sind immer Textfelder, die aber von Libreoffice Javascript mitbekommen. Siehe Beispiel unten. Was ein reader (generic) damit macht, ist seine Sache. Dass diese Weitergeben einen Bug hat - den ich inzwischen umschifft habe - war der Sinn dieses Threads.

Der Haken ist, dass in sicherheitskritischen Umgebungen es durchaus richtig sein kann, Javascript nicht zu befolgen. Deshalb ist das Fehlen von Validierungen ohne Javascript eine Schwäche von PDF.

1 Like

… und selbst die eingebaute Version zum Lesen der PDF-Dateien in Firefox überprüft mit den exportierten Feldern ja das Datumsfeld auf Korrektheit (leider eben nicht im entsprechenden Format) und auch das Zahlenfeld bei Dezimalzahlen mit eingestellten Nachkommastellen (nur leider mit dem Punkt als Dezimaltrenner).

Es macht also einen Unterschied, ob eben Datumsfeld und Zahlenfeld oder ein Textfeld benutzt wird. Das fomatierbare Feld hingegen wird wie ein Textfeld exportiert.

Es ist zwar richtig, dass Datum immer Textfelder sind, aber PDF kennt Datumsfelder am Javascript. Jetzt kann ich das Bild eingeben, vorher ging das nicht, da neu hier.
Winking.PdfAnalyzer_rirUUaCCXL

Das geht in LibreOffice, wird auch exportiert, aber mit dem falschen Format. Dann klappt im PDF ein Kalender runter. Funktioniert, aber leider ist das von Writer exportierte Javascript-Objekt mit dem falschen Format versehen. Ich halte das für einen Bug beim Export nach PDF. Das Fehlen von Punkt-Formaten ist schon mal in einem anderen Thread gemeldet worden.

Ich kann hier jedenfalls in so ein erstelltes Datumsfeld alles möglich eingeben - auch beliebigen Text.

Dann wurde das Feld nicht als Datum markiert. Ähnliches gilt für Zahlenfelder.

Wenn ich das erzeugte Formular in PDF Studio (entspricht Vollversion Acrobat) öffne, sehe ich, dass ein benutzerdefiniertes Format dd/mm/yy eingestellt ist. Das kann ich nachträglich ändern, aber es ist nicht so geschickt, dass LibreOffice das so verkorkts.

pdfstudio2023_kuRILaQgVD

Ich habe das jetzt einmal mit Firefox statt Okular (unter Linux) probiert. Ist richtig: Firefox zeigt da zwar kein Aufklappfeld, aber zeigt den Fehler beim Format. Unter Okular ist das völlig wurscht, weil da eben nur das Textfeld gesehen wird.

Wusste gar nicht, dass da LibreOffice irgendetwas in Richtung JavaScript mit exportiert.

Ich habe das jetzt auch mit FoxitReader als Aufklappbar gesehen. Das Ganze würde ich als Bug für das Datumsfeld melden. innerhalb von LibreOffice selbst funktioniert das ja, aber beim Export wird die Einstellung “Standard” nicht korrekt ausgelesen.
Weiterer Hinweis: Das gilt für mich übrigens genauso bei numerischen Feldern, die die Eingabe von Dezimalzahlen nur mit dem Punkt ermöglichen, sehr wohl aber die Anzahl an Nachkommastellen für entsprechende Reader mit exportieren.

@dmenne : Den Bug habe ich gemeldet: Bug 156272. Vielleicht kannst Du das kurz bestätigen.

Done. Hoffentlich richtig. Wir verwenden seit Jahren kein Bugzilla mehr, bin etwas außer Übung.

Interessanter Versuch — Chrome erlaubt keinen Unsinn, aber alle möglichen Datenformate (etwas 20.01.49), und wandelt die dann in die / Darstellung um. Kurioserweise akzeptiert es 20.01.1949, schreibt aber 20.01.19, was Unsinn ist.

Okular ist bei mir mit Formularen unbrauchbar. Was durchaus Sinn machen würde im Sinne der Schlankheit, aber dann sollen sie die Anzeige ganz unterbinden.

@dmenne,

Schreib doch noch eine Lösung, die keine Lösung ist.

Dies ist die Anleitung - Wie benutze ich die Ask Seite?

Ich habe gerade mal Brute-Force alle dd/mm/yy durch dd.mm.yy ersetzt, mit NotePad++. Da ich das Formular sowieso zum Teil mit einem C# Programm bearbeite (mit itext), geht das vorläufig.

Keine Lösung, ein Hack. Irgendwann werde ich das mal mit itext hinkriegen, da ist die Dokumentation von version 8 noch dürftig.

Wenn jemand die itext-Funktionen dafür findet, bin ich aber dankbar.

Diese Brutalo-Method scheint auch itext zu verfolgen:

https://kb.itextpdf.com/home/it7kb/examples/replacing-pdf-objects

Falls es jemand interessiert: Hier das Workaround. Hässlich, geht aber.

    static bool ReplaceBinary(ref byte[] fileBytes, byte[] oldBytes, byte[] newBytes)
    {
      int index = IndexOfBytes(fileBytes, oldBytes);
      if (index < 0)
      {
        // Text was not found
        return false;
      }

      byte[] newFileBytes =
          new byte[fileBytes.Length + newBytes.Length - oldBytes.Length];

      Buffer.BlockCopy(fileBytes, 0, newFileBytes, 0, index);
      Buffer.BlockCopy(newBytes, 0, newFileBytes, index, newBytes.Length);
      Buffer.BlockCopy(fileBytes, index + oldBytes.Length,
          newFileBytes, index + newBytes.Length,
          fileBytes.Length - index - oldBytes.Length);
      fileBytes = new byte[newFileBytes.Length];
      Buffer.BlockCopy(newFileBytes, 0, fileBytes, 0, newFileBytes.Length);
      return true;
    }
    static int ReplaceTextInFile(string pdfFileName,  string tempFileName, 
      string oldText, string newText)
    {
      byte[] fileBytes = File.ReadAllBytes(pdfFileName),
      // https://stackoverflow.com/questions/28062565/how-can-i-replace-a-unicode-string-in-a-binary-file
          oldBytes = Encoding.UTF8.GetBytes(oldText),
          newBytes = Encoding.UTF8.GetBytes(newText);
      int replaceCount = 0;
      while (ReplaceBinary(ref fileBytes, oldBytes, newBytes)) {
        replaceCount++;
      };
      Trace.WriteLine("Replace date formats replaced " +replaceCount + " repeats");
      if (replaceCount!= 0)
        File.WriteAllBytes(tempFileName, fileBytes);      
      return replaceCount;
    }


    static int IndexOfBytes(byte[] searchBuffer, byte[] bytesToFind)
    {
      for (int i = 0; i < searchBuffer.Length - bytesToFind.Length; i++)
      {
        bool success = true;
        for (int j = 0; j < bytesToFind.Length; j++)
        {
          if (searchBuffer[i + j] != bytesToFind[j])
          {
            success = false;
            break;
          }
        }
        if (success)
        {
          return i;
        }
      }
      return -1;
    }

    private void ReplaceDateFormats(string src)
    {
      // Brute force method to get around a bug in LibreOffice
      string dest = Path.GetTempFileName();
      // Check if replace yyyy is also required
      if (ReplaceTextInFile(src, dest, "dd/mm/yy", "dd.mm.yyyy") > 0)
        File.Move(dest, src, true);
    }
  }