Source Browser ?

1% \enablemode[print]
2
3\usemodule[present-overlap,abr-02]
4
5\startdocument
6  [title=e-books,
7   subtitle=old wine in new bottles,
8   location=\ConTeXt\ Meeting 2011]
9
10\Topic{Some observations}
11
12\StartSteps
13\startitemize
14\item Most ebooks are just books (or try to be). \FlushStep
15\item Only a small portion has (or needs) design. \FlushStep
16\item To what extent appreciation matters is hard to measure. \FlushStep
17\item Vendor locking is spoiling much. \FlushStep
18\item 10 years of low res screens have made readers tolerant. \FlushStep
19\item Publishers already lost the edge. \FlushStep
20\item Eventually authors will publish themselves. \FlushStep
21\stopitemize
22\StopSteps
23
24% Does quality matter (just look around you)
25% Does livetime matter (much tolerance for potentially crappy old stuff anyway)
26% Does timebound look and feel matter (it helps to put into perspective)
27
28\Topic{What is an ebook}
29
30\StartSteps
31\startitemize
32\item Nicest is it being a \PDF\ (some design). \FlushStep
33\item Easiest is it being an \XHTML\ file (with some \CSS). \FlushStep
34\item Pointless it is being a frozen app. \FlushStep
35\item We can already provide a \PDF\ for paper and screen for quite a while. \FlushStep
36\item We can consider providing an \XHTML\ alongside as reflowable variant. \FlushStep
37\item Who knows what we can provide in the future. \FlushStep
38\stopitemize
39\StopSteps
40
41\Topic{The starting point}
42
43\StartSteps
44\startitemize
45\item No output is better than the input. \FlushStep
46\item Fixing bad coding is a waste of energy. \FlushStep
47\item Not that many publishers want to invest in coding. \FlushStep
48\item Not that many tools enforce structure. \FlushStep
49\item The real good devices still have to come but we can be ready for it. \FlushStep
50\item The intelligence has to be in the macro package, not in the engine. \FlushStep
51\stopitemize
52\StopSteps
53
54\Topic{Implementation}
55
56\StartSteps
57\startitemize
58\item Some users have to produce tagged pdf (to satisfy validators). \FlushStep
59\item It helps that many commands in \CONTEXT\ are built upon a relatively small generic set. \FlushStep
60\item So, given some basic structure, supporting tags is easy. \FlushStep
61\item It integrates in the core. \FlushStep
62\item And as a side effect an export was equally easy to support. \FlushStep
63\item The overhead is not that large (upto 10\%). \FlushStep
64\item Instead of going for freaky solutions (no need for challenges) we assume proper structure. \FlushStep
65\item It's not to hard to extend the current features. \FlushStep
66\stopitemize
67\StopSteps
68
69\Topic{Consequence for users}
70
71\StartSteps
72\startitemize
73\item Use \type{\startchapter} cum suis, but that was already the \MKIV\ fashion. \FlushStep
74\item Preferable use \type{\startitem} instead of \type {\item}. \FlushStep
75\item Playing safe means tagging paragraphs with \type {\startparagraph}. \FlushStep
76\item Use style environments instead of font switches. \FlushStep
77\item Just use whatever structural markup that \CONTEXT\ already provides for ages. \FlushStep
78\stopitemize
79\StopSteps
80
81\Topic{An example}
82
83\StartSteps
84\startitemize
85\item A normal input with \TEX\ commands (cld-mkiv.tex) \FlushStep
86\item Regular (tagged) output (cld-mkiv.pdf) \FlushStep
87\item Structured output (cld-mkiv.xml) \FlushStep
88\item Reflowable output (cld-mkiv-export.xhtml) \FlushStep
89\item Dynamic styling (cld-mkiv-export.css) \FlushStep
90\item Basic template (cld-mkiv-export.template) \FlushStep
91\stopitemize
92\StopSteps
93
94\stopdocument
95