3 ms·

What does an EPUB reader provide that a browser doesn't? Because right now it seems to me that the answer is just one, trivial thing: It can treat a .epub file

What does an EPUB reader provide that a browser doesn't? Because right now it seems to me that the answer is just one, trivial thing: It can treat a .epub file (that is, a zip file) like a directory. If that really is the only thing that differentiates an EPUB reader from (a subset of) a browser, it seems that the simplest and least-effort thing to do would be: 1. Enable existing browsers to treat a zip file like a directory, under certain circumstances. 2. Describe a machine-checkable restriction of HTML that guarantees fully local assets as described in TFA (this might be as straightforward as requiring all URLs (except for links) to be relative). Declare any zip file that satisfies this restriction to be "a portable EPUB". 3. Forget about special-purpose EPUB readers altogether, both existing and new.

LorenPechtel 3y ago
Agreed, this sounds like the real solution. As for fully local assets--what I would like to see is a requirement that all objects have locally available fallback options. You can't get that font, use this standard one. Might not look perfect but it should work reasonably well if you limit yourself to things in the fallback. There is still one failure mode he didn't fully address--images that don't work right. Fundamentally, this is because images can't reflow. To a large degree I think this could be addressed with using SVG, but that's not going to handle things which are truly raster rather than vector. Unfortunately, I think the only way to address that is provide a few resolutions. (And I have faced a related problem that I haven't seen a good answer for but I haven't looked hard: SVG that is aware of it's resolution and can bring in more detailed images if it has the resolution to do so. Try to draw sub-pixel lines and you're going to get a blur, but blowing up the same image and those lines become a good thing. Windows acknowledges this with icons, you can include a variety of resolutions and it will work with whatever is most appropriate for the context.)
- akoboldfrying 3y ago
  >a requirement that all objects have locally available fallback options If we instead mandate that every font used is either packaged within the zip, or one of a small, fixed, well known list of "standard" fonts that every system can be required to support, what would be lost? (IOW, what do we gain by allowing the concept of "fallbacks"? Because what we'd lose would be consistency between internetful and internetless renderings, and self-containedness.) >images that don't work right What's an example where storing a single high-resolution image, which can be dynamically scaled down if needed, doesn't work well?
  - LorenPechtel 3y ago
    If you require including the fonts outside the base set you are going to end up tossing a lot of fonts around that aren't really needed. What I'm after is use this if you can, if you can't use that. As for scaling--it doesn't work when the zoom is too great. It really doesn't work too well if you have some sort of texture to your image and you squash it too much. Consider a real world case: maps. I'm looking at a topographic map of an area around here, the farther back I pull the camera the more features get omitted because painting them would end up obscuring more useful information. You could use lines with a wider spacing but that isn't even too useful as the camera pulls back.

LorenPechtel 3y ago

Agreed, this sounds like the real solution. As for fully local assets--what I would like to see is a requirement that all objects have locally available fallback options. You can't get that font, use this standard one. Might not look perfect but it should work reasonably well if you limit yourself to things in the fallback. There is still one failure mode he didn't fully address--images that don't work right. Fundamentally, this is because images can't reflow. To a large degree I think this could be addressed with using SVG, but that's not going to handle things which are truly raster rather than vector. Unfortunately, I think the only way to address that is provide a few resolutions. (And I have faced a related problem that I haven't seen a good answer for but I haven't looked hard: SVG that is aware of it's resolution and can bring in more detailed images if it has the resolution to do so. Try to draw sub-pixel lines and you're going to get a blur, but blowing up the same image and those lines become a good thing. Windows acknowledges this with icons, you can include a variety of resolutions and it will work with whatever is most appropriate for the context.)

akoboldfrying 3y ago
>a requirement that all objects have locally available fallback options If we instead mandate that every font used is either packaged within the zip, or one of a small, fixed, well known list of "standard" fonts that every system can be required to support, what would be lost? (IOW, what do we gain by allowing the concept of "fallbacks"? Because what we'd lose would be consistency between internetful and internetless renderings, and self-containedness.) >images that don't work right What's an example where storing a single high-resolution image, which can be dynamically scaled down if needed, doesn't work well?
- LorenPechtel 3y ago
  If you require including the fonts outside the base set you are going to end up tossing a lot of fonts around that aren't really needed. What I'm after is use this if you can, if you can't use that. As for scaling--it doesn't work when the zoom is too great. It really doesn't work too well if you have some sort of texture to your image and you squash it too much. Consider a real world case: maps. I'm looking at a topographic map of an area around here, the farther back I pull the camera the more features get omitted because painting them would end up obscuring more useful information. You could use lines with a wider spacing but that isn't even too useful as the camera pulls back.