From 2a1225ca5378e34ff5d60f9795cf12a1f6359d27 Mon Sep 17 00:00:00 2001 From: Alex Cabal Date: Thu, 3 Jun 2021 19:03:10 -0500 Subject: [PATCH] Update pages and processes to match 2.0.0 toolset --- README.md | 2 +- scripts/deploy-ebook-to-www | 18 +- .../producing-an-ebook-step-by-step.php | 430 ++++++++++-------- www/css/core.css | 8 + www/css/manual.css | 36 +- 5 files changed, 264 insertions(+), 230 deletions(-) diff --git a/README.md b/README.md index dada2a22..a0352009 100644 --- a/README.md +++ b/README.md @@ -101,7 +101,7 @@ The site will now be available at `https://localhost/`, although as it’s a sel To automatically populate your server with ebooks from https://github.com/standardebooks/, you can use `sync-ebooks` and `deploy-ebook-to-www` in the [scripts](scripts) directory. If you don’t want to clone all ebooks, don’t use `sync-ebooks`, and instead clone the books you want into `/standardebooks.org/ebooks` with `git clone --bare`. To clone a list of books, you can use `while IFS= read -r line; do git clone --bare "${line}"; done < urllist.txt` -- `/standardebooks.org/web/www/manual/` contains the *compiled* [Standard Ebooks Manual of Style](https://github.com/standardebooks/manual). Because it is compiled from other sources, the distributable PHP files are not included in this repo. To include the manual, clone the SEMOS repo and follow the instructions in its readme to compile it into `/standardebooks.org/web/www/manual/x.y.z/`. +- `/standardebooks.org/web/www/manual/` contains the *compiled* [Standard Ebooks Manual of Style](https://github.com/standardebooks/manual). Because it is compiled from other sources, the distributable PHP files are not included in this repo. To include the manual, clone the SEMoS repo and follow the instructions in its readme to compile it into `/standardebooks.org/web/www/manual/x.y.z/`. # Testing diff --git a/scripts/deploy-ebook-to-www b/scripts/deploy-ebook-to-www index 622d0833..2e84d566 100755 --- a/scripts/deploy-ebook-to-www +++ b/scripts/deploy-ebook-to-www @@ -257,17 +257,21 @@ do # Build the ebook if [ "${epubcheck}" = "true" ]; then - if ! se build --output-dir="${workDir}"/downloads/ --check --kindle --kobo --covers "${workDir}"; then + if ! se build --output-dir="${workDir}"/downloads/ --check --kindle --kobo "${workDir}"; then rm --preserve-root --recursive --force "${workDir}" die "Error building ebook, stopping deployment." fi else - if ! se build --output-dir="${workDir}"/downloads/ --kindle --kobo --covers "${workDir}"; then + if ! se build --output-dir="${workDir}"/downloads/ --kindle --kobo "${workDir}"; then rm --preserve-root --recursive --force "${workDir}" die "Error building ebook, stopping deployment." fi fi + # Build distributable covers + convert -resize "1400" -sampling-factor 4:2:0 -strip -quality 80 -colorspace RGB -interlace JPEG "${workDir}/src/epub/images/cover.svg" ""${workDir}"/downloads/cover.jpg" + convert -resize "350" -sampling-factor 4:2:0 -strip -quality 80 -colorspace RGB -interlace JPEG "${workDir}/src/epub/images/cover.svg" ""${workDir}"/downloads/cover-thumbnail.jpg" + if [ "${verbose}" = "true" ]; then printf "Done.\n" fi @@ -278,12 +282,20 @@ do sed --in-place --regexp-extended "s/.+?<\/meta>/${modifiedDate}<\/meta>/" "${workDir}/src/epub/content.opf" if [ "${recompose}" = "true" ]; then + if [ "${verbose}" = "true" ]; then + printf "Recomposing ebook ... " + fi + # Recompose the epub into a single file, but put it outside of the epub src for now so we don't stomp on it with the following sections. # We do this first because the tweaks below shouldn't apply to the single-page file se recompose-epub --xhtml --output "${workDir}"/single-page.xhtml --extra-css-file="${webRoot}/www/css/web.css" "${workDir}" # Adjust sponsored links in the colophon - sed --in-place 's|

  • Select an ebook to produce

    -

    The best place to look for public domain ebooks to produce is Project Gutenberg. If downloading from Gutenberg, be careful of the following:

    +

    The best place to look for public domain ebooks to produce is Project Gutenberg. If downloading from Project Gutenberg, be careful of the following:

    Now our source file looks something like this:

    @@ -115,8 +115,8 @@

    The file we downloaded contains the entire work. Jekyll is a short work, but for longer work it quickly becomes impractical to have the entire text in one file. Not only is it a pain to edit, but ereaders often have trouble with extremely large files.

    The next step is to split the file at logical places; that usually means at each chapter break. For works that contain their chapters in larger “parts,” the part division should also be its own file. For example, see Treasure Island.

    To split the work, we use se split-file. se split-file takes a single file and breaks it in to a new file every time it encounters the markup <!--se:split-->. se split-file automatically includes basic header and footer markup in each split file.

    -

    Notice that in our source file, each chapter is marked with an <h2> tag. We can use that to our advantage and save ourselves the trouble of adding the <!--se:split--> markup by hand:

    perl -pi -e "s|<h2|<\!--se:split--><h2|g" src/epub/text/body.xhtml -

    (Note the slash before the ! for compatibility with some shells.)

    +

    Notice that in our source file, each chapter is marked with an <h2> element. We can use that to our advantage and save ourselves the trouble of adding the <!--se:split--> markup by hand:

    sed --in-place "s|<h2|<\!--se:split--><h2|g" src/epub/text/body.xhtml +

    (Note the slash before the ! for compatibility with some shells.)

    Now that we’ve added our markers, we split the file. se split-file puts the results in our current directory and conveniently names them by chapter number.

    se split-file src/epub/text/body.xhtml mv chapter* src/epub/text/

    Once we’re happy that the source file has been split correctly, we can remove it.

    rm src/epub/text/body.xhtml
    • @@ -143,7 +143,7 @@ </section> </body> </html> -

    If you look carefully, you’ll notice that the <html> tag has the xml:lang="en-US" attribute, even though our source text uses British spelling! We have to change the xml:lang attribute for the source files to match the actual language, which in this case is en-GB. Let’s do that now:

    perl -pi -e "s|en-US|en-GB|g" src/epub/text/chapter* +

    If you look carefully, you’ll notice that the <html> element has the xml:lang="en-US" attribute, even though our source text uses British spelling! We have to change the xml:lang attribute for the source files to match the actual language, which in this case is en-GB. Let’s do that now:

    sed --in-place "s|en-US|en-GB|g" src/epub/text/chapter*

    Note that we don’t change the language for the metadata or front/back matter files, like content.opf, titlepage.xhtml, or colophon.xhtml. Those must always be in American spelling, so they’ll always have the en-US language tag.

  • @@ -165,32 +165,39 @@

    Normalizes spacing in em-, en-, and double-em-dashes, as well as between nested quotation marks, and adds word joiners.

    • -

    While se typogrify does a lot of work for you, each ebook is totally different so there’s almost always more work to do that can only be done by hand. In Jekyll, you’ll notice that the chapter titles are in all caps. The S.E. standard requires chapter titles to be in title case, and se titlecase can do that for us.

    -

    se titlecase accepts a string as its argument, and outputs the string in title case. Many text editors allow you to configure external macros—perfect for creating a keyboard shortcut to run se titlecase on selected text.

    +

    While se typogrify does a lot of work for you, each ebook is totally different so there’s almost always more work to do that can only be done by hand. In Jekyll, you’ll notice that the chapter titles are in all caps. The S.E. standard requires chapter titles to be in title case, and se titlecase can do that for us. se titlecase accepts a string as its argument, and outputs the string in title case.

    +

    Typography checklist

    -

    There are many things that se typogrify isn’t well suited to do automatically. Check our complete typography manual to see exactly how to format the work. Below is a brief, but incomplete, list of common issues that arise in ebooks:

    +

    There are many things that se typogrify isn’t well suited to do automatically. Check the Typography section of the SEMoS to see exactly how to format the work. Below is a brief, but incomplete, list of common issues that arise in ebooks:

    + +

    After you’ve reviewed the changes, create an [Editorial] commit. This commit is important, because it gives purists an avenue to revert modernizing changes to the original text.

    +

    Note how we preface this commit with [Editorial]. Any change you make to the source text that can be considered a modernization or editorial change should be prefaced like this, so that the git history can be easily searched by people looking to revert changes.

    + git commit -am "[Editorial] Modernize hyphenation and spelling" + +
  • +

    Check for consistent diacritics

    +

    Sometimes during transcription or even printing, instances of some words might have diacritics while others don’t. For example, a word in one chapter might be spelled châlet, but in the next chapter it might be spelled chalet.

    +

    se find-mismatched-diacritics lists these instances for you to review. Spelling should be normalized across the work so that all instances of the same word are spelled in the same way. Keep the following in mind as you review these instances:

    + +
    • +
  • +

    Set <title> elements

    +

    After you’ve added semantics and correctly marked up section headers, it’s time to update the <title> elements in each chapter to match their expected values.

    +

    The se build-title tool takes a well-marked-up section header from a file, and updates the file’s <title> element to match:

    + se build-title . +

    Once you’ve verified the titles look good, commit:

    + git commit -am "Add titles" +
    • +
  • +

    Build the manifest and spine

    +

    In content.opf, the manifest is a list of all of the files in the ebook. The spine is the reading order of the various XHTML files.

    +

    se build-manifest and se build-spine will create these for you. Run these on our source directory and they’ll update the <manifest> and <spine> elements in content.opf.

    + +

    Since this is the first time we’re editing content.opf, we’re OK with replacing both the manifest and spine elements with a guess at the correct contents.

    + + se build-manifest . + se build-spine . + +

    The manifest is already in the correct order and doesn’t need to be edited. The spine, however, will have to be reordered to be in the correct reading order. Once you’ve done that, commit!

    git commit -am "Add manifest and spine" +
    • +
  • +

    Build the table of contents

    +

    With the spine in the right order, we can now build the table of contents.

    +

    The table of contents is a structured document that lets the reader easily navigate the book. In a Standard Ebook, it’s stored outside of the readable text directory with the assumption that the reading system will parse it and display a navigable representation for the user.

    +

    Use se build-toc to generate a table of contents for this ebook.

    + se build-toc . +

    Review the generated ToC in ./src/epub/toc.xhtml to make sure se build-toc did the right thing. se build-toc is a valuable tool to discover structural problems in your ebook. If an entry is arranged in a way you weren’t expecting, perhaps the problem isn’t with se build-toc, but with your XHTML code—be careful!

    +

    It’s very rare that se build-toc makes an error given a correct ebook structure, but if it does, you may have to make changes to the table of contents by hand.

    +

    Once you’re done, commit:

    + git commit -am "Add ToC" +
    • +
  • +

    Clean and lint

    +

    Before you build the ebook for proofreading, it’s a good idea to check the ebook for some common problems you might have run in to during production.

    +

    First, run se clean one more time to both clean up the source files, and to alert you if there are XHTML parsing errors. Even though we ran se clean before, it’s likely that in the course of production the ebook got in to less-than-perfect markup formatting. Remember you can run se clean as many times as you want—it should always produce the same output.

    + se clean . +

    Now, run se lint. If your ebook has any problems, you’ll see some output listing them. We’re expecting some errors, because we haven’t added a cover or completed the colophon or metadata. You can ignore those errors for now, because we’ll fix them in a later step. But, you do want to correct any fixable errors related to your previous work.

    + se lint . +

    If there are no errors, se lint will complete silently—but again, at this stage we’re expecting to see some errors because our ebook isn’t done yet.

    +
    • +
  • +

    Build and proofread, proofread, proofread!

    +

    At this point, our ebook is still missing some important things—a cover, the colophon, and some metadata—but the actual book is in a state where we can start proofreading. We complete a cover-to-cover proofread now, even though there’s still work to be done on the ebook, because once you’ve actually read the book, you’ll have a better idea of what kind of cover to select and what to write in the metadata description.

    +

    se build will create a usable epub file for transfer to your ereader. We’ll run it with the --kindle and --kobo flag to build a file for Kindles and Kobos too. If you won’t be using a Kindle or Kobo, you can omit those flags.

    + se build --output-dir=$HOME/dist/ --kindle --kobo . +

    If there are no errors, we’ll see five files in the brand-new ~/dist/ folder in our home directory:

    + +

    Now, transfer the ebook to your ereader and start a cover-to-cover proofread.

    +

    It’s extremely common for transcriptions sourced from Project Gutenberg to have various typos and formatting errors (like missing italics), and it’s also not uncommon for one of Standard Ebook’s tools to make the wrong guess about things like a closing quotation mark somewhere. As you proofread, mark any obvious, or possible but not obvious, errors so that you can compare them with the page scans you found earlier. Keep an eye out for things that we may have to adjust in order to make the text conform to the Typography section of the SEMoS.

    +

  • Create the cover image

    @@ -508,7 +590,8 @@

    If you commit non-public-domain cover art, you’ll have to rebase your repository to remove the art from its history. This is complicated, dangerous, and annoying, and you’ll be tempted to give up.

    Contact us first with page scans verifying your cover art’s public domain status before you commit your cover art!

    -

    Cover images for Standard Ebooks books have a standardized layout. The bulk of the work you’ll be doing is locating a suitable public domain painting to use. See the Art and Images section of the Standard Ebooks Manual of Style for details on assembling a cover image.

    +

    Now that you’ve read the ebook, you’re ready to find a cover image.

    +

    Cover images for Standard Ebooks books have a standardized layout. The bulk of the work you’ll be doing is locating a suitable public domain painting to use. See the Art and Images section of the SEMoS for details on assembling a cover image.

    As you search for an image, keep the following in mind:

    -

    What can we use for Jekyll? In 1885 Albert Edelfelt painted a portrait of Louis Pasteur in a laboratory. A crop of the lab equipment would be a good way to represent Dr. Jekyll’s lab.

    -

    The cover file itself, cover.svg, is easy to edit. It automatically links to cover.jpg. All you have to do is open cover.svg with a text editor and edit the title and author. Make sure you have the League Spartan font installed on your system!

    +

    What can we use for Jekyll? In 1863 Hans von Marées painted an eerie self-portrait with a friend. The sallow, enigmatic look of the man on the left suggests the menacing personality of Hyde hiding just behind the sober Jekyll. It was reproduced in a book published in 1910.

    +

    The cover file itself, ./images/cover.svg, is easy to edit. It automatically links to ./images/cover.jpg. All you have to do is open cover.svg with a text editor and edit the title and author. Make sure you have the League Spartan font installed on your system!

    After we’re done with the cover, we’ll have four files in ./images/:

    -
    • -
  • -

    Create the titlepage image, build both the cover and titlepage, and commit

    -

    Titlepage images for Standard Ebooks books are also standardized. See our the Art and Images section of the Standard Ebooks Manual of Style for details.

    -

    se create-draft already created a completed titlepage for you. If the way it arranged the lines doesn’t look great, you can always edit the titlepage to make the arrangement of words on each line more aesthetically pleasing. Don’t use a vector editing program like Inkscape to edit it. Instead, open it up in your favorite text editor and type the values in directly.

    -

    The source images for both the cover and the titlepage are kept in ./images/. Since the source images refer to installed fonts, and since we can’t include those fonts in our final ebook without having to include a license, we have to convert that text to paths for final distribution. se build-images does just that.

    se build-images .

    se build-images takes both ./images/cover.svg and ./images/titlepage.svg, converts text to paths, and embeds the cover jpg. The output goes to ./src/epub/images/.

    -

    Once we built the images successfully, perform a commit.

    git add -A git commit -m "Add cover and titlepage images" +

    Once we built the images successfully, perform a commit.

    git add -A git commit -m "Add cover image"

  • Complete content.opf

    -

    content.opf is the file that contains the ebook metadata like author, title, description, and reading order. Most of it will be filling in that basic information, and including links to various resources related to the text.

    -

    The content.opf is standardized. See the Metadata section of the Standard Ebooks Manual of Style for details on how to fill out content.opf.

    -

    As you complete the metadata, you’ll have to order the spine and the manifest in this file. Fortunately, Standard Ebooks has tools for that too: se print-manifest and se print-spine. Run these on our source directory and, as you can guess, they’ll print out the <manifest> and <spine> elements for this work.

    -

    If you’re using a Mac, and thus the badly-behaved Finder program, you may find that it has carelessly polluted your work directory with useless .DS_Store files. Before continuing, you should find a better file manager program, then delete all of that litter with the following command. Otherwise, se print-manifest and se print-spine will include that litter in its output and your epub won’t be valid.

    - find . -name ".DS_Store" -type f -delete -

    Since this is the first time we’re editing content.opf, we’re OK with replacing both the manifest and spine elements with a guess at the correct contents. We can do this using the --in-place option. If we have to update the manifest or spine later, we can omit the option to print to standard output instead of altering content.opf directly.

    - - se print-manifest --in-place . - se print-spine --in-place . - -

    The manifest is already in the correct order and doesn’t need to be edited. The spine, however, will have to be reordered to be in the correct reading order. Once you’ve done that, commit!

    git commit -am "Complete content.opf" -
    • -
  • -

    Complete the table of contents

    -

    The table of contents is a structured document that should let the reader easily navigate the book. In a Standard Ebook, it’s stored outside of the readable text directory with the assumption that the reading system will parse it and display a navigable representation for the user.

    -

    Once you’ve completed the <spine> element in content.opf, you can use se print-toc to generate a table of contents for this ebook. Since this is the first time we’re generating a ToC for this ebook, use the --in-place flag to replace the template ToC file with the generated ToC.

    - se print-toc --in-place . -

    Review the generated ToC in ./src/epub/toc.xhtml to make sure se print-toc did the right thing. se print-toc is a valuable tool to discover structural problems in your ebook. If an entry is arranged in a way you weren’t expecting, perhaps the problem isn’t with se print-toc, but with your HTML code—be careful! You may have to make changes by hand for complex or unusual books.

    +

    content.opf is the file that contains the ebook metadata like author, title, description, and reading order. Most of it will be filling in that basic information, and including links to various resources related to the text. We already completed the manifest and spine in an earlier step.

    +

    content.opf is standardized. See the Metadata section of the SEMoS for details on how to fill it out.

    +

    The last details to fill out here will be the short and long descriptions, verifying any Wikipedia links that se create-draft automatically found, adding cover artist metadata, filling out any missing author or contributor metadata, and adding your own metadata as the ebook producer.

    Once you’re done, commit:

    - git commit -am "Add ToC" + git commit -am "Complete content.opf"
  • -

    Complete the colophon

    -

    se create-draft put a skeleton colophon.xhtml file in the ./src/epub/text/ folder. Now that we have the cover image and artist, we can fill out the various fields there. Make sure to credit the original transcribers of the text (generally we assume them to be whoever’s name is on the file we download from Gutenberg) and to include a link back to the Gutenberg text we used, along with a link to any scans we used (from archive.org or hathitrust.org, for example).

    +

    Complete the imprint and colophon

    +

    se create-draft put a skeleton imprint.xhtml file in the ./src/epub/text/ folder. Fill out the links to the transcription and page scans.

    +

    There’s also a skeleton colophon.xhtml file. Now that we have the cover image and artist, we can fill out the various fields there. Make sure to credit the original transcribers of the text (generally we assume them to be whoever’s name is on the file we download from Project Gutenberg) and to include a link back to the Gutenberg text we used, along with a link to any scans we used (from the Internet Archive or Hathi Trust, for example).

    You can also include your own name as the producer of this Standard Ebooks edition. Besides that, the colophon is standardized; don’t get too creative with it.

    -

    The release and updated dates should be the same for the first release, and they should match the dates in content.opf. For now, leave them unchanged, as se prepare-release will automatically fill them in for you as we’ll describe later in this guide.

    git commit -am "Complete the colophon" -
    • -
  • -

    Complete the imprint

    -

    There’s also a skeleton imprint.xhtml file in the ./src/epub/text/ folder. All you’ll have to change here is the links to the transcription and page scans you used.

    +

    Leave the release date unchanged, as se prepare-release will fill it in for you in a later step.

    +

    Once you’re done, commit:

    + git commit -am "Complete the imprint and colophon"
  • -

    Clean and lint before building

    -

    Before you build the final ebook for you to proofread, it’s a good idea to check the ebook for some common problems you might run in to during production.

    -

    First, run se clean one more time to both clean up the source files, and to alert you if there are XHTML parsing errors. Even though we ran se clean before, it’s likely that in the course of production the ebook got in to less-than-perfect markup formatting. Remember you can run se clean as many times as you want—it should always produce the same output.

    - se clean . -

    Now, run se lint. If your ebook has any problems, you’ll see some output listing them. If everything’s OK, then se lint will complete silently.

    +

    Final checks

    +

    It’s a good idea to run se typogrify and se clean one more time before running these final checks. Make sure to review the changes with git difftool before accepting them—se typogrify is usually right, but not always!

    +

    Now that our ebook is complete, let’s verify that there are no errors at the S.E. style level:

    se lint . -
    • -
  • -

    Build and proofread, proofread, proofread!

    -

    At this point we’re just about ready to build our proofreading draft! se build does this for us. We’ll run it with the --check flag to make sure the epub we produced is valid, and with the --kindle and --kobo flag to build a file for Kindles and Kobos too. If you won’t be using a Kindle or Kobo, you can omit those flags.

    - se build --output-dir=$HOME/dist/ --kindle --kobo --check . -

    If there are no errors, we’ll see five files in the brand-new ~/dist/ folder in our home directory:

    - -

    This is the step where you read the ebook and make adjustments to the text so that it conforms to our typography manual.

    -

    All Standard Ebooks productions must be proofread at this stage to confirm that there are no typos, formatting errors, or typography errors. It’s extremely common for transcriptions sourced from Gutenberg to have various typos and formatting errors (like missing italics), and it’s also not uncommon for one of Standard Ebook’s tools to make the wrong guess about things like a closing quotation mark somewhere. As you proofread, it’s extremely handy to have a print copy of the book with you. For famous books that might just be a trip to your local library. For rarer books, or for those without a library nearby, there are several sites that provide free digital scans of public domain writing:

    - -

    If you end up using scans from one of these sources, you must mention it in the ebook’s colophon and as a <dc:source> item in content.opf.

    -

    If you’re using a transcription from Project Gutenberg as the base for this ebook, you may wish to report typos you’ve found to them, so that they can correct their copy. Instructions for how to do so are here.

    +

    Once se lint completes without errors, we’re ready to confirm that there are no errors at the epub level. We do this by invoking se build with the --check flag, which will run epubcheck to verify that our final epub has no errors:

    + se build --check --output-dir=${TMPDIR:-/tmp} . +

    Once that completes without errors, we’re ready to move on to the final step!

  • Initial publication

    -

    Now that we’ve proofread the work and corrected any errors we’ve found, we’re ready to release the finished ebook!

    -

    It’s a good idea to run se typogrify and se clean one more time before releasing. Make sure to review the changes with git difftool before accepting them—se typogrify is usually right, but not always!

    +

    You’re ready to publish!

    -

    Finally, build everything again.

    - - se build --output-dir=$HOME/dist/ --kindle --kobo --check . - -

    If the build completed successfully, congratulations! You’ve just finished producing a Standard Ebook!

    +

    Congratulations! You’ve just finished producing a Standard Ebook!

    • diff --git a/www/css/core.css b/www/css/core.css index 542d11ca..03545f07 100644 --- a/www/css/core.css +++ b/www/css/core.css @@ -2044,6 +2044,14 @@ label.checkbox input{ margin-right: .25rem; } +article.step-by-step-guide ol ol{ + margin-left: 1.2rem; + list-style: decimal; +} + +.step-by-step-guide ol ol li p{ + margin-left: 0; +} @media (hover: none) and (pointer: coarse){ /* target ipads and smartphones without a mouse */ /* For iPad, unset the height so it matches the other elements */ diff --git a/www/css/manual.css b/www/css/manual.css index ff95358b..23fe11a0 100644 --- a/www/css/manual.css +++ b/www/css/manual.css @@ -16,25 +16,18 @@ @font-face{ font-family: "Fira Sans"; - src: local("Fira Sans"); + src: local("Fira Sans"), url("/fonts/fira-sans-italic.woff2") format("woff2"); font-weight: normal; font-style: italic; } @font-face{ font-family: "Fira Sans"; - src: local("Fira Sans"); + src: local("Fira Sans"), url("/fonts/fira-sans-bold-italic.woff2") format("woff2"); font-weight: bold; font-style: italic; } -@font-face{ - font-family: "Fira Sans"; - src: local("Fira Sans"); - font-weight: bold; - font-style: normal; -} - .manual h1, .manual h2, .manual h3, @@ -219,9 +212,9 @@ code{ code.terminal{ color: #fff; - background-color: #444; + background-color: #333; text-align: left; - padding: 1rem 1rem 1rem 3rem; + padding: 1rem 1rem 1rem 2.5rem; border-radius: .25rem; position: relative; display: block; @@ -230,7 +223,9 @@ code.terminal{ } code.terminal::before{ - content: url("/images/terminal.svg"); + content: ""; + background: url("/images/terminal.svg"); + background-size: cover; height: 1rem; width: 1rem; top: 1.15rem; @@ -253,10 +248,6 @@ code.terminal span::before{ display: inline; } -code.terminal > span::before{ - content:"user@localhost>"; -} - .utf{ border: 1px solid var(--body-text); padding: .1rem; @@ -581,6 +572,10 @@ figure.corrected code{ top: .5rem; } +.manual aside.tip code{ + font-style: normal; +} + span.ws{ border: 1px solid #222; padding: .1rem; @@ -609,16 +604,13 @@ code.bash i.glob{ color: #719ece; } +code.html .ws, figure code.html .ws, code.full .ws{ border-color: #fff; margin-top: 0; } -main.manual ul.changes table{ - margin-top: 0; -} - main.manual ul.changes td{ padding: 0; } @@ -730,10 +722,6 @@ main.manual aside.alert p{ main.manual nav + article h1{ margin-top: 0; } - - .manual > article > section[id] > aside.number{ - margin-top: 0; - } } @media(max-width: 1100px){