This is the mail archive of the
mailing list for the Cygwin project.
>>> One small problem I noticed (and this may be an upstream one) is that I'm
>>> getting a "Syntax error in: '0x98 #UNDEFINED'" error when viewing a Word97
>>> file with the cp1251.txt mapping. The document then displays ok.
>>> A "grep UNDEFINED *.txt" in usr/share/antiword shows
>>> cp1250.txt:0x81 #UNDEFINED
>>> cp1250.txt:0x83 #UNDEFINED
>>> cp1250.txt:0x88 #UNDEFINED
>>> cp1250.txt:0x90 #UNDEFINED
>>> cp1250.txt:0x98 #UNDEFINED
>>> cp1251.txt:0x98 #UNDEFINED
>>> cp1252.txt:0x81 #UNDEFINED
>>> cp1252.txt:0x8D #UNDEFINED
>>> cp1252.txt:0x8F #UNDEFINED
>>> cp1252.txt:0x90 #UNDEFINED
>>> cp1252.txt:0x9D #UNDEFINED
>>> I think these may need to be substituted by a meaningful character (e.g.,
Undefined is meaningfull. Think of the difference of NULL and '0'
(e.g. in SQL). Why does Word makes use of undefined characters?
Well, if there are these symbols, the program should know it and don't
report an error.
>> Hmm, I thought about upgrading the whole package to Unicode 4.0.
>> Will talk about it to the author.
> Huh? The files are just mappings from different charsets to Unicode.
> Some characters are apparently not defined in some charsets. I don't
> quite see how switching to a newer version of Unicode will allow you to
> define a character *in a particular charset* that you weren't able to
> define with the previous version...
There are no newer versions of the mappings available anyway.
> One advantage of the generic-build-script is that it allows partial
> actions (e.g., "prep", then "conf", then "make", and you're ready to
>> And I decided to upgrade to the OSFA for the next release.
> BTW, in your script, you could use "ln -fs" instead of "rm -f ...; ln -s".
Yes, I see, thanks,