Problem Umlaute/RTF/Mac

[TigerLilly]

Mein Programm erzeugt ein RTF Dokument. Dazu wird mit Word eine Vorlage von mir erzeugt, als RTF abgespeichert + die Software füllt dann Daten ein.
Der Benutzer öffnet dann das RTF mit dem Programm seiner Wahl - meist MS Word.

So weit so gut.

Jetzt habe ich einen User in der Schweiz, der die Software auf einem Mac mit Parallels einsetzt. Das von meiner Software erzeugte RTF wird dem Mac-Word geöffnet. Auch das funktioniert normalerweise ohne Probleme, aber hier gibt es Probleme mit den Umlauten - die werden nicht korrekt erkannt.

Ich denke, das hat wohl etwas mit dem Zeichensatz zu tun. Die RTF beginnen alle mit
{\rtf1\adeflang1025\ansi\ansicpg1252\uc1\
eingeleitet.
Umlaute im RTF sind so abgebildet:
ges\'e4ttigte Fetts\'e4uren

Wer kann mir weiterhelfen? Danke!

[nahpets]

Kennt der Mac die angegebene Codepage aus: {\rtf1\adeflang1025\ansi\ansicpg1252\uc1\

Das müsste Microsoft Windows Codepage 1252 (ANSI) sein.

Schau mal bitte hier http://www.aivosto.com/vbtips/charsets-codepages.html, ob eine Alternative zu finden ist.

Eventuell den Zeichensatz auf UTF-8 wechseln?

[TigerLilly]

Ja, das ist die Windows Codepage.

Wie überprüfe ich, ob der Mac die CP kennt? Und wenn nicht, wie bringe ich sie ihm bei?

Ich wüsste nicht, wie ich auf UTF-8 wechseln sollte, wenn ich mit Word ein neues RTF Dokument erzeuge, wird genau dieser Header erzeugt.

[nahpets]

Lass Dir mal auf dem Mac mit dessen Word ein RTF-Dokument erstellen (mit allen Umlauten) und schau, ob Du da Unterschiede finden kannst.

Wenn ja, müsstest Du schauen, ob Du da "irgendwie flexibel" drauf reagieren kannst.

Ein Ansatz: http://www.aboutvb.de/bas/formate/pdf/rtf.pdf
Dort Tabellen 10.2 und 10.2a

Aus

Code:

{\rtf1\adeflang1025\ansi\ansicpg1252\uc1\

müsste (vermutlich) sowas in der Art werden:

Code:

{\rtf1\adeflang1025\mac\HierHabIchKeineInfoFindenKönnenFürDieCodepage\uc1\

[mjustin]

Hallo!
Könntest Du eine RTF Datei und einen Screenshot des auf dem Mac dargestellten Dokuments hier hochladen? Ich arbeite sehr viel mit RTF Konvertierungen.

Für die Konvertierung ist entscheident, welche Codepage dem RTF Text zugewiesen wird - die Codepage steht im RTF Header in der fonttable. Daher brauchtman zur Fehlersuche möglichst ein komplettes, kleines RTF Dokument.

[p80286]

Ich hab da mal was kopiert:

Zitat:

Character Set
After specifying the RTF version, you must declare the default character set used in the document unless it is \ansi (the default). The control word for the character set must precede any plain text or any table control words. The RTF Specification supports the following document character sets <character set>
<character set> (\ansi | \mac | \pc | \pca)? \ansicpgN?

where the control words are defined by
Control word Character set
\ansi ANSI (the default)
\mac Apple Macintosh
\pc IBM PC code page 437
\pca IBM PC code page 850, used by IBM Personal System/2 (not implemented in version 1 of Microsoft Word for OS/2)
\ansicpgN This keyword represents the default ANSI code page used to perform the Unicode to ANSI conversion when writing RTF text. N represents the code page in decimal. This is typically set to the default ANSI code page of the run-time environment (for example, \ansicpg1252 for U.S. Windows). The reader can use the same ANSI code page to convert ANSI text back to Unicode. If it appears, this keyword should be emitted in the RTF header section right after the \ansi, \mac, \pc or \pca keyword. Possible values include those in the following table.
\fbidis Flag written by RichEdit to indicate a single font is active instead of a set of associated fonts.


Code page Name
437 United States IBM
708 Arabic (ASMO 708)
709 Arabic (ASMO 449+, BCON V4)
710 Arabic (transparent Arabic)
711 Arabic (Nafitha Enhanced)
720 Arabic (transparent ASMO)
819 Windows 3.1 (United States and Western Europe)
850 IBM multilingual
852 Eastern European
860 Portuguese
862 Hebrew
863 French Canadian
864 Arabic
865 Norwegian
866 Soviet Union
874 Thai
932 Japanese
936 Simplified Chinese
949 Korean
950 Traditional Chinese
1250 Eastern European
1251 Cyrillic
1252 Western European
1253 Greek
1254 Turkish
1255 Hebrew
1256 Arabic
1257 Baltic
1258 Vietnamese
1361 Johab
10000 MAC Roman
10001 MAC Japan
10004 MAC Arabic
10005 MAC Hebrew
10006 MAC Greek
10007 MAC Cyrillic
10029 MAC Latin2
10081 MAC Turkish
57002 Devanagari
57003 Bengali
57004 Tamil
57005 Telugu
57006 Assamese
57007 Oriya
57008 Kannada
57009 Malayalam
57010 Gujarati
57011 Punjabi

Note that runs of text marked with a particular font index (see \fN in the Font Table section) use the codepage for that font as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF described in the following section.

Und hier findest Du das vollständige Dokument.

Gruß
K-H

[mjustin]

Zitat von TigerLilly:

{\rtf1\adeflang1025\ansi\ansicpg1252\uc1\

Sieht nach einem Microsoft Word 2000 oder neuer Dokument aus, der Header ist ok:

\adeflang1025 = Sprache des Dokuments ist Saudi-Arabisch ("Default language ID for South Asian/Middle Eastern text in Word")
\ansicpg1252 = Windows Code Page 1252 (Westeuropa) als Default für ANSI-Unicode Konvertierung

Dies sind nur die Defaults. Da jeder im Dokument verwendete Font eine anderes Charset (Codepage) angeben kann, ist der Ausschnitt für eine Diagnose zu kurz

[TigerLilly]

Danke für die vielen Tipps. Ich habe eine der RTF-Dateien hochgeladen + einen Screenshot, der (leider unvollständig) zeigt, was das Problem ist.
Die erste Zeile oben soll lauten ... Sie einen Überblick über Ihre Nährstoffversorgung
Der Test findet sich im RTF nicht, weil der von der Software an Stelle von \frtf(tb(’SI-INTRO’))\ eingefügt wird.

Das gekennzeichnete "Ö" ist im Orginal ein "…" - das ist ein einzelnes Zeichen - im RTF \'85

Danke nochmal!

[mjustin]

Zitat von TigerLilly:

Danke für die vielen Tipps. Ich habe eine der RTF-Dateien hochgeladen + einen Screenshot, der (leider unvollständig) zeigt, was das Problem ist.

Auf den ersten Blick sieht der Code zwar ok aus, allerdings ist er mit einer relativ alten Version der RichEdit DLL erstellt worden - anhand der Information im Header "generator Msftedit 5.41.15.1515" kann man annehmen, dass es eine Version zwischen XP und Office 2003 ist, die den RTF Code erzeugt hat.

(Quelle: https://forum.lazarus.freepascal.org...topic=34477.30)

v5.30.23.1230 (included with Windows XP)
v5.31.23.1229 (included with Windows 7)
v5.40.11.2210 (installed with Office XP)
v5.50.99.2050 (installed with Office 2003)
v12.0.4518.1014 (installed with Office 2007)
v14.0.4750.1000 (installed with Office 2010)
v15.0.4420.1017 (installed with Office 2013)
v16.0.6925.1014 (installed with Office 2016)

Es ist möglicherweise so, dass die Mac-Anwendung nur RTF Dateien die von neueren RichEdit Versionen erzeugt wurden korrekt wiedergeben kann.
Wäre es möglich, die Delphi-Anwendung mit einer neueren RichEdit Version zu testen?

Ich nehme an, die Delphi-Anwendung läuft nicht unter MacOS sondern unter Windows, und verwendet daher die unter Windows vorhandene RichEd20.dll?

[TigerLilly]

Hmm. Die RTFs werden auf dem PC mit Word erzeugt - Office 2003. Ich kann mal versuchen, die RTF Vorlagen mit neueren Word Version zu öffnen+zu speichern.

ABER: Üblicherweise funktioniert das ja, also alle anderen Macs, bei denen der Ablauf derselbe ist, stellen die Umlaute richtig dar.

Ich vermute, es hat etwas mit der Schweiz zu tun