RTEJava(beta version)Copyright © 2003-2006 Mark K. Davis. All rights reserved. |
Backward-compatibility details
Why does the original utility have this flaw?The encoding/decoding algorithm used by the original utility makes it impossible to decode a .rte file correctly unless the user has a key file that is identical byte-for-byte to the key file used for encoding. The Windows, Mac, and *nix platforms use different byte sequences to indicate a line return in a text file. In some cases where the key file used is a text file (for example, a Wavefront .obj file), the key file used for encoding has a different line return sequence than the key file used for decoding. The original utility will fail to decode the .rte file in such a case.
What is the name of the "original .rte utility"?The author of that other utility has requested that I refrain from using his name and trademark (that is, the name of his utility).
How important is this flaw?There are probably a small number of key files that will be problematic. However, the severity of this flaw is related to the popularity of the key files used, not the number of such key files.
One example is the Victoria geometry file
Another example discovered by Renderosity member MarianneR is
the DAZ3D
RTEJava has been designed to handle the different line return sequences.
For example, RTEJava can decode the Netherworks-Viomar V3 Hybrid character
no matter which version of
How does RTEJava compensate for the flaw in the original utility?RTEJava and the original utility use the same encoding algorithm, but RTEJava uses an improved decoding algorithm that automatically converts the line return sequences used by a text key file, if such conversion is needed. Here is a description of the new decoding algorithm used by RTEJava: When the user chooses a key file, the name, length, and CRC are compared to the expected key file name, length and CRC, which are stored in the .rte file header. Why did you choose this solution?One alternative was to release a "decode-only" application to allow Mac and *nix users access to existing .rte files. However, any attempt to encode a new .rte file using the original utility in a virtual environment (Virtual PC, VMWare, etc.) could still lead to files that Windows users could not decode with the original utility. There was no compelling reason to deny content creators who work on a Mac or *nix computer from encoding their work on their chosen platform.A second alternative was to create a new file format, similar to but not identical with the original file format. Either a different version number could be stored internally in .rte files created by RTEJava (so that the original utility would refuse to open those files), or a different extension (.rtj) could be used. This alternative would have been too drastic, as one of the goals of RTEJava was to extend the functionality of the original utility to non-Windows platforms, rather than to replace the original utility.
A third alternative was to "standardize" all key files
to match the Windows version by virtualizing the key when
encoding a new .rte file.
This turns out to be impossible! The table below shows that
there is no "standard" line return sequence for
some common Poser files on either the Windows or Mac platforms!
The solution chosen by the developer is to not change the original .rte format at all, and to allow non-Windows users the opportunity to create encoded .rte files, with a warning at the time that the encoded file is created that these new .rte files may not be compatible with version 1.00 of the original utility.
Is there a way to avoid the effects of this flaw?Yes. Use RTEJava for all your encoding and decoding, as it was designed to be cross-platform.
But I really, really, REALLY want to use "the original utility"!The flaw is built into the original utility, but just follow this rule: If you are encoding using a text key file, use the "Windows" version of that key file. Be careful to understand what this rule means! Do not convert all your text files to use DOS/Windows style line returns, as many Windows text key files use Unix (or even Mac!) line returns, as shown in the table above. Try to obtain a copy of the exact key file that a Windows user would have installed on her/his computer! NOTE: There is no need to follow this rule for binary data key files. For example, a JPG image is not a text file, and should not differ across platforms. For example, a Mac user who runs Virtual PC and uses Poser 4 could install the Windows version of Poser (and any other content) to a shared folder on the Mac's hard drive, then use the files in the shared Windows Runtime folder as key files for encoding. Likewise, a Linux user on a dual-boot Windows/Linux box could install Poser under Windows, then boot into Linux and mount the Windows partition to access the Windows Runtime as key files for encoding. |
Copyright © 2003-2006 Mark K. Davis. All rights reserved.