Quote:
Originally Posted by dpierron
Well, I tested with Windows XP and ADE and it definitively comes from an ADE bug. Let me explain...
I expanded the ePub file into a folder, edited the CSS file, setting an absolute path for the font resource and then opened the HTML file with Firefox ; guess what, it worked out of the box.
When I did the exact same thing directly in the ePub file (same edit) and opened it with ADE, it didn't work (showing question marks instead of asiatic-looking thingies).
So, it has something to do with ADE ; either it's a bug, or it's an obscure point of the ePub standard that ADE enforces ? I can't tell.
|
I don't think this is complicated. If ADE (or a web browser for that matter) fails to find the referenced font then it uses the default font, and hence the question marks. The "res://" is with respect to the app's root directory, but that does not have to be the system's root directory. So, the Mac ADE has the expected root but the Window's ADE has some other root - which we don't know (or I guess it could have no root at all, for "security" reasons).
There are a couple of examples of this with mobile ADE:
The Windows Sony ebook library reader has a root of C:\Program Files\Sony\Reader\Data\bin.
It isn't clear what the Hanlin's (V3 and V5) root is, but it isn't the root of the system filesystem because so far only the SD card appears to be visible (at res:///abook) and not the user-accessible internal memory.
Under Linux (or Unix, e.g. on the Mac), softlinks can probably be used to build whatever kind of access restrictions for "res://" the app developer wants. I don't think this is as easy under Windows, or on Windows-like filesystems.