Quote:
Originally Posted by BryanK
Are you implying that Kobo has the ability to add those features to the RMSDK engine and chooses not to? Or that the ACCESS engine has the ability to read Adobe DRM epubs and provide the same features on them as it does on kepubs? As far as I know, neither is true, but I would be happy to learn otherwise.
|
The ACCESS rendering engine used for kepubs is an epub3 renderer. The current version of RMSDK is still an epub2 renderer though some epub3 features are now supported. You will find that some kepubs which make use of epub3 features when rendered by an epub2 renderer look like crap. Other kepubs were produced by companies whose only epub3 "feature" was changing the version in the content.opf file to "3.0". OTOH, you pretty much need RMSDK to support Adobe's ADEPT DRM ecosystem -- the ACCESS renderer does not support Adobe's DRM.
IMO, Kobo would not be adding features to either renderer. ACCESS would handle changes for their renderer and it appears that they are moving to using the Readium codebase. The Adobe RMSDK used by Kobo is (I think...) supported by Datalogic. Going by Adobe's website, RMSDK 11 is moving towards supporting enough epub3 features to start calling it an epub3 renderer. One caveat is that Adobe never quite made it to full support of epub2. One suggestion about the future of RMSDK is that RMSDK will use the Readium code base with an Adobe ADEPT DRM wrapper.
I would disagree that this is an artificial distinction -- when Kobo was first looking at the Japanese market, RMSDK did not support enough language features to support Japanese typography with it's mixture of text directions, the use of three writing systems in kanji (a ideographic writing system), katakana and hiragana (two different phonetic alphabets), furigana (smaller kana glyphs beside or above (depending on text direction) a kanji glyph for pronunciation assistance), etc.