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/reader/users/igorsk/FskSDK-0.1.zip

Wow impressive.

That. Is. So. Cool.

Thank you igorsk!

I'm sorry, what's Fsk?

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

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.

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?

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:

CanHandle, which is used by Fsk to check whether the plugin can render a given mime type
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.
Dispose, called when closing the file.
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.
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.

What about handling graphics?

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

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.

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...

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.

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

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)

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...

igorsk, has Sony tried to hire you yet??

No, why would they?

Well, to make use of your skills, obviously. You seem to be able to do things that the programmers that they have working for them now evidently can't. :wink2:

I'm sure they can do all that just fine. It's just that the marketing folks have their own vision.
I myself am working in a pretty big company's (not so big) software department and I can perfectly understand why Sony doesn't add more features and why they don't release a full SDK.

I have troubles working with the testviewer sample.

After proper compilling of the dll with VS2005, I placed it in the directory next to the reader executable file.

I run Connect, with the "debug console" open.
When trying to open a ".txt2" file with something like "HEllo world !", inside, nothing happens.
The reader UI doesn't show anything in the viewing windows, not even a blank page.
When I check the console (I commented nearly all the "printf" lines to avoid filling the console windows with junk I don't need at the time), I can see that the application open and dispose the file 2 consecutives times. I don't know if it's the proper behavior.
More, when I check hostData->pszFileUrl (the name of the file normally passed to the dll file),
printf("File: %s, \n", hostData->pszFileUrl);
just shows me
File: (null)

And all the others properties of hostData (a ViewerData kind of variable, if igorsk remembers his code :)) are set to null...

I suppose there's a problem when the file is handled to the dll. But I don't know what's wrong (and I imagine that tracing the whole Connect with a debugger will be a real pain...). Does anybody have a hint ?

Learning that the Reader ran tinyhttp, I loaded an html file on an SD card and popped it into the Reader. It failed to show up in the file list in the Reader. Wondering then whether the Reader would render html embedded in a text file, I changed the file extension to "txt" and put it back into the Reader. Again, it failed to show up in the file list on the Reader, though the Reader had placed its characteristic data on the SD card.

This suggests the Reader is actually looking at the file content during the indexing process.

It would be nice if the Reader would display html. Any ideas?

Despite the fact that the main application is called "tinyhttp", it's NOT an HTTP server or an HTML browser. Currently there's no ability to render HTML in the Reader.

Igor on your SDK(the little example app), did you download the GCC source on the Sony Linux site and just use the same source code to compile for ARM ?

Once I get a development environment up and going, there could very well be a HTML parser soon :D Many sources of content is in HTML.

Actually I didn't try compiling for ARM yet.

So since you linked the apps to the library, will that text app actually run on the reader? One would think you would have to set up an ARM compiler toolchain and compile that library with ARM9 (proper chip) as the cpu target before beeing able to use it on device native apps?

I guess I just dont understand what you can do with the little SDK if it is not compiled for ARM to run on the reader. Is there a emulator? Does it run on the reader? I dont understand.

Once me and my friend have a worked development environment we will post a package and instructions so any programmer can get up and running making custom apps for the reader.

The API used in Connect software on PC is the same, so you can test your plugins on PC and then port to the Reader.

That is kind of interesting. I installed the reader and tried various conversion tools. I didn't know the preview window was actually an emulator of the reader software.

Thanks Igor. Once I get my reader I will actually try some code. I've got my arm toolchain almost setup here in Ubuntu so will be able to compile stuff for the reader shortly.

Can someone post the LRS documents in a zip file? I've tried getting registered and it's just not working for me.

Derek

Can someone post the LRS documents in a zip file? I've tried getting registered and it's just not working for me.

Derek
Did you check your spam filter? I had to pull the email out of gmail's spam filter.

Not using GMail for this. Not the spam filter on the machine in question.

Don't know what the problem is.

Derek

Did you check your spam filter? I had to pull the email out of gmail's spam filter.

http://www.y-adagio.com/public/committees/iec_pt62448/5_final(0611)/final_text_061113.doc

Thank you O Great Master!

:pray:

http://www.y-adagio.com/public/committees/iec_pt62448/5_final(0611)/final_text_061113.doc

Not using GMail for this. Not the spam filter on the machine in question.

Don't know what the problem is.

Derek
Check the spam box of whoever is hosting the email. ISP, gmail, hotmail, etc. I use the pop from gmail and I had to go to their web interface to see the spam.

You may just have to use a different e-mail address. Here's a quote of my post last time this came up:
Their mail agent is really badly configured. A lot of MTAs are likely to drop the e-mail before it even gets to a spam checker. It's not just the time stamp. They're also sending it through a machine with no reverse DNS, virtually guaranteeing it's going to get dropped.

Add to that, it's sending HTML e-mail with a mangled MIME type header and no multi-part plain-text component, and you've got a recipe for getting dropped in the bit bucket unknown.

If you don't get the e-mail immediately, and it's not in your junk filters, you'll have to use another address. A lot of commercial services are going to reject it out of hand.

Yeah, hotmail did not work, but gmail did.

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"

Current version: 0.1
http://projects.mobileread.com/reader/users/igorsk/FskSDK-0.1.zip

Igorsk, testviewer.dll is missing in the achive. Do you have compiled one?

Here's a copy.

Is there any info on Javascript functions available in Sony Reader?