PRS-500 Unofficial Sony Reader SDK released

[igorsk]

Well, I finally got this more or less working.
Included:
1) an import library for Fsk.dll (MSVC format)
2) a header file with definitions of enough Fsk functions to implement a simple text viewer
3) a sample of said viewer

How to install the sample:
1) Copy testviewer.dll next to "CONNECT Reader.exe"
2) Add the followings line to kconfig.xml (make sure to backup it!)
after <extension href="[applicationPath]FskDocumentViewer"/>:

<extension href="testviewer"/>

after <subtype name="plain" extension="txt"/>:

<subtype name="plain2" extension="txt2"/>

to see the debug messages, after </environment>:

<debug>
          <console visible="true"/>
</debug>

To test the sample, make a simple text file (if you use any non-ASCII symbols, make sure to save it as UTF-8) and give it a .txt2 extension. Then just open it in Connect.

I'm sorry that there's no documentation, I'm not really a doc writing type. I hope the code is more or less self-explaining. Feel free to ask about anything and I'll try to explain. Also check fsk.lst file for the list of all Fsk functions. Let me know if there's any one that looks interesting to you and I will try to find out how it works.

TODO (in no specific order):

• Fix bookmarks so that the view doesn't shift after switching between font sizes
• make and test port for Reader
• implement save/load of layout info and bookmarks
• implement bitmap display
• document more Fsk functions.
• implement links
• implement spans

Current version: 0.1
http://projects.mobileread.com/reade...FskSDK-0.1.zip

[kovidgoyal]

Wow impressive.

[Alexander Turcic]

That. Is. So. Cool.

Thank you igorsk!

[alex_d]

I'm sorry, what's Fsk?

Is this an SDK for the Reader or for the Connect software?

[igorsk]

Fsk is the engine of the Reader (and Connect) UI. On win32 it's implemented in Fsk.dll and on the Reader in libtinyhttp.so. The current release of SDK supports only Win32, but as the API is basically the same, it shouldn't be too hard to port to Linux. Right now I only described enough functions to make a custom viewer plugin, but in theory it's possible to add image viewers, audio decoders and about any custom UI components.

[alex_d]

cool

but the Connect UI looks nothing like the Reader's. Is there going to be some sort of interoperability? Ability to test and debug on win32 and move to the reader?

also, if you add a viewer using this method, what can the viewer do? Anything it wants? What about the issues of the user input, system messages, etc that I'm dealing with in the other thread?

[igorsk]

Viewer plugins interface is very abstract, so you can use the same code on Win32 and Linux. Fsk takes care of all input and display, you only need to implement the features you need. The text viewer interface is described by the DocViewer structure. For the bare minimum you need to implement:

1. CanHandle, which is used by Fsk to check whether the plugin can render a given mime type
2. New, which is called by Fsk on opening of the file and should return a new viewer instance. One of the parameters has a pointer to the fileRead function, which can be used to read the actual file data.
3. Dispose, called when closing the file.
4. Render, called by Fsk when it needs to render a page. It should return an FskBitmap with rendered text/graphics. Various Fsk APIs can be used for rendering text and graphics on the bitmap.
5. A few propery handlers in PropTable. You probably need at least handlers for Dimensions and Crop. If you want resizable text, you need to implement TextScale. To handle multi-page documents, Page and Pages.

When using resizable fonts, marks interface needs to be implemented too (MarkNewFromLocation etc).
To register in the viewer plugins chain, the plugin should call FskExtensionInstall in the fskLoad function.

[JSWolf]

What about handling graphics?

[igorsk]

Did you mean picture viewer? Or books with images? Both are doable, though I didn't investigate them too far yet.

[JSWolf]

Originally Posted by igorsk

Did you mean picture viewer? Or books with images? Both are doable, though I didn't investigate them too far yet.

How easy do you think it might be to write say a LIT viewer (no need for DRM) or a Mobipocket viewer. I know for sure that a Mobipocket viewer is more important as it would get more people away from the palm and onto the Sony.

[igorsk]

Well, the groundwork is there, all that's left is someone to write the actual code
Maybe I will see what I can do some time later...

[JSWolf]

Originally Posted by igorsk

Well, the groundwork is there, all that's left is someone to write the actual code
Maybe I will see what I can do some time later...

That would be nice!Is the source code for Mobipocket available? if not, I can try to ask Mobipocket if it's ok to have such for porting to the Sony. It would be in their best interest.

[igorsk]

Hehe I doubt they will share it
I'll see if it's possible to reuse some of FBReader's code...

[alex_d]

Oh, I see. So it's not about programming viewers per se, it's about programming file-handling plugins for the Sony viewer. I mean, can I even create my own interface where I can enter page numbers?

It's nice to see how elegantly Sony programmed everything. However, I'm afraid this is useless for my needs because i'm focusing on doing advanced rendering by directly controlling the eink.

igorsk, what about modifying the Reader UI to call other executables? (ie, similar integration but more power)

[igorsk]

Well, the problem is that a lot of the UI logic is implemented in ECMAScript, and hooking into it is rather complicated if the plugins interface is not enough for you...