| Subject: | RTF::HTML::Converter kudos + fixes |
| Date: | Fri, 15 Dec 2006 21:50:13 -0600 |
| To: | bug-RTF-Parser [...] rt.cpan.org |
| From: | Cynbe ru Taren <cynbe [...] muq.org> |
FWIW, converting a Nisus RTF file, we found we
needed to make a few additions to the tables:
Charsets.pm
# I added the following entries to all three
# of the tables %ansi %mac %pc
# since I didn't know which was/were the most
# relevant:
aafterfl 61
cafterfi 63
eafterfi 65
nafterfi 6e
oafterfl 6f
rafterfi 72
uafterfi 75
char_map
# Here I added the matching entries:
aafterfl a
cafterfi c
eafterfi e
nafterfi n
rafterfi r
oafterfl o
uafterfi u
(Without the above, the output HTML file wound up being
littered with '61' '65' etc, which is most unsightly.)
It seems highly probable that the actual
standard, where-ever it is, in fact defines
a complete alphabetic sequence:
aafterfl 61
bafterfi 62
cafterfi 63
dafterfi 64
eafterfi 65
fafterfi 66
gafterfi 67
hafterfi 68
iafterfi 69
jafterfi 6a
kafterfi 6b
lafterfi 6c
mafterfi 6d
nafterfi 6e
oafterfl 6f
pafterfl 70
qafterfl 71
rafterfi 72
safterfi 73
tafterfi 74
uafterfi 75
vafterfi 76
wafterfi 77
xafterfi 78
yafterfi 79
zafterfi 7a
Or at the least, it is a curious coincidence that the
ones empirically derived above fit perfectly into the
above guesswork sequence. :) Presumably they are
supposed to be kerned somewhat differently due to
appearing immediately after a ligature.
There may be an issue with treatment of tabs, too,
I haven't looked at that in detail yet.
Life is Good!
-- Cynbe