View Full Version : .ePUB extension should be reserved for non-DRM eBooks


DaleDe
04-19-2009, 08:11 PM
I believe that Adobe should not use the ePUB extension for eBooks that have DRM applied. They can do what they want with PDF but ePUB is not their format and they have no right to take it over with ADE based DRM. They should develop a new extension for use on DRM'd books. The end user can easily be confused and not be able to read what they purchased. Only a very few devices actually support DRM on ePUB but many devices have support for ePUB.

For example Sony is careful to use LRF and LRX to distinguish non-DRM from DRM ebooks. Others should take this lead and adopt it as well. Several others also adopt this rule.

I think the ePUB committee should outlaw the use of the ePUB extension for DRM'd eBooks. Their extension has been hijacked for commercial purposes IMHO.

Dale

ilovejedd
04-19-2009, 09:18 PM
I think the ePUB committee should outlaw the use of the ePUB extension for DRM'd eBooks. Their extension has been hijacked for commercial purposes IMHO.
As far as I know, the ePub extension does have a provision for DRM so I don't think there's any hijacking involved. I do agree, though, that they should use a different extension for DRM'd works to avoid consumer confusion.

pilotbob
04-19-2009, 10:03 PM
Dale,

That's a good point. It will be very confusing, espesially when you see that the Jetbooks supports ePub... but no DRM version. We have .epub with Adobe DRM and will eventually have .epub with EReader DRM.

Perhaps it should be standardized as...

.epub.drmtype

For example...

.epub.erdr
.epub.adobe

OR something.

BOb

DaleDe
04-20-2009, 01:08 AM
Dale,

That's a good point. It will be very confusing, espesially when you see that the Jetbooks supports ePub... but no DRM version. We have .epub with Adobe DRM and will eventually have .epub with EReader DRM.

Perhaps it should be standardized as...

.epub.drmtype

For example...

.epub.erdr
.epub.adobe

OR something.

BOb

Two dots is an abomination and used by spam and viruses to mask the fact that they are an executable. I think they could change one letter, add one letter or just use .ade as an extension. Any of those could work.

The ePUB specification allows for user defined DRM but I believe they intened it like version one where mobi, eBookwise, and LIT all used the same basic format but then wrapped it in their own DRM and eventually their own format. I don't think the private format was the correct solution but private DRM is always private so it should have its own unique extension to aid the user in recognizing the format and reader that can be used to read that format.

ilovejed: I didn't intend to say that they had hijacked ePUB as a format, just the extension. I think they need to support ePUB but with a different extension so that the users are not confused. There can be lots of different DRM systems present according to the ePUB standard. Should they all use the same extension? Wouldn't that totally destroy the format and confuse the final customers? Too much today rides on the extension to abuse it in this fashion.

Dale

netseeker
04-20-2009, 02:11 AM
Maybe one of us (with a better english than mine) could write to the IDPF and ask what they are thinking about this topic?

ilovejedd
04-20-2009, 08:48 AM
ilovejed: I didn't intend to say that they had hijacked ePUB as a format, just the extension. I think they need to support ePUB but with a different extension so that the users are not confused. There can be lots of different DRM systems present according to the ePUB standard. Should they all use the same extension? Wouldn't that totally destroy the format and confuse the final customers? Too much today rides on the extension to abuse it in this fashion.

In case you missed it, I agree with you on the extension issue...
As far as I know, the ePub extension does have a provision for DRM so I don't think there's any hijacking involved. I do agree, though, that they should use a different extension for DRM'd works to avoid consumer confusion.

JSWolf
04-20-2009, 10:46 AM
Mobipocket has been doing this for as long as Mobipocket has existed. So has Microsoft with MS Reader. eReader is also guilty. Adobe has also with PDF.

So why single out Adobe for ePub?

pilotbob
04-20-2009, 11:20 AM
Two dots is an abomination and used by spam and viruses to mask the fact that they are an executable.

If you say so. :rolleyes: Then again if you don't know to modify your options to not hide extensions then you really don't know what's going on anyway. That "hide extensions" is the default in Windows installs is the true abomination.

BOb

DaleDe
04-20-2009, 11:27 AM
Mobipocket has been doing this for as long as Mobipocket has existed. So has Microsoft with MS Reader. eReader is also guilty. Adobe has also with PDF.

So why single out Adobe for ePub?

Because it is attempting to be an industry standard. It should be setting the example for the future and correcting the wrongs of the past. In addition it is multi-vendor while the other formats were specific to one companies product. ePUB is supposed to be an industry wide standard.

Dale

DaleDe
04-20-2009, 11:28 AM
If you say so. :rolleyes: Then again if you don't know to modify your options to not hide extensions then you really don't know what's going on anyway. That "hide extensions" is the default in Windows installs is the true abomination.

BOb


I agree but I am trying to change one fault, not the entire world :)

Dale

pilotbob
04-20-2009, 11:31 AM
I agree but I am trying to change one fault, not the entire world :)

Dale

Remember Knight Rider... one man CAN make a difference.

BOb

Xenophon
04-20-2009, 11:35 AM
Remember Knight Rider... [SNIP]
BOb

Do I have to? :eek::eek:

:p

Xenophon

kovidgoyal
04-20-2009, 12:20 PM
If you say so. :rolleyes: Then again if you don't know to modify your options to not hide extensions then you really don't know what's going on anyway. That "hide extensions" is the default in Windows installs is the true abomination.

BOb

From a programmer's perspective, multi-dot extensions are extremely annoying, since there is then no way to know where the extension begins and the filename ends.

JSWolf
04-20-2009, 12:34 PM
Remember Knight Rider... one man CAN make a difference.

BOb
And get canceled trying to do so.

JSWolf
04-20-2009, 12:34 PM
.epub for no DRM

.epubd for DRM

kovidgoyal
04-20-2009, 12:39 PM
I prefer .depub for DRMed EPUB as it can also stand for de-published ;)

DaleDe
04-20-2009, 12:41 PM
I prefer .depub for DRMed EPUB as it can also stand for de-published ;)

To make the object oriented paradigm work you actually need separate extensions for each form of DRM since a different program needs to be launched to read it.

Dale

ilovejedd
04-20-2009, 12:49 PM
To make the object oriented paradigm work you actually need separate extensions for each form of DRM since a different program needs to be launched to read it.
Yep. The extensions are looking to be irritatingly long, though...

DaleDe
04-20-2009, 01:04 PM
Yep. The extensions are looking to be irritatingly long, though...

One more letter will cover all the DRM formats available today I think.

Dale

Barcey
04-24-2009, 07:00 AM
I think that the IDPF should state that if you add DRM the file extension must be .!epub

tirsales
04-24-2009, 07:41 AM
To make the object oriented paradigm work you actually need separate extensions for each form of DRM since a different program needs to be launched to read it.Not necessarily - you could just as well provide a single header-element that specifies the type of DRM used. Then you would have to start an interpreter (read header) which starts the corresponding DRM-reader.
But I agree that different file extensions would be better (can you imagine the amount of support-requests resulting from it otherwise?)

DaleDe
04-24-2009, 11:42 AM
Not necessarily - you could just as well provide a single header-element that specifies the type of DRM used. Then you would have to start an interpreter (read header) which starts the corresponding DRM-reader.
But I agree that different file extensions would be better (can you imagine the amount of support-requests resulting from it otherwise?)

You could certainly design Object oriented differently such as was done on the Palm (embedded header) or Mac (separate resource file) but for windows it works the way it works depending totally on the file extension. I am concerned about the user and support requests and disappointments are a major part of the reason I am concerned.

Dale

tirsales
04-24-2009, 12:46 PM
You could certainly design Object oriented differently such as was done on the Palm (embedded header) or Mac (separate resource file) but for windows it works the way it works depending totally on the file extension. I am concerned about the user and support requests and disappointments are a major part of the reason I am concerned.I know what you mean and I (totally) support your position - I just wanted to state that different file types with the same extension are possible (lets take different versions of PDF or DOC as examples)

=X=
04-24-2009, 02:28 PM
I believe that Adobe should not use the ePUB extension for eBooks that have DRM applied. They can do what they want with PDF but ePUB is not their format and they have no right to take it over with ADE based DRM.
Interesting point. I do agree with you that there is a problem and also some confusion.

However I feel the group to blame is not Adobe but IDPF. They are responsible for creating this format and did not do a thorough job.

It was the responsibility of the iDPF:
1- Create a universal ePUB logo.
2- Create a universal DRM solution.
3- Take into account devices with small memory footprints.
4- Create a certifiable ePUB format.

especially if they are claiming its a one size fits all format.

This way it would be clear to any person buying an eBook or buying an eBook Reader that if it sported the ePUB logo it would work.

Right now things are not so bad because Adobe is the only ePUB DRM in town. But enter another company that throws on another DRM solution and now we will have a huge headache on our hands.

=X=

netseeker
04-24-2009, 03:44 PM
However I feel the group to blame is not Adobe but IDPF. They are responsible for creating this format and did not do a thorough job.
We should blame both, IDPF for making some doubtful decisions when developing the ePub-standard and Adobe for delivering only a incomplete (and partially incompatible) implementation of that standard.

It was the responsibility of the iDPF:
1- Create a universal ePUB logo.
2- Create a universal DRM solution.
3- Take into account devices with small memory footprints.
4- Create a certifiable ePUB format.


Agreed.
If they would do, they would side with the Pro-DRM-faction. This might be just too "politically charged" for them.
They did indeed, but made some doubtful decisions (eg. to include SVG support)
What did you mean with "certifiable"? That ePub should become a certified standard according to another international organization for standardization (ISO, IETF, ..) or do you mean that IDPF should launch a public certification process?

Barcey
04-24-2009, 05:44 PM
Unfortunately when I load at the Board of Directors for IDPF I don't see this getting fixed.

http://www.idpf.org/about/boardofdirectors.htm

Open Standards are great for the publishers and the consumers. If you allow it to be encrypted with proprietary DRM and still allow it to be marketed as an open standard it no longer meets the consumer requirements of interoperability. This is just going to lead to upset customers. It's at best ill advised and at worst fraud.

IMHO EPUB encrypted with ADEPT is Adobe Digital Editions, it's not EPUB.

Andybaby
04-25-2009, 09:52 AM
doesn't part of the standard call for it to be able to be converted into other formats?
If DRM epubs dont allow for this, so then they are not epubs.

netseeker
04-25-2009, 04:01 PM
doesn't part of the standard call for it to be able to be converted into other formats?
Afaik no, even if many interpret the written purposes within the OPS, OCF and OEB specification documents that way.

wallcraft
04-26-2009, 09:05 AM
This makes perfect sense: .epub for DRM-free, .epuba for Adobe DRM, .epube for eReader DRM, etcetera. It would be in FictionWise's interest to use .epube (say) because that reduces the confusion over a 2nd DRM scheme. They also have gone through this in spades with .pdb. The problem is that Adobe has already "squatted" on .epub for ePub with Adobe DRM.

One approach would be to somehow get Adobe to stop using .epub for ePubs with Adobe DRM. Or we could standardize on .epubf (say) for DRM-free ePub. I was concerned that Adobe Digital Editions would not accept this, but the Windows version does not care what the extension is. However, you currently can't add .epubf files to the ADE library.

JSWolf
04-27-2009, 10:42 AM
Do you really want to see a word such as epube for the form,at of an eBook? Say it out loud to yourself. Personally, I think it's rather inappropriate. The easiest solution is to get Fictionwise to drop the nonsense about adding yet another DRM scheme to ePub.

DaleDe
04-27-2009, 11:07 AM
Do you really want to see a word such as epube for the form,at of an eBook? Say it out loud to yourself. Personally, I think it's rather inappropriate. The easiest solution is to get Fictionwise to drop the nonsense about adding yet another DRM scheme to ePub.

I take it you really like a monopoly by the way you are promoting this. do you have stock in Adobe?

Dale

=X=
04-27-2009, 11:56 AM
If they would do, they would side with the Pro-DRM-faction. This might be just too "politically charged" for them.

Yes I agree, and everyone save the (some) publishers/(some) authors belives DRM is evil and makes baby Jesus cry.
However I'd rather see a working DRM like DVDs than have what we have today, and ignoring DRM is just a naive attitude. IDPF should have addressed this when it created the ePUB standard especially if it was being touted as an Open format.



They did indeed, but made some doubtful decisions (eg. to include SVG support)

Well not really I can make an ePUB book that will not work on the SONY device. Now you can blame sony for that--and I wont disagree-- but you still have a perfectly legal ePUB that will not work on any device. That is not the case for LIT/MOBI/eReader.



What did you mean with "certifiable"? That ePub should become a certified standard according to another international organization for standardization (ISO, IETF, ..) or do you mean that IDPF should launch a public certification process?

Yea I guess, I was thinking more along the lines of POSIX, OpenGL, OMG, but I think that falls along the same line as ISO, IETF,IEEE.

The former just have tests to validate software and/or hardware to make sure one is compliant.

This makes perfect sense: .epub for DRM-free, .epuba for Adobe DRM, .epube for eReader DRM, etcetera. It would be in FictionWise's interest to use .epube (say) because that reduces the confusion over a 2nd DRM scheme. They also have gone through this in spades with .pdb. The problem is that Adobe has already "squatted" on .epub for ePub with Adobe DRM.

Wallcraft you are a smart guy... and maybe I'm not as smart as I though I was because after reading this my head hurt.

I honestly believe an extensions solution would be a nightmare. I can honestly not imaging trying to explain this to anybody that is not technical in nature.

I understand where your coming from but instead of patching something that is broken I say fix what is broken.

ePUB v2.0 needs to come out and address the ePUB branding issues and DRM issues. A consumer should not have to worry about the source of where they bought the ePUB they should be able to buy an ePUB from any source and play it on any source that supports ePUB.

Just like a DVD.


The problem is that Adobe has already "squatted" on .epub for ePub with Adobe DRM.

Yep that's smart business. What Adobe is trying to do is establish themselves as the defeacto standard for ePUB DRM. It was just as brilliant for them to kludge PDF and ePUB under the same DRM scheme. Now Adobe has a great marketing tool to say look at all the eBooks we have under DRM. Unfortunately it's at the consumer expense.

I can't blame Adobe that is just smart, and in the end it does not really mess up the consumer they still get what ultimately matters most to them content!

=X=

Jellby
04-27-2009, 11:57 AM
Actually, computers should stop assuming that "extension is everything". TIFFs and AVIs are containers with a single extension and lots of possible content, knowledgeable software knows (or should know) how to manage this, I don't see why it should be different with ePUB.

I agree it is going to be a problem for users if the same "name" is used for different incompatible DRMed formats, but it shouldn't be a problem for the software.

netseeker
04-27-2009, 12:33 PM
IDPF should have addressed this when it created the ePUB standard especially if it was being touted as an Open format.
I disagree and think it's good that they didn't include any statement about DRM in their specifications. But i get your point and it's not neccessary that we share the same opinion.

Well not really I can make an ePUB book that will not work on the SONY device. Now you can blame sony for that--and I wont disagree-- but you still have a perfectly legal ePUB that will not work on any device. That is not the case for LIT/MOBI/eReader.
You are right - but is it really the fault of the format? I don't think so. It seems that i've more technical reasons (point of view of a software developer) to criticize the ePub-specification. Despite that i think developers could implement a good and standard conforming implementation for ePub-reading software even if there are some features outlined in the specification which can be very hard to implement on mobile devices. Adobes (+Sonys) implementation isn't as good as it could/should be and i don't know any other useable implementation at the moment. We just need more ePub-reading software. LIT/Mobi had the same problems at the beginning - initially there weren't any other reading software available than those from Mobipocket (mobi) and Microsoft (lit).

=X=
04-27-2009, 02:03 PM
I disagree and think it's good that they didn't include any statement about DRM in their specifications. But i get your point and it's not neccessary that we share the same opinion.

Agreed


You are right - but is it really the fault of the format? I don't think so. It seems that i've more technical reasons (point of view of a software developer) to criticize the ePub-specification.

Well as a SW developer for many years I've seen many proposed standards come and go. The best standards are those that are rigorous enough to allow consistency yet flexible enough for developers/hardware vendors to implement a cost effective solution.

ePUB today is too flexibility. SONY's file limitation should not have happened. The spec should have provided for these memory constrained devices or excluded them form supporting ePUB.



Despite that i think developers could implement a good and standard conforming implementation for ePub-reading software even if there are some features outlined in the specification which can be very hard to implement on mobile devices. Adobes (+Sonys) implementation isn't as good as it could/should be and i don't know any other useable implementation at the moment. We just need more ePub-reading software. LIT/Mobi had the same problems at the beginning - initially there weren't any other reading software available than those from Mobipocket (mobi) and Microsoft (lit).

Right and that is what scares me. With MOBI/LIT one company had complete control of the clients developed, to ensure MOBI/LIT worked across whatever device was developed.

ePUB does not benefit from this and with a very loosely defined standard I see a bumpy road for ePUB.

I really want ePUB to succeed but fear without a conforming ePUB standard there will be many solutions of ePUB that will not work different devices.

JSWolf
04-27-2009, 02:09 PM
I take it you really like a monopoly by the way you are promoting this. do you have stock in Adobe?

Dale
It's just that we have enough issues with DRM as it is and a fairly tall tower of eBable. We don't need Fictionwise screwing with what could be the eBook standard and making it so confusing that it never does become the standard.

JSWolf
04-27-2009, 02:14 PM
Well not really I can make an ePUB book that will not work on the SONY device. Now you can blame sony for that--and I wont disagree-- but you still have a perfectly legal ePUB that will not work on any device. That is not the case for LIT/MOBI/eReader.
Actually, it is the case for Mobipocket. Some devices have an older version of Mobipocket Reader that will not work well or at all with current version Mobipocket files.

kovidgoyal
04-27-2009, 02:33 PM
Right and that is what scares me. With MOBI/LIT one company had complete control of the clients developed, to ensure MOBI/LIT worked across whatever device was developed.

ePUB does not benefit from this and with a very loosely defined standard I see a bumpy road for ePUB.

I really want ePUB to succeed but fear without a conforming ePUB standard there will be many solutions of ePUB that will not work different devices.

Actually EPUB is as loosely defined as XHTML+CSS which is plenty successfull. And the fact that there isn't one company guiding it's development is an advantage not otherwise. It will reach the level of maturity of MOBI (a much simpler format) far more quickly as a result. As for the 300K file limit that everyone keeps complaining about, it's really not an issue. It just requires tool support in epub creation tools.

As for DRM incompatibilities, DRM by its very nature has to be incompatible. If we had a DRM scheme was not incompatible across devices and software implementations, it would be like a PDF password.

DRM stands for Digital RIghts Management which means that publishers want to be able to manage what you are allowed to do with the book. If a DRM scheme allows a book to be used in many different software programs and devices, it is completely failing to provide any management.

As for the question of extensions, I think having one extension with various incompatible DRM schemes is an excellent thing. The time of ebooks and EPUB has come, nothing is going to stop them. This sort of craziness will hurt only one thig, DRM.

netseeker
04-27-2009, 02:42 PM
Well as a SW developer for many years I've seen many proposed standards come and go. The best standards are those that are rigorous enough to allow consistency yet flexible enough for developers/hardware vendors to implement a cost effective solution.

ePUB today is too flexibility. SONY's file limitation should not have happened. The spec should have provided for these memory constrained devices or excluded them form supporting ePUB.
I would have to re-read the specification documents to discuss this further, but i guess you are right. What i don't get is why the sony developers didn't choose another way to solve the memory issues. They must have been very "uninspired"...

ePUB does not benefit from this and with a very loosely defined standard I see a bumpy road for ePUB.

I really want ePUB to succeed but fear without a conforming ePUB standard there will be many solutions of ePUB that will not work different devices.
Yes, that's my worry too. I hope that the FBReader team will improve it's ePub-implementation and that a lot of other projects will add standard conforming (and well working) implementions soon.

PS: Sorry for my assumption that you aren't (or weren't) a sw developer...

AnemicOak
04-27-2009, 03:02 PM
What i don't get is why the sony developers didn't choose another way to solve the memory issues. They must have been very "uninspired"...


IIRC it was Adobe that developed the epub reader software for the Sony, not Sony.

netseeker
04-27-2009, 03:09 PM
IIRC it was Adobe that developed the epub reader software for the Sony, not Sony.
Until now i thought Sony did adapt the (at that time unofficial) mobile DE-SDK with Adobes help. Maybe i was wrong...

AnemicOak
04-27-2009, 03:12 PM
You could be right, I'm not entirely sure.

netseeker
04-27-2009, 03:28 PM
As for the question of extensions, I think having one extension with various incompatible DRM schemes is an excellent thing. The time of ebooks and EPUB has come, nothing is going to stop them. This sort of craziness will hurt only one thig, DRM.
Well, maybe not "excellent" (at least not for consumers) but my thoughts are very similiar to yours.

=X=
04-27-2009, 05:30 PM
Actually, it is the case for Mobipocket. Some devices have an older version of Mobipocket Reader that will not work well or at all with current version Mobipocket files.
Yea that is not really the same thing. The issue your pointing out is due to obsolescence. That is going to happen as long as technology is involved. ... Right I mean the PRS-500 doesn't support ePUB

What I'm talking about is current solutions. SONY is not obsolete in fact it's the only eInk device that supports ePUB. Yet there are ePubs that will not work with SONY.

Actually EPUB is as loosely defined as XHTML+CSS which is plenty successfull. And the fact that there isn't one company guiding it's development is an advantage not otherwise. It will reach the level of maturity of MOBI (a much simpler format) far more quickly as a result. As for the 300K file limit that everyone keeps complaining about, it's really not an issue. It just requires tool support in epub creation tools.

I think your not seeing my point, and I'll agree it's not too obvious. I just want one solution that works. I'm tired of dealing with all the different formats out there. I can't standardize on one format since often I can only finding certain books under MOBI/PDF/LIT/eReader/<your format here>.

I want ePUB to succeed esp since it has done a good job for the most part, but I find it failing in some key areas. Which leads to abuse from companies, the very nature of this post is an example.

What I'm gripping about is for the ePUB standard to fix this to prevent future abuse, or future misinterpretation of standards.

For me it's not so much SONY's 300KB file size limit that cause me concern, itt's the failed expectation that as long as I have an ePUB file I can read it on any ePUB device.

I would have to re-read the specification documents to discuss this further, but i guess you are right. What i don't get is why the sony developers didn't choose another way to solve the memory issues. They must have been very "uninspired"...


Yes, that's my worry too. I hope that the FBReader team will improve it's ePub-implementation and that a lot of other projects will add standard conforming (and well working) implementions soon.

PS: Sorry for my assumption that you aren't (or weren't) a sw developer...
No worries this board is quite diverse message board.

=X=

Valloric
04-27-2009, 05:33 PM
ePUB today is too flexibility.

With this I somewhat agree. The epub spec has too many sections that start with "can" and end with "don't have to". But as Sorotokin said in a thread here on mobileread, when you're creating a standard you can't just do what you think is best; there are politics involved. There are a lot of members in the IDPF, and some kind of consensus has to be reached.

SONY's file limitation should not have happened. The spec should have provided for these memory constrained devices or excluded them form supporting ePUB.

This is silly. You can't just proclaim that all devices should parse content files of unlimited length because every device is memory constrained in some way. And yet you cannot pigeonhole the standard to 2007 and set arbitrary limits on content files. Ten years from now (probably a lot sooner) even embedded devices will have more than enough resources to parse any kind of epub file, so such limitations would be a hindrance.

netseeker
04-27-2009, 05:52 PM
And yet you cannot pigeonhole the standard to 2007 and set arbitrary limits on content files. Ten years from now (probably a lot sooner) even embedded devices will have more than enough resources to parse any kind of epub file, so such limitations would be a hindrance.
Sorry if i'm interfering but nobody says that they should include limitations. Though they could make clear what is the expected handling on devices with low resources. Sax and StAX, HTTP 1.1, MIME and a lot other specifications provide implicit solutions for low-resource devices. Why should a format specification like ePub doesn't take care of such concerns?

From the OPS specification:
The specification is intended to give content providers (e.g. publishers, authors, and others who have content to be displayed) and publication tool providers, minimal and common guidelines that ensure fidelity, accuracy, accessibility, and adequate presentation of electronic content over various Reading Systems.

Valloric
04-27-2009, 06:06 PM
Though they could make clear what is the expected handling on devices with low resources.

Tell me, what do you think should be the expected handling for huge single file epub books on a device like the Sony Reader?

kovidgoyal
04-27-2009, 06:07 PM
For me it's not so much SONY's 300KB file size limit that cause me concern, itt's the failed expectation that as long as I have an ePUB file I can read it on any ePUB device.


But that's unrealistic, you cant both have flexibilty and "read on any device", because flexibility requires processing power/memory to back it up. In the long run, I think flexibility is far more important that read anywhere.

kovidgoyal
04-27-2009, 06:07 PM
Tell me, what do you think should be the expected handling for huge single file epub books on a device like the Sony Reader?

fallback to non CSS based rendering. in that case you dont have to load the whle html tree into memory

wallcraft
04-27-2009, 06:11 PM
As for the question of extensions, I think having one extension with various incompatible DRM schemes is an excellent thing. The time of ebooks and EPUB has come, nothing is going to stop them. This sort of craziness will hurt only one thig, DRM. The problem, though, is that the same extension is also used for DRM-free ePubs. Perhaps we should use .epubf (or .fpub) for DRM-free ePubs and not worry about what the DRM vendors are doing. We would then need a logo and icon for DRM-free ePubs. This is =X='s branding point, but I don't see IDPF as likely to take the lead.

JSWolf
04-27-2009, 06:18 PM
The problem, though, is that the same extension is also used for DRM-free ePubs. Perhaps we should use .epubf (or .fpub) for DRM-free ePubs and not worry about what the DRM vendors are doing. We would then need a logo and icon for DRM-free ePubs. This is =X='s branding point, but I don't see IDPF as likely to take the lead.
So why not also do the same for all the other formats?

netseeker
04-27-2009, 06:19 PM
Tell me, what do you think should be the expected handling for huge single file epub books on a device like the Sony Reader?
Well, i'm not a contributor of the ePub-specification and can only speak for myself. Why doesn't the reading software use a stax-like aproach when parsing XHTML for example? Why does the epub-producer have to split the file into parts if just those parts that are required could be read? It's not easy to implement such solutions (not because of the XML but because of the CSS-selectors for example) but developers do this day for day if they know that the targeted plattform is low on resources. A specification can take account of such concerns and include (or point to) best practices for such scenarios. It can also explain such scenarios in a more abstract manner than i did here.

wallcraft
04-27-2009, 06:22 PM
For me it's not so much SONY's 300KB file size limit that cause me concern, itt's the failed expectation that as long as I have an ePUB file I can read it on any ePUB device. It is certainly a failure on Adobe's part that they will add their DRM to an ePub which isn't readable by their own mobile Adobe Digital Editions.

For DRM-free ePubs the situation is a bit different. Anyone can call their ebook an ePub, and there will be "standard conforming" ePubs that don't display on all devices. On the other hand, Calibre has demonstrated that a desktop-based format shifter can customize an ePub for a given device and Savory (http://www.mobileread.com/forums/showthread.php?t=44122) on the Kindle 2 is an indication that the same could be done on handheld devices directly.

Valloric
04-27-2009, 06:23 PM
fallback to non CSS based rendering. in that case you dont have to load the whle html tree into memory

Then you would have users complaining how the epub doesn't display properly. :)

wallcraft
04-27-2009, 06:27 PM
So why not also do the same for all the other formats? We could, but ePub is the only one not owned by a single vendor. I don't know that there is the same expectation that a DRM-free MOBI (say) will be readable by non-MobiPocket readers.

kovidgoyal
04-27-2009, 06:28 PM
Then you would have users complaining how the epub doesn't display properly. :)

Better than complaining tha it doesn't display at all :)

Moejoe
04-28-2009, 09:32 AM
How about:

.epub = non-drm

.crap = with drm

No confusion there :)

ilovejedd
04-28-2009, 10:17 AM
How about:
.epub = non-drm
.crap = with drm
No confusion there :)
I heartily agree. :)

tirsales
04-28-2009, 10:20 AM
.epub = non-drm

.crap = with drmWonderful! Two small words, describing whatever needed ;)
Just add some kind of X (.crapA for Adobe crap, .crapF for Fictionwise crap, etc)

=X=
04-28-2009, 12:26 PM
The problem, though, is that the same extension is also used for DRM-free ePubs. Perhaps we should use .epubf (or .fpub) for DRM-free ePubs and not worry about what the DRM vendors are doing. We would then need a logo and icon for DRM-free ePubs. This is =X='s branding point, but I don't see IDPF as likely to take the lead.

That's a great idea! What a V8 moment. We have some talented graphic artists here anybody want to take a first stab?

I'll create a new thread.

=X=

=X=
04-28-2009, 12:32 PM
For those that are interesting in Branding a DRM-Free(liberated) ePUB I've started a new thread here MobileRead Unite! Create a Logo for DRM-Free(liberated) ePUB (http://www.mobileread.com/forums/showthread.php?p=441714#post441714)

joblack
05-05-2009, 11:33 PM
I believe that Adobe should not use the ePUB extension for eBooks that have DRM applied. They can do what they want with PDF but ePUB is not their format and they have no right to take it over with ADE based DRM. They should develop a new extension for use on DRM'd books. The end user can easily be confused and not be able to read what they purchased. Only a very few devices actually support DRM on ePUB but many devices have support for ePUB.

For example Sony is careful to use LRF and LRX to distinguish non-DRM from DRM ebooks. Others should take this lead and adopt it as well. Several others also adopt this rule.

I think the ePUB committee should outlaw the use of the ePUB extension for DRM'd eBooks. Their extension has been hijacked for commercial purposes IMHO.

Dale

They can use whatever extension they want. Extensions aren't licensable ...

Kris777
05-06-2009, 12:37 AM
How about:

.epub = non-drm

.crap = with drm

No confusion there :)

.epub = non-drm

.bupe = with drm

;)