perro
/
perrotuerto.blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed typos

This commit is contained in:
NikaZhenya 2018-10-12 15:49:55 -05:00
parent 94af5557d1
commit a76c06a6ce
4 changed files with 55 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
ebooks/entry001.epub
View File

Binary file not shown.

BIN
ebooks/entry001.mobi
View File

Binary file not shown.

2
html/entry001.html
View File

File diff suppressed because one or more lines are too long

108
md/entry001.md
View File

@ -65,54 +65,54 @@ doing things this way:
1. The code, design and text edition's qualities tend to be
lower in comparison of others methods.
2. It forgots that the most important thing about the
digital revolution it is not the ebook.
2. It is often forgotten that the most important thing about
the digital revolution it is not the ebook.
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 __behind the scenes
of ebook's development__.
deeper we will have to familiarize with __the behind the
scenes of ebook's development__.
> 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
> In spanish I insist that digital publishing isn't the same
> as digital editing. In spanish it is common to use the
> word “edition” and derivatives for things concerning
> publishing. But as far as I can see, “edition“ has
> a more general meaning in english spoken world. {.addenda}
> With “digital editing” I mean _the process_ for publishing
> With “digital editing” I mean _the process_ of publishing
> that involves the use of a computer (practically
> all publishing industry nowadays). “Digital publishing”
> is _the product_ 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
> will use the terms interchangeably. Only when I see it
> relevant I will say “digital editing” or “digital text
> editing.” {.addenda}
Some people are skeptical about the need of publishing “from
scratch.” Most people prefer to use conversors to
scratch.” Most people prefer to use converters to
automatically create +++EPUB+++ files.
Why we have to learn markup languages such as [+++HTML+++](https://en.wikipedia.org/wiki/HTML)
Why do we have to learn markup languages such as [+++HTML+++](https://en.wikipedia.org/wiki/HTML)
or [Markdown](https://en.wikipedia.org/wiki/Markdown)? Why
we should worry about styles sheets like [+++CSS+++](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)
should we worry about styles sheets like [+++CSS+++](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)
or [+++SCSS+++](https://en.wikipedia.org/wiki/Sass_(stylesheet_language))?
Why we must think about programming languages ([JavaScript](https://en.wikipedia.org/wiki/JavaScript),
Why must we think about programming languages ([JavaScript](https://en.wikipedia.org/wiki/JavaScript),
[Python](https://en.wikipedia.org/wiki/Python_(programming_language)), [Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language))
or [C++](https://en.wikipedia.org/wiki/C%2B%2B), e.g.) and
how it could create new reading experiencies or improve the
quality of text edition?
Regardless you want a print or digital book, if we start to
put attention in methodologies, litle by litle we will see
its importance.
Regardless wether you want a print or digital book, if we
start to pay attention in methodologies, litle by litle we
will see its importance.
## Exercise's peculiarities
To show the advantages and disadvantages of conversors
To show the advantages and disadvantages of converters
compared to “from scratch publishing,” we will develop the
same book but with each method.
We are gonna do this exercise as real as possible. That is
why we are gonna use [Gutenberg Project's spanish edition of
We are gonna do this exercise as realistically as possible.
That is why we are gonna use [Gutenberg Project's spanish edition of
_Don Quixote_](http://www.gutenberg.org/ebooks/2000). For
uniformity our standing points are the text in +++HTML+++
format and the same +++CSS+++ style sheet.
@ -126,13 +126,13 @@ You could wonder:
* __Why will we use an already formated text and not the
direct source?__ I found some typos and similar issues;
plus, formating text could be a nigthmare which I
prefer to discuss it other time.
prefer to discuss another time.
* __Why will we use the same style sheet instead of
redesign the book in each method?__ 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.
another entry.
* __Which methods will we apply in this exercise?__ We will
see [InDesign's](https://www.adobe.com/products/indesign.html)
way of doing things because it is the most common among
@ -143,14 +143,14 @@ You could wonder:
show how “from scratch publishing” could be a good
candidate for digital publishing.
## Production time chart: the efectiveness of “from scratch”
method
## Production time chart: the efectiveness of the
“from scratch” method
![Production time chart in minutes.](../img/e001_01.jpg)
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
doesn't mean we have to code it all by hand. As we will
see in other entries, with [scripts](https://en.wikipedia.org/wiki/Scripting_language)
we can grasp all monotonous work implied in +++EPUB+++
development.
@ -183,13 +183,13 @@ recreate the directory tree or import files.
![+++EPUB+++'s size chart in +++KB+++s.](../img/e001_02.jpg)
There are two factors that impact +++EPUB+++'s
size: __1)__ embedded images __2)__ “junk” code.
size: __1)__ embedded images and __2)__ “junk” code.
Most +++EPUB+++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
__the most heavy files in an +++EPUB+++__ if we have one
or more of these setups:
sometimes also a back cover and an author's photo. It
doesn't matter if there are just a couple elements, images
are __the most heavy files in an +++EPUB+++__ if we have
one or more of these setups:
* The book is short.
* The images are bigger than our needs.
@ -199,21 +199,21 @@ or more of these setups:
Neither of this conditions affect our exercise because we
are using the same 204 +++KB+++ image.
__The difference comes from “junk” code__. Some conversors
__The difference comes from “junk” code__. Some converters
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 +++CSS+++ styles.
> These extra code lines doesn't improve the reading
> These extra code lines don't improve the reading
> experience of our +++EPUB+++, that is why we called them
> “junk” code. {.addenda}
When we allow conversors to create the +++CSS+++, they
When we allow converters to create the +++CSS+++, they
will use their own name conventions that generates __two
downsides__:
1. Needless increase of file's size.
2. +++CSS+++ name convention that could made hard to
2. +++CSS+++ name convention that could make it hard to
understand or edit.
InDesing and Jutoh's +++EPUB+++ are bigger because of “junk”
@ -232,7 +232,7 @@ between Sigil and “from scratch publishing” books.
> This means that by default Sigil doesn't create the new
> required +++TOC+++ format. That could affect the reading
> experience in newest devices. {.addenda}
> experience in newer devices. {.addenda}
## Errors and warnings chart: +++EPUB+++ validation
@ -241,15 +241,15 @@ between Sigil and “from scratch publishing” books.
One of the main advantages of not developing an +++EPUB+++
with “from scratch” method is that we don't have to know
+++HTML+++, +++CSS+++ and +++EPUB+++ structures. Usually we
also count with a graphic interface that implies a short
also count with a graphical interface that implies a short
learning curve.
However, __ebooks not only requieres good text edition and
design qualities, they also need coherent structures__,
i.e. we have to care about the technical issues. +++EPUB+++s
must not have errors or warnings because bad quality
However, __ebooks not only requiere good text edition and
design quality, they also need coherent structures__,
i.e. we have to care about technical issues. +++EPUB+++s
must not have errors or warnings because of bad quality
+++HTML+++ or +++CSS+++ code, insufficient metadata or
images issues.
image issues.
For this reasons we need __+++EPUB+++ validators__. The
official tool for +++EPUB+++ validation is EpubCheck. You
@ -265,7 +265,7 @@ EpubCheck didn't find any error or warning. We had a few
issues because we used the same +++HTML+++ and +++CSS+++
files. Besides, each method created metadata independently.
(For “from scratch publishing” we used [Pecas](https://pecas.cliteratu.re/),
a suite of publishing scripts).
a suite of publishing scripts.)
In InDesign the issue is because an incorrect image
compression. For Sigil and Jutoh, BlueGriffon considers they
@ -273,7 +273,7 @@ are using obsolete metadata elements.
Actually, __it isn't hard to solve these issues__.
Nevertheless, it could be very frustrating to solve them if
you don't now what is inside an +++EPUB+++ file. In order to
you don't know what is inside an +++EPUB+++ file. In order to
solve them we must decompress the +++EPUB+++, then we have
to modify the problematic files and, finally, compress the
files again.
@ -283,7 +283,7 @@ files again.
We dont need to buy software in order to develop
+++EPUB+++s.
However, the half of the methods seen here use propertary
However, 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
@ -291,17 +291,17 @@ software.
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:
enviroment this isn't true. As we could see in this exercise:
__Sigil and “from scratch publishing” had better results__.
Nevertheless, most publishers only use Adobe products, so in
However, most publishers only use Adobe products, so in
specific circumstances it is more convenient to develop
ebooks by this way.
If you really care about the quality of your +++EPUB+++s,
think twice before buying propertary software. The free and
open source software communities have great alternatives
that could fullfit your needs.
that could fulfill your needs.
## Conclusion: “from scratch publishing” wins the match
@ -310,15 +310,15 @@ publishing”__ had better results. Most readers could think
that this method requieres certain complex knowledge and a
long learning curve.
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 +++HTML+++,
+++CSS+++ or command line tools.
I can say that within a 24 hours workshop anybody can
develop their first ebook “from scratch.” Usually most
learners don't have a technical background such as
knowing +++HTML+++, +++CSS+++ or command line tools.
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
software. With this you can avoid the cost increments at
the same time that you can get free help from their
communities.
You can download the [graphics](http://git.cliteratu.re/publishing-is-coding/blob/master/src/entry001/graphics.ods)