Rumor has it Sony rummages around in these threads.

This thread is to report "internal" bugs to Sony (since they haven't provided a mechanism I'm aware of.)

My first internal bug.

When issuing a Directory Read Command via USB to the Sony Reader (you see why I call these internal errors) if you provide an invalid handle e.g. not what was returned from a Directory Open Command, the Reader panics (does a reboot).

Example, I was issued handle 0x00138418 but I handed back 0xffff8418. :rolleyes5

Fonts embedded in LRF do not get not loaded if the stream containing them is not compressed or scrambled (that's why they didn't work with LRFs produced by stock XylogParser.dll).

Sony, there is an open source WMF library you could use to implement WMF images in RTF documents. This would add cover graphics for Baen RTF ebooks and diagrams for scientific/mathmatical articles.

http://gnuwin32.sourceforge.net/packages/libwmf.htm

If you would like some assistance, just PM me.

I don't think they will want to use a GPL library, as that would require opening the source of their RTF viewer.

libwmf is LGPL.

When you request information on a non-existent file the Sony Reader supplies information on some other file....

reader_getattr (/Data/database/cache/media.xml2)
Short Path Command: 51 bytes

0000: 18 00 00 00 01 00 00 00 00 00 00 00 23 00 00 00
0010: 1f 00 00 00 2f 44 61 74 61 2f 64 61 74 61 62 61
0020: 73 65 2f 63 61 63 68 65 2f 6d 65 64 69 61 2e 78
0030: 6d 6c 32
out control_msg result: 51
in control_msg result: 32

0000: 00 10 00 00 01 00 00 00 00 00 00 00 0c 00 00 00
0010: 18 00 00 00 d7 ff ff ff 00 00 00 00 00 00 00 00
Bulk read length 40
bulk read result: 40

0000: 03 00 01 00 00 00 00 00 00 00 00 00 18 00 00 00
0010: 8b 3e 07 00 00 00 00 00 01 00 00 00 f8 92 85 40
0020: 24 ec 83 40 a4 ea bf be

I would have expected the file attribute packet to be full of zero's but it looks like valid goods for some other file.

The response code of d7 ff ff ff indicates path not found. You are supposed to discard the bulk packet after that.

Right, I did that, but I also noticed the bulk buffer seemed to get filled with valid data for some other file.

I think we call that a security glitch/bug/something to fix.

With updated firmware I found this bug in the USB Protocol.

When reading from: /opt0/deviceInfo.xml

It does a GetAttr, GetLength (why, GetAttr gave length already), FileOpen, FileRead...

But get this, the FileRead is for length 32K, even though the file is 0x65 length! And the Sony Reader dutifully hands over 0x65 of file and 32K - 0x65 of zero's...

That is costing time.

16 00 00 00 01 00 00 00 00 00 00 00 10 00 00 00 ................
10 F6 31 00 00 00 00 00 00 00 00 00 00 80 00 00 .ö1..........?.


Should be

16 00 00 00 01 00 00 00 00 00 00 00 10 00 00 00 ................
10 F6 31 00 00 00 00 00 00 00 00 00 65 00 00 00 .ö1..........?.

Same thing when processing: b:/Sony Reader/database/cache.xml

CONNECT reads that file in 32K chunks, even when the last 32K exceeds the end of file.

I think that bug was present even before the update.

The one bug that gets me is the italic bug. Sony really needs to fix it.

How it should look
This is a test. See how the italics work?

This is how they do look
This is a test . See how the italics work?

And when you have lines that have more then a normal space between the words, it gets worse. The problem is the Reader software takes the regular font, slants it and gets the spacing all wrong at the end of the italics. They need it have a true italic font internalto the reader to thix this problem.

Jon