[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Not entirely OT: ODT format



≪This is an open standard?≫ The definition of open standard is that
the codes have been published (somewhere public, such as any of several
well-known forums for such things) and no one is entitled to license
fees for the use of them, not that the codes (or whatever it is that
results from them) are in ASCII text.

≪As I understand it, mathematical compression would do things like
representing a line with 20 e's as "20e" which is only 3 characters
instead
of 20. Of course, that is much, much cruder than the actual compression
routines. But it is clear that that is a different animal from bit-wise
encoding.≫ Correct. Compression algorithms in general replace multiple
instances of repeating characters or strings by tokens, as Harry
surmised. JPEG picture compression works the same, except that it takes
blocks of repeating pixels rather than lines of repeating text as its
unit of application. The file (header) typically contains something like
an index defining the tokens.

≪the ODT format was actually smaller than TXT. Short of compression,
anyone know how that's possible?≫ Elegant formatting codes. I have a
steganographic program which hides cypher text inside a BMP file. Anyone
who intercepts the BMP file and opens it sees only the foto; no trace of
text is evident. The BMP file size is no larger with the hidden text in
it. The principle is similar to that mentioned by Harry; the
steganography program squeezes cypher text into unused bits in the
red-green-blue color space.

I tried opening the BMP files containing hidden cypher text with a
number of hacker tools. Interestingly, Xy3 is the only program which
showed me the tokens where cypher text had been inserted between pixels.
Every other tool showed only the pixels.