Code Monkey home page Code Monkey logo

manual's Introduction

Purpose and voice

The Standard Ebooks Manual of Style describes a complete approach to editing and producing ebooks, from internal code style to semantic enhancement and typography rules.

It is not a how-to manual; that is, it does not aim to give instructions on how to accomplish the various goals it describes. For example, it would not contain step by step guides, or guides on Inkscape usage, or SE toolset usage. Instead, the manual describes in declarative language how a Standard Ebook should appear after it is produced.

Each directive is numbered and can contain any number of sub directives. Directives declare what the expected final appearance is, not how a producer should achieve the final appearance.

For example:

Good: “OK” is set without periods or spaces.

Bad: Don’t put periods or spaces in “OK” or “OK” shouldn’t be set with periods or spaces.

Submitting changes

The master branch is reserved for typo fixes, clarifications, and version releases. Anything else should be committed to the next branch, which is periodically merged into master as a version release.

Building

The following pip packages are required:

pip3 install beautifulsoup4 pygments natsort regex rst2html5

To build the final PHP files, invoke the build-manual.py executable:

./build-manual.py SOURCE_DIR DEST_DIR

To generate the syntax highlighting stylesheet:

pygmentize -S monokai -f html > monokai.css

Versioning

The overall version of the manual is stored as a comment in the index.rst file. This comment is used by build-manual.py to set the version number of the manual.

Within .rst files, the string VERSION is replaced with the version number when built. For example, a link to another part of the manual could be: `The SE identifier </manual/VERSION/9-metadata#9.2>`__.

Code style

Indentation

All indentation is with tabs, not spaces.

A tab space follows the bullet point in all list items:

-	List item 1

-	List item 2

#.	List item 1

#.	List item 2

RST extensions

Several additional RST roles are available for use in the manual:

  • HTML: :html:`<p>Some HTML</p>`

  • CSS: :css:`.some-class{ font-weight: bold; }`

  • Bash: :bash:`se build --check .`

  • Paths: :path:`/standardebooks.org/web/www/`

  • Italics (<i>, not <em>): :italics:`The Iliad`

  • Whitespace: :ws:`hairsp`

  • UTF: :utf:`½`

  • HTML attribute value: :value:`A value of an HTML attribute`

  • String: :string:`A string that is not syntax highlighted`

While they are not defined in each .rst file to avoid header clutter, they are defined by build-manual.py during the build process.

You may also create a tip or warning block:

.. tip::

	Here’s a tip!

.. warning::

	Here’s a warning!

The string PD_YEAR will be replaced with <?= PD_YEAR ?>, which will print the current public domain year when served from the SE website. For example, it will print 1926 if the current public domain includes works published up to and including 1926.

The string PD_STRING will be replaced with <?= PD_STRING ?>, which will print the first day the public domain ends when served from the SE website. For example, it will print January 1, 1927 if the current public domain includes works published up to and including 1926.

Headings

####
<h1>
####

<h2>
****

<h3>
====

<h4>
----

<h5>
~~~~

<h6>
^^^^

Numbered directives

All headings are automatically numbered and begin new <section> elements.

Numbered directives begin with #. (Read: Hash, Period, Tab space) and begin new <ol> elements.

#.	Major structural divisions of a larger work, like parts, volumes, books, chapters, or subchapters, are contained in a :html:`<section>` element.

#.	Individual items in a larger collection (like a poem in a poetry collection) are contained in a :html:`<article>` element.

Sub-directives follow that convention, on the next indent level.

#.	:html:`<img>` elements have an :html:`alt` attribute that uses prose to describe the image in detail; this is what screen reading software will read aloud.

	#.	The :html:`alt` attribute describes the visual image itself in words, which is not the same as writing a caption or describing its place in the book.

To create a heading that is not numbered, precede it with the ..no-numbering class:

.. class:: no-numbering

Examples
--------

Consider a book that contains several top-level subdivisions: Books 1–4, with each book having 3 parts, and each part having 10 chapters. Below is an example of three files demonstrating the structure necessary to achieve recomposability:

Code samples

Block-level code samples are marked with the .. code:: html class:

.. code:: html

	<img alt="Pierre’s fruit-filled dinner" src="..." />

To add the “green check” or “red x” styling, add the .. corrected or .. wrong class:

.. class:: wrong

	.. code:: html

		<img alt="The illustration for chapter 10" src="..." />

.. class:: wrong

	.. code:: html

		<img alt="Pierre’s fruit-filled dinner" src="..." />

manual's People

Contributors

acabal avatar acbsmith avatar b-t-k avatar bentley avatar colagrosso avatar concavetrillion avatar crvdgc avatar dajare avatar davgross avatar dillonn241 avatar drgrigg avatar emmasweeney avatar fvictorio avatar glgertsen avatar gragt avatar hatchetation avatar jenrodge avatar kianmeng avatar lukasbystricky avatar maticstric avatar richardjs avatar robinwhittleton avatar srensamblador avatar ssteve avatar thewchan avatar villeporte avatar vr8hub avatar vrajmohan avatar weijia-cheng avatar zoeypeterson avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

manual's Issues

Short description sentence fragment rule

The manual currently says that short descriptions should be complete sentences, not sentence fragments.

I perused the short descriptions and by my count about 30% of the corpus violates this rule by using a sentence fragment. (As an aside, one book violates the ‘ending in a period’ rule by ending in a question mark, The Slaves of Paris: “A group of blackmailers play a long game on several families; will Lecoq be able to catch them?”)

Many of these are short story collections and similar; in such cases the sentence fragment is a useful description and convenient for producers to write. @acabal has suggested that an exception can be made for these. I agree.

Some of the other fragments can be easily turned into sentences through minor rewording/shuffling. However, given that we have already come up with one exception, and given the many works that currently violate the sentence fragment rule, I think this rule is worth re‐evaluating.

Should fulltitle file-as reference the fulltitle?

manual/9-metadata.rst

Lines 103 to 105 in 064e5de

<dc:title id="fulltitle">The Man Who Was Thursday: A Nightmare</dc:title>
<meta property="file-as" refines="#fulltitle">Man Who Was Thursday, The</meta>
<meta property="title-type" refines="#fulltitle">extended</meta>

This feels like a bug, but I want to check. Line 104 should be the following right?

<meta property="file-as" refines="#fulltitle">Man Who Was Thursday: A Nightmare, The</meta> 

document En dashes and word joiners

In the documentation on en- and em-dashes, the use of word-joiner unicode characters is mentioned in conjection with em dashes, but not mentioned, or used in the examples given, for en dashes, e.g. ranges of numbers:

https://standardebooks.org/manual/1.0.0/8-typography#8.7.7

But se typogrify will add word-joiners on both sides on en dashes, according to this comment:
https://github.com/standardebooks/tools/blob/master/se/typography.py#L89-L90

and this appears to be the intended behaviour (to keep both parts of the en-dashed range together, and not line break in the middle of them). So presumably the documentation needs updated to match the tooling.

I spotted this because my current ebook reading software got confused by these invisible characters, and reversed the order of the two numbers either side of the en-dash, but that appears just to be a bug in their code, it doesn't happen with any other ereader software I've tested so far.

Drama paragraph indentation

In the drama CSS we use:

[epub|type~="z3998:drama"] td p{
        text-indent: 0;
}

With run-on monologues this has the effect of removing all paragraph separation. Should we add a first child pseudoclass?

[epub|type~="z3998:drama"] td p:first-child{
        text-indent: 0;
}

Differentiating between poem and verse, song and hymn

Should we add something to 7.5.6 that indicates when to use verse and when to use poem? What's been mentioned on the list is that verse is for partial quotes of a poem and poem is for when a full poem is quoted. And I know what a hymn is (well, in my context anyway), but I don't know that I've ever seen anything on the list about when to use which (hymn vs song).

I'll write something up if need be; would you want it on 7.5.6, or as a sub-item, i.e. 7.5.6.1, etc.? (I just noticed the other issue I raised about internal thoughts; I'll do that tonight, I had forgotten about it.)

Initialisms rule is unclear, possible typo

Rule 8.10.2 states "Initialisms (terms made up of initials in which each initial is pronounced separately, like ABC, HTML, or CSS) are set with without periods (with the following exceptions)..." So is that with periods, or without periods? I assume there's a missing 'or' between 'with' and 'without'. And what are the following exceptions? The ones in 8.10.4?

Style guide is silent on modernizing spelling

Several of the contribution guides contain guidance on modernizing spelling. e.g., Step By Step and Reviewing for Production.

However, it doesn't appear that these directives are formalized in the style guide.

Typo in § 7.7.2.7

(Unfortunately, can't link to a specific line as in unrendered texts!)

In ch. 7 at § 7.7.2.7, for within a saluation (for example → read → within a salutation (for example (insert "t").

Hope that helps!

`eoc` needed in example letter?

One of the example letters (§ 7.7.3.5.1), signed "Edward Gardner", includes this @ line 1192 (of the raw .rst file):

<p epub:type="z3998:valediction">Yours, <abbr>etc.</abbr></p>

Should this <abbr> also include class="eoc"? or does this type of paragraph not need the class?

Common issues

I have the start of a Common Issues file. For now, I've just used the same formatting as the manual, because it was in front of me and easy to structure and have the formatting for bash, wrong and corrected examples, etc. We can regex it to adjust it to whatever we want as we go on.

Where would you like me to put it? Matt mentioned wanting to help with it as well.

Examples in 7.1.5.1 not consistent with 1.1.7.1?

The new recomposability examples in 7.1.5.1 show the new data-parent attribute as the last attribute, but alphabetically data-parent is before id so it should go first according to 1.1.7.1.

If you do follow the manual's example of putting data-parent last, running se clean moves it first, so it seems either 7.1.5.1 is correct or 1.1.7.1./se clean is correct.

HTML5: <cite> must not be used to mark up people’s names

This one’s a doozy. According to the current HTML5 spec, cite must not be used for people’s names. In fact, cite may be used for titles of works mentioned in passing, not just citations.

This contradicts several examples from the manual:

And given the examples in the spec, it seems that 8.2.11.2 would be updated to italicize titles using cite.

Internal thoughts

In an email exchange last year on the list, you mentioned that internal thoughts that are italicized in the source should probably just be unsemanticated <i>. That’s not in the italics section in the manual; would you like a PR to add it? I've had this in a couple of books, and it just came up in a book I reviewed, so I think it happens enough that it would be helpful for it to be in the manual.

French chapter ?

Do you have a French chapter for your initiave ?

The manual is adequate for english but would require changes for French books.

Are you interested in getting help starting a French chapter ?

Varying uses of the term "elision" in step 8 of the step-by-step guide

Step 8 contains the following two dictates:

  • Elision. ’ (i.e., ’) is used for elided letters in a word. se typogrify often gets this wrong, and you need to review your ebook by hand to ensure it didn’t insert ‘ (‘) instead.
  • Two-em dashes should be used for elision.

I was told the second reference of elision is actually referring to "partially obscured words".

If so, why not clarify this by replacing the second mention of "elision" with "partially obscured words"?

Header inconsistency in Section 7.2.3

Section 7.2.3 says:

The book’s title is implicitly at the <h1> level, even if <h1> is not present in the ebook. An <h1> element is only present if the ebook contains a half title page. Because of the implicit <h1>, all other sections begin at <h2>.

But 6.3.3 says that the title page uses <h1> and 6.5.4 says that the half title page uses <h2>.

Proposal: <dfn> for newly‐used English words

HTML has the <dfn> element, which “represents the defining instance of a term.” Semantically, it at least partly overlaps with section 8.2.10 of the manual. Perhaps it would be appropriate to mention it there.

I said “partly overlaps” because I’m not sure how broad a “defining instance” is. For instance, the first example in the manual seems like a clear match: “English whalers have given this the name ‘ice blink.’” But is the second? It doesn’t contain a definition per se: “The soil consisted of that igneous gravel called tuff.” On the other hand, maybe “igneous gravel” counts.

Another wrinkle is style. By default, <dfn> is rendered in italics. The manual says to use italics for technical terms. If <dfn> is used for quoted English, though, it would need an additional style (maybe a class?) to un‐italicize.

<p>English whalers have given this the name “<dfn class="common-english">ice blink</dfn>.”</p>
<p>The soil consisted of that igneous gravel called <dfn>tuff</dfn>.</p>

Unicode hyphens

Unicode says:

Because of its prevalence in legacy encodings, U+002D hyphen-minus is the most common of the dash characters used to represent a hyphen. It has ambiguous semantic value and is rendered with an average width. U+2010 hyphen represents the hyphen as found in words such as “left-to-right.” It is rendered with a narrow width. When typesetting text, U+2010 hyphen is preferred over U+002D hyphen-minus.

I have personally used U+2010 in most situations for at least a decade. In my experience, most fonts use the same glyph for U+2010 as for U+002D, but occasionally I encounter a font whose U+2010 has a better height or width because its U+002D tries to straddle hyphen and minus. Only rarely do I encounter a font with no glyph for U+2010, so another font’s glyph gets substituted instead.

Should SE start using the correct hyphen character? Typogrify already replaces U+2011 with U+002D—perhaps it should replace U+002D and U+2011 with U+2010 instead.

Example used in 8.10.9.4 contradicts 8.10.9.5

The Australian Broadcasting Corporation is (now) stylised as "ABC", not "A.B.C."

Also, should a text written when the ABC was stylised as "A.B.C." be modernised to "ABC"? Or should modernisation only follow general English usage and not the whims of marketing departments?

Typos

8.4.2

The first line of body text in a section, or any text following a visible break in text flow (like a header, a scene break, a figurem etc.), is not indented, with the exception of block quotations.


8.14.1

When scansion marks are next to, instead of above, letters, × (U+00d7) indicates an unstressed sylllable and...

I was just reading the manual to see what this project was about and I saw these. Have a great day!

Update 'EPUB 3 Structural Semantics Vocabulary' page links

The links to epub spec's semantic vocabulary seem to be obsolete now. The currently used link is to a draft and there is a new and official W3 working group page. If this change is ok, I can create a pull request either to the main or to the next branch.

Root paths on `se create-draft` are different when `--white-label` is used

I noticed this difference when creating a skeleton for the project described here. If this is indeed the case, would it not be appropriate to indicate that when passing this flag, the content root within a project is at $BOOK/epub instead of $BOOK/src/epub?

Chris in [~/Documents/h-beam-piper_murder-in-the-gunroom] on (main) % tree .
    .
├── LICENSE.md
├── images
│   ├── cover.jpg
│   ├── cover.svg
│   └── titlepage.svg
└── src
    ├── META-INF
    │   └── container.xml
    ├── epub
    │   ├── content.opf
    │   ├── css
    │   │   ├── core.css
    │   │   ├── local.css
    │   │   └── se.css
    │   ├── images
    │   │   ├── cover.svg
    │   │   ├── logo.svg
    │   │   └── titlepage.svg
    │   ├── onix.xml
    │   ├── text
    │   │   ├── body.xhtml
    │   │   ├── colophon.xhtml
    │   │   ├── imprint.xhtml
    │   │   ├── titlepage.xhtml
    │   │   └── uncopyright.xhtml
    │   └── toc.xhtml
    └── mimetype
Chris in [~/Documents/christopher-matthew-finazzo_methods-for-writing-technical-documents] on (main) % tree .
.
├── META-INF
│   └── container.xml
├── epub
│   ├── content.opf
│   ├── css
│   │   ├── core.css
│   │   └── local.css
│   ├── images
│   │   └── cover.jpg
│   ├── onix.xml
│   ├── text
│   │   ├── abstract.xhtml
│   │   ├── body.xhtml
│   │   ├── colophon.xhtml
│   │   ├── imprint.xhtml
│   │   ├── references.xhtml
│   │   ├── titlepage.xhtml
│   │   └── uncopyright.xhtml
│   └── toc.xhtml
├── images
└── mimetype

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.