I've fixed it locally but not checked it in because its wound up in some
other changes that I'm not quite done with. I will get it checked in today.
I'm working on the two way transcoding, and I think I'll have enough to
check in a first whack at that today. It won't be necessarily fully baked,
but it will be enough that I need to do an initial check in.
Just for everyone's reading pleasure, here is what I've done so far:
1) XMLTranscoder::transcodeXML() became XMLTransdoder::transcodeFrom()
2) Added a new XMLTranscoder::transcodeTo()
3) transcodeTo() has an option that says that a char cannot be represented
then either use the replacement char or throw an exception
4) Added a new XMLTranscoder::canTranscodeTo(), which checks a single XMLCh
for transcodability into the encoding. This will be used in the later
higher level output writer functionality.
5) Created a new XML256TableTranscoder which is now the base class for the
1252, IBM1140, and IBM-37 intrinsic transcoders. Since all of those are 8
bit, since byte, table driven transcoders, they all have the same logic.
Now, all those derived classes do are provide their particular in/out
tables to the new base class, so they are now trivial and code is reduced.
6) Created a new tool program called ICUData which will take an ICU UCM
file as input and spit out the in/out tables for a 8b/SB type transcoder.
Others might be added later. This way we get rid of the hacky and redundant
conditional code currently used to spit these tables out and can easily
update our intrinsics to track ICU if changes are made.
7) Implemented the transcodeTo() in all of the intrinsic transcoders, and
made initial hacks at the Win32 and ICU transcoders. The IConv one will be
done after the fact.
8) Fixed the Win32 transcoder as per the topic of the message I'm replying
to so that if the CharSet registry key is not present, the transcoder will
be ok with that and will just not support any named encodings.
9) Updated the XMLReader code to match the transcoder changes
10) Improved somewhat the performance of the intrinsic encoders.
So anyway, I'll put this back later today. Then next week I'll initial work
on making sure the output transcoding actually works correctly. Then I'm
move up to the next step of a standard output formatting utility class that
does the simple grunt work of taking a string and some options and give
back a string formatted to the desired encoding and options.
For SAX and internal event programs, probably the little helper formatter
utility class will be sufficient for simple output requirements. Then,
after some more discussion, I'm move on to a generic output formatter for
DOM and perhaps looking at a more elaborate streaming architecture.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Jeff Lewis <[EMAIL PROTECTED]> on 03/17/2000 07:41:48 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Win32TransService and IE4.0
Did anyone ever get a chance to look at this?
I have been checking the files in CVS for any changes,
but haven't yet seen anything in util\transcoders\win32.
Thanks,
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 14, 2000 11:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Win32TransService and IE4.0
Hmmm... This was why I was worried about incorporating this stuff because I
didn't understand fully what the issues were with different Win32 systems.
We can certainly make it gracefully handle an empty or non-present registry
entry for the MIME stuff, in which case it will fall back to not supporting
anything but LCP and intrinsic encodings. I'll do that today as a first
step. That will make it able to use what's there but not freak out if its
not there.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Jeff Lewis <[EMAIL PROTECTED]> on 03/13/2000 11:13:16 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Win32TransService and IE4.0
We just tried to move a production application from one of our development
machines to a server. When doing so, we bumped into a little problem with
the Win32TransService. It seems that it looks into:
\\HKEY_CLASSES_ROOT\MIME\Database\Charset
Which is perfectly happy and full of all sorts of useful information on a
machine with IE 5.0 installed, but the problem appears when trying to use
Xerces with this transcoder on a machine that one has IE 4.0 installed.
This branch of the registry is empty which causes a panic exception to be
thrown...
Any ideas as to how I might fix this?
(Installing IE 5.0 is probably what we will do for know, but I really don't
what to force our customers to download IE 5.0 for 3 hours when our
application only takes 5 minutes to download...)
Thanks,
