Additional dictionaries and some bugfixes

[siebert]

I added support for the Free Dicitionary and the SlovoEd English German Deluxe Dictionary (commercial) and fixed some bugs.

[geometer]

Hi,

I want to accept your patches, but I must to ask your opinion about our contribution rules: http://www.fbreader.org/docs/contributions.php. In short, I can accept patches only if we can use it in our non-GPL projects too.

Regards,

-- Nikolay

[siebert]

Hi Nikolay,

in general I have no problems with dual-licensed code. But the information on the linked page is very vague. Can you give some more information about the nature of the license? Will the source of the DRM code be available? Or at least the libraries so that third parties can build their own FBReaderJ derivates including the DRM features?

Ciao,
Steffen

[geometer]

Hi Steffen,

in general I have no problems with dual-licensed code. But the information on the linked page is v
ery vague. Can you give some more information about the nature of the license? Will the source of th
e DRM code be available? Or at least the libraries so that third parties can build their own FBReade
rJ derivates including the DRM features?

There are several usages of the text on the linked pages.

1. Sometimes we do customized versions of FBReader for several
   devices. There is at least one case when such customized version
   is closed-source. (That's a requirement of the device seller, I'm not
   sure I understand the cause.)
2. We sell a non-exlusive non-transferrable license for device
   manufacturers who want to create his own FBReader-based code.
3. As for possible DRM code, such version is currently in progress,
   however we have no final solution about licensing at this moment.
   The open-source DRM code could be too easy to crack, so I think
   it will be not open-source.

Regards,

-- Nikolay

[siebert]

Hi Nikolay,

I give you my permission to use my patches in your non-GPL projects, too.

Just a note about the DRM code: Security by obscurity has been proven to be a bad concept, so a good DRM solution should hold strong even if sourcecode is available.

Ciao,
Steffen

[geometer]

I give you my permission to use my patches in your non-GPL projects, too.

Thank you! I will use your code in 0.99.4 (it will be released today or tomorrow).

I made some changes in dictionary code. In particular, SlovoEd is not visible in Dictionary option list if it is not installed on the device.

I did this because not all users want to use English<->German dictionaries. E.g., I prefer English<->Russian & German<->Russian. ;) I think that is good idea to list only 'universal dictionaries'. In the other hand, if you already use a specific dictionary it would be in the list.

Just a note about the DRM code: Security by obscurity has been proven to be a bad concept, so a good DRM solution should hold strong even if sourcecode is available.

That's not so clear for publishers. :)

[siebert]

I can understand that the list of dictionary options would be way too long if all available dictionaries would be included in FBReaderJ. But I think it should then at least be mentioned in the documentation, which dictionaries are supported though not visible in the options unless installed.

May I ask you to give me some help on how to solve the issue I have in my "browserness" branch?
In case you didn't read it, I wrote about it in this google groups posting:
http://groups.google.com/group/fbreader/browse_thread/thread/d099b73dd70d77d0?hl=en

Thanks,
Steffen

[geometer]

But I think it should then at least be mentioned in the documentation, which dictionaries are supported though not visible in the options unless installed.

Agreed. The (missing) documentation is a real pain of the project. At least I will mention this in a release notes on the site.

As for your question I'll answer after some thinking. :)

Regards,

-- Nikolay

[siebert]

Hi,

As for your question I'll answer after some thinking. :)

Great, I'm eagerly awaiting your answer :)

Another thought about the dictionaries: I think it would be a good solution to add a "Custom" entry to the list of dictionaries for which the user can enter the necessary PackageInfo data of his preferred dictionary. This way FBReaderJ could instantly support lots of dictionaries without having to add each of them to the sourcecode.

Ciao,
Steffen

[geometer]

Hi,

Answered in the group.

Could you please send me a sample epub with relative paths containing '../'? I made some cosmetical changes in your code and I want to test this code now. (geometer-at-fbreader-dot-org).

Regards,

-- Nikolay

[siebert]

Answered in the group.

See my reply in the group.

Could you please send me a sample epub with relative paths containing '../'?

EPUBs generated by Calibre recipes had this issue. Calibre was already change to prevent this type of links, but nevertheless I think think FBReaderJ should be fixed to handle them correctly.

You can find a sample EPUB attached to the Calibre bug
http://bugs.calibre-ebook.com/ticket/7788
as original.epub
http://bugs.calibre-ebook.com/attachment/ticket/7788/original.epub

Any comments on the "Custom" dictionary entry idea?

Ciao,
Steffen

[geometer]

See my reply in the group.

You're right. I didn't see your code. I'll try to understand real issue.

Thank you for the link. I found an another issue in the same file: SVG embedded images were not supported. Fixed.

As for custom dictionaries, that might be too unclear for most users. :(

Regards,

-- Nikolay