Source Browser ?

1% language=us
2
3\startcomponent onandon-media
4
5\environment onandon-environment
6
7\startchapter[title={The state of \PDF}]
8
9\startsection[title={Introduction}]
10
11Below I will spend some words on the state of \PDF\ in \CONTEXT\ mid 2018. These
12are just some reflections, not an in|-|depth discussion of the state of affairs. I
13sometimes feel the need to wrap up.
14
15\stopsection
16
17\startsection[title={Media}]
18
19For over two decades \CONTEXT\ has supported fancy \PDF\ features like movies and
20sound. In fact, as happens more, the flexibility of \TEX\ made it possible to
21support such features right after they became available, often even before other
22applications supported them.
23
24The first approach to support such media clips was relatively easy. In \PDF\ one
25has the text flow, resulting from the typesetting process, either or not enhanced
26with images that are referred to from the flow. In that respect images are an
27integral part of \PDF. On a separate layer there can be annotations. There are
28many kinds and they are originally a sort of extension mechanism that permits
29plugins to add features to a document. Examples of this are hyperlinks and the
30already mentioned media clips. Video was supported by the quicktime movie plugin.
31As far as I know in the meantime that plugin has been dropped as official part of
32Acrobat but one can still plug it in.
33
34Later an extra mechanism was introduced, tagged renditions. It separates the
35views from the media and was more complex. When I first played with it, quite
36some media were possible, and I made a demo that could handle mov, mp3, smi and
37swf files. But last time I checked none of these really worked, apart from the
38swf file. One gets pop|-|ups for missing viewers and a look at the reader
39preferences makes one pessimistic about future support anyway. But one should be
40able to set up a list of useable players with this mechanism (although only an
41Adobe one seems to be okay so we're back to where we started).
42
43At some point support for u3d was added. Interesting is that there is quite some
44infrastructure described in the \PDF\ standard. Also something called rich media
45was introduced and that should replace the former video and audio annotations
46(definitely in \PDF\ version 2) and probably some day the renditions will no
47longer be supported either. Open source \PDF\ viewers just stuck to supporting
48text and static images.
49
50Now, do these rich media work well? Hardly. The standard leaves it to the viewer
51and provides ways to define viewers (although it's unclear to me how that works
52out in practice.) Basically in \PDF\ version 2 there is no native support for
53simple straightforward video. One has to construct a complex set of related
54annotations.
55
56One can give arguments (like security risks) for not supporting all these fancy
57features but then why make rich media part of the specification at all? Browsers
58beat \PDF\ viewers in showing media and as browsers can operate in kiosk mode I
59suppose that it's not that hard to delegate showing whatever you want in an
60embedded window in the \PDF\ viewer. Or why not simply support videolan out of
61the box. All we need is the ability to view movies and control them (play, pause,
62stop, rewind, etc). Where \HTML\ evolved towards easier media support, \PDF\
63evolved to more obscurity.
64
65So, how bad is it really? There are \PDF\ files around that have video! Indeed,
66but the way they're supposed to do this is as follows: currently one actually has
67to embed a shockwave video player (a user interface around something built|-|in)
68and let that player show for instance an mp4 movie. However, support for
69shockwave (flash) will be dropped in 2020 and that renders documents that use it
70obsolete. This even makes one wonder about \JAVASCRIPT\ and widgets like form
71fields, also a rather moving and somewhat unstable target. (I must have a
72document being a calculator somewhere made in the previous century, in the early
73days of \PDF.)
74
75I think that the plugin model failed already rather early in the \PDF\ history if
76only because it made no sense to develop them when in a next version of Acrobat
77the functionality was copied in the core. In a similar fashion \JAVASCRIPT\
78support seems to have stalled.
79
80Unfortunately the open source viewers never catched on with media, forms and
81\JAVASCRIPT\ and therefore there has been no momentum created to keep things
82supported. It all makes efforts spent on supporting this kind of \PDF\ features a
83waste of time. It also makes one careful in using them: it only works on the
84short term.
85
86Get me right, I'm not talking of complex media like 3d or animations but of
87straightforward video support. I understand that the rich media framework tries
88to cover complex cases but it's simple cases that carry the format. On the other
89hand, one can wonder why the \PDF\ format makes it possible to specify behaviour
90that in practice depends on \JAVASCRIPT\ and therefore could as well have been
91delegated to \JAVASCRIPT\ as well. It would probably have been much cleaner.
92\footnote {It looks like mu\PDF\ in 2018 got some support related to widgets aka
93fields but alas not for layers which would be quite useful.}
94
95The \PDF\ version 2 specification mentions \type {3D}, \type {Video} and \type
96{Audio} as primary content types so maybe future viewers will support video out
97of the box. Who knows. We try to keep up in \CONTEXT\ because it's often not that
98complex to support \PDF\ features but with hardly any possibility to test them,
99they have a low priority. And with Acrobat moving to the cloud and thereby
100creating a more of less lifelong dependency on remote resources it doesn't become
101much interesting to explore those routes either.
102
103\stopsection
104
105\startsection[title={Accessibility}]
106
107A popular \PDF\ related topic is accessibility. One aspect of that is tagged
108\PDF. This substandard is in my opinion not something that deserves a price for
109beauty. I know that there are \CONTEXT\ users who need to be compliant but I
110always wonder what a publisher really does with such a file. It's a bit like
111requiring \XML\ as source but at the same time sacrificing really rich encoded
112and sources for tweaks that suite the current limitations of for instance browsers,
113tool|-|chains and competence. We've seen it happen.
114
115Support for tagged \PDF\ has been available in \CONTEXT\ already for a while but
116as far as I know only Acrobat professional can do something with it. The reason
117for tagging is that a document is then useable for (for instance) visually
118impaired users, but aren't they better served with a proper complete and very
119structured source in some format that tools suitable for it can use? How many
120publishers distribute \PDF\ files while they can still make money on prints? How
121many are really interested in distributing enriched content that then can be
122reused somehow? And how many are willing to invest in tools instead of waiting
123for it to happen for free? It's a bit cheap trick to just expect authors (and
124their in the case of \TEX\ free tools) to suit a publishers needs. Anyway, just
125as with advanced interactive documents or forms, I wonder if it will catch on. At
126least no publisher ever asked us and by the time they might do the competition of
127web based dissemination could have driven \PDF\ to the background. But, in
128\CONTEXT\ we will keep supporting such features anyway, if only because it's
129quite doable. But \unknown\ it's user demand that drives development, not the
130market, which means that the motivation for implementing such features depends on
131user input as well as challenging aspects that make it somewhat fun to spend time
132on them.
133
134\stopsection
135
136\startsection[title={Quality assurance}]
137
138Another aspect popping up occasionally is validation. I'm not entirely sure what
139drives that but delegating a problem can be one reason. Often we see publishers
140and printers use old versions of \PDF\ related tools. Also, some workflows are
141kind of ancient anyway and are more driven by \POSTSCRIPT\ history than \PDF\
142possibilities. I sometimes get the impression that it takes at least a decade for
143these things to catch on, and by that time it doesn't matter any more that \TEX\
144and friends were at the front: their users are harassed by what the market
145demands by then.
146
147Support for several standards related to validation is already part of \CONTEXT\
148for quite a while. For instance the bump from \PDF\ 1.7 to 2.0 was hardly worth
149noticing, simply because there are not that many fundamental changes. Adapting
150\LUATEX\ was trivial (and actually not really needed), and macro packages can
151provide what is needed without much problems. So, yes, we can support it without
152much hassle. Personally I never ran into a case where validation was really
153needed. The danger of validation is that it can give a false impression of
154quality. And as with everything quality control created a market. As with other
155features it is users who drive the availability of support for this. After all,
156they are the ones testing it and figuring out the often fuzzy specifications.
157These are things that one can always look at in retrospect (like: it has to be
158done this or that way) while in practice in order to be an early adopter one has
159to gamble a bit and see where it fails or succeeds. Fortunately it's relatively
160easy to adapt macro packages and \CONTEXT\ users are willing to update so it's
161not really an issue.
162
163Putting a stamp of approval on a \PDF\ cannot hide the inconsistencies between
164for instance vector graphics produced by a third party. They also don't expose
165inconsistent use of color and fonts. The page streams produced by \LUATEX\ are
166simple and clean enough to not give problems with validation. The problem lays
167more with resources coming from elsewhere. When you're phoned by a printing house
168about an issue with \RGB\ images in a file where there is no sign of \RGB\ being
169used but where a validator reports an issue, you're lucky when an experienced
170printer dating back decades then replies that he already had that impression and
171will contact the origin. There is no easy way out of this but educating users
172(authors) is an option. However, they are often dependent on the publishers and
173departments that deal with these and those tend to come with directives that the
174authors cannot really argue with (or about).
175
176\stopsection
177
178\startsection[title={Interactivity}]
179
180This is an area where \TEX\ (an therefore also \CONTEXT) always had an edge,
181There is a lot possible and in principle all that \PDF\ provides can be
182supported. But the more fancy one goes, the more one depends on Acrobat.
183Interactivity in \PDF\ evolved stepwise and is mostly market driven. As a result
184it is (or was) not always consistent. This is partly due to the fact that we have
185a chicken|-|egg issue: you need typesetting machinery, viewer as well as a
186standard.
187
188The regular hyperlinks, page or named driven are normally supported by viewers.
189Some redefined named destinations (like going to a next page, or going back in a
190chain of followed links) not always. Launching applications, as it also relates
191to security, can be qualified as an unreliable mechanism. More advanced linking,
192for instance using \JAVASCRIPT\ is hardly supported. In that respect \PDF\
193viewers lag way behind \HTML\ browsers. I understand that there can be security
194risks involved. It's interesting to see that in Acrobat one can mess with
195internals of files which makes the \API\ large and complex, but if we stick to
196the useful core, the amount of interfacing needed is quite small. Lack of support
197in open source viewers (we're talking of about two decades now) made me loose
198interest in these features but they are and will be supported in \CONTEXT. We'll
199see if and when viewers catch up.
200
201Comments and attachments are also part of interactivity and of course we
202supported them right from the start. Some free viewers also support them by now.
203Personally I never use comments but they can be handy for popping up information
204or embedding snippets or (structured) sources (like \MATHML\ or bibliographic
205data). In \CONTEXT\ we can even support \PDF\ inclusion with (a reasonable)
206subset of these so called annotations. As the \PDF\ standard no longer evolves
207much we can expect all these features to become stable.
208
209\stopsection
210
211\startsection[title={Summary}]
212
213We have always supported the fancy \PDF\ features and we will continue doing so
214in \CONTEXT . However, many of them depends on what viewers support, and after
215decades of \PDF\ that is still kind of disappointing, which is not that
216motivating. We'll see what happens.
217
218\stopsection
219
220\stopchapter
221