[CC] Userabhängiger Zeichensalat

Ich habe bei einem Kundensystem mit sehr variablen Umgebungen (im Einsatz sind u.a. Notebookclients, Clients mit Citrix Virtual Desktop, Citrix Published Applications, W10, W7,…) ein userabhängiges Zeichenkonvertierungsproblem.
Es handelt sich um Sonderzeichen, die alle in Codepage 850 bzw. 1252 vorhanden und auch korrekt in der Datenbank enthalten sind.
Bei den meisten Usern (so auch bei mir , reproduzieren kann ich das selber nicht) kommen die Zeichen auch korrekt im Ausdruck in die PDFs.

Bei einigen wenigen Usern kommt es aber stellenweise zu falschen Zeichen im Ausdruck, die sich aber mit den üblichen Codepageeinstellungen nicht erklären lassen.
Codepage 850 und 1252 sind ja beide für Westeuropa gedacht, in 1252 fehlen aber etliche Rahmenzeichen, die in der DOS-Ära noch gebraucht wurden.
Das Eurozeichen € wird z.B. bei den betroffenen Usern in das Rahmenzeichen ┴ umgewandelt.
Box Drawing Code 193

Die Probleme sehen auch eher nach einem Konflikt mit Codepage 437 aus.
Richtige Zeichen auch bei den betroffenen Usern (Quellzeichen in Codepage 1252, 850 und 437 enthalten):

• ç Ausdruck korrekt
• é Ausdruck korrekt

Falsche Zeichen

(Quellzeichen in Codepage 1252 bzw. 850, aber nicht in 437 enthalten):

• ã Ausdruck —
• õ Ausdruck Ì
• € Ausdruck ┴ (Rahmenzeichen)
  (Quellzeichen nur in Codepage 1252 enthalten):
• “ Ausdruck š (öffnendes Anführungszeichen (Alt-Code 0147), nicht das einfache " (Alt-Code 034))
• ” Ausdruck › (schließendes Anführungszeichen (Alt-Code 0148), nicht das einfache " (Alt-Code 034))

Hat jemand diesen Effekt schon einmal gesehen? Selber konfigurieren kann ich diese Umgebungen nicht, aber es wäre sehr hilfreich, wenn ich der dortigen IT Hinweise geben könnte, woran es liegen könnte.

Hallo,

eine immer wieder gerne genommene Ursache sind Datenimporte oder kopieren aus Excel (oder woanders her). Insbesondere wenn es ein "gewachsenes" System aus älteren Versionen ist kommt das gerne vor.

Wenn dann bei der Umstellung von Native auf SQL nicht aufgeräumt wurde, oder gar jemand direkt per SQL-Server- Import Daten mir der falschen Codepage ins System eingelesen hat, kann alles mögliche passieren.

Übrigens enthält Codepage 850 kein €- Zeichen. Dafür brauchst du Codepage 858

Ich gehe davon aus, aber sicherheitshalber solltest du auf den unterschiedlichen Systemen immer mit den gleichen Daten/belegen testen.
Dann gab es in der Druckereinrichtung des CC noch die Möglichkeit Fonts zu mappen. D.h. aus dem Helvetica von NAV konntest du etwas machen, dass u.U. die Codepage nicht richtig unterstützt.

Ich weiß nicht wo er das abgespeichert hat, aber evtl. mal mit einem neuen Benutzer (neue ZUP- Datei) testen, ob da das Problem auch auftritt.

Aber es gibt da noch diverse andere Möglichkeiten, warum Codepages nicht richtig gemappt werden.

Gruß Fiddi

Übrigens enthält Codepage 850 kein €- Zeichen. Dafür brauchst du Codepage 858

Das stimmt, es gibt allerdings auch Varianten von Codepage 850 mit €-Zeichen wie IBM PC DOS 2000, aber das ist ein anderes Thema . Das €-Zeichen wird hier nicht gar nicht importiert, sondern wurde ganz normal im Client in die Ländertabelle in ein neues Feld eingegeben.

Die üblichen Fehler beim Zusammentragen von Übersetzungen sind alle vorhanden gewesen, aber das habe ich bereinigt. Es liegen auch keine Normalierungsfehler vor. Das kann z.B. passieren wenn man Texte aus Word-Docs direkt in C/SIDE eingibt.

Normalierungsfehler.png

In diesem Fall sind es auch Captions im Report, also keine Feldinhalte (die Tabellenfelder zeigen bei den betroffenen Usern aber das gleiche Verhalten). In C/SIDE sind alle Sonderzeichen korrekt dargestellt und bei den meisten Usern auch bei der Ausgabe.
Es gibt nur eine Datenbank (native, kein SQL) für alle, eine Tabelle und einen Report für alle und innerhalb von NAV keinerlei userspezifische Konvertierung. Trotzdem erhält User A u.U. eine andere Ausgabe als User B. Die betroffenen Personen sitzen auch nicht in Zentral- bzw. Osteuropa, wo andere Codepages im Einsatz sind.

Weitere Fehlzeichen sind (nur in CP 1252 enthalten):

• “ Ausdruck š (öffnendes Anführungszeichen (Alt-Code 0147), nicht das einfache " (Alt-Code 034))
• ” Ausdruck › (schließendes Anführungszeichen (Alt-Code 0148), nicht das einfache " (Alt-Code 034))

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hast du bereits den Drucker und das System ausgeschlossen? Drucken also alle auf dem selben Drucker und wandert das Problem, wenn Benutzer von einer anderen Maschine aus drucken?

Hast du bereits den Drucker und das System ausgeschlossen?

Nein, das ist mittlerweile auch mein größter Verdacht . Im Einsatz sind dort zwei Versionen vom PDFCreator. Innerhalb von NAV wird dann anhand der vorhandenen Installation entschieden, welcher angesteuert wird. Wenn die betroffenen Personen alle auf den alte Version geleitet werden und dort ein falsche Codepage eingestellt ist, wäre das eine Erklärung.

Im Einsatz sind dort zwei Versionen vom PDFCreator.

"Leider" setzt eine der betroffenen Personen die gleiche Version ein wie ich (2.3, die nutzen auch andere User dort erfolgreich), daran scheint es also nicht zu liegen. Der PDFCreator hat zwar bei den Ghostscriptparametern einige Textformateinstellungen, aber nichts, um so etwas zu erklären.

PDFCreatorGhostscript.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.