Browse code

Cleaning

Nika Zhenya authored on 23/01/2019 17:30:58
Showing 6 changed files
... ...
@@ -18,7 +18,7 @@
18 18
     nika.zhenya@cliteratu.re (Nika Zhenya)
19 19
   </managingEditor>
20 20
   <lastBuildDate>
21
-    Mon, 05 Nov 2018 00:00:00 -0600
21
+    Wed, 23 Jan 2019 00:00:00 -0600
22 22
   </lastBuildDate>
23 23
   <image>
24 24
     <title>
... ...
@@ -31,28 +31,5 @@
31 31
       https://blog.cliteratu.re
32 32
     </link>
33 33
   </image>
34
-  <item>
35
-    <guid>
36
-      https://blog.cliteratu.re/html/entry001
37
-    </guid>
38
-    <title>
39
-      Digital Publishing as Publishing from Scratch
40
-    </title>
41
-    <link>
42
-      https://blog.cliteratu.re/html/entry001.html
43
-    </link>
44
-    <description>
45
-      A general comparation between the most common methods for developing EPUBs: InDesign, Sigil, Jutoh and “from scratch publishing.”
46
-    </description>
47
-    <author>
48
-      nika.zhenya@cliteratu.re (Nika Zhenya)
49
-    </author>
50
-    <category>
51
-      Methodology
52
-    </category>
53
-    <pubDate>
54
-      Wed, 03 Oct 2018 00:00:00 -0500
55
-    </pubDate>
56
-  </item>
57 34
 </channel>
58 35
 </rss>
... ...
@@ -1,7 +1,7 @@
1 1
 <!DOCTYPE html>
2 2
 <html lang="en-US">
3 3
 <head>
4
-  <title>Publishing is Coding: Change My Mind | Digital Publishing as Publishing from Scratch</title>
4
+  <title>Publishing is Coding: Change My Mind | Main</title>
5 5
   <meta charset="utf-8" />
6 6
   <meta name="application-name" content="Publishing is Coding: Change My Mind">
7 7
   <meta name="description" content="Nika Zhenya's entries from Mariana Eguaras' blog in broken english.">
... ...
@@ -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>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>
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,11 @@
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: InDesign, Sigil, Jutoh and “from scratch publishing.”</p></div>
29 28
 </section>
30 29
 <footer>
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>
30
+  <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://perrotuerto.blog">perrotuerto.blog</a></p>
32 31
   <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: November 5, 2018 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
32
+  <p>Last build: January 23, 2019 | <span class="smallcap"><a target="_blank" href="https://blog.cliteratu.re/feed/rss.xml">RSS</a></span></p>
34 33
   <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 34
   <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 35
 </footer>
37 36
deleted file mode 100644
... ...
@@ -1,325 +0,0 @@
1
-# Digital Publishing as Publishing from Scratch
2
-
3
-@meta['2018-10-12','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
-
5
-Thanks to [Mariana Eguaras](http://marianaeguaras.com/)
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
-
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.
17
-
18
-However, you have to consider that some technicalities
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
-
24
-> The entries were originally wrote in spanish. Some of 
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}
33
-
34
-> Do you want to improve this mess? You can always help
35
-> through [GitLab](https://gitlab.com/NikaZhenya/publishing-is-coding) 
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 is often forgotten that the most important thing about 
69
-   the 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 __the behind the 
74
-scenes of ebook's development__.
75
-
76
-> In spanish I insist that digital publishing isn't the same 
77
-> as digital editing. In spanish it is common to use the 
78
-> word “edition” and derivatives for things concerning 
79
-> 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_ of 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 it
87
-> relevant 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 converters to
92
-automatically create +++EPUB+++ files.
93
-
94
-Why do 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
-should we 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 must we 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 wether you want a print or digital book, if we 
105
-start to pay attention in methodologies, litle by litle we 
106
-will see its importance.
107
-
108
-## Exercise's peculiarities
109
-
110
-To show the advantages and disadvantages of converters 
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 realistically as possible. 
115
-That is 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 another 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
-  another 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 the 
147
-   “from scratch” method
148
-
149
-![Production time chart in minutes.](../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 code it all 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 
186
-size: __1)__ embedded images and __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. It 
190
-doesn't matter if there are just a couple elements, images 
191
-are __the most heavy files in an +++EPUB+++__ if we have 
192
-one 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 converters
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 don't improve the reading
208
-> experience of our +++EPUB+++, that is why we called them
209
-> “junk” code. {.addenda}
210
-
211
-When we allow converters 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 make it 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
-+++KB+++ resulting in a difference of only 5 +++KB+++ 
231
-between Sigil and “from scratch publishing” books.
232
-
233
-> This means that by default Sigil doesn't create the new
234
-> required +++TOC+++ format. That could affect the reading
235
-> experience in newer devices. {.addenda}
236
-
237
-## Errors and warnings chart: +++EPUB+++ validation
238
-
239
-![Erros and warnings chart.](../img/e001_03.jpg)
240
-
241
-One of the main advantages of not developing an +++EPUB+++ 
242
-with “from scratch” method is that we don't have to know
243
-+++HTML+++, +++CSS+++ and +++EPUB+++ structures. Usually we
244
-also count with a graphical interface that implies a short 
245
-learning curve.
246
-
247
-However, __ebooks not only requiere good text edition and
248
-design quality, they also need coherent structures__,
249
-i.e. we have to care about technical issues. +++EPUB+++s
250
-must not have errors or warnings because of bad quality 
251
-+++HTML+++ or +++CSS+++ code, insufficient metadata or
252
-image issues.
253
-
254
-For this reasons we need __+++EPUB+++ validators__. The 
255
-official tool for +++EPUB+++ validation is EpubCheck. You 
256
-can use it [online](http://validator.idpf.org/) or 
257
-[download it](https://github.com/IDPF/epubcheck/releases).
258
-
259
-Generally we use another validator so we can do a double
260
-check. For this exercise we also used [BlueGriffon](http://www.bluegriffon-epubedition.com/BGEV.html).
261
-This software isn't free, but is demanded by some clients.
262
-
263
-The above chart only show BlueGriffon's validation because
264
-EpubCheck didn't find any error or warning. We had a few
265
-issues because we used the same +++HTML+++ and +++CSS+++
266
-files. Besides, each method created metadata independently.
267
-(For “from scratch publishing” we used [Pecas](https://pecas.cliteratu.re/),
268
-a suite of publishing scripts.)
269
-
270
-In InDesign the issue is because an incorrect image 
271
-compression. For Sigil and Jutoh, BlueGriffon considers they 
272
-are using obsolete metadata elements.
273
-
274
-Actually, __it isn't hard to solve these issues__. 
275
-Nevertheless, it could be very frustrating to solve them if
276
-you don't know what is inside an +++EPUB+++ file. In order to
277
-solve them we must decompress the +++EPUB+++, then we have 
278
-to modify the problematic files and, finally, compress the
279
-files again.
280
-
281
-## Implicit production costs: propertary _vs_ free software
282
-
283
-We dont need to buy software in order to develop 
284
-+++EPUB+++s.
285
-
286
-However, half of the methods seen here use propertary
287
-software and, therefore, they have some additional costs. 
288
-For InDesign and Jutoh we have to purchase software 
289
-licenses. Sigil and “from scratch publishing” only use free 
290
-software.
291
-
292
-A common myth between non-free software users is that this
293
-kind of tools have lower quality. At least in publishing
294
-enviroment this isn't true. As we could see in this exercise:
295
-__Sigil and “from scratch publishing” had better results__.
296
-
297
-However, most publishers only use Adobe products, so in
298
-specific circumstances it is more convenient to develop
299
-ebooks by this way.
300
-
301
-If you really care about the quality of your +++EPUB+++s,
302
-think twice before buying propertary software. The free and
303
-open source software communities have great alternatives 
304
-that could fulfill your needs.
305
-
306
-## Conclusion: “from scratch publishing” wins the match
307
-
308
-As it was shown in this exercise __“from scratch 
309
-publishing”__ had better results. Most readers could think
310
-that this method requieres certain complex knowledge and a
311
-long learning curve.
312
-
313
-I can say that within a 24 hours workshop anybody can 
314
-develop their first ebook “from scratch.” Usually most 
315
-learners don't have a technical background such as 
316
-knowing +++HTML+++, +++CSS+++ or command line tools.
317
-
318
-If you are gong to use software exclusively for ebooks, the
319
-recommendation is that it has to be free or open source
320
-software. With this you can avoid the cost increments at
321
-the same time that you can get free help from their
322
-communities.
323
-
324
-You can download the [graphics](http://git.cliteratu.re/publishing-is-coding/blob/master/src/entry001/graphics.ods)
325
-and the [data](http://git.cliteratu.re/publishing-is-coding/raw/master/src/entry001/data.txt) :)
326 1
new file mode 100644
... ...
@@ -0,0 +1,325 @@
0
+# Digital Publishing as Publishing from Scratch
1
+
2
+@meta['2018-10-12','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']
3
+
4
+Thanks to [Mariana Eguaras](http://marianaeguaras.com/)
5
+we are going to blog about __digital publishing__,
6
+its __characteristics, benefits and challenges__. We are
7
+also going to talk about __its relation with print 
8
+publishing__ and how these issues directly affect the 
9
+proceedings for any kind of publishing.
10
+
11
+We already have planned what we are going to write about
12
+in the first entries, but any suggestions are welcome. As 
13
+much as it is possible the writing won't be technical. We 
14
+are going to try to be more friendly to the general public 
15
+or publishers.
16
+
17
+However, you have to consider that some technicalities
18
+are necessary for publishing. The typography, printing or 
19
+design slangs are common knowledge for publishers. In the
20
+same way, the jargons from web or software developers are 
21
+starting to be part of our cultural background.
22
+
23
+> The entries were originally wrote in spanish. Some of 
24
+> them are now kind of old: in some things I have a 
25
+> different opinion or approach. And as it is obvious, 
26
+> english is not my first language. Therefore, you are 
27
+> going to find a lot of grammar mistakes or typos 
28
+> and I will only translate (in a very loose way) the 
29
+> entries that I still consider relevant. So when you find 
30
+> this kind of box, it means that it is an _addendum_ only 
31
+> for this broken english version. {.addenda}
32
+
33
+> Do you want to improve this mess? You can always help
34
+> through [GitLab](https://gitlab.com/NikaZhenya/publishing-is-coding) 
35
+> or [GitHub](https://github.com/NikaZhenya/publishing-is-coding). {.addenda}
36
+
37
+In this first entry we will do a __general comparison 
38
+between some of the most common methods for developing an 
39
+standarized ebook in +++EPUB+++ format__. Some other time 
40
+we will go deeper in the history of +++EPUB+++.
41
+
42
+First off we should say that between the different ebook 
43
+formats available the +++EPUB+++ since the begining was 
44
+created as a type of file for _ebooks_. The +++EPUB+++ 
45
+stands out because of its __versatility, lightness and 
46
+respect of web standards__. This ensures code uniformity 
47
+and __complete control over the text edition__.
48
+
49
+With these features, the +++EPUB+++ is easily convertible
50
+in propertary formats as the ones used by Amazon or Apple.
51
+That means that we can save resources and time when we
52
+develop a digital publication.
53
+
54
+This flexibility also allows the development of software
55
+that intends to facilitate the creation of +++EPUB+++s. Just
56
+with a couple of clicks in a text processor (Writer or Word,
57
+e.g.) or desktop publishing (like InDesign) we instantly
58
+have an +++EPUB+++.
59
+
60
+At first glance this is a huge advantage for indie authors
61
+or publishers that don't want to invest in “additional 
62
+efforts.” However there are at least __two disvantages__ in
63
+doing things this way:
64
+
65
+1. The code, design and text edition's qualities tend to be
66
+   lower in comparison of others methods.
67
+2. It is often forgotten that the most important thing about 
68
+   the digital revolution it is not the ebook.
69
+
70
+The ebook is the most common feature in digital publishing
71
+but it is just the tip of the iceberg. In order to go
72
+deeper we will have to familiarize with __the behind the 
73
+scenes of ebook's development__.
74
+
75
+> In spanish I insist that digital publishing isn't the same 
76
+> as digital editing. In spanish it is common to use the 
77
+> word “edition” and derivatives for things concerning 
78
+> publishing. But as far as I can see, “edition“ has
79
+> a more general meaning in english spoken world. {.addenda}
80
+
81
+> With “digital editing” I mean _the process_ of publishing
82
+> that involves the use of a computer (practically 
83
+> all publishing industry nowadays). “Digital publishing”
84
+> is _the product_ of such process. In these translations I
85
+> will use the terms interchangeably. Only when I see it
86
+> relevant I will say “digital editing” or “digital text
87
+> editing.” {.addenda}
88
+
89
+Some people are skeptical about the need of publishing “from
90
+scratch.” Most people prefer to use converters to
91
+automatically create +++EPUB+++ files.
92
+
93
+Why do we have to learn markup languages such as [+++HTML+++](https://en.wikipedia.org/wiki/HTML)
94
+or [Markdown](https://en.wikipedia.org/wiki/Markdown)? Why
95
+should we worry about styles sheets like [+++CSS+++](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)
96
+or [+++SCSS+++](https://en.wikipedia.org/wiki/Sass_(stylesheet_language))?
97
+Why must we think about programming languages ([JavaScript](https://en.wikipedia.org/wiki/JavaScript),
98
+[Python](https://en.wikipedia.org/wiki/Python_(programming_language)), [Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language))
99
+or [C++](https://en.wikipedia.org/wiki/C%2B%2B), e.g.) and 
100
+how it could create new reading experiencies or improve the
101
+quality of text edition?
102
+
103
+Regardless wether you want a print or digital book, if we 
104
+start to pay attention in methodologies, litle by litle we 
105
+will see its importance.
106
+
107
+## Exercise's peculiarities
108
+
109
+To show the advantages and disadvantages of converters 
110
+compared to “from scratch publishing,” we will develop the
111
+same book but with each method.
112
+
113
+We are gonna do this exercise as realistically as possible. 
114
+That is why we are gonna use [Gutenberg Project's spanish edition of
115
+_Don Quixote_](http://www.gutenberg.org/ebooks/2000). For
116
+uniformity our standing points are the text in +++HTML+++
117
+format and the same +++CSS+++ style sheet.
118
+
119
+You could wonder:
120
+
121
+* __Why will we use Gutenberg Project's edition if there are
122
+  better editions online?__ Because it is public domain. 
123
+  Unlike [Wikisource's edition](https://es.wikisource.org/wiki/El_ingenioso_hidalgo_Don_Quijote_de_la_Mancha),
124
+  it is easy to download in a single file.
125
+* __Why will we use an already formated text and not the 
126
+  direct source?__ I found some typos and similar issues; 
127
+  plus, formating text could be a nigthmare which I 
128
+  prefer to discuss another time.
129
+* __Why will we use the same style sheet instead of 
130
+  redesign the book in each method?__ Design could involve
131
+  a lot of time and resources. Also, I want to show the
132
+  revelance and flexibility of web style sheets on 
133
+  publishing even though I am going to talk about it in
134
+  another entry.
135
+* __Which methods will we apply in this exercise?__ We will
136
+  see [InDesign's](https://www.adobe.com/products/indesign.html) 
137
+  way of doing things because it is the most common among 
138
+  publishers and designers. We will use [Jutoh](http://jutoh.com/)
139
+  like an example of propertary software for ebook 
140
+  publishing. Also, we will employ [Sigil](https://github.com/Sigil-Ebook/Sigil)
141
+  as open software for ebook publishing. Finally, we will
142
+  show how “from scratch publishing” could be a good
143
+  candidate for digital publishing.
144
+
145
+## Production time chart: the efectiveness of the 
146
+   “from scratch” method
147
+
148
+![Production time chart in minutes.](../img/e001_01.jpg)
149
+
150
+One of the biggest myths about “from scratch publishing”
151
+is that it requires a lot of time. But “from scratch” 
152
+doesn't mean we have to code it all by hand. As we will 
153
+see in other entries, with [scripts](https://en.wikipedia.org/wiki/Scripting_language) 
154
+we can grasp all monotonous work implied in +++EPUB+++ 
155
+development.
156
+
157
+With “from scratch publishing” I mean a method were we 
158
+don't have a publishing enviroment. Instead of that we use
159
+a [plain text editor](https://en.wikipedia.org/wiki/Text_editor)
160
+or a [source code editor](https://en.wikipedia.org/wiki/Source_code_editor)
161
+and a [command-line interface](https://en.wikipedia.org/wiki/Command-line_interface).
162
+
163
+This method could sound very complex and time consuming.
164
+While “from scratch publishing” has it owns challenges, 
165
+anyone with a computer can overcome these difficulties.
166
+
167
+If we ignore the time needed to format text, in the
168
+following chart we can see that __“from scratch” method is
169
+the most efective__.
170
+
171
+With InDesign and Jutoh we have to link each +++CSS+++ style
172
+to a paragraph or character style. InDesign is way more 
173
+intuitive than Jutoh. With Sigil or “from scratch 
174
+publishing” we don't have this need, because we can 
175
+automatically link the +++CSS+++ with the book. But “from
176
+scratch” method has the advantage that we don't have to
177
+recreate the directory tree or import files.
178
+
179
+## +++EPUB+++'s size chart: the impact of images and “junk”
180
+   code
181
+
182
+![+++EPUB+++'s size chart in +++KB+++s.](../img/e001_02.jpg)
183
+
184
+There are two factors that impact +++EPUB+++'s 
185
+size: __1)__ embedded images and __2)__ “junk” code.
186
+
187
+Most +++EPUB+++s embed at least one image, the cover, and
188
+sometimes also a back cover and an author's photo. It 
189
+doesn't matter if there are just a couple elements, images 
190
+are __the most heavy files in an +++EPUB+++__ if we have 
191
+one or more of these setups:
192
+
193
+* The book is short.
194
+* The images are bigger than our needs.
195
+* The images lack of good compression.
196
+* The images are in an inconvenient format.
197
+
198
+Neither of this conditions affect our exercise because we
199
+are using the same 204 +++KB+++ image.
200
+
201
+__The difference comes from “junk” code__. Some converters
202
+add extra code lines. Most of the times it is because it
203
+inject its credits. We also get extra code if we work with 
204
+paragraph or character styles instead of +++CSS+++ styles.
205
+
206
+> These extra code lines don't improve the reading
207
+> experience of our +++EPUB+++, that is why we called them
208
+> “junk” code. {.addenda}
209
+
210
+When we allow converters to create the +++CSS+++, they 
211
+will use their own name conventions that generates __two
212
+downsides__:
213
+
214
+1. Needless increase of file's size.
215
+2. +++CSS+++ name convention that could make it hard to 
216
+   understand or edit.
217
+
218
+InDesing and Jutoh's +++EPUB+++ are bigger because of “junk” 
219
+code. Nevertheless, the size difference between Sigil and 
220
+“from scratch publishing” involes the ebook's structure.
221
+
222
+From +++EPUB+++3 we have two files for the table of 
223
+contents (+++TOC+++). +++NCX+++ is the legacy file while the 
224
+new file follows an [+++XHTML+++](https://en.wikipedia.org/wiki/XHTML)
225
+structure.
226
+
227
+Because of that, __the +++EPUB+++ developed with “from
228
+scratch publishing” has two +++TOC+++s__. This adds 11 
229
+between Sigil and “from scratch publishing” books.
230
+
231
+> This means that by default Sigil doesn't create the new
232
+> required +++TOC+++ format. That could affect the reading
233
+> experience in newer devices. {.addenda}
234
+
235
+## Errors and warnings chart: +++EPUB+++ validation
236
+
237
+![Erros and warnings chart.](../img/e001_03.jpg)
238
+
239
+One of the main advantages of not developing an +++EPUB+++ 
240
+with “from scratch” method is that we don't have to know
241
+also count with a graphical interface that implies a short 
242
+learning curve.
243
+
244
+However, __ebooks not only requiere good text edition and
245
+design quality, they also need coherent structures__,
246
+i.e. we have to care about technical issues. +++EPUB+++s
247
+must not have errors or warnings because of bad quality 
248
+image issues.
249
+
250
+For this reasons we need __+++EPUB+++ validators__. The 
251
+official tool for +++EPUB+++ validation is EpubCheck. You 
252
+can use it [online](http://validator.idpf.org/) or 
253
+[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 know 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, 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 isn't true. As we could see in this exercise:
290
+__Sigil and “from scratch publishing” had better results__.
291
+
292
+However, 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 fulfill 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 a 24 hours workshop anybody can 
309
+develop their first ebook “from scratch.” Usually most 
310
+learners don't have a technical background such as 
311
+knowing +++HTML+++, +++CSS+++ or command line tools.
312
+
313
+If you are gong to use software exclusively for ebooks, the
314
+recommendation is that it has to be free or open source
315
+software. With this you can avoid the cost increments at
316
+the same time that you can get free help from their
317
+communities.
318
+
319
+You can download the [graphics](http://git.cliteratu.re/publishing-is-coding/blob/master/src/entry001/graphics.ods)
320
+and the [data](http://git.cliteratu.re/publishing-is-coding/raw/master/src/entry001/data.txt) :)
0 321
deleted file mode 100644
... ...
@@ -1,41 +0,0 @@
1
-# Cyclical and branched publishing:
2
-  from the anteroom to the digital «revolution»
3
-
4
-@meta['2018-10-19','Methodology','EMPTY.','https://marianaeguaras.com/edicion-ciclica-y-edicion-ramificada-de-la-antesala-a-la-revolucion-digital']
5
-
6
-Print publishing has never been easy. Since scribes
7
-until printing it has been necessary to acomplish
8
-several steps. Generally, there are:
9
-
10
-1. Edit and proofread.
11
-2. Graphic and layout design.
12
-3. Compare and review.
13
-4. Print.
14
-5. Distribute.
15
-6. Market and business management.
16
-
17
-Before the digital «revolution» each step used to
18
-set the rhythm in publishing. It was almost sure that
19
-quality would decrease or an step would have to be
20
-repeated if something went wrong. __The tasks in
21
-traditional publishing had to go step by step and
22
-trying to return as little as possible__.
23
-
24
-This rhythm was also constrained to the existent
25
-infrastructure, resources and demand. The rhythm
26
-was consistent and «slow» before printing. After that
27
-publishing processes got faster, costs went down and
28
-demand went up.
29
-
30
-Books stopped to being luxury goods and began to be
31
-a common well. We could say that printing wasn't only
32
-a «revolution» but also an «opening» of information.
33
-
34
-This revolution created new crafts that specialized
35
-among centuries. Techniques changed and improved over
36
-time but until the middle of +++XX+++ century the
37
-method was the same: __Publishing was an unilateral
38
-progression until book's marketing__.
39
-
40
-## In the digital «revolution»
41
-
42 1
new file mode 100644
... ...
@@ -0,0 +1,41 @@
0
+# Cyclical and branched publishing:
1
+  from the anteroom to the digital «revolution»
2
+
3
+@meta['2018-10-19','Methodology','EMPTY.','https://marianaeguaras.com/edicion-ciclica-y-edicion-ramificada-de-la-antesala-a-la-revolucion-digital']
4
+
5
+Print publishing has never been easy. Since scribes
6
+until printing it has been necessary to acomplish
7
+several steps. Generally, there are:
8
+
9
+1. Edit and proofread.
10
+2. Graphic and layout design.
11
+3. Compare and review.
12
+4. Print.
13
+5. Distribute.
14
+6. Market and business management.
15
+
16
+Before the digital «revolution» each step used to
17
+set the rhythm in publishing. It was almost sure that
18
+quality would decrease or an step would have to be
19
+repeated if something went wrong. __The tasks in
20
+traditional publishing had to go step by step and
21
+trying to return as little as possible__.
22
+
23
+This rhythm was also constrained to the existent
24
+infrastructure, resources and demand. The rhythm
25
+was consistent and «slow» before printing. After that
26
+publishing processes got faster, costs went down and
27
+demand went up.
28
+
29
+Books stopped to being luxury goods and began to be
30
+a common well. We could say that printing wasn't only
31
+a «revolution» but also an «opening» of information.
32
+
33
+This revolution created new crafts that specialized
34
+among centuries. Techniques changed and improved over
35
+time but until the middle of +++XX+++ century the
36
+method was the same: __Publishing was an unilateral
37
+progression until book's marketing__.
38
+
39
+## In the digital «revolution»
40
+