Converting .IMP to anything? WE ARE NOW THERE!

[nrapallo]

Originally Posted by DixieGal

YAY! I'm bookmarking this thread and printing a hard copy, so as to never lose this info! THANK YOU!

And hopefully with ETI's new entry into the e-ink reader world, you may never have to use this program to migrate away...

I'm here (meaning .imp world) to stay!

[nrapallo]

Added ability to extract only one .imp file.

See post #1 above and use the 'extract.bat.txt' attachment (just save as 'extract.bat') and in the MS-DOS command prompt window, type:

1. unimp "Impfilename.imp" and

2. extract "Resdirname" (note no .RES and Resdirname may differ from Impfilename)

[delphidb96]

Originally Posted by nrapallo

Thanks!



It's all here now! See post #1 above. Thanks for waiting...

Another fine crafted software... What do you think?

Coolness, like SO TOTALLY *IS*!!! I'm sending you Karma!

Derek

[JSWolf]

Is the goal to be able to extract the contents of the IMP file with the full formatting and graphics for easy conversion to another format of our choice?

[nrapallo]

Originally Posted by JSWolf

Is the goal to be able to extract the contents of the IMP file with the full formatting and graphics for easy conversion to another format of our choice?

For now, the goal was to be able to at least salvage the text portion of a .imp if the user "leaves" the .imp platform behind.

I doubt that I will be able to get the original html "look" since it is not stored in the .imp file. Only the basic components are, like a record that tells you where all the font/styles changes are located in the file, another record indicates where to end the line so that it doesn't spill over the screen size of that .imp and other records that stores the images, hyperlinks used, etc.

Basically all the building blocks are there (scattered) and it would not be trivial to reassemble the .html! Possible, but would be like reverse-engineering everything.

This is the next best thing for now.

Later, I wouldn't mind doing something along the lines of an Impperl suite of programs ala Mobiperl. Until now no programs have been able to extract any information from .imp files, so this is the begininng of the journey....

[LeserattePD]

It's really wonderful that you've managed that! Now I might actually get a new e-ink reader. I love my ebookwise but I cracked the screen and the battery is giving up after 3 years of intense use. Living in the UK, I'd have to get a new one, so I'm thinking of switching to e-ink.

Any idea of a timeline for the new ebooktechnologies reader? At the moment I'm actually thinking of getting the Iliad (for the pdf support as I'm an academic) and because it seems closest to the ebookwise in other functions.

[mscott161]

Nick,

I know you are working on the conversion of imp to other formats. I have been working on the same goal. I have viewed the source code for the LZSS compression but have not been successful in tweeking it to decompress the text from the imp. Can you give me and insite? I would be willing to same source code in the endever. My code is currently in c# and working toward a imp to lrf converter.

Michael

[nrapallo]

Originally Posted by mscott161

Nick,

I know you are working on the conversion of imp to other formats. I have been working on the same goal. I have viewed the source code for the LZSS compression but have not been successful in tweeking it to decompress the text from the imp. Can you give me and insite? I would be willing to same source code in the endever. My code is currently in c# and working toward a imp to lrf converter.

Michael

Nice to hear of your .imp interest, as I'm a big supporter of this format! I would welcome another programmer on the .imp band-wagon.

The LZSS decompressor routine has already been re-written (and working) in Perl. It's been incorporated into EBook-Tools by mobileread.com member AZed by way of a LZSS.pm. It currently is only available in trunk, but should be released soon in version 4.0.

If you would like to PM me with your email address, I can help you with the C source code of same, but since it's a hack, I'm relucant (embarrassed) to post it here.

We (AZed and myself) have a lot more "goodies" in the EBook-Tools bag, like metadata editing and .html and images extraction. So stay-tuned!

I had previoulsy reverse-engineered the .imp format (as did ashkulz), but had no way of implementing what I had learnt via code. Now that I'm involved with EBook-Tools I forsee a lot of re-writing of existing programs to do things the EBook-Tools way. Perhaps you can use this for your conversions as well!

[mscott161]

Nick,

My email is michaels@ebizsoft.com. The problem I have is on the encoding bit. I read a offset then the length, but the numbers are pointing to bytes that have nothing in them. I am also using a byte array to hold the compressed data and using it as the incoming file and output is to a string that at the end I write to a file to check. I have parsed the PNG files, !!sw, confused on the values for !!cm. I am assuming the default 64 resource. I have been working on the style and extended style data to parse. All is in objects so I can hopefully at the end put together other formats.

Michael

[nrapallo]

Originally Posted by mscott161

Nick,

My email is michaels@ebizsoft.com. The problem I have is on the encoding bit. I read a offset then the length, but the numbers are pointing to bytes that have nothing in them. I am also using a byte array to hold the compressed data and using it as the incoming file and output is to a string that at the end I write to a file to check. I have parsed the PNG files, !!sw, confused on the values for !!cm. I am assuming the default 64 resource. I have been working on the style and extended style data to parse. All is in objects so I can hopefully at the end put together other formats.

Michael

Michael:

I just sent you my source for deimp.exe and imp_dump.pl which parses a .imp into it's component filetype records and extracts the images and text.

I have not yet parsed !!cm (didn't need to just yet as deimp is used), but have parsed !!sw (which I think is useless/nonfunctional?). I have a lot of "notes" on this, but have not yet coded (in Perl) all of the .RES filetypes.

If you are interested in further reverse-engineering of the .imp format, then I think a new thread is in order. I know quite of few will join in! The main information on .imp reverse-engineering comes from the Jeffrey Kraus-yao's excellent website http://krausyaoj.tripod.com/reb1200.htm (or on the REB1200 for Dummies website http://www.chromakinetics.com/REB1200/imp_format.htm) .

[RikaStrom]

Originally Posted by nrapallo

And hopefully with ETI's new entry into the e-ink reader world, you may never have to use this program to migrate away...

I'm here (meaning .imp world) to stay!

Nick,

Another question please. What is an alternative to the ebookwise ETI device? Are they going to come out with an e-ink device that will read my .imps and other formats?

I know it's in not in the works that the powers that be would let us have one or multiple devices that would read all the formats. (sigh)

Thank you

[nrapallo]

Originally Posted by RikaStrom

Nick,

Another question please. What is an alternative to the ebookwise ETI device? Are they going to come out with an e-ink device that will read my .imps and other formats?

ETI did have an idea, long-long-ago (about 3-4 years ago), to produce an e-ink device (see their e-ink prototype showing what their ebook operating system would look like thereon). This "idea" has failed to become a reality and as such I do not foresee any other future device being able to read the .imp format.

I know it's in not in the works that the powers that be would let us have one or multiple devices that would read all the formats. (sigh)

Thank you

Nice idea, akin to "world peace and harmony"...