which format will win?

[kennyc]

Originally Posted by JSWolf

https://www.mobileread.com/forums/sho...590#post431590

There you go.

Does not display properly in FBReader. Looks good in Adobe DE.

[JSWolf]

Originally Posted by kennyc

Does not display properly in FBReader. Looks good in Adobe DE.

But we are not talking FBReader as we know FBReader is too buggy to matter.

[kennyc]

Originally Posted by JSWolf

But we are not talking FBReader as we know FBReader is too buggy to matter.

I don't know if it's buggy or not. It displays most of my epubs correctly. This one however is something of a special case and I'm pointing out that it did not work properly in one well-known epub reader program.

[JSWolf]

Originally Posted by kennyc

I don't know if it's buggy or not. It displays most of my epubs correctly. This one however is something of a special case and I'm pointing out that it did not work properly in one well-known epub reader program.

Does FBReader support embedded fonts and SVG? If not, then it's the fault of FBReader that it doesn't work.

[kennyc]

Originally Posted by JSWolf

Does FBReader support embedded fonts and SVG? If not, then it's the fault of FBReader that it doesn't work.

Choices are made in all implementations. Many hate Adobe's implementation of epub as well.

Again all I'm saying is that your example does not display properly in FBReader.

[frank.w]

... so long as there are tools around to do a good job on the conversion.

I'm trying Calibre at the moment (more for organizing my eLibrary, but it does conversion also). No troubles so far, but I've only play around with easy stuff (text only) and only just starting out.

Frank

[charleski]

Originally Posted by kennyc

Choices are made in all implementations. Many hate Adobe's implementation of epub as well.

It's not optional
"OPS Reading Systems must support SVG (Scalable Vector Graphics) as an OPS Core Media Type. "

A reader that can't handle SVG is not compliant.

[frabjous]

Originally Posted by JSWolf

https://www.mobileread.com/forums/sho...590#post431590

There you go.

Thanks.

First, some observations.

1. There is no MathML in that document. The equations are done using embedded SVGs, which is why it works so-so on Sonys.

2. This also explains why a relatively short article (which wouldn't be more than 10 pages printed) takes up a whopping 2.1 MB.

3. It is clearly not adequate for anything. And it certainly refutes your own argument that this format works better across different devices.

Here's what it looks like in calibre.



I get significantly better results in EPUBreader for Firefox, though it's still not adequate. You'll see that parts of the equations are printed on top of each other, tops of characters are often shaved off (this was worse elsewhere in the document) and the whitespace usage is wildly inconsistent. You'll also notice that italics text both uses an italics font, but is also made oblique, thus making it look pretty bad.



Here's what the extracted XHTML and SVGs look like together in Opera (presumably also anything based on Opera mobile)



And in Google Chrome:



If you were reading this on anything Safari-based (which would be most people using iPads or IPhones, etc.), the SVG support isn't terrible (though notice again that parts are shaved off), but the real problem here is how terrible the text looks. (And yes, this is exactly how it looked.)



By far the best representation was in ADE. I guess ADE does support SVG (not MathML, but as noted, there is none here). But as I predicted, when you change the screen size to use shorter lines, the whitespace usage is very noticeable... notice the huge gaps between certain words. This could all be fixed with hyphenation, and something like the breqn package for LaTeX that knows good places to put line breaks in equations.



I accidentally left my Sony at work on Friday, but I'll test on there next week.

Now I realize that these are not problems with the format, or this document in question, but with this software. My original point in this thread was that in the future, when ePub rendering improves, when support for MathML and SVG became consistent and reliable, at that point, perhaps ePub will surpass PDF in my estimation. But at the moment, the PDF format is still necessary for getting quality results.

[kennyc]

Originally Posted by charleski

It's not optional
"OPS Reading Systems must support SVG (Scalable Vector Graphics) as an OPS Core Media Type. "

A reader that can't handle SVG is not compliant.

There ya go then.

It was still a choice made in implementing it.

BTW the title of that document is:

Open Publication Structure (OPS) 2.0 v0.9871.0

Recommended Specification July 11, 2007September 11, 2007

[DawnFalcon]

Originally Posted by frabjous

Semantics? Are you somehow suggesting that Word and InDesign are the same product with different names?

No, you're suggesting that the vast majority of people don't use WYSIWYG editors for working with day to day.

I think most authors should use WYSIWYM editors.

I strongly disagree. Only very specialist applications - and I'm talking the equivalent of brain surgery - should need to deviate one iota from WYSIWYG.

Please give one example of one way in which CSS interferes with the kind of "WYSIWYG" (notice the scare quotes) editor you have in mind.

Where are they? The WYWIWYG web editors, that is? Find some modern ones and you'll be right. The issue is well known.

There is no such thing as a true WYSIWYG editor for websites. (Even if there were something close, the differences in browsers would cause trouble.)

Yes, because the standard is so hard to implement that you end up with radically different results! This is a direct strike against it. Again, pre-CSS there were some editors which gave pretty good results...

But separation of form from content is definitely not silly.

I didn't say it was. I am objecting to the implementation, not the concept. For example, you don't have to allow free editing of font size etc, but instead use a style editor...

WYSIWYG editors encourage people to put in manual line breaks or page breaks that only work well for their display. It encourages people not to think in terms of rules or semantic categories (e.g., this is a chapter title, this is a subsection title, this is a display, this is a citation, this is a comment), but in terms of individual parts of individual documents, and thus to inconsistencies.

No, you just need a moderately smart parser which can handle 95% of situations sanely. The other 5% can be tweaked by a true web designer if that last 0.0001 seconds of loading speed is important.

And nuts - you can work with stylesets perfectly well in word. You can also chose not to, sure, which is messy. It's down to the GUI and how the user uses the program, and you're mixing up "sloppy" and "WYSIWYG" - when you're not using something like CSS which is very very hard to use in a WYWIWYG environment!

WYSIWYG-produced material is also inefficient in file size, and in a variety of other ways.

So what? The difference in 99.9% of cases, especially for simple websites, is absolutely insignificant. And you're certainly proving my point, originally made to Ahi, about TeX users being completely out of step with modern mass usage of computer programs.

But that's is not the final output--since LyX then takes the source generated in this way and optimizes the paragraph layout...

That's true WYWIWYG. Simply because it uses a parser to adjust things behind the scenes doesn't make the blindest bit of difference. Aim for a 95% "sanity rate", and you'll be doing good. Sure, it'll have slightly messy code in the 5% of cases. But that's really not critical - especially since you can run it through /several/ sanity checkers...

(But only if the standards are implemented fully, which again CSS fails hard at!)

The difference is, with a sane standard in place of CSS, people wouldn't need web designers for even the simplest web sites. And of course we can't have THAT. /Sarcasm.

[frabjous]

Originally Posted by DawnFalcon

No, you're suggesting that the vast majority of people don't use WYSIWYG editors for working with day to day.

I never suggested anything remotely like that. In fact, you are, because you suggested none exist.

I strongly disagree. Only very specialist applications - and I'm talking the equivalent of brain surgery - should need to deviate one iota from WYSIWYG.

No argument for this conclusion. Typical.

Where are they? The WYWIWYG web editors, that is? Find some modern ones and you'll be right. The issue is well known.

I haven't looked much into it... but Dreamweaver? KomPozer? Google docs? Any widely used WordProcessor that can export to HTML? Aren't most websites made this way?

I didn't say it was. I am objecting to the implementation, not the concept. For example, you don't have to allow free editing of font size etc, but instead use a style editor...

What you are describing is precisely what I suggested earlier.

And nuts - you can work with stylesets perfectly well in word. You can also chose not to, sure, which is messy. It's down to the GUI and how the user uses the program, and you're mixing up "sloppy" and "WYSIWYG" - when you're not using something like CSS which is very very hard to use in a WYWIWYG environment!

I didn't say you couldn't do it with WYSIWYG, only that it is not encouraged--the sloppiness is encouraged instead. Someone who uses styles consistently with a Word Processor is still going to get decent output. In fact, I made precisely this point in another thread.

I think at that point, however, it's just easier to see the mark-up, however.

The difference is, with a sane standard in place of CSS, people wouldn't need web designers for even the simplest web sites. And of course we can't have THAT. /Sarcasm.

It is you, not I, that is arguing in favor of depriving most people the ability to create typographically proper documents. WYSIWYM editors are easy to use, and could be passed into something that used that source to create nice looking and typographically correct documents.

It is entirely possible to have a very easy to use GUI for creating and modifying CSS -- so long as that was kept separate from the content creation part of things, all would be well.

[DawnFalcon]

Originally Posted by frabjous

I never suggested anything remotely like that. In fact, you are, because you suggested none exist.

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

I haven't looked much into it...

Exactly.

I think at that point, however, it's just easier to see the mark-up, however.

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

WYSIWYM editors are easy to use

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.

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.

When it comes to a mass medium like the web, that should be clearly and strongly unacceptable! The ability of the average layman to create and maintain a basic, reasonably good looking website should be a core goal of the web... (And that means a WYSIWYG editor, like the other programs they use on a day to day basis!)

[pdurrant]

Originally Posted by frabjous

That's what I wrote in the paragraph above the one you quote!

Umm... You wrote that you knew that SVG worked on the Sony 505. You then stated that SVG was not supported by Adobe Digital Editions (ADE).

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.

[pdurrant]

Originally Posted by kennyc

There ya go then.

BTW the title of that document is:

Open Publication Structure (OPS) 2.0 v0.9871.0

Recommended Specification July 11, 2007September 11, 2007

Here's a reference to the OPS 2.0 v1.0 final specificaton.

http://www.idpf.org/2007/ops/OPS_2.0...tml#Section2.5

"OPS Reading Systems must support SVG (Scalable Vector Graphics) as an OPS Core Media Type."

emphasis in original.

[kennyc]

Originally Posted by pdurrant

Here's a reference to the OPS 2.0 v1.0 final specificaton.

http://www.idpf.org/2007/ops/OPS_2.0...tml#Section2.5



emphasis in original.

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.