Comments on: The shape of EPUB to come, #2: Hyphenation http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/ News & views on e-books, libraries, publishing and related topics Tue, 07 Oct 2008 14:04:23 +0000 http://wordpress.org/?v=2.6.2 By: Tamas Simon http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760101 Tamas Simon Thu, 10 Apr 2008 22:49:40 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760101 IMO instead of comities we need a good open-source implementation - both reader and author tool. This would evolve faster than the standard and would provide a way to try new ideas. I come from a CORBA background. Though CORBA is pretty much dead because the OMG - the group overseeing the standard - reacted way too slow some gurus started a small company called ZeroC, open-sourced the product, fixed the old specs where they were lacking and simply are just doing the right thing. I wonder if this will ever happen with EPUBS. As you know from my posts... I'm not a big fan... IMO instead of comities we need a good open-source implementation - both reader and author tool.
This would evolve faster than the standard and would provide a way to try new ideas.

I come from a CORBA background.
Though CORBA is pretty much dead because the OMG - the group overseeing the standard - reacted way too slow some gurus started a small company called ZeroC, open-sourced the product, fixed the old specs where they were lacking and simply are just doing the right thing.

I wonder if this will ever happen with EPUBS.

As you know from my posts… I’m not a big fan…

]]> By: Aaron S. Miller, CTO of BookGlutton http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760078 Aaron S. Miller, CTO of BookGlutton Thu, 10 Apr 2008 21:56:39 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760078 CSS is the way to nice typography in epubs. Rather than picking out properties to include, the OPS spec should REQUIRE ALL reading systems to be CSS2 compliant first, and recommend on top of that. This will help usher in all the goodness of CSS3 that is around the corner, and it won't do any harm to backward compatibility with older versions of OPS. This is contrary to the approach taken right now, which I think favors hardware systems by selectively including certain CSS properties and not others, and by forbidding script interpretation, which at is the heart of cross-browser rendering consistency and which, with monstrosities like Internet Explorer 8 out there, is our only hope of having good-looking books on-line. CSS is the way to nice typography in epubs. Rather than picking out properties to include, the OPS spec should REQUIRE ALL reading systems to be CSS2 compliant first, and recommend on top of that. This will help usher in all the goodness of CSS3 that is around the corner, and it won’t do any harm to backward compatibility with older versions of OPS. This is contrary to the approach taken right now, which I think favors hardware systems by selectively including certain CSS properties and not others, and by forbidding script interpretation, which at is the heart of cross-browser rendering consistency and which, with monstrosities like Internet Explorer 8 out there, is our only hope of having good-looking books on-line.

]]> By: Jack Tingle http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760023 Jack Tingle Thu, 10 Apr 2008 19:59:01 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-760023 Please, don't include hyphenation! Or any other really cool features. I read on a diverse range of systems, and each feature that gets added is another way for one or another of the systems to screw up. Keep it simple. Other features you should consider not adding: ligatures, compound characters, accented characters which aren't part of the normal set, nice looking but non-standard single quotes, double quotes, and apostrophes, to name but a few. Regards, Jack Tingle Please, don’t include hyphenation! Or any other really cool features. I read on a diverse range of systems, and each feature that gets added is another way for one or another of the systems to screw up. Keep it simple.

Other features you should consider not adding: ligatures, compound characters, accented characters which aren’t part of the normal set, nice looking but non-standard single quotes, double quotes, and apostrophes, to name but a few.

Regards,
Jack Tingle

]]> By: Jon Noring http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759948 Jon Noring Thu, 10 Apr 2008 17:26:27 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759948 It is simply good practice, and one I would require had I written the OPS specification, for all XHTML and DTBook documents in an OPS Publication, to include <code>xml:lang</code> on the root element. Doing it here, in addition to doing it in the OPF Package, assures the information is not lost when such documents are repurposed. It is simply good practice, and one I would require had I written the OPS specification, for all XHTML and DTBook documents in an OPS Publication, to include xml:lang on the root element. Doing it here, in addition to doing it in the OPF Package, assures the information is not lost when such documents are repurposed.

]]> By: Hadrien http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759937 Hadrien Thu, 10 Apr 2008 16:59:31 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759937 Yes you're right, the xml:lang element is probably more suited for this than the DublinCore in the OPF file. Yes you’re right, the xml:lang element is probably more suited for this than the DublinCore in the OPF file.

]]> By: Jon Noring http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759924 Jon Noring Thu, 10 Apr 2008 16:35:49 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759924 For situations where there are words in the content not of the primary language defined in <code>dc:language</code> (and better yet the attribute <code>xml:lang</code> applied to the <code><html></code> or <code><body></code> elements in each XHTML content document), then the author should apply <code>xml:lang</code> to them. This way hyphenation engines will know in which dictionary to look. In addition, this allows text-to-speech engines to likewise know the language of each word. For situations where there are words in the content not of the primary language defined in dc:language (and better yet the attribute xml:lang applied to the <html> or <body> elements in each XHTML content document), then the author should apply xml:lang to them. This way hyphenation engines will know in which dictionary to look.

In addition, this allows text-to-speech engines to likewise know the language of each word.

]]> By: Hadrien http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759912 Hadrien Thu, 10 Apr 2008 16:12:16 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759912 I agree Jon, the first step would be a recommandation in the OPS specs: a best-practice for authoring and a recommendation for the Reading System. The TeX approach to hyphenation is usually considered pretty good but not perfect. In the OPF file of an EPUB book, you <b>MUST</b> specify the language of the book using dc:language (at least one element, multiple elements supported too). Therefore, a Reading System could automatically hyphenate if there's default hyphenation patterns available for this language. I think that we really need something similar to <i>hyphenate-resource</i> for another reason: for some languages or when you're using a specialized vocabulary, you'll most likely use words that the basic patterns won't be able to hyphenate. I agree Jon, the first step would be a recommandation in the OPS specs: a best-practice for authoring and a recommendation for the Reading System.

The TeX approach to hyphenation is usually considered pretty good but not perfect. In the OPF file of an EPUB book, you MUST specify the language of the book using dc:language (at least one element, multiple elements supported too). Therefore, a Reading System could automatically hyphenate if there’s default hyphenation patterns available for this language.

I think that we really need something similar to hyphenate-resource for another reason: for some languages or when you’re using a specialized vocabulary, you’ll most likely use words that the basic patterns won’t be able to hyphenate.

]]> By: Alan Wallcraft http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759840 Alan Wallcraft Thu, 10 Apr 2008 14:20:39 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759840 FBReader's automatic hyphenation is based on TeX's approach, see http://www.tex.ac.uk/cgi-bin/texfaq2html?label=hyphen It needs to know the language to hyphenate correctly. FBReader’s automatic hyphenation is based on TeX’s approach, see http://www.tex.ac.uk/cgi-bin/texfaq2html?label=hyphen
It needs to know the language to hyphenate correctly.

]]> By: Jon Noring http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759834 Jon Noring Thu, 10 Apr 2008 14:14:27 +0000 http://www.teleread.org/blog/2008/04/10/the-shape-of-epub-to-come-hyphenation/#comment-759834 Great article, Hadrien! As a contributor to IDPF’s OEBPS Working Group, Hadrien’s article on hyphenation support in EPub is certainly intriguing, and I suggest that Hadrien submit a formal request to the OEBPS Working Group asking the group to study it and determine whether to explicitly include recommendations and/or requirements in a future version of the <a href="http://www.idpf.org/2007/ops/OPS_2.0_final_spec.html" rel="nofollow">OPS specification</a>. It is important in this discussion, and any discussion about EPub, to separate the Reading System (or as Lee Passey prefers to put it, the “User Agent”) from the OPS specification. (For those not familiar with the underpinnings of EPub, EPub is defined by the interrelated OPS, <a href="http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html" rel="nofollow">OPF</a> and <a href="http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm" rel="nofollow">OCF</a> specifications.) Regarding Hadrien’s first suggestion, using the “soft hyphen” character, the current OPS specification implies support for this character per Unicode and the HTML specification. Thus, the OPS author (EPub author) may include that character in content. So, Hadrien’s recommendation is pointed towards EPub Publication authors. However, OPS itself says nothing about how Reading Systems are to handle soft hyphens when encountered. Here the recommendations of HTML that Hadrien quoted come into play since OPS supports XHTML. Of course, a Reading System may completely ignore the soft hyphens it encounters in content and not use them in any manner (default rendering is that soft hyphens are invisible and of zero-width.) So a future version of the OPS specification could add a section discussing the use of the soft hyphen, and include both authoring and Reading System suggestions, recommendations and requirements. Hadrien’s second comment on the use of the <a href="http://www.w3.org/Style/CSS/current-work" rel="nofollow">CSS3</a> properties of <code>hyphens</code> and <code>hyphenate-resource</code> is also interesting. Currently OPS <em>does</em> allow these properties to be used in CSS documents, but does not require Reading Systems to recognize them. Any Reading System may simply ignore CSS properties that it is not required by OPS to recognize. So, a future version of OPS could also discuss the use of these CSS3 properties. (Note that the OEBPS Working Group was reluctant to “bless” any of the CSS3 properties for the current OPS, since most of them are still in the draft phase at W3C. A Reading System, though, may choose to recognize and use any of them — at least that’s my current understanding without delving back into the subtleties of OPS.) Great article, Hadrien!

As a contributor to IDPF’s OEBPS Working Group, Hadrien’s article on hyphenation support in EPub is certainly intriguing, and I suggest that Hadrien submit a formal request to the OEBPS Working Group asking the group to study it and determine whether to explicitly include recommendations and/or requirements in a future version of the OPS specification.

It is important in this discussion, and any discussion about EPub, to separate the Reading System (or as Lee Passey prefers to put it, the “User Agent”) from the OPS specification. (For those not familiar with the underpinnings of EPub, EPub is defined by the interrelated OPS, OPF and OCF specifications.)

Regarding Hadrien’s first suggestion, using the “soft hyphen” character, the current OPS specification implies support for this character per Unicode and the HTML specification. Thus, the OPS author (EPub author) may include that character in content. So, Hadrien’s recommendation is pointed towards EPub Publication authors.

However, OPS itself says nothing about how Reading Systems are to handle soft hyphens when encountered. Here the recommendations of HTML that Hadrien quoted come into play since OPS supports XHTML. Of course, a Reading System may completely ignore the soft hyphens it encounters in content and not use them in any manner (default rendering is that soft hyphens are invisible and of zero-width.)

So a future version of the OPS specification could add a section discussing the use of the soft hyphen, and include both authoring and Reading System suggestions, recommendations and requirements.

Hadrien’s second comment on the use of the CSS3 properties of hyphens and hyphenate-resource is also interesting. Currently OPS does allow these properties to be used in CSS documents, but does not require Reading Systems to recognize them. Any Reading System may simply ignore CSS properties that it is not required by OPS to recognize.

So, a future version of OPS could also discuss the use of these CSS3 properties. (Note that the OEBPS Working Group was reluctant to “bless” any of the CSS3 properties for the current OPS, since most of them are still in the draft phase at W3C. A Reading System, though, may choose to recognize and use any of them — at least that’s my current understanding without delving back into the subtleties of OPS.)

]]>