which format will win?

[JSWolf]

The sample was created using MathML. It does have embedded fonts which is which is part of why it doesn't really work in the web browsers.

As for Calibre's viewer, open a ticket and attach the ePub since clearly it's a flaw with Calibre's viewer.

[charleski]

Originally Posted by kennyc

Again my point:

The DOCUMENT AS A WHOLE SAYS:

Recommended Specification

It's a recommendation. Any particular implementation might or might not follow it. Clearly the FBReader does not follow this particular item.

It's not a BFD, it's simply a fact.

I sincerely hope you realise how irrelevant your point is and are just being argumentative.

If FBReader doesn't want to follow the spec, fine, but it can't be used as a representative ePub reader in any manner.

[Format C:]

Originally Posted by nick_

I just saw that you have created ... SIX different documents for different devices!!!

Exactly my point!

And why six documents and not ten? Or 20?

We need a format with just one document, not multiple.

Latex and pdf were created for printed paper, not for screens. Sure, there are people who learned to use these formats and they don't want to learn anything else. This does not change the fact that those are printed paper formats. Tex and Latex are around for 30 years and they are marginal formats at best. They are not going to get more popular in the future, they will slowly disappear.


(The topic is: which format will win?)

I think that a unformatted source with 20 (or 20 thousand) different "layout recipes" will do.

• The author provide the content
• The device producer provide the template for the "layout recipe", with the embedded rules about what the device can / cannot do
• The publisher provides the formatting template
• The dealer combines the device template and the publisher's formatting and sends them with the ebook
• The user can edit, modify and create its own "layout recipe" to have the most enjoyable reading experience.

In a world of standards, it all can be done with very simple UIs.

To stay in topic, wich format will win, there are actually two answers:

1. The one with the hardest to circumvent DRM schema (if it will ever exist)
2. The one which is proprietary to the coolest device in the market (if iPad had some function in it, other than coolness, I'd say iBooks, but I dont believe enough people will buy those useless bricks, no matter how cool they are...)

[Format C:]

Originally Posted by BillSmithBooks

The funny thing about the whole DRM argument is how easily DRM can be circumvented by even the most un-nerdy noob:

Use a camera.

Display each page of your ebook, take a picture of each page, set up your ebook as a series of JPEGs, read on any picture viewer.

Not elegant and a little time consuming, but certainly usable.

(I hope posting this "secret" doesn't run afoul of Mobile Read's TOS since it technically is a way to overcome DRM...but it is interesting to note how the thousands (millions?) of dollars spent to develop these sophisticated DRM schemes can be foiled by someone with a $20 disposable digital camera).

The best DRM circumventing machine has been around for almost two centuries...

[DawnFalcon]

Originally Posted by Format C:

I think that a unformatted source with 20 (or 20 thousand) different "layout recipes" will do.

Only for really simply laid-out books where the layout itself doesn't matter to the content. Rather, what needs to be available is an template overlay system where you can overwrite certain layout settings (and leave the others alone).

That's something which can be handled on the device, but a specification for it would be nice... (And it should be trivial to do the basics like margin settings, fonts and font size via a GUI menu, for that matter)

[kennyc]

Originally Posted by charleski

I sincerely hope you realise how irrelevant your point is and are just being argumentative.

If FBReader doesn't want to follow the spec, fine, but it can't be used as a representative ePub reader in any manner.

I hope you realize that this whole side-topic is irrelevant. I stated that the document presented did not work in fbreader. It doesn't.

[delphidb96]

Originally Posted by HarryT

That's not correct. It's Mobi who don't allow you to have other DRM formats on the device; Adobe have no problem with it. Thus you have the Sony Reader, which supports both ADE and BBeB DRM, and the nook, which supports both ADE and eReader DRM, for example.

Actually, it's Mobipocket - the company - which prevents mutiple DRM'd formats in one device. Mobi - the ebook format - doesn't care one whit.

Derek

[DawnFalcon]

Originally Posted by delphidb96

Actually, it's Mobipocket - the company - which prevents mutiple DRM'd formats in one device.

Nitpicking

But given the Nook does it's DRM, both kinds, though ADE and the fact that Sony are phasing out BBeB for ePub... my point stands. The choice is Mobipocket DRM or ADE DRM.

[frabjous]

Originally Posted by DawnFalcon

No, I said no deacent web design WYSIWYG interfaces exist. Most programs used by computer users are WYSIWYG!

I never said that decent WYSIWYG editors exist. If that was your claim, then I agree. My point was that the lack of them is not the fault of CSS, and that WYSIWYG editors haven't ceased to exist since the advent of CSS.

It's not really worth arguing about. Here is a case where you'll have to admit that yours is a lost cause. CSS is here to stay, like it or not.

Again, you're expecting people to do the equivalent of brain surgery to make a web page!

I said I found it easier to just look at the mark-up. I didn't recommend it for others. This is not brain surgery believe me. But that was just comparing it to using styles on a traditional word processor.

What I actually explicitly advocated for the casual user is WYSIWYM, which is easier to use than WYSIWYG.

Suresure, that's why they're dominant...oh wait, they're not. They're a specialist and rapidly dying breed outside a few narrow fields.

Where are you getting these assumptions from? Their usage has only increased, and it's a fairly new concept, developed largely because of the crap you get from WYSIWYG for the web.

In any case, number of users does not reflect quality. (Consider Internet Explorer.)

And there there is no need whatsoever, except to protect web designer's jobs, to force artificial separation at the GUI end onto the user. A properly designed standard can and should allow WYSIWYG editing. In good part, the clunky and poorly defined nature of CSS has created a situation where you either code or you go home.

I have already given reasons for the necessity of separating form and content. For you to say there is no reason without responding to those considerations is just silly.

To suggest that traditional WYSIWYG is the only way to allow ordinary people to create content is just incorrect. And I think most ordinary people aren't interested in creating style, just content.

And even if they did care about style, as I noted, it is entirely possible to create a very intuitive interface for creating CSS. And even if there weren't such a thing, it is really not very complicated. I am not a web designer. I have no formal training in programming. My degrees are all in the humanities. But I don't find CSS in the least intimidating.

I assumed that you were making a distinction between the ePub reader implemented on the Sony 505 and the desktop ADE software. Perhaps you just typed something you didn't mean.

Yeah, I expressed myself poorly, sorry. I didn't know that it supported SVG, but I was pretty sure it didn't support both, which was all I meant.

Originally Posted by JSWolf

The sample was created using MathML. It does have embedded fonts which is which is part of why it doesn't really work in the web browsers.

It may well have been created by converting MathML to SVG, but open the source, and it'll become very evidence that it's all SVG. Indeed, "svg" is by far the most common XHTML tag in that document.

In any case, dedicated eBook readers that support ePub are very rare in the grand scheme of things (since that excludes Kindles). Most people who would be able to read it at all would be reading it on a web browser, or something calling upon web browser technology on a netbook or tablet.

If you were the author of that document, would you trust it being distributed only in that form? Be honest.

But even if these compatibility problems didn't exist, it still wouldn't look as good as a PDF made for my reader.

As for Calibre's viewer, open a ticket and attach the ePub since clearly it's a flaw with Calibre's viewer.

Might be worth doing so, but I expect Kovid at this point isn't professing support for SVG, and even if he is, I'm sure he's just adapting code from another open source library. The viewer is basically built on the WebKit library, and until that improves, I doubt calibre will.

[DawnFalcon]

Originally Posted by frabjous

I never said that decent WYSIWYG editors exist. If that was your claim, then I agree. My point was that the lack of them is not the fault of CSS.

Oh? A standard so arcane major browsers can't do it properly? A standard which killed off WYSIWYG editors which were coming along nicely before? No, CSS is most certainly to blame.

You think that's brain surgery? What are you talking about? WYSIWYM is much easier to use than WYSIWYG.

Absolute and total nonsense. There is a good reason basically every single program out there for the mass market is WYSIWYG, whereas WYSIWYM programs are for highly technical specialists in narrow markets.

I have already given reasons for the necessity of separating form and content.

There is good reason to separate them in terms of files, yes. But not in the UI presented to the user of the program: that simply needs to be managed such that you generate form and function files by using, for example, stylesets.

I think most ordinary people aren't interested in creating style, just content.

So basically you want to disenfranchise people from making websites, keeping it to the realm of the specialists. Lovely! It's precisely that attitude which I intensely dislike.

And even if they did care about style, as I noted, it is entirely possible to create a very intuitive interface for creating CSS.

LINK!

(And "intuitive" means it cannot contain ANY visible scripting, let alone coding ofc...)

[frabjous]

{Oh? A standard so arcane major browsers can't do it properly? A standard which killed off WYSIWYG editors which were coming along nicely before? No, CSS is most certainly to blame.

Again you claim falsely that WYSIWYG editors have fallen off in usage.

And while no other browser does CSS perfectly, everything except IE is close enough that's it's not really an issue. And IE's noncompliance is deliberate.

Absolute and total nonsense. There is a good reason basically every single program out there for the mass market is WYSIWYG, whereas WYSIWYM programs are for highly technical specialists in narrow markets.

WYSIWYM is not made for specialized disciplines! What gave you that idea? You are using one right now to post this message on MobileRead. They are standard on most blogs software. They are becoming more and more common as the web is offering more and more people the chance to post content. This is a little less WYSIWYM than I would find ideal: I'd prefer that italics look in italics and bold looks in bold, the way they do in LyX, and more functions of course, but it's close.

But even if some mark-up tags remain, surely they're not rocket science. You yourself did a virtual "/sarcasm" earlier, which is something i'm seeing more and more of, which suggests people could easily get used to such things.

There is good reason to separate them in terms of files, yes. But not in the UI presented to the user of the program: that simply needs to be managed such that you generate form and function files by using, for example, stylesets.

Managed user interfaces that give you a choice of stylesets is precisely what I advocated earlier and you mocked. This is precisely what WYSIWYM editors do, and it's precisely what I'm advocating.

So basically you want to disenfranchise people from making websites, keeping it to the realm of the specialists. Lovely! It's precisely that attitude which I intensely dislike.

You are fully of incorrect assumptions about what I'm advocating.

(And "intuitive" means it cannot contain ANY visible scripting, let alone coding ofc...)

Download and try LyX. You'll see that's precisely what it's like. It's got less visible code than Mobileread's "Go Advanced" does.

[DawnFalcon]

Originally Posted by frabjous

WYSIWYM is not made for specialized disciplines! What gave you that idea? You are using one right now to post this message on MobileRead.

Yes, and that's why a massive amount of people DON'T use "advanced", and just ignore the "advanced" formatting options. WYSIWYG hacks for bulletin boards are among the most commonly used - many are TinyMCE-based, for example.

Indeed, this forum is unusual these days in that it shows the tags. Most of the forums I use simply display the formatting in the edit box. Heck, 99% of my Foswiki editing these days doesn't involve dropping into tag-editing mode.

(And the other 1% is when I'm effectively writing applications in Foswiki, which is precisely the sort of thing I'd expect to be scripting!*)

You are fully of incorrect assumptions about what I'm advocating.

You're advocating non-WYSIWYG interfaces and CSS-as-a-good-soloution. No?

Download and try LyX. You'll see that's precisely what it's like. It's got less visible code than Mobileread's "Go Advanced" does.

I'm not interested in yet another app which doesn't do WYSIWYG editing, designed for a specialist market. Especially one which uses TeX, not a XML-based markup language.

Still waiting on the CSS editor which has an intuitive interface...


*Even then: I've worked at a games company where their editor used a visual scripting system. There was NO textual scripting interface (which has a few drawbacks, but they're not really relevant to this discussion, or for 99% of what you do with it) and it allowed VERY rapid prototyping and development! The best designer couldn't code one line, but did some amazing things with that engine!

[frabjous]

Originally Posted by DawnFalcon

Yes, and that's why a massive amount of people DON'T use "advanced", and just ignore the "advanced" formatting options.

Which is perfectly fine. If what you're writing is plain text, that's what it should be.

Indeed, this forum is unusual these days in that it shows the tags. Most of the forums I use simply display the formatting in the edit box. Heck, 99% of my Foswiki editing these days doesn't involve dropping into tag-editing mode.

These are precisely the kinds of editors I'm advocating for casual users. (NOT for professional publishers.) These are not WYSIWYG, since you're limited in the tags you can choose to semantic relevant ones, not to mention that the line breaks, exact placement, etc., will be different once hitting submit. (Or you resize your browser window.) Everything will look different if the CSS is changed.

You're advocating non-WYSIWYG interfaces and CSS-as-a-good-soloution. No?

Quasi-WYSIWYG (WYSIWYM), with GUIs to edit CSS, yes.

CSS is great. For example, I override MobilRead's CSS and so for me it looks like this:



We should have such control over ebooks, yes.

Still waiting on the CSS editor which has an intuitive interface...

Here's what I mean by a GUI to edit CSS. I couldn't find one accessible to everyone online, but there's one built into the software faculty can use to build course webpages at the university at which I teach. Basically it looks like this. There is a sample display with a generic title, a generic subtitle, a generic table, a generic paragraph, and so on. You click on these and a pop-up box where choose the color, font, font-size you'd prefer. This style is then uniformly applied to all the content on the site. Students with disabilities, however, can override your choices with ones with greater contrast, or a larger font, etc.

Sure, it doesn't give you as much control as writing the CSS yourself, but it's definitely good enough for casual users to design their own pages.

The important thing is that this is kept separate from the interfaces where you add content.

I'm not interested in yet another app which doesn't do WYSIWYG editing, designed for a specialist market. Especially one which uses TeX, not a XML-based markup language.

What differences does it make what mark-up language it uses? You don't have to edit it directly, that was the point. (And it has a function to export to HTML.)

In any case, if you're going to make accusations about something, shouldn't you know what it is?

[DawnFalcon]

Because it strongly affects ongoing maintenance and usability. In this day and age, anything not using XML needs a darn good excuse (And CSS in particular dosn't have one!). Why should I be locked into TeX parsers rather than XML ones?

(And sure, you can convert. But conversion tends to be a lossy process, and one which needs direct script editing to fix...)

There are only a very few, very poor WYSIWYG editors for web pages as a direct result of the current implementation of CSS, and HTML5 looks to make the problem considerably worse, not better, by upping the complexity without addressing the usability issues.

WYSIWYM is based on a fundamentally different philosophy to WYSIWYG (not "quasi" anything), and there's a good reason it's not used by mass market programs! Yes, software needs to be smarter to come up with sane solutions within a WYSIWYG GUI, but it's been managed in most fields: There should be a web editor sitting alongside Word and alongside Writer. (Sure, they can save-as HTML themselves. The results are very crude...)

Again, there's not a generally applicable, easy-to-use web editor precisely because of the particular way CSS+HTML is structured. The lack of such carries the argument, unless and until one exists: professional web designers script directly, and they've structured the web's architecture around their desires (I'll admit mostly unintentionally, but it's a positive feedback cycle because they're the people with the most time to dedicate to it) and needs.

As one example - because of the non-compliant CSS implementations of every major browser, a WYSIWYG editor can either only create a page which looks good in a given rendering engine, or it needs to support multiple rendering engines (Not impossibly, but a pain in the ass) and be able to handle the gross changes between them automagically so far as is possible, which dramatically adds to the complexity of the task.

And CSS 5 support looks to be even more fragmented than support than 2.1!

(Oh, and my interface with these forums is a greasemonkey-modified Firefox interface which works quite differently from the standard view, but it's going well beyond CSS changes...most people find it confusing, but the author and several other people such as myself like it. Now if he can actually get round to replacing a certain lump of code and making it freely distributable...)

[frabjous]

Originally Posted by DawnFalcon

. Why should I be locked into TeX parsers rather than XML ones?

I was just using that as an example of the kind of editor I had in mind. You could certainly have one that used XML as its own underlying code. Clearly the reason for it to use TeX is so it can make use of TeX's typesetting algorithms, for which nothing of comparable quality exists for XML for the same price and availability. Prince XML comes close, but is not open source.

I don't know whether or not a good WYSIWY-whatever editor exists for web pages. I have no need of one. But nothing you've written has provided a single reason for why there couldn't be one. I even asked you for a reason, and you've yet to provide one. You've simply asserted over and over that it's a fact. Anyway, CSS is a fait accompli. You're going to have resign yourself to that fact.

Aside from IE, CSS noncompliance is really not that bad... and certainly it's fine for the needs of the casual user.