[rogue_ronin]

Originally Posted by DMcCunney

Pretty much. HTML support is pretty good, though CSS support is lacking.

It supports embedded images and hyperlinks, text attributes (bold/italic/etc.) and custom fonts on the PDA if you run Palm OS 5.

I still use a palm Treo 680. But my eyes can't handle it without glasses now. Frickin' eyes... I've lost a lot of enthusiasm for the platform, too.

I just remembered that I have Plucker and iSilo on there. Never really used Plucker, and only played with iSilo a bit. They're both attractive -- basically HTML 3.2, I think. Can't handle CSS, as you mentioned. Good for the times, of course -- and if palm had not essentially abandoned development, they'd possibly have better apps. I think I never really used them because I have had an REB1100 for a long time, and it was far superior for reading ebooks (but had its own limitations, too.)

I got started in ebooks because a former employer decided the IT folks should all have PDAs, and a Handspring Visor Deluxe showed up in interoffice mail. I went looking for software that could help me do my job, and discovered Plucker, which would let me convert the HTML based manuals for a lot of the systems I dealt with to a form I could read on the PDA... [snip]

Lucky! I had to buy a Palm III while I was in Japan in '98, and I couldn't sync until I got back to the States six months later... Such a dork.

I don't think it's converting to fb2 format for display. Simpler, I think, if you can read the foreign format in the first place to just display it.

I expect that sort of conversion to occur on the desktop in the program that creates the files viewable on the reader (like Mobi Creator ripping stuff to HTML, and creating the Mobi file from that.)

I guess I meant something more like "The display engine was probably designed for FB2, so it may not have the tools necessary." After all, there are (and have been) display engines around for a long time that they could have used. I think they built their own, and have to add things as they go forward.

Reading a foreign format well enough to extract the content, and building an engine to display it faithfully seem to me to be a different magnitude of problem. Simpler to make a basic translator that ignores much beyond header/italic/bold/image. Think tables -- mostly never translate, after all. If they had a display engine, it would probably work, no?

I'm sure that the converters (in my case, Calibre) are also somewhat limited in transformational capability. But since ePub displays so well in Calibre's viewer, I think that it's having trouble emulating it in FB2. Could be a limitation of the programmers (although they seem uber-capable) or the format.

I've looked at the FB2 specification (but understood less about XML then than I do now) and don't recall anything that suggests that elements can have their display properties changed. Doesn't mean that it doesn't, of course.

I wouldn't hold my breath. The demand will be for an all-in-one solution ala FBReader.

Yup. Which is why it'll always lack excellence, but will work sorta okay at a lot of things. I mean, FBReader can't even delete an ePub after you add it to the library. Sticks around if you delete the disk file, too. (They just switched from XML to SQLite for database management. It's alpha beta, of course.)

I'm almost always an outlier, but I'm confident that if what I wanted were around, people would use it instead. Doing one thing well is Linuxy.

m a r