impserve: serving content and accessing the internet for the 1200/1150

[Roberts324]

Originally Posted by nrapallo

Ok, then, try changing (temporarily) line 105 in the BeautifulSoup.py plugin to read:

DEFAULT_OUTPUT_ENCODING = "windows-1252"

instead of "utf-8".

Don't know why it returns uppercase e acute though for é.

Closer?

Nick, I did just that; now I am unable to connect to the liberation site (I get a message saying the server did not answer, reverting to utf-8 cures the problem).

However, I could connect to my home page and see some accented letters rendered; however, é (eacute) is replaced by uocase è, à (agrave) is replaced by the Yen sign and so forth...

Obviously there is a whole domain to explore there if this nice program is to be used by more than anglo-saxon people. Accented letters, diacritics, special letetrs like the cedilla (ç) are used by all western languages!

[nrapallo]

Originally Posted by Roberts324

Nick, I did just that; now I am unable to connect to the liberation site (I get a message saying the server did not answer, reverting to utf-8 cures the problem).

However, I could connect to my home page and see some accented letters rendered; however, é (eacute) is replaced by uocase è, à (agrave) is replaced by the Yen sign and so forth...

And here I thought we were getting closer...

Obviously there is a whole domain to explore there if this nice program is to be used by more than anglo-saxon people. Accented letters, diacritics, special letetrs like the cedilla (ç) are used by all western languages!

You would think utf-8 -> cp1252 would be something easy and standard to do! Obviously, something isn't working properly.

Is it the primitive HTML 3.2 ebookwise renderer or the python translation of utf-8 webpages or a combination thereof?

(aside: this seems a very common issue, as I usually find stray characters on webpages of international subsidaries on Canadian/US domains. The euro sign comes up a lot, in the most unexpected places sometimes. I always thought it was bad transcriptions!!! It appears its just a utf-8 to windows 1252 issue! )

Anyone else see a possible solution to this?

[RikaStrom]

Originally Posted by nrapallo

I have had a lot of experience "cleaning up" html code to properly prepare a .imp ebook, but unfortunately, it is mostly from writing/using Mobi2IMP in perl.

Nick, a question about this.

Several times I have "processed" an html book through GEB and the result was a disaster of coding and formatting. I've always held the opinion that this was because the original source code was "dirty". Is this what you mean when you say you "clean up" the html code before processing html to imp?

Thanks
Rika

[RikaStrom]

Originally Posted by nrapallo

Do you know how to format (erase external) the SM card within the ebook reader? You can format it using FAT (not FAT32) with a SM card reader and a PC, but I would still allow the reader to format it (again) before use, just to be sure.

You can save those SM chips when they crash? Would you tell me how? I've had three go TU on me, the reader tells me the chip is full, the book tells me the chip isn't even there. And with what those puppies cost, I want to reutilize them if possible.

Rika

[nrapallo]

Originally Posted by RikaStrom

Nick, a question about this.

Several times I have "processed" an html book through GEB and the result was a disaster of coding and formatting. I've always held the opinion that this was because the original source code was "dirty". Is this what you mean when you say you "clean up" the html code before processing html to imp?

Thanks
Rika

I use eBook Publisher (not GEB Librarian) to primarily convert .html to .imp ebooks. If the .html was prepared/copied from a website, there are a lot of things that eBook Publisher will complain about (it's great at finding most errors) which then requires you to edit the .html file so that it will work in the .imp ebook.

Recent versions of eBook Publisher have introduced some strange limitations, like only being able to use "\" in path of absolute filenames, require removal of any "width=" within image references like <img src="cover.jpg" width="50%">, etc.

When the preparer/author of the .html used is not you, then a lot of things can be wrongly/differently coded, as the eBook Publisher expects things to be presented in it's ways or it doesn't work. These "errors" are what I clean up when using .html as a source. I'm sorry I can't give you a checklist of things to change as each .html would be different, but after doing one of two conversions, you'll be able to see a pattern of things that need to be "fixed".

If you cannot determine why something doesn't work, try posting a new thread with the issue and help will come along...

[nrapallo]

Originally Posted by RikaStrom

You can save those SM chips when they crash? Would you tell me how? I've had three go TU on me, the reader tells me the chip is full, the book tells me the chip isn't even there. And with what those puppies cost, I want to reutilize them if possible.

Rika

There were a lot of flaky SM chips and even more so now given their age since manufactured (early 2000's).

I don't know of any way to "revive" faulty SM cards other than reformatting them in a card reader that is capable of reading them i.e. some of the "20-in-1" or similar units from Tigerdirect.com

The eBookwise 1150 will allow you to reformat the external (SM) card using the hidden menu that can be accessed when you turn on your reader while holding down the "page down" button AT THE SAME TIME. (see Item 2. under Fixing stuff: here EBookwise-1150)