Quote:
Originally Posted by milady133
I'm just speculating, maybe there were other previous decisions that led to developing they're own reading program, but I'm sure it all started because there was something that the RMSDK lacked, and they needed to develop they're own solution. Then they kept adding on that solution because it's easier than working around other company's library. Once you have something you control completely and you can modify as needed it's easier to work on that.
|
The pressure to add an ePub3 renderer to Kobo ereaders was based on their purchase by Rakuten and moving into the Japanese market in 2012. If you have never looked at Japanese typography, it is rather complex. Two syllabaries (Hiragana and Katakana), a logographic system (Kanji) and text that can go in multiple directions. Add in features such as furigana (seen as small Hiragana characters placed next to Kanji to give the pronunciation since Kanji often has multiple pronunciations for the same glyph). You will also find quite a few Romanji (Latin alphabet) characters being used. You will notice the 4 names quoted below have the same Kanji but different pronunications.
Quote:
淳子 (Junko)
淳子 (Atsuko)
淳子 (Kiyoko)
淳子 (Akiko)
|
Basically, RMSDK was not capable of handling this and so Kobo licensed the ACCESS NetFront BookReader v1.0 EPUB Edition for use on their devices/apps. Later ACCESS code was done with the Readium project SDK which resulted in the PUBPLUS™ Reader v2.0 EPUB.
Later versions of the Kobo renderer were based on the Readium/webkit and Readium 2 SDKs.
And yes, I strongly suspect that by using their own DRM and servers, Kobo is able to avoid a decent chunk of the cost involved with using Adobe ADEPT DRM and Adobe Content Server.