Incorrect assignment of \fcharset128 to ANSI 1252 font
Posted: Wed Aug 06, 2008 12:32 am
I don't know where to direct/post this problem/bug report. It is pretty technical in nature.
We make fonts for a living. We also have small application programs (LinkLetter and UndoLinkLetter) that read and write \rtf flavor to and from the ClipBoard/Pasteboard. These apps work perfectly with Word (97, 98, 2000, 2003, 2007, X, 2004, and 2008), Pages ('06 and '08), WordPad, TextEdit, InDesign, and more. However, our apps do not work correctly with Open Office 2 or 3 on either Windows or Mac. We would like to make them work right with OO.
The problem that we are encountering is that in LinkLetter, we look only for our own fonts to manipulate, and since they are encoded either Mac Roman (\fcharset77) or ANSI 1252 (\fcharset0), that is how we expect characters in them to be present on the ClipBoard, either in Unicode or in \'xx format.
In OO 2 and 3, fonts that have been encoded as Mac Roman or ANSI 1252 should have \mac or \ansi1252, or \fcharset0 or \fcharset77as their descriptors in RTF put on the Clipboard. Instead, OO is describing these fonts (500+ of them) as \fcharset128, which is Japanese! We have no idea why OO is ignoring the font encoding and unilaterally forcing us to learn to read and speak Japanese. If that will even work.
Here is the Clipboard .rtf from OO 3 Mac Beta. Note the font description of "All 256 Characters":
{\rtf1\ansi\deff0\adeflang1025
{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\fnil\fprq2\fcharset128 All 256 Characters;}{\f2\fnil\fprq2\fcharset0 Tahoma;}}
\fcharset128 is Japanese encoding. Since the font is encoded as Mac Roman, and all other word processors work correctly with it, the problem is in OO and its generation of RTF.
In OO 1.5, the RTF generation worked fine. Now it doesn't. This isn't an enhancement request so much as a bug report -- it used to work and now doesn't.
Is there anything we can do to facilitate a fix?
Thanks.
We make fonts for a living. We also have small application programs (LinkLetter and UndoLinkLetter) that read and write \rtf flavor to and from the ClipBoard/Pasteboard. These apps work perfectly with Word (97, 98, 2000, 2003, 2007, X, 2004, and 2008), Pages ('06 and '08), WordPad, TextEdit, InDesign, and more. However, our apps do not work correctly with Open Office 2 or 3 on either Windows or Mac. We would like to make them work right with OO.
The problem that we are encountering is that in LinkLetter, we look only for our own fonts to manipulate, and since they are encoded either Mac Roman (\fcharset77) or ANSI 1252 (\fcharset0), that is how we expect characters in them to be present on the ClipBoard, either in Unicode or in \'xx format.
In OO 2 and 3, fonts that have been encoded as Mac Roman or ANSI 1252 should have \mac or \ansi1252, or \fcharset0 or \fcharset77as their descriptors in RTF put on the Clipboard. Instead, OO is describing these fonts (500+ of them) as \fcharset128, which is Japanese! We have no idea why OO is ignoring the font encoding and unilaterally forcing us to learn to read and speak Japanese. If that will even work.
Here is the Clipboard .rtf from OO 3 Mac Beta. Note the font description of "All 256 Characters":
{\rtf1\ansi\deff0\adeflang1025
{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\fnil\fprq2\fcharset128 All 256 Characters;}{\f2\fnil\fprq2\fcharset0 Tahoma;}}
\fcharset128 is Japanese encoding. Since the font is encoded as Mac Roman, and all other word processors work correctly with it, the problem is in OO and its generation of RTF.
In OO 1.5, the RTF generation worked fine. Now it doesn't. This isn't an enhancement request so much as a bug report -- it used to work and now doesn't.
Is there anything we can do to facilitate a fix?
Thanks.