Browse code

Creation of first full entry; it still needs some proofreading

NikaZhenya authored on 07/10/2018 18:04:57
Showing 12 changed files
... ...
@@ -1,8 +1,8 @@
1 1
 # Publishing is Coding: Change My Mind
2 2
 
3
-## A broken english version of some entries published in [Mariana Eguaras's blog](https://marianaeguaras.com/blog/)
3
+## Nika Zhenya's entries from [Mariana Eguaras' blog]((https://marianaeguaras.com/blog/)) in broken english
4 4
 
5
-This is the repo of “[Publishing is coding: change my mind](https://blog.cliteratu.re/)” blog.
5
+This is the repo of “[Publishing is Coding: Change My Mind](https://blog.cliteratu.re/).”
6 6
 You can find the original spanish version in [GitLab](https://gitlab.com/NikaZhenya/entradas-eguaras),
7 7
 [GitHub](https://github.com/NikaZhenya/entradas-eguaras) or [GitList](https://git.cliteratu.re/).
8 8
 
... ...
@@ -22,7 +22,7 @@ _Edición digital como metodología para una edición global_ (_Digital Publishi
22 22
 
23 23
 Pecas, herramientas editoriales (Pecas, publishing tools): [pecas.cliteratu.re](https://pecas.cliteratu.re/).
24 24
 
25
-Sitio personal (personal website): [xxx.cliteratu.re](https://xxx.cliteratu.re/).
25
+Sitio personal (personal site): [xxx.cliteratu.re](https://xxx.cliteratu.re/).
26 26
 
27 27
 ## License
28 28
 
... ...
@@ -36,5 +36,5 @@ any of this content under the following conditions:
36 36
 
37 37
 1. Any product produced with this content must be under some type of LEAL.
38 38
 2. Merchandising cannot be the only way to acquire the final product.
39
-3. The use of content mustn't harm to any collaborator.
39
+3. The use of content must not harm any collaborator.
40 40
 4. All files (editables or finals) must be public access.
... ...
@@ -504,6 +504,11 @@ code {
504 504
     padding: .125em .5em;
505 505
     border: 1px solid #ddd;
506 506
     border-radius: .25em;
507
+    -moz-hyphens: none;
508
+    -webkit-hyphens: none;
509
+    -o-hyphens: none;
510
+    -ms-hyphens: none;
511
+    hyphens: none;
507 512
 }
508 513
 
509 514
 pre {
... ...
@@ -504,6 +504,11 @@ code {
504 504
     padding: .125em .5em;
505 505
     border: 1px solid #ddd;
506 506
     border-radius: .25em;
507
+    -moz-hyphens: none;
508
+    -webkit-hyphens: none;
509
+    -o-hyphens: none;
510
+    -ms-hyphens: none;
511
+    hyphens: none;
507 512
 }
508 513
 
509 514
 pre {
510 515
Binary files a/ebooks/entry001.epub and b/ebooks/entry001.epub differ
511 516
Binary files a/ebooks/entry001.mobi and b/ebooks/entry001.mobi differ
... ...
@@ -9,7 +9,7 @@
9 9
     https://blog.cliteratu.re
10 10
   </link>
11 11
   <description>
12
-    A broken english version of some Nika Zhenya's entries published in Mariana Eguaras's blog.
12
+    Nika Zhenya's entries from Mariana Eguaras' blog in broken english.
13 13
   </description>
14 14
   <language>
15 15
     en-US
... ...
@@ -18,7 +18,7 @@
18 18
     nika.zhenya@cliteratu.re (Nika Zhenya)
19 19
   </managingEditor>
20 20
   <lastBuildDate>
21
-    Thu, 04 Oct 2018 00:00:00 -0500
21
+    Sun, 07 Oct 2018 00:00:00 -0500
22 22
   </lastBuildDate>
23 23
   <image>
24 24
     <title>
... ...
@@ -42,7 +42,7 @@
42 42
       https://blog.cliteratu.re/html/entry001.html
43 43
     </link>
44 44
     <description>
45
-      A general comparation between the most common methods for developing EPUBs.
45
+      A general comparation between the most common methods for developing EPUBs: InDesign, Sigil, Jutoh and “from scratch publishing”.
46 46
     </description>
47 47
     <author>
48 48
       nika.zhenya@cliteratu.re (Nika Zhenya)
... ...
@@ -4,7 +4,7 @@
4 4
   <title>Publishing is Coding: Change My Mind | Digital Publishing as Publishing from Scratch</title>
5 5
   <meta charset="utf-8" />
6 6
   <meta name="application-name" content="Publishing is Coding: Change My Mind">
7
-  <meta name="description" content="A broken english version of some Nika Zhenya's entries published in Mariana Eguaras's blog.">
7
+  <meta name="description" content="Nika Zhenya's entries from Mariana Eguaras' blog in broken english.">
8 8
   <meta name="keywords" content="publishing, blog, book, ebook, methodology, foss, libre-software, format, markdown, html, epub, pdf, mobi, latex, tex">
9 9
   <link rel="shortcut icon" href="../icon.png">
10 10
   <link rel="alternate" type="application/rss+xml" href="https://blog.cliteratu.re/feed/" title="Publishing is Coding: Change My Mind">
... ...
@@ -16,7 +16,7 @@
16 16
 <body>
17 17
 <header>
18 18
   <h1><a href="https://blog.cliteratu.re">Publishing is Coding: Change My Mind</a></h1>
19
-  <p>A broken english version of some Nika Zhenya's entries published in <a target="_blank" href="https://marianaeguaras.com/blog/">Mariana Eguaras's blog</a>.</p>
19
+  <p>Nika Zhenya's entries from <a target="_blank" href="https://marianaeguaras.com/blog/">Mariana Eguaras' blog</a> in broken english.</p>
20 20
   <nav>
21 21
     <h3>Contact</h3>
22 22
     <p><a target="_blank" href="mailto:nika.zhenya@cliteratu.re">Email</a></p>
... ...
@@ -25,12 +25,12 @@
25 25
   </nav>
26 26
 </header>
27 27
 <section>
28
-<h1 id="digital-publishing-as-publishing-from-scratch">Digital Publishing as Publishing from Scratch</h1>        <p class="meta">October 3, 2018 | Methodology | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/md/entry001.md">MD</a></span> / <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/ebooks/entry001.epub">EPUB</a></span> / <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/ebooks/entry001.mobi">MOBI</a></span> / <a target="_blank" href="https://marianaeguaras.com/edicion-digital-como-edicion-desde-cero">spanish source</a></p>        <p>Thanks to <a href="http://marianaeguaras.com/">Mariana Eguaras</a> we are going to blogging about <b>digital publishing</b>, its <b>characteristics, benefits and challenges</b>, as well as <b>its relation with print publishing</b> and how these issues directly affect the necesary proceedings for any kind of publishing.</p>        <p>We already have planned what we are going write in the first entries, but any suggestion is welcome. As far as possible the writing is not going to be technical and more friendly to general public or publishers.</p>        <p>However, you have to consider that some technicalities are now necessary for publishing. As well as the typography, printing or design slangs are common knowledge for publishers, in the same way the jargons from web or software developers are starting to be part of our cultural background.</p>        <blockquote class="addenda">            <p>The entries were originally wrote in spanish. Some of them are now kind of old: for some things I already have a different opinion or distinct approach. And as is obvious, english is not my first language. Therefore, you are going to find a lot of grammar mistakes or typos and I will only translate (in a very free way) the entries that I still consider relevant. So when you find this kind of box with, it means that it is an <i>addendum</i> only for this broken english version.</p>        </blockquote>        <blockquote class="addenda">            <p>Do you want to improve this mess? You can always help through <a href="https://gitlab.com/NikaZhenya/publishing-is-coding">GitLab</a> or <a href="https://github.com/NikaZhenya/publishing-is-coding">GitHub</a>.</p>        </blockquote>    
28
+<h1 id="digital-publishing-as-publishing-from-scratch">Digital Publishing as Publishing from Scratch</h1>        <p class="meta">October 3, 2018 | Methodology | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/md/entry001.md">MD</a></span> / <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/ebooks/entry001.epub">EPUB</a></span> / <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/ebooks/entry001.mobi">MOBI</a></span> / <a target="_blank" href="https://marianaeguaras.com/edicion-digital-como-edicion-desde-cero">spanish version</a></p>        <p>Thanks to <a href="http://marianaeguaras.com/">Mariana Eguaras</a> we are going to blog about <b>digital publishing</b>, its <b>characteristics, benefits and challenges</b>. We are also going to talk about <b>its relation with print publishing</b> and how these issues directly affect the proceedings for any kind of publishing.</p>        <p>We already have planned what we are going to write about in the first entries, but any suggestions are welcome. As much as it is possible the writing won't be technical. We are going to try to be more friendly to the general public or publishers.</p>        <p>However, you have to consider that some technicalities are necessary for publishing. The typography, printing or design slangs are common knowledge for publishers. In the same way, the jargons from web or software developers are starting to be part of our cultural background.</p>        <blockquote class="addenda">            <p>The entries were originally wrote in spanish. Some of them are now kind of old: in some things I have a different opinion or approach. And as it is obvious, english is not my first language. Therefore, you are going to find a lot of grammar mistakes or typos and I will only translate (in a very loose way) the entries that I still consider relevant. So when you find this kind of box, it means that it is an <i>addendum</i> only for this broken english version.</p>        </blockquote>        <blockquote class="addenda">            <p>Do you want to improve this mess? You can always help through <a href="https://gitlab.com/NikaZhenya/publishing-is-coding">GitLab</a> or <a href="https://github.com/NikaZhenya/publishing-is-coding">GitHub</a>.</p>        </blockquote>        <p>In this first entry we will do a <b>general comparison between some of the most common methods for developing an standarized ebook in <span class="smallcap">EPUB</span> format</b>. Some other time we will go deeper in the history of <span class="smallcap">EPUB</span>.</p>        <p>First off we should say that between the different ebook formats available the <span class="smallcap">EPUB</span> since the begining was created as a type of file for <i>ebooks</i>. The <span class="smallcap">EPUB</span> stands out because of its <b>versatility, lightness and respect of web standards</b>. This ensures code uniformity and <b>complete control over the text edition</b>.</p>        <p>With these features, the <span class="smallcap">EPUB</span> is easily convertible in propertary formats as the ones used by Amazon or Apple. That means that we can save resources and time when we develop a digital publication.</p>        <p>This flexibility also allows the development of software that intends to facilitate the creation of <span class="smallcap">EPUB</span>s. Just with a couple of clicks in a text processor (Writer or Word, e.g.) or desktop publishing (like InDesign) we instantly have an <span class="smallcap">EPUB</span>.</p>        <p>At first glance this is a huge advantage for indie authors or publishers that don't want to invest in “additional efforts.” However there are at least <b>two disvantages</b> in doing things this way:</p>        <ol>            <li>                <p>The code, design and text edition's qualities tend to be lower in comparison of others methods.</p>            </li>            <li>                <p>It forgots that the most important thing about the digital revolution it is not the ebook.</p>            </li>        </ol>        <p>The ebook is the most common feature in digital publishing but it is just the tip of the iceberg. In order to go deeper we will have to familiarize with <b>behind the scenes of ebook's development</b>.</p>        <blockquote class="addenda">            <p>In spanish I insist that digital publishing it isn't the same that digital editing. In spanish it is common to use the word “edition” and derivatives for things concerned during publishing. But as far as I can see, “edition“ has a more general meaning in english spoken world.</p>        </blockquote>        <blockquote class="addenda">            <p>With “digital editing” I mean <i>the process</i> for publishing that involves the use of a computer (practically all publishing industry nowadays). “Digital publishing” is <i>the product</i> of such process. In these translations I will use the terms interchangeably. Only when I see the relevance I will say “digital editing” or “digital text editing.”</p>        </blockquote>        <p>Some people are skeptical about the need of publishing “from scratch.” Most people prefer to use conversors to automatically create <span class="smallcap">EPUB</span> files.</p>        <p>Why we have to learn markup languages such as <a href="https://en.wikipedia.org/wiki/HTML"><span class="smallcap">HTML</span></a> or <a href="https://en.wikipedia.org/wiki/Markdown">Markdown</a>? Why we should worry about styles sheets like <a href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets"><span class="smallcap">CSS</span></a> or <a href="https://en.wikipedia.org/wiki/Sass_(stylesheet_language)"><span class="smallcap">SCSS</span></a>? Why we must think about programming languages (<a href="https://en.wikipedia.org/wiki/JavaScript">JavaScript</a>, <a href="https://en.wikipedia.org/wiki/Python_(programming_language)">Python</a>, <a href="https://en.wikipedia.org/wiki/Ruby_(programming_language)">Ruby</a> or <a href="https://en.wikipedia.org/wiki/C++">C++</a>, e.g.) and how it could create new reading experiencies or improve the quality of text edition?</p>        <p>Regardless you want a print or digital book, if we start to put attention in methodologies, litle by litle we will see its importance.</p>        <h2 id="exercises-peculiarities">Exercise's peculiarities</h2>        <p>To show the advantages and disadvantages of conversors compared to “from scratch publishing,” we will develop the same book but with each method.</p>        <p>We are gonna do this exercise as real as possible. That is why we are gonna use <a href="http://www.gutenberg.org/ebooks/2000">Gutenberg Project's spanish edition of <i>Don Quixote</i></a>. For uniformity our standing points are the text in <span class="smallcap">HTML</span> format and the same <span class="smallcap">CSS</span> style sheet.</p>        <p>You could wonder:</p>        <ul>            <li>                <p><b>Why will we use Gutenberg Project's edition if there are better editions online?</b> Because it is public domain. Unlike <a href="https://es.wikisource.org/wiki/El_ingenioso_hidalgo_Don_Quijote_de_la_Mancha">Wikisource's edition</a>, it is easy to download in a single file.</p>            </li>            <li>                <p><b>Why will we use an already formated text and not the direct source?</b> I found some typos and similar issues; plus, formating text could be a nigthmare which I prefer to discuss it other time.</p>            </li>            <li>                <p><b>Why will we use the same style sheet instead of redesign the book in each method?</b> Design could involve a lot of time and resources. Also, I want to show the revelance and flexibility of web style sheets on publishing even though I am going to talk about it in other entry.</p>            </li>            <li>                <p><b>Which methods will we apply in this exercise?</b> We will see <a href="https://www.adobe.com/products/indesign.html">InDesign's</a> way of doing things because it is the most common among publishers and designers. We will use <a href="http://jutoh.com/">Jutoh</a> like an example of propertary software for ebook publishing. Also, we will employ <a href="https://github.com/Sigil-Ebook/Sigil">Sigil</a> as open software for ebook publishing. Finally, we will show how “from scratch publishing” could be a good candidate for digital publishing.</p>            </li>        </ul>        <h2 id="production-time-chart-the-efectiveness-of-from-scratch-method">Production time chart: the efectiveness of “from scratch”    method</h2>        <figure>            <img src="../img/e001_01.jpg" alt="Production time chart in minutes. “Desde cero” is equal to “from scratch”."/>            <figcaption>                Production time chart in minutes. “Desde cero” is equal to “from scratch”.            </figcaption>        </figure>        <p>One of the biggest myths about “from scratch publishing” is that it requires a lot of time. But “from scratch” doesn't mean we have to do all the code by hand. As we will see in other entries, with <a href="https://en.wikipedia.org/wiki/Scripting_language">scripts</a> we can grasp all monotonous work implied in <span class="smallcap">EPUB</span> development.</p>        <p>With “from scratch publishing” I mean a method were we don't have a publishing enviroment. Instead of that we use a <a href="https://en.wikipedia.org/wiki/Text_editor">plain text editor</a> or a <a href="https://en.wikipedia.org/wiki/Source_code_editor">source code editor</a> and a <a href="https://en.wikipedia.org/wiki/Command-line_interface">command-line interface</a>.</p>        <p>This method could sound very complex and time consuming. While “from scratch publishing” has it owns challenges, anyone with a computer can overcome these difficulties.</p>        <p>If we ignore the time needed to format text, in the following chart we can see that <b>“from scratch” method is the most efective</b>.</p>        <p>With InDesign and Jutoh we have to link each <span class="smallcap">CSS</span> style to a paragraph or character style. InDesign is way more intuitive than Jutoh. With Sigil or “from scratch publishing” we don't have this need, because we can automatically link the <span class="smallcap">CSS</span> with the book. But “from scratch” method has the advantage that we don't have to recreate the directory tree or import files.</p>        <h2 id="epubs-size-chart-the-impact-of-images-and-junk-code"><span class="smallcap">EPUB</span>'s size chart: the impact of images and “junk”    code</h2>        <figure>            <img src="../img/e001_02.jpg" alt="EPUB's size chart in KBs."/>            <figcaption>                <span class="smallcap">EPUB</span>'s size chart in <span class="smallcap">KB</span>s.            </figcaption>        </figure>        <p>There are two factors that impact EPUB's size: <b>1)</b> embedded images <b>2)</b> “junk” code.</p>        <p>Most <span class="smallcap">EPUB</span>s embed at least one image, the cover, and sometimes also a back cover and an author's photo. No matter there are just a couple of elements, images are <b>the most heavy files in an <span class="smallcap">EPUB</span></b> if we have one or more of these setups:</p>        <ul>            <li>                <p>The book is short.</p>            </li>            <li>                <p>The images are bigger than our needs.</p>            </li>            <li>                <p>The images lack of good compression.</p>            </li>            <li>                <p>The images are in an inconvenient format.</p>            </li>        </ul>        <p>Neither of this conditions affect our exercise because we are using the same 204 <span class="smallcap">KB</span> image.</p>        <p><b>The difference comes from “junk” code</b>. Some conversors add extra code lines. Most of the times it is because it inject its credits. We also get extra code if we work with paragraph or character styles instead of <span class="smallcap">CSS</span> styles.</p>        <blockquote class="addenda">            <p>These extra code lines doesn't improve the reading experience of our <span class="smallcap">EPUB</span>, that is why we called them “junk” code.</p>        </blockquote>        <p>When we allow conversors to create the <span class="smallcap">CSS</span>, they will use their own name conventions that generates <b>two downsides</b>:</p>        <ol>            <li>                <p>Needless increase of file's size.</p>            </li>            <li>                <p><span class="smallcap">CSS</span> name convention that could made hard to understand or edit.</p>            </li>        </ol>        <p>InDesing and Jutoh's <span class="smallcap">EPUB</span> are bigger because of “junk” code. Nevertheless, the size difference between Sigil and “from scratch publishing” involes the ebook's structure.</p>        <p>From <span class="smallcap">EPUB</span>3 we have two files for the table of contents (<span class="smallcap">TOC</span>). <span class="smallcap">NCX</span> is the legacy file while the new file follows an <a href="https://en.wikipedia.org/wiki/XHTML"><span class="smallcap">XHTML</span></a> structure.</p>        <p>Because of that, <b>the <span class="smallcap">EPUB</span> developed with “from scratch publishing” has two <span class="smallcap">TOC</span>s</b>. This adds 11 <span class="smallcap">KB</span> resulting in a difference of only 5 <span class="smallcap">KB</span> between Sigil and “from scratch publishing” books.</p>        <blockquote class="addenda">            <p>This means that by default Sigil doesn't create the new required <span class="smallcap">TOC</span> format. That could affect the reading experience in newest devices.</p>        </blockquote>        <h2 id="errors-and-warnings-chart-epub-validation">Errors and warnings chart: <span class="smallcap">EPUB</span> validation</h2>        <figure>            <img src="../img/e001_03.jpg" alt="Erros and warnings chart. Errors displayed in red and warnings in yellow."/>            <figcaption>                Erros and warnings chart. Errors displayed in red and warnings in yellow.            </figcaption>        </figure>        <p>One of the main advantages of not developing an <span class="smallcap">EPUB</span> with “from scratch” method is that we don't have to know <span class="smallcap">HTML</span>, <span class="smallcap">CSS</span> and <span class="smallcap">EPUB</span> structures. Usually we also count with a graphic interface that implies a short learning curve.</p>        <p>However, <b>ebooks not only requieres good text edition and design qualities, they also need coherent structures</b>, i.e. we have to care about the technical issues. <span class="smallcap">EPUB</span>s must not have errors or warnings because bad quality <span class="smallcap">HTML</span> or <span class="smallcap">CSS</span> code, insufficient metadata or images issues.</p>        <p>For this reasons we need <b>EPUB validators</b>. The official tool for EPUB validation is EpubCheck. You can use it <a href="http://validator.idpf.org/">online</a> of <a href="https://github.com/IDPF/epubcheck/releases">download it</a>.</p>        <p>Generally we use another validator so we can do a double check. For this exercise we also used <a href="http://www.bluegriffon-epubedition.com/BGEV.html">BlueGriffon</a>. This software isn't free, but is demanded by some clients.</p>        <p>The above chart only show BlueGriffon's validation because EpubCheck didn't find any error or warning. We had a few issues because we used the same <span class="smallcap">HTML</span> and <span class="smallcap">CSS</span> files. Besides, each method created metadata independently. (For “from scratch publishing” we used <a href="https://pecas.cliteratu.re/">Pecas</a>, a suite of publishing scripts).</p>        <p>In InDesign the issue is because an incorrect image compression. For Sigil and Jutoh, BlueGriffon considers they are using obsolete metadata elements.</p>        <p>Actually, <b>it isn't hard to solve these issues</b>. Nevertheless, it could be very frustrating to solve them if you don't now what is inside an <span class="smallcap">EPUB</span> file. In order to solve them we must decompress the <span class="smallcap">EPUB</span>, then we have to modify the problematic files and, finally, compress the files again.</p>        <h2 id="implicit-production-costs-propertary-vs-free-software">Implicit production costs: propertary <i>vs</i> free software</h2>        <p>We dont need to buy software in order to develop <span class="smallcap">EPUB</span>s.</p>        <p>However, the half of the methods seen here use propertary software and, therefore, they have some additional costs. For InDesign and Jutoh we have to purchase software licenses. Sigil and “from scratch publishing” only use free software.</p>        <p>A common myth between non-free software users is that this kind of tools have lower quality. At least in publishing enviroment this is fake. As we could see in this exercise: <b>Sigil and “from scratch publishing” had better results</b>.</p>        <p>Nevertheless, most publishers only use Adobe products, so in specific circumstances it is more convenient to develop ebooks by this way.</p>        <p>If you really care about the quality of your <span class="smallcap">EPUB</span>s, think twice before buying propertary software. The free and open source software communities have great alternatives that could fullfit your needs.</p>        <h2 id="conclusion-from-scratch-publishing-wins-the-match">Conclusion: “from scratch publishing” wins the match</h2>        <p>As it was shown in this exercise <b>“from scratch publishing”</b> had better results. Most readers could think that this method requieres certain complex knowledge and a long learning curve.</p>        <p>I can say that within 24 hours workshop anybody can develop its first ebook “from scratch.” Usually most assitants don't have a technical background such as knowing <span class="smallcap">HTML</span>, <span class="smallcap">CSS</span> or command line tools.</p>        <p>If you are gong to use software exclusively for ebooks, the recommendation is that it has to be free or open source software. With this you can avoid the costs increment at the same time that you can get free help from its communities.</p>        <p>You can download the exercise's files <a href="http://clientes.cliteratu.re/eguaras/epubs.zip">here</a>. Just consider that they are in spanish :)</p>    
29 29
 </section>
30 30
 <footer>
31 31
   <p><a target="_blank" href="https://ted.cliteratu.re/">ted.cliteratu.re</a> | <a target="_blank" href="https://ed.cliteratu.re/">ed.cliteratu.re</a> | <a target="_blank" href="https://pecas.cliteratu.re/">pecas.cliteratu.re</a> | <a target="_blank" href="https://xxx.cliteratu.re/">xxx.cliteratu.re</a></p>
32 32
   <p>All content is under <a target="_blank" href="https://github.com/NikaZhenya/publishing-is-coding#license">Licencia Editorial Abierta y Libre (<span class="smallcap">LEAL</span>)</a>.</p>
33
-  <p>Last build: October 4, 2018 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
33
+  <p>Last build: October 7, 2018 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
34 34
   <p><a target="_blank" href="https://gitlab.com/NikaZhenya/publishing-is-coding">GitLab</a> | <a target="_blank" href="https://github.com/NikaZhenya/publishing-is-coding">GitHub</a> | <a target="_blank" href="http://git.cliteratu.re/publishing-is-coding">GitList</a></p>
35 35
   <p><a target="_blank" href="https://etherscan.io/address/0x39b0bf0cf86776060450aba23d1a6b47f5570486"><span class="smallcap">ETH</span></a> | <a target="_blank" href="https://dogechain.info/address/DMbxM4nPLVbzTALv5n8G16TTzK4WDUhC7G"><span class="smallcap">DOGE</span></a> | <a target="_blank" href="https://www.paypal.me/perrotuerto">PayPal</a></p>
36 36
 </footer>
37 37
new file mode 100644
38 38
Binary files /dev/null and b/img/e001_01.jpg differ
39 39
new file mode 100644
40 40
Binary files /dev/null and b/img/e001_02.jpg differ
41 41
new file mode 100644
42 42
Binary files /dev/null and b/img/e001_03.jpg differ
... ...
@@ -4,7 +4,7 @@
4 4
   <title>Publishing is Coding: Change My Mind | Digital Publishing as Publishing from Scratch</title>
5 5
   <meta charset="utf-8" />
6 6
   <meta name="application-name" content="Publishing is Coding: Change My Mind">
7
-  <meta name="description" content="A broken english version of some Nika Zhenya's entries published in Mariana Eguaras's blog.">
7
+  <meta name="description" content="Nika Zhenya's entries from Mariana Eguaras' blog in broken english.">
8 8
   <meta name="keywords" content="publishing, blog, book, ebook, methodology, foss, libre-software, format, markdown, html, epub, pdf, mobi, latex, tex">
9 9
   <link rel="shortcut icon" href="icon.png">
10 10
   <link rel="alternate" type="application/rss+xml" href="https://blog.cliteratu.re/feed/" title="Publishing is Coding: Change My Mind">
... ...
@@ -16,7 +16,7 @@
16 16
 <body>
17 17
 <header>
18 18
   <h1><a href="https://blog.cliteratu.re">Publishing is Coding: Change My Mind</a></h1>
19
-  <p>A broken english version of some Nika Zhenya's entries published in <a target="_blank" href="https://marianaeguaras.com/blog/"><a target="_blank" href="https://marianaeguaras.com/blog/">Mariana Eguaras's blog</a></a>.</p>
19
+  <p>Nika Zhenya's entries from <a target="_blank" href="https://marianaeguaras.com/blog/"><a target="_blank" href="https://marianaeguaras.com/blog/">Mariana Eguaras' blog</a></a> in broken english.</p>
20 20
   <nav>
21 21
     <h3>Contact</h3>
22 22
     <p><a target="_blank" href="mailto:nika.zhenya@cliteratu.re">Email</a></p>
... ...
@@ -25,12 +25,12 @@
25 25
   </nav>
26 26
 </header>
27 27
 <section>
28
-<div class="entry" id="entry001"><p><a href="./html/entry001.html">Digital Publishing as Publishing from Scratch</a></p><p class="meta">October 3, 2018 | Methodology</p><p>A general comparation between the most common methods for developing EPUBs.</p></div>
28
+<div class="entry" id="entry001"><p><a href="./html/entry001.html">Digital Publishing as Publishing from Scratch</a></p><p class="meta">October 3, 2018 | Methodology</p><p>A general comparation between the most common methods for developing EPUBs: InDesign, Sigil, Jutoh and “from scratch publishing”.</p></div>
29 29
 </section>
30 30
 <footer>
31 31
   <p><a target="_blank" href="https://ted.cliteratu.re/">ted.cliteratu.re</a> | <a target="_blank" href="https://ed.cliteratu.re/">ed.cliteratu.re</a> | <a target="_blank" href="https://pecas.cliteratu.re/">pecas.cliteratu.re</a> | <a target="_blank" href="https://xxx.cliteratu.re/">xxx.cliteratu.re</a></p>
32 32
   <p>All content is under <a target="_blank" href="https://github.com/NikaZhenya/publishing-is-coding#license">Licencia Editorial Abierta y Libre (<span class="smallcap">LEAL</span>)</a>.</p>
33
-  <p>Last build: October 4, 2018 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
33
+  <p>Last build: October 7, 2018 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
34 34
   <p><a target="_blank" href="https://gitlab.com/NikaZhenya/publishing-is-coding">GitLab</a> | <a target="_blank" href="https://github.com/NikaZhenya/publishing-is-coding">GitHub</a> | <a target="_blank" href="http://git.cliteratu.re/publishing-is-coding">GitList</a></p>
35 35
   <p><a target="_blank" href="https://etherscan.io/address/0x39b0bf0cf86776060450aba23d1a6b47f5570486"><span class="smallcap">ETH</span></a> | <a target="_blank" href="https://dogechain.info/address/DMbxM4nPLVbzTALv5n8G16TTzK4WDUhC7G"><span class="smallcap">DOGE</span></a> | <a target="_blank" href="https://www.paypal.me/perrotuerto">PayPal</a></p>
36 36
 </footer>
... ...
@@ -1,37 +1,324 @@
1 1
 # Digital Publishing as Publishing from Scratch
2 2
 
3
-@meta['2018-10-03','Methodology','A general comparation between the most common methods for developing EPUBs.','https://marianaeguaras.com/edicion-digital-como-edicion-desde-cero']
3
+@meta['2018-10-03','Methodology','A general comparation between the most common methods for developing EPUBs: InDesign, Sigil, Jutoh and “from scratch publishing”.','https://marianaeguaras.com/edicion-digital-como-edicion-desde-cero']
4 4
 
5 5
 Thanks to [Mariana Eguaras](http://marianaeguaras.com/)
6
-we are going to blogging about __digital publishing__,
7
-its __characteristics, benefits and challenges__, as
8
-well as __its relation with print publishing__ and how
9
-these issues directly affect the necesary proceedings
10
-for any kind of publishing.
6
+we are going to blog about __digital publishing__,
7
+its __characteristics, benefits and challenges__. We are
8
+also going to talk about __its relation with print 
9
+publishing__ and how these issues directly affect the 
10
+proceedings for any kind of publishing.
11 11
 
12
-We already have planned what we are going write in the
13
-first entries, but any suggestion is welcome. As far as
14
-possible the writing is not going to be technical and
15
-more friendly to general public or publishers.
12
+We already have planned what we are going to write about
13
+in the first entries, but any suggestions are welcome. As 
14
+much as it is possible the writing won't be technical. We 
15
+are going to try to be more friendly to the general public 
16
+or publishers.
16 17
 
17 18
 However, you have to consider that some technicalities
18
-are now necessary for publishing. As well as the
19
-typography, printing or design slangs are common 
20
-knowledge for publishers, in the same way the jargons
21
-from web or software developers are starting to be part
22
-of our cultural background.
19
+are necessary for publishing. The typography, printing or 
20
+design slangs are common knowledge for publishers. In the
21
+same way, the jargons from web or software developers are 
22
+starting to be part of our cultural background.
23 23
 
24 24
 > The entries were originally wrote in spanish. Some of 
25
-> them are now kind of old: for some things I already 
26
-> have a different opinion or distinct approach. And as 
27
-> is obvious, english is not my first language. 
28
-> Therefore, you are going to find a lot of grammar 
29
-> mistakes or typos and I will only translate (in a very 
30
-> free way) the entries that I still consider relevant. 
31
-> So when you find this kind of box with, it means that 
32
-> it is an _addendum_ only for this broken english 
33
-> version. {.addenda}
25
+> them are now kind of old: in some things I have a 
26
+> different opinion or approach. And as it is obvious, 
27
+> english is not my first language. Therefore, you are 
28
+> going to find a lot of grammar mistakes or typos 
29
+> and I will only translate (in a very loose way) the 
30
+> entries that I still consider relevant. So when you find 
31
+> this kind of box, it means that it is an _addendum_ only 
32
+> for this broken english version. {.addenda}
34 33
 
35 34
 > Do you want to improve this mess? You can always help
36 35
 > through [GitLab](https://gitlab.com/NikaZhenya/publishing-is-coding) 
37 36
 > or [GitHub](https://github.com/NikaZhenya/publishing-is-coding). {.addenda}
37
+
38
+In this first entry we will do a __general comparison 
39
+between some of the most common methods for developing an 
40
+standarized ebook in +++EPUB+++ format__. Some other time 
41
+we will go deeper in the history of +++EPUB+++.
42
+
43
+First off we should say that between the different ebook 
44
+formats available the +++EPUB+++ since the begining was 
45
+created as a type of file for _ebooks_. The +++EPUB+++ 
46
+stands out because of its __versatility, lightness and 
47
+respect of web standards__. This ensures code uniformity 
48
+and __complete control over the text edition__.
49
+
50
+With these features, the +++EPUB+++ is easily convertible
51
+in propertary formats as the ones used by Amazon or Apple.
52
+That means that we can save resources and time when we
53
+develop a digital publication.
54
+
55
+This flexibility also allows the development of software
56
+that intends to facilitate the creation of +++EPUB+++s. Just
57
+with a couple of clicks in a text processor (Writer or Word,
58
+e.g.) or desktop publishing (like InDesign) we instantly
59
+have an +++EPUB+++.
60
+
61
+At first glance this is a huge advantage for indie authors
62
+or publishers that don't want to invest in “additional 
63
+efforts.” However there are at least __two disvantages__ in
64
+doing things this way:
65
+
66
+1. The code, design and text edition's qualities tend to be
67
+   lower in comparison of others methods.
68
+2. It forgots that the most important thing about the 
69
+   digital revolution it is not the ebook.
70
+
71
+The ebook is the most common feature in digital publishing
72
+but it is just the tip of the iceberg. In order to go
73
+deeper we will have to familiarize with __behind the scenes
74
+of ebook's development__.
75
+
76
+> In spanish I insist that digital publishing it isn't the
77
+> same that digital editing. In spanish it is common to use
78
+> the word “edition” and derivatives for things concerned
79
+> during publishing. But as far as I can see, “edition“ has
80
+> a more general meaning in english spoken world. {.addenda}
81
+
82
+> With “digital editing” I mean _the process_ for publishing
83
+> that involves the use of a computer (practically 
84
+> all publishing industry nowadays). “Digital publishing”
85
+> is _the product_ of such process. In these translations I
86
+> will use the terms interchangeably. Only when I see the
87
+> relevance I will say “digital editing” or “digital text
88
+> editing.” {.addenda}
89
+
90
+Some people are skeptical about the need of publishing “from
91
+scratch.” Most people prefer to use conversors to
92
+automatically create +++EPUB+++ files.
93
+
94
+Why we have to learn markup languages such as [+++HTML+++](https://en.wikipedia.org/wiki/HTML)
95
+or [Markdown](https://en.wikipedia.org/wiki/Markdown)? Why
96
+we should worry about styles sheets like [+++CSS+++](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)
97
+or [+++SCSS+++](https://en.wikipedia.org/wiki/Sass_(stylesheet_language))?
98
+Why we must think about programming languages ([JavaScript](https://en.wikipedia.org/wiki/JavaScript),
99
+[Python](https://en.wikipedia.org/wiki/Python_(programming_language)), [Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language))
100
+or [C++](https://en.wikipedia.org/wiki/C%2B%2B), e.g.) and 
101
+how it could create new reading experiencies or improve the
102
+quality of text edition?
103
+
104
+Regardless you want a print or digital book, if we start to
105
+put attention in methodologies, litle by litle we will see
106
+its importance.
107
+
108
+## Exercise's peculiarities
109
+
110
+To show the advantages and disadvantages of conversors 
111
+compared to “from scratch publishing,” we will develop the
112
+same book but with each method.
113
+
114
+We are gonna do this exercise as real as possible. That is
115
+why we are gonna use [Gutenberg Project's spanish edition of
116
+_Don Quixote_](http://www.gutenberg.org/ebooks/2000). For
117
+uniformity our standing points are the text in +++HTML+++
118
+format and the same +++CSS+++ style sheet.
119
+
120
+You could wonder:
121
+
122
+* __Why will we use Gutenberg Project's edition if there are
123
+  better editions online?__ Because it is public domain. 
124
+  Unlike [Wikisource's edition](https://es.wikisource.org/wiki/El_ingenioso_hidalgo_Don_Quijote_de_la_Mancha),
125
+  it is easy to download in a single file.
126
+* __Why will we use an already formated text and not the 
127
+  direct source?__ I found some typos and similar issues; 
128
+  plus, formating text could be a nigthmare which I 
129
+  prefer to discuss it other time.
130
+* __Why will we use the same style sheet instead of 
131
+  redesign the book in each method?__ Design could involve
132
+  a lot of time and resources. Also, I want to show the
133
+  revelance and flexibility of web style sheets on 
134
+  publishing even though I am going to talk about it in
135
+  other entry.
136
+* __Which methods will we apply in this exercise?__ We will
137
+  see [InDesign's](https://www.adobe.com/products/indesign.html) 
138
+  way of doing things because it is the most common among 
139
+  publishers and designers. We will use [Jutoh](http://jutoh.com/)
140
+  like an example of propertary software for ebook 
141
+  publishing. Also, we will employ [Sigil](https://github.com/Sigil-Ebook/Sigil)
142
+  as open software for ebook publishing. Finally, we will
143
+  show how “from scratch publishing” could be a good
144
+  candidate for digital publishing.
145
+
146
+## Production time chart: the efectiveness of “from scratch”
147
+   method
148
+
149
+![Production time chart in minutes. “Desde cero” is equal to “from scratch”.](../img/e001_01.jpg)
150
+
151
+One of the biggest myths about “from scratch publishing”
152
+is that it requires a lot of time. But “from scratch” 
153
+doesn't mean we have to do all the code by hand. As we will 
154
+see in other entries, with [scripts](https://en.wikipedia.org/wiki/Scripting_language) 
155
+we can grasp all monotonous work implied in +++EPUB+++ 
156
+development.
157
+
158
+With “from scratch publishing” I mean a method were we 
159
+don't have a publishing enviroment. Instead of that we use
160
+a [plain text editor](https://en.wikipedia.org/wiki/Text_editor)
161
+or a [source code editor](https://en.wikipedia.org/wiki/Source_code_editor)
162
+and a [command-line interface](https://en.wikipedia.org/wiki/Command-line_interface).
163
+
164
+This method could sound very complex and time consuming.
165
+While “from scratch publishing” has it owns challenges, 
166
+anyone with a computer can overcome these difficulties.
167
+
168
+If we ignore the time needed to format text, in the
169
+following chart we can see that __“from scratch” method is
170
+the most efective__.
171
+
172
+With InDesign and Jutoh we have to link each +++CSS+++ style
173
+to a paragraph or character style. InDesign is way more 
174
+intuitive than Jutoh. With Sigil or “from scratch 
175
+publishing” we don't have this need, because we can 
176
+automatically link the +++CSS+++ with the book. But “from
177
+scratch” method has the advantage that we don't have to
178
+recreate the directory tree or import files.
179
+
180
+## +++EPUB+++'s size chart: the impact of images and “junk”
181
+   code
182
+
183
+![+++EPUB+++'s size chart in +++KB+++s.](../img/e001_02.jpg)
184
+
185
+There are two factors that impact EPUB's size: __1)__
186
+embedded images __2)__ “junk” code.
187
+
188
+Most +++EPUB+++s embed at least one image, the cover, and
189
+sometimes also a back cover and an author's photo. No 
190
+matter there are just a couple of elements, images are
191
+__the most heavy files in an +++EPUB+++__ if we have one
192
+or more of these setups:
193
+
194
+* The book is short.
195
+* The images are bigger than our needs.
196
+* The images lack of good compression.
197
+* The images are in an inconvenient format.
198
+
199
+Neither of this conditions affect our exercise because we
200
+are using the same 204 +++KB+++ image.
201
+
202
+__The difference comes from “junk” code__. Some conversors
203
+add extra code lines. Most of the times it is because it
204
+inject its credits. We also get extra code if we work with 
205
+paragraph or character styles instead of +++CSS+++ styles.
206
+
207
+> These extra code lines doesn't improve the reading
208
+> experience of our +++EPUB+++, that is why we called them
209
+> “junk” code. {.addenda}
210
+
211
+When we allow conversors to create the +++CSS+++, they 
212
+will use their own name conventions that generates __two
213
+downsides__:
214
+
215
+1. Needless increase of file's size.
216
+2. +++CSS+++ name convention that could made hard to 
217
+   understand or edit.
218
+
219
+InDesing and Jutoh's +++EPUB+++ are bigger because of “junk” 
220
+code. Nevertheless, the size difference between Sigil and 
221
+“from scratch publishing” involes the ebook's structure.
222
+
223
+From +++EPUB+++3 we have two files for the table of 
224
+contents (+++TOC+++). +++NCX+++ is the legacy file while the 
225
+new file follows an [+++XHTML+++](https://en.wikipedia.org/wiki/XHTML)
226
+structure.
227
+
228
+Because of that, __the +++EPUB+++ developed with “from
229
+scratch publishing” has two +++TOC+++s__. This adds 11 
230
+between Sigil and “from scratch publishing” books.
231
+
232
+> This means that by default Sigil doesn't create the new
233
+> required +++TOC+++ format. That could affect the reading
234
+> experience in newest devices. {.addenda}
235
+
236
+## Errors and warnings chart: +++EPUB+++ validation
237
+
238
+![Erros and warnings chart. Errors displayed in red and warnings in yellow.](../img/e001_03.jpg)
239
+
240
+One of the main advantages of not developing an +++EPUB+++ 
241
+with “from scratch” method is that we don't have to know
242
+also count with a graphic interface that implies a short 
243
+learning curve.
244
+
245
+However, __ebooks not only requieres good text edition and
246
+design qualities, they also need coherent structures__,
247
+i.e. we have to care about the technical issues. +++EPUB+++s
248
+must not have errors or warnings because bad quality 
249
+images issues.
250
+
251
+For this reasons we need __EPUB validators__. The official
252
+tool for EPUB validation is EpubCheck. You can use it
253
+[online](http://validator.idpf.org/) of [download it](https://github.com/IDPF/epubcheck/releases).
254
+
255
+Generally we use another validator so we can do a double
256
+check. For this exercise we also used [BlueGriffon](http://www.bluegriffon-epubedition.com/BGEV.html).
257
+This software isn't free, but is demanded by some clients.
258
+
259
+The above chart only show BlueGriffon's validation because
260
+EpubCheck didn't find any error or warning. We had a few
261
+issues because we used the same +++HTML+++ and +++CSS+++
262
+files. Besides, each method created metadata independently.
263
+(For “from scratch publishing” we used [Pecas](https://pecas.cliteratu.re/),
264
+a suite of publishing scripts).
265
+
266
+In InDesign the issue is because an incorrect image 
267
+compression. For Sigil and Jutoh, BlueGriffon considers they 
268
+are using obsolete metadata elements.
269
+
270
+Actually, __it isn't hard to solve these issues__. 
271
+Nevertheless, it could be very frustrating to solve them if
272
+you don't now what is inside an +++EPUB+++ file. In order to
273
+solve them we must decompress the +++EPUB+++, then we have 
274
+to modify the problematic files and, finally, compress the
275
+files again.
276
+
277
+## Implicit production costs: propertary _vs_ free software
278
+
279
+We dont need to buy software in order to develop 
280
+
281
+However, the half of the methods seen here use propertary
282
+software and, therefore, they have some additional costs. 
283
+For InDesign and Jutoh we have to purchase software 
284
+licenses. Sigil and “from scratch publishing” only use free 
285
+software.
286
+
287
+A common myth between non-free software users is that this
288
+kind of tools have lower quality. At least in publishing
289
+enviroment this is fake. As we could see in this exercise:
290
+__Sigil and “from scratch publishing” had better results__.
291
+
292
+Nevertheless, most publishers only use Adobe products, so in
293
+specific circumstances it is more convenient to develop
294
+ebooks by this way.
295
+
296
+If you really care about the quality of your +++EPUB+++s,
297
+think twice before buying propertary software. The free and
298
+open source software communities have great alternatives 
299
+that could fullfit your needs.
300
+
301
+## Conclusion: “from scratch publishing” wins the match
302
+
303
+As it was shown in this exercise __“from scratch 
304
+publishing”__ had better results. Most readers could think
305
+that this method requieres certain complex knowledge and a
306
+long learning curve.
307
+
308
+I can say that within 24 hours workshop anybody can develop
309
+its first ebook “from scratch.” Usually most assitants don't
310
+have a technical background such as knowing +++HTML+++,
311
+
312
+If you are gong to use software exclusively for ebooks, the
313
+recommendation is that it has to be free or open source
314
+software. With this you can avoid the costs increment at
315
+the same time that you can get free help from its 
316
+communities.
317
+
318
+You can download the exercise's files [here](http://clientes.cliteratu.re/eguaras/epubs.zip).
319
+Just consider that they are in spanish :)