diff options
Diffstat (limited to 'doc')
35 files changed, 1220 insertions, 359 deletions
diff --git a/doc/context/documents/general/manuals/luatex.pdf b/doc/context/documents/general/manuals/luatex.pdf Binary files differindex 032c5b1b6..545e55d68 100644 --- a/doc/context/documents/general/manuals/luatex.pdf +++ b/doc/context/documents/general/manuals/luatex.pdf diff --git a/doc/context/documents/general/manuals/onandon.pdf b/doc/context/documents/general/manuals/onandon.pdf Binary files differindex 3195b7ebd..add044367 100644 --- a/doc/context/documents/general/manuals/onandon.pdf +++ b/doc/context/documents/general/manuals/onandon.pdf diff --git a/doc/context/documents/general/manuals/tiptrick.pdf b/doc/context/documents/general/manuals/tiptrick.pdf Binary files differindex 55d65029a..ea55ab7d8 100644 --- a/doc/context/documents/general/manuals/tiptrick.pdf +++ b/doc/context/documents/general/manuals/tiptrick.pdf diff --git a/doc/context/documents/general/qrcs/setup-cs.pdf b/doc/context/documents/general/qrcs/setup-cs.pdf Binary files differindex 597e89e0c..329441f3c 100644 --- a/doc/context/documents/general/qrcs/setup-cs.pdf +++ b/doc/context/documents/general/qrcs/setup-cs.pdf diff --git a/doc/context/documents/general/qrcs/setup-de.pdf b/doc/context/documents/general/qrcs/setup-de.pdf Binary files differindex 4838c00e5..70c658b2b 100644 --- a/doc/context/documents/general/qrcs/setup-de.pdf +++ b/doc/context/documents/general/qrcs/setup-de.pdf diff --git a/doc/context/documents/general/qrcs/setup-en.pdf b/doc/context/documents/general/qrcs/setup-en.pdf Binary files differindex b467a753e..f2279cf49 100644 --- a/doc/context/documents/general/qrcs/setup-en.pdf +++ b/doc/context/documents/general/qrcs/setup-en.pdf diff --git a/doc/context/documents/general/qrcs/setup-fr.pdf b/doc/context/documents/general/qrcs/setup-fr.pdf Binary files differindex 2f550ac44..5a3e45afe 100644 --- a/doc/context/documents/general/qrcs/setup-fr.pdf +++ b/doc/context/documents/general/qrcs/setup-fr.pdf diff --git a/doc/context/documents/general/qrcs/setup-it.pdf b/doc/context/documents/general/qrcs/setup-it.pdf Binary files differindex 4e39b5e08..b03853499 100644 --- a/doc/context/documents/general/qrcs/setup-it.pdf +++ b/doc/context/documents/general/qrcs/setup-it.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-cs.pdf b/doc/context/documents/general/qrcs/setup-mapping-cs.pdf Binary files differindex faf79f9b7..ec2d100e3 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-cs.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-cs.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-de.pdf b/doc/context/documents/general/qrcs/setup-mapping-de.pdf Binary files differindex 7037db2c0..a94f73894 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-de.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-de.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-en.pdf b/doc/context/documents/general/qrcs/setup-mapping-en.pdf Binary files differindex 5f495892a..f44fe7c4a 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-en.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-en.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-fr.pdf b/doc/context/documents/general/qrcs/setup-mapping-fr.pdf Binary files differindex c92fdf0d9..71ee87097 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-fr.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-fr.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-it.pdf b/doc/context/documents/general/qrcs/setup-mapping-it.pdf Binary files differindex ad7c68621..f37ab1589 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-it.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-it.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-nl.pdf b/doc/context/documents/general/qrcs/setup-mapping-nl.pdf Binary files differindex d09218df0..dab7f627a 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-nl.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-nl.pdf diff --git a/doc/context/documents/general/qrcs/setup-mapping-ro.pdf b/doc/context/documents/general/qrcs/setup-mapping-ro.pdf Binary files differindex 3312cbd36..3021a6ac5 100644 --- a/doc/context/documents/general/qrcs/setup-mapping-ro.pdf +++ b/doc/context/documents/general/qrcs/setup-mapping-ro.pdf diff --git a/doc/context/documents/general/qrcs/setup-nl.pdf b/doc/context/documents/general/qrcs/setup-nl.pdf Binary files differindex 20965c2b7..b6d12170c 100644 --- a/doc/context/documents/general/qrcs/setup-nl.pdf +++ b/doc/context/documents/general/qrcs/setup-nl.pdf diff --git a/doc/context/documents/general/qrcs/setup-ro.pdf b/doc/context/documents/general/qrcs/setup-ro.pdf Binary files differindex 729ff45d1..09040ae71 100644 --- a/doc/context/documents/general/qrcs/setup-ro.pdf +++ b/doc/context/documents/general/qrcs/setup-ro.pdf diff --git a/doc/context/sources/general/manuals/luatex/luatex-lua.tex b/doc/context/sources/general/manuals/luatex/luatex-lua.tex index e9007e964..0f7cae3a3 100644 --- a/doc/context/sources/general/manuals/luatex/luatex-lua.tex +++ b/doc/context/sources/general/manuals/luatex/luatex-lua.tex @@ -673,6 +673,8 @@ accept a string and return a string with the hash. \startsubsection[title={Locales}] +\index {locales} + In stock \LUA, many things depend on the current locale. In \LUATEX, we can't do that, because it makes documents unportable. While \LUATEX\ is running if forces the following locale settings: diff --git a/doc/context/sources/general/manuals/onandon/onandon-53.tex b/doc/context/sources/general/manuals/onandon/onandon-53.tex new file mode 100644 index 000000000..0d5dc1b9c --- /dev/null +++ b/doc/context/sources/general/manuals/onandon/onandon-53.tex @@ -0,0 +1,288 @@ +% language=uk + +\startcomponent onandon-53 + +\environment onandon-environment + +\startchapter[title={From \LUA\ 5.2 to 5.3}] + +When we started with \LUATEX\ we used \LUA\ 5.1 and moved to 5.2 when that became +available. We didn't run into issues then because there were no fundamental +changes that could not be dealt with. However, when \LUA\ 5.3 was announced in +2015 we were not sure if we should make the move. The main reason was that we'd +chosen \LUA\ because of its clean design which meant that we had only one number +type: double. In 5.3 on the other hand, deep down a number can be either an +integer or a floating point quantity. + +Internally \TEX\ is mostly (up to) 32-bit integers and when we go from \LUA\ to +\TEX\ we round numbers. Nonetheless one can expect some benefits in using +integers. Performance|-|wise we didn't expect much, and memory consumption would +be the same too. So, the main question then was: can we get the same output and +not run into trouble due to possible differences in serializing numbers; after +all \TEX\ is about stability. The serialization aspect is for instance important +when we compare quantities and|/|or use numbers in hashes. + +Apart from this change in number model, which comes with a few extra helpers, +another extension in 5.3 was that bit|-|wise operations are now part of the +language. The lpeg library is still not part of stock \LUA. There is some minimal +\UTF8 support, but less than we provide in \LUATEX\ already. So, looking at these +changes, we were not in a hurry to update. Also, it made sense to wait till this +important number|-|related change was stable. + +But, a few years later, we still had it on our agenda to test, and after the +\CONTEXT\ 2017 meeting we decided to give it a try; here are some observations. A +quick test was just dropping in the new \LUA\ code and seeing if we could make a +\CONTEXT\ format. Indeed that was no big deal but a test run failed because at +some point a (for instance) \type {1} became a \type {1.0}. It turned out that +serializing has some side effects. And with some ad hoc prints for tracing (in +the \LUATEX\ source) I could figure out what went on. How numbers are seen can +(to some extent) be deduced from the \type {string.format} function, which is in +\LUA\ a combination of parsing, splitting and concatenation combined with piping +to the \CCODE\ \type {sprintf} function. \footnote {Actually, at some point I +decided to write my own formatter on top of \type {format} and I ended up with +splitting as well. It's only now that I realize why this is working out so well +(in terms of performance): simple format (single items) are passed more or less +directly to \type {sprintf} and as \LUA\ itself is fast, due to some caching, the +overhead is small compared to the built|-|in splitter method. And the \CONTEXT\ +formatter has many more options and is extensible.} + +\starttyping +local a = 2 * (1/2) print(string.format("%s", a),math.type(x)) +local b = 2 * (1/2) print(string.format("%d", b),math.type(x)) +local c = 2 print(string.format("%d", c),math.type(x)) +local d = -2 print(string.format("%d", d),math.type(x)) +local e = 2 * (1/2) print(string.format("%i", e),math.type(x)) +local f = 2.1 print(string.format("%.0f",f),math.type(x)) +local g = 2.0 print(string.format("%.0f",g),math.type(x)) +local h = 2.1 print(string.format("%G", h),math.type(x)) +local i = 2.0 print(string.format("%G", i),math.type(x)) +local j = 2 print(string.format("%.0f",j),math.type(x)) +local k = -2 print(string.format("%.0f",k),math.type(x)) +\stoptyping + +This gives the following results: + +\starttabulate[|cBT|c|T|c|cT|] +\BC a \NC 2 * (1/2)\NC s \NC 1.0 \NC float \NC \NR +\BC b \NC 2 * (1/2)\NC d \NC 1 \NC float \NC \NR +\BC c \NC 2 \NC d \NC 2 \NC integer \NC \NR +\BC d \NC -2 \NC d \NC 2 \NC integer \NC \NR +\BC e \NC 2 * (1/2)\NC i \NC 1 \NC float \NC \NR +\BC f \NC 2.1 \NC .0f \NC 2 \NC float \NC \NR +\BC g \NC 2.0 \NC .0f \NC 2 \NC float \NC \NR +\BC h \NC 2.1 \NC G \NC 2.1 \NC float \NC \NR +\BC i \NC 2.0 \NC G \NC 2 \NC float \NC \NR +\BC j \NC 2 \NC .0f \NC 2 \NC integer \NC \NR +\BC k \NC -2 \NC .0f \NC 2 \NC integer \NC \NR +\stoptabulate + +This demonstrates that we have to be careful when we need these numbers +represented as strings. In \CONTEXT\ the number of places where we had to check +for that was not that large; in fact, only some hashing related to font sizes had +to be done using explicit rounding. + +Another surprising side effect is the following. Instead of: + +\starttyping +local n = 2^6 +\stoptyping + +we now need to use: + +\starttyping +local n = 0x40 +\stoptyping + +or just: + +\starttyping +local n = 64 +\stoptyping + +because we don't want this to be serialized to \type {64.0} which is due to the +fact that a power results in a float. One can wonder if this makes sense when we +apply it to an integer. + +At any rate, once we could process a file, two documents were chosen for a +performance test. Some experiments with loops and casts had demonstrated that we +could expect a small performance hit and indeed, this was the case. Processing +the \LUATEX\ manual takes 10.7 seconds with 5.2 on my 5-year-old laptop and 11.6 +seconds with 5.3. If we consider that \CONTEXT\ spends 50\% of its time in \LUA, +then we see a 20\% performance penalty. Processing the \METAFUN\ manual (which +has lots of \METAPOST\ images) went from less than 20 seconds (\LUAJITTEX\ does +it in 16 seconds) up to more than 27 seconds. So there we lose more than 50\% on +the \LUA\ end. When we observed these kinds of differences, Luigi and I +immediately got into debugging mode, partly out of curiosity, but also because +consistent performance is important to~us. + +Because these numbers made no sense, we traced different sub-mechanisms and +eventually it became clear that the reason for the speed penalty was that the +core \typ {string.format} function was behaving quite badly in the \type {mingw} +cross-compiled binary, as seen by this test: + +\starttyping +local t = os.clock() +for i=1,1000*1000 do + -- local a = string.format("%.3f",1.23) + -- local b = string.format("%i",123) + local c = string.format("%s",123) +end +print(os.clock()-t) +\stoptyping + +\starttabulate[|c|c|c|c|c|] +\BC \BC lua 5.3 \BC lua 5.2 \BC texlua 5.3 \BC texlua 5.2 \BC \NR +\BC a \NC 0.43 \NC 0.54 \NC 3.71 (0.47) \NC 0.53 \NC \NR +\BC b \NC 0.18 \NC 0.24 \NC 3.78 (0.17) \NC 0.22 \NC \NR +\BC c \NC 0.26 \NC 0.68 \NC 3.67 (0.29) \NC 0.66 \NC \NR +\stoptabulate + +The 5.2 binaries perform the same but the 5.3 Lua binary greatly outperforms +\LUATEX, and so we had to figure out why. After all, all this integer +optimization could bring some gain! It took us a while to figure this out. The +numbers in parentheses are the results after fixing this. + +Because font internals are specified in integers one would expect a gain +in running: + +\starttyping +mtxrun --script font --reload force +\stoptyping + +and indeed that is the case. On my machine a scan results in 2561 registered +fonts from 4906 read files and with 5.2 that takes 9.1 seconds while 5.3 needs a +bit less: 8.6 seconds (with the bad format performance) and even less once that +was fixed. For a test: + +\starttyping +\setupbodyfont[modern] \tf \bf \it \bs +\setupbodyfont[pagella] \tf \bf \it \bs +\setupbodyfont[dejavu] \tf \bf \it \bs +\setupbodyfont[termes] \tf \bf \it \bs +\setupbodyfont[cambria] \tf \bf \it \bs +\starttext \stoptext +\stoptyping + +This code needs 30\% more runtime so the question is: how often do we call \type +{string.format} there? A first run (when we wipe the font cache) needs some +715,000 calls while successive runs need 115,000 calls so that slow down +definitely comes from the bad handling of \type {string.format}. When we drop in +a \LUA\ update or whatever other dependency we don't want this kind of impact. In +fact, when one uses external libraries that are or can be compiled under the +\TEX\ Live infrastructure and the impact would be such, it's bad advertising, +especially when one considers the occasional complaint about \LUATEX\ being +slower than other engines. + +The good news is that eventually Luigi was able to nail down this issue and we +got a binary that performed well. It looks like \LUA\ 5.3.4 (cross|)|compiles +badly with \GCC\ 5.3.0 and 6.3.0. + +So in the end caching the fonts takes: + +\starttabulate[||c|c|] +\BC \BC caching \BC running \NC \NR +\BC 5.2 stock \NC 8.3 \NC 1.2 \NC \NR +\BC 5.3 bugged \NC 12.6 \NC 2.1 \NC \NR +\BC 5.3 fixed \NC 6.3 \NC 1.0 \NC \NR +\stoptabulate + +So indeed it looks like 5.3 is able to speed up \LUATEX\ a bit, given that one +integrates it in the right way! Using a recent compiler is needed too, although +one can wonder when a bad case will show up again. One can also wonder why such a +slow down can mostly go unnoticed, because for sure \LUATEX\ is not the only +compiled program. + +The next examples are some edge cases that show you need to be aware +that +\startitemize[n,text,nostopper] + \startitem an integer has its limits, \stopitem + \startitem that hexadecimal numbers are integers and \stopitem + \startitem that \LUA\ and \LUAJIT\ can be different in details. \stopitem +\stopitemize + +\starttabulate[||T|T|] +\NC \NC \tx print(0xFFFFFFFFFFFFFFFF) \NC \tx print(0x7FFFFFFFFFFFFFFF) \NC \NR +\HL +\BC lua 52 \NC 1.844674407371e+019 \NC 9.2233720368548e+018 \NC \NR +\BC luajit \NC 1.844674407371e+19 \NC 9.2233720368548e+18 \NC \NR +\BC lua 53 \NC -1 \NC 9223372036854775807 \NC \NR +\stoptabulate + +So, to summarize the process. A quick test was relatively easy: move 5.3 into the +code base, adapt a little bit of internals (there were some \LUATEX\ interfacing +bits where explicit rounding was needed), run tests and eventually fix some +issues related to the Makefile (compatibility) and \CCODE\ obscurities (the slow +\type {sprintf}). Adapting \CONTEXT\ was also not much work, and the test suite +uncovered some nasty side effects. For instance, the valid 5.2 solution: + +\starttyping +local s = string.format("02X",u/1024) +local s = string.char (u/1024) +\stoptyping + +now has to become (both 5.2 and 5.3): + +\starttyping +local s = string.format("02X",math.floor(u/1024)) +local s = string.char (math.floor(u/1024)) +\stoptyping + +or (both 5.2 and (emulated or real) 5.3): + +\starttyping +local s = string.format("02X",bit32.rshift(u,10)) +local s = string.char (bit32.rshift(u,10)) +\stoptyping + +or (only 5.3): + +\starttyping +local s = string.format("02X",u >> 10)) +local s = string.char (u >> 10) +\stoptyping + +or (only 5.3): + +\starttyping +local s = string.format("02X",u//1024) +local s = string.char (u//1024) +\stoptyping + +A conditional section like: + +\starttyping +if LUAVERSION >= 5.3 then + local s = string.format("02X",u >> 10)) + local s = string.char (u >> 10) +else + local s = string.format("02X",bit32.rshift(u,10)) + local s = string.char (bit32.rshift(u,10)) +end +\stoptyping + +will fail because (of course) the 5.2 parser doesn't like that. In \CONTEXT\ we +have some experimental solutions for that but that is beyond this summary. + +In the process a few \UTF\ helpers were added to the string library so that we +have a common set for \LUAJIT\ and \LUA\ (the \type {utf8} library that was added +to 5.3 is not that important for \LUATEX). For now we keep the \type {bit32} +library on board. Of course we'll not mention all the details here. + +When we consider a gain in speed of 5-10\% with 5.3 that also means that the gain +of \LUAJITTEX\ compared to 5.2 becomes less. For instance in font processing both +engines now perform closer to the same. + +As I write this, we've just entered 2018 and after a few months of testing +\LUATEX\ with \LUA\ 5.3 we're confident that we can move the code to the +experimental branch. This means that we will use this version in the \CONTEXT\ +distribution and likely will ship this version as 1.10 in 2019, where it becomes +the default. The 2018 version of \TEX~Live will have 1.07 with \LUA\ 5.2 while +intermediate versions of the \LUA\ 5.3 binary will end up on the \CONTEXT\ +garden, probably with number 1.08 and 1.09 (who knows what else we will add or +change in the meantime). + +\stopchapter + +\stopcomponent + +% collectgarbage("count") -- two return values in 2 diff --git a/doc/context/sources/general/manuals/onandon/onandon-execute.tex b/doc/context/sources/general/manuals/onandon/onandon-execute.tex new file mode 100644 index 000000000..abb3b4d8a --- /dev/null +++ b/doc/context/sources/general/manuals/onandon/onandon-execute.tex @@ -0,0 +1,396 @@ +% language=uk + +\startcomponent onandon-execute + +\environment onandon-environment + +\startchapter[title={Executing \TEX}] + +Much of the \LUA\ code in \CONTEXT\ originates from experiments. When it survives +in the source code it is probably used, waiting to be used or kept for +educational purposes. The functionality that we describe here has already been +present for a while in \CONTEXT, but improved a little starting with \LUATEX\ +1.08 due to an extra helper. The code shown here is generic and not used in +\CONTEXT\ as such. + +Say that we have this code: + +\startbuffer +for i=1,10000 do + tex.sprint("1") + tex.sprint("2") + for i=1,3 do + tex.sprint("3") + tex.sprint("4") + tex.sprint("5") + end + tex.sprint("\\space") +end +\stopbuffer + +\typebuffer + +% \ctxluabuffer + +When we call \type {\directlua} with this snippet we get some 30 pages of \type +{12345345345}. The printed text is saved till the end of the \LUA\ call, so +basically we pipe some 170.000 characters to \TEX\ that get interpreted as one +paragraph. + +Now imagine this: + +\startbuffer +\setbox0\hbox{xxxxxxxxxxx} \number\wd0 +\stopbuffer + +\typebuffer + +which gives \getbuffer. If we check the box in \LUA, with: + +\startbuffer +tex.sprint(tex.box[0].width) +tex.sprint("\\enspace") +tex.sprint("\\setbox0\\hbox{!}") +tex.sprint(tex.box[0].width) +\stopbuffer + +\typebuffer + +the result is {\tttf \ctxluabuffer}, which is not what you would expect at first +sight. However, if you consider that we just pipe to a \TEX\ buffer that gets +parsed after the \LUA\ call, it will be clear that the reported width is the +width that we started with. It will work all right if we say: + +\startbuffer +tex.sprint(tex.box[0].width) +tex.sprint("\\enspace") +tex.sprint("\\setbox0\\hbox{!}") +tex.sprint("\\directlua{tex.sprint(tex.box[0].width)}") +\stopbuffer + +\typebuffer + +because now we get: {\tttf\ctxluabuffer}. It's not that complex to write some +support code that makes this more convenient. This can work out quite well but +there is a drawback. If we use this code: + +\startbuffer +print(status.input_ptr) +tex.sprint(tex.box[0].width) +tex.sprint("\\enspace") +tex.sprint("\\setbox0\\hbox{!}") +tex.sprint("\\directlua{print(status.input_ptr)\ + tex.sprint(tex.box[0].width)}") +\stopbuffer + +\typebuffer + +Here we get \type {6} and \type {7} reported. You can imagine that when a lot of +nested \type {\directlua} calls happen, we can get an overflow of the input level +or (depending on what we do) the input stack size. Ideally we want to do a \LUA\ +call, temporarily go to \TEX, return to \LUA, etc.\ without needing to worry +about nesting and possible crashes due to \LUA\ itself running into problems. One +charming solution is to use so|-|called coroutines: independent \LUA\ threads +that one can switch between --- you jump out from the current routine to another +and from there back to the current one. However, when we use \type {\directlua} +for that, we still have this nesting issue and what is worse, we keep nesting +function calls too. This can be compared to: + +\starttyping +\def\whatever{\ifdone\whatever\fi} +\stoptyping + +where at some point \type {\ifdone} is false so we quit. But we keep nesting when +the condition is met, so eventually we can end up with some nesting related +overflow. The following: + +\starttyping +\def\whatever{\ifdone\expandafter\whatever\fi} +\stoptyping + +is less likely to overflow because there we have tail recursion which basically +boils down to not nesting but continuing. Do we have something similar in +\LUATEX\ for \LUA ? Yes, we do. We can register a function, for instance: + +\starttyping +lua.get_functions_table()[1] = function() print("Hi there!") end +\stoptyping + +and call that one with: + +\starttyping +\luafunction 1 +\stoptyping + +This is a bit faster than calling a function like: + +\starttyping +\directlua{HiThere()} +\stoptyping + +which can also be achieved by + +\starttyping +\directlua{print("Hi there!")} +\stoptyping + +which sometimes can be more convenient. Anyway, a function call is what we can +use for our purpose as it doesn't involve interpretation and effectively behaves +like a tail call. The following snippet shows what we have in mind: + +\startbuffer[code] +local stepper = nil +local stack = { } +local fid = 0xFFFFFF +local goback = "\\luafunction" .. fid .. "\\relax" + +function tex.resume() + if coroutine.status(stepper) == "dead" then + stepper = table.remove(stack) + end + if stepper then + coroutine.resume(stepper) + end +end + +lua.get_functions_table()[fid] = tex.resume + +function tex.yield() + tex.sprint(goback) + coroutine.yield() + texio.closeinput() +end + +function tex.routine(f) + table.insert(stack,stepper) + stepper = coroutine.create(f) + tex.sprint(goback) +end +\stopbuffer + +\ctxluabuffer[code] + +\startbuffer[demo] +tex.routine(function() + tex.sprint(tex.box[0].width) + tex.sprint("\\enspace") + tex.sprint("\\setbox0\\hbox{!}") + tex.yield() + tex.sprint(tex.box[0].width) +end) +\stopbuffer + +\typebuffer[demo] +We start a routine, jump out to \TEX\ in the middle, come back when we're done +and continue. This gives us: \ctxluabuffer [demo], which is what we expect. + +\setbox0\hbox{xxxxxxxxxxx} + +\ctxluabuffer[demo] + +This mechanism permits efficient (nested) loops like: + +\startbuffer[demo] +tex.routine(function() + for i=1,10000 do + tex.sprint("1") + tex.yield() + tex.sprint("2") + tex.routine(function() + for i=1,3 do + tex.sprint("3") + tex.yield() + tex.sprint("4") + tex.yield() + tex.sprint("5") + end + end) + tex.sprint("\\space") + tex.yield() + end +end) +\stopbuffer + +\typebuffer[demo] + +We do create coroutines, go back and forwards between \LUA\ and \TEX, but avoid +memory being filled up with printed content. If we flush paragraphs (instead of +e.g.\ the space) then the main difference is that instead of a small delay due to +the loop unfolding in a large set of prints and accumulated content, we now get a +steady flushing and processing. + +However, we can still have an overflow of input buffers because we still nest +them: the limitation at the \TEX\ end has moved to a limitation at the \LUA\ end. +How come? Here is the code that we use: + +\typebuffer[code] + +The \type {routine} creates a coroutine, and \type {yield} gives control to \TEX. +The \type {resume} is done at the \TEX\ end when we're finished there. In +practice this works fine and when you permit enough nesting and levels in \TEX\ +then you will not easily overflow. + +When I picked up this side project and wondered how to get around it, it suddenly +struck me that if we could just quit the current input level then nesting would +not be a problem. Adding a simple helper to the engine made that possible (of +course figuring it out took a while): + +\startbuffer[code] +local stepper = nil +local stack = { } +local fid = 0xFFFFFF +local goback = "\\luafunction" .. fid .. "\\relax" + +function tex.resume() + if coroutine.status(stepper) == "dead" then + stepper = table.remove(stack) + end + if stepper then + coroutine.resume(stepper) + end +end + +lua.get_functions_table()[fid] = tex.resume + +if texio.closeinput then + function tex.yield() + tex.sprint(goback) + coroutine.yield() + texio.closeinput() + end +else + function tex.yield() + tex.sprint(goback) + coroutine.yield() + end +end + +function tex.routine(f) + table.insert(stack,stepper) + stepper = coroutine.create(f) + tex.sprint(goback) +end +\stopbuffer + +\ctxluabuffer[code] + +\typebuffer[code] + +The trick is in \type {texio.closeinput}, a recent helper and one that should be +used with care. We assume that the user knows what she or he is doing. On an old +laptop with a i7-3840 processor running \WINDOWS\ 10 the following snippet takes +less than 0.35 seconds with \LUATEX\ and 0.26 seconds with \LUAJITTEX. + +\startbuffer[code] +tex.routine(function() + for i=1,10000 do + tex.sprint("\\setbox0\\hpack{x}") + tex.yield() + tex.sprint(tex.box[0].width) + tex.routine(function() + for i=1,3 do + tex.sprint("\\setbox0\\hpack{xx}") + tex.yield() + tex.sprint(tex.box[0].width) + end + end) + end +end) +\stopbuffer + +\typebuffer[code] + +% \testfeatureonce {1} {\setbox0\hpack{\ctxluabuffer[code]}} \elapsedtime + +Say that we run the bad snippet: + +\startbuffer[code] +for i=1,10000 do + tex.sprint("\\setbox0\\hpack{x}") + tex.sprint(tex.box[0].width) + for i=1,3 do + tex.sprint("\\setbox0\\hpack{xx}") + tex.sprint(tex.box[0].width) + end +end +\stopbuffer + +\typebuffer[code] + +% \testfeatureonce {1} {\setbox0\hpack{\ctxluabuffer[code]}} \elapsedtime + +This time we need 0.12 seconds in both engines. So what if we run this: + +\startbuffer[code] +\dorecurse{10000}{% + \setbox0\hpack{x} + \number\wd0 + \dorecurse{3}{% + \setbox0\hpack{xx} + \number\wd0 + }% +} +\stopbuffer + +\typebuffer[code] + +% \testfeatureonce {1} {\setbox0\hpack{\getbuffer[code]}} \elapsedtime + +Pure \TEX\ needs 0.30 seconds for both engines but there we lose 0.13 seconds on +the loop code. In the \LUA\ example where we yield, the loop code takes hardly +any time. As we need only 0.05 seconds more it demonstrates that when we use the +power of \LUA\ the performance hit of the switch is quite small: we yield 40.000 +times! In general, such differences are far exceeded by the overhead: the time +needed to typeset the content (which \type {\hpack} doesn't do), breaking +paragraphs into lines, constructing pages and other overhead involved in the run. +In \CONTEXT\ we use a slightly different variant which has 0.30 seconds more +overhead, but that is probably true for all \LUA\ usage in \CONTEXT, but again, +it disappears in other runtime. + +Here is another example: + +\startbuffer[code] +\def\TestWord#1% + {\directlua{ + tex.routine(function() + tex.sprint("\\setbox0\\hbox{\\tttf #1}") + tex.yield() + tex.sprint(math.round(100 * tex.box[0].width/tex.hsize)) + tex.sprint(" percent of the hsize: ") + tex.sprint("\\box0") + end) + }} +\stopbuffer + +\typebuffer[code] \getbuffer[code] + +\startbuffer +The width of next word is \TestWord {inline}! +\stopbuffer + +\typebuffer \getbuffer + +Now, in order to stay realistic, this macro can also be defined as: + +\startbuffer[code] +\def\TestWord#1% + {\setbox0\hbox{\tttf #1}% + \directlua{ + tex.sprint(math.round(100 * tex.box[0].width/tex.hsize)) + } % + percent of the hsize: \box0\relax} +\stopbuffer + +\typebuffer[code] + +We get the same result: \quotation {\getbuffer}. + +We have been using a \LUA|-|\TEX\ mix for over a decade now in \CONTEXT, and have +never really needed this mixed model. There are a few places where we could +(have) benefitted from it and we might use it in a few places, but so far we have +done fine without it. In fact, in most cases typesetting can be done fine at the +\TEX\ end. It's all a matter of imagination. + +\stopchapter + +\stopcomponent diff --git a/doc/context/sources/general/manuals/onandon/onandon-expansion.tex b/doc/context/sources/general/manuals/onandon/onandon-expansion.tex new file mode 100644 index 000000000..73a0b4953 --- /dev/null +++ b/doc/context/sources/general/manuals/onandon/onandon-expansion.tex @@ -0,0 +1,307 @@ +% language=uk + +\startcomponent onandon-expansion + +\environment onandon-environment + +\startchapter[title={More (new) expansion trickery}] + +Contrary to what one might expect when looking at macro definitions, \TEX\ is +pretty efficient. Occasionally I wonder if some extra built in functionality +could help me write better code but when you program with a bit care there is +often not much to gain in terms of tokens and performance. \footnote {The long +trip to the yearly Bacho\TeX\ meeting is always a good opportunity to ponder +\TEX\ and its features. The new functionality discussed here is a side effect of +the most recent trip.} Also, some possible extensions probably only would be +applied a few times which makes them low priority. When you look at the +extensions brought by \ETEX\ the number is not that large, and \LUATEX\ only +added a few that deal with the language, for instance \tex {expanded} which is +like an \tex {edef} without the defining a macro and acts on a token list wrapped +in (normally) curly braces. Just as reference we mention some of the expansion +related helpers. + +\starttabulate[|l|l|p|] +\BC command \BC argument \BC + comment +\NC \NR +\HL +\NC \tex {expandafter} \NC \type {token} \NC + The token after the next token gets expanded (one level only). In tricky + \TEX\ code you can often see multiple such commands in sequence which makes a + nice puzzle. +\NC \NR +\NC \tex {noexpand} \NC \type {token} \NC + The token after this command is not expanded in the context of expansion. +\NC \NR +\NC \tex {expanded} \NC \type {{tokens}} \NC + The given token list is expanded. This command showed up early in \LUATEX\ + development and was taken from \ETEX\ follow|-|ups. I have mails from 2011 + mentioning its presence in \PDFTEX\ 1.50 (which was targeted in 2008) but + somehow it never ended up in a production version at that time (and we're + still not at that version). In \CONTEXT\ we already had a command with that + name so there we use \tex {normalexpanded}. Users normally can just use the + \CONTEXT\ variant of \type {\expanded}. +\NC \NR +\NC \tex {unexpanded} \NC \type {{tokens}} \NC + The given token list is hidden from expansion. Again, in \CONTEXT\ we already + had a command serving as prefix for definitions so instead we use \tex + {normalunexpanded}. In the core of \CONTEXT\ this new \ETEX\ command is hardly + used. +\NC \NR +\NC \tex {detokenize} \NC \type {{tokens}} \NC + The given tokenlist becomes (basically) verbatim \TEX\ code. We had something + like that in \CONTEXT\ but have no nameclash. It is used in a few places. It's + also an \ETEX\ command. +\NC \NR +\NC \tex {scantokens} \NC \type {{tokens}} \NC + This primitive interprets its argument as a pseudo file. We don't really use it. +\NC \NR % +\NC \tex {scantextokens} \NC \type {{tokens}} \NC + This \LUATEX\ primitive does the same but has no end|-|of|-|file side + effects. This one is also not really used in \CONTEXT. +\NC \NR +\NC \tex {protected} \NC \type {\.def} \NC + The definition following this prefix, introduced in \ETEX, is unexpandable in + the context of expansion. We already used such a command in \CONTEXT\ but + with a completely different meaning so use \tex {normalprotected} as prefix + or \tex {unexpanded} which is an alias. +\NC \NR +\stoptabulate + +Here I will present two other extensions in \LUATEX\ that can come in handy, and +they are there simply because their effect can hardly be realized otherwise +(never say never in \TEX). One has to do with immediately applying a definition, +the other with user defined conditions. The first one relates directly to +expansion, the second one concerns conditions and relates more to parsing +branches which on purpose avoids expansion. + +For the first one I use some silly examples. I must admit that although I can +envision useful application, I really need to go over the large amount of +\CONTEXT\ source code to really find a place where it is making things better. +Take the following definitions: + +\startbuffer +\newcount\NumberOfCalls + +\def\TestMe{\advance\NumberOfCalls1 } + +\edef\Tested{\TestMe foo:\the\NumberOfCalls} +\edef\Tested{\TestMe foo:\the\NumberOfCalls} +\edef\Tested{\TestMe foo:\the\NumberOfCalls} + +\meaning\Tested +\stopbuffer + +\typebuffer + +The result is a macro \tex {Tested} that not only has the unexpanded incrementing +code in its body but also hasn't done any advancing: + +\getbuffer + +Of course when you're typesetting something, this kind of expansion normally is +not needed. Instead of the above definition we can define \tex {TestMe} in a way +that expands the assignment immediately. You need of course to be aware of +preventing look ahead interference by using a space or \tex {relax} (often an +expression works better as it doesn't leave an \tex {relax}). + +\startbuffer +\def\TestMe{\immediateassignment\advance\NumberOfCalls1 } + +\edef\Tested{\TestMe bar:\the\NumberOfCalls} +\edef\Tested{\TestMe bar:\the\NumberOfCalls} +\edef\Tested{\TestMe bar:\the\NumberOfCalls} + +\meaning\Tested +\stopbuffer + +\typebuffer + +This time the counter gets updated and we don't see interference in the resulting +\tex {Tested} macro: + +\getbuffer + +Here is a somewhat silly example of an expanded comparison of two \quote +{strings}: + +\startbuffer +\def\expandeddoifelse#1#2#3#4% + {\immediateassignment\edef\tempa{#1}% + \immediateassignment\edef\tempb{#2}% + \ifx\tempa\tempb + \immediateassignment\def\next{#3}% + \else + \immediateassignment\def\next{#4}% + \fi + \next} + +\edef\Tested + {(\expandeddoifelse{abc}{def}{yes}{nop}/% + \expandeddoifelse{abc}{abc}{yes}{nop})} + +\meaning\Tested +\stopbuffer + +\typebuffer + +I don't remember many cases where I needed such an expanded comparison. We have a +variant in \CONTEXT\ that uses \LUA\ but that one is not really used in the core. +Anyway, the above code gives: + +\getbuffer + +You can do the same assignments as in preambles of \tex {halign} and after \tex +{accent} which means that assignments to box registers are blocked (boxing +involves grouping and delayed assignments and so). The error you will get when +you use a non||assignment command refers to a prefix, because internally such +commands are called prefixed commands. Leading spaces and \tex {relax} are +ignored. + +In addition to this one|-|time immediate assignment a pseudo token list variant +is provided, so the above could be rewritten to: + +\starttyping +\def\expandeddoifelse#1#2#3#4% + {\immediateassigned { + \edef\tempa{#1} + \edef\tempb{#2} + }% + \ifx\tempa\tempb + \immediateassignment\def\next{#3}% + \else + \immediateassignment\def\next{#4}% + \fi + \next} +\stoptyping + +While \tex {expanded} first builds a token lists that then gets used, the \tex +{immediateassigned} primitive just walls over the list delimited by curly braces. + +A next extension concerns conditions. If you have done a bit of extensive \TEX\ +programming you know that nested conditions need to be properly constructed in +for instance macro bodies. This is because (for good reason) \TEX\ goes into a +fast scanning mode when there is a match and it has to skip the \tex {else} upto +\tex {fi} branch. In order to do that properly a nested \tex {if} in there needs +to have a matching \tex {fi}. + +In practice this is no real problem and careful coding will never give a problem +here: you can either hide nested code in a macro or somehow jump over nested +conditions if really needed. Actually you only need to care when you pickup a +token inside the branch because likely you don't want to pick up for instance a +\tex {fi} but something that comes after it. Say that we have a sane conditional +setup like this: + +\starttyping +\newif\iffoo \foofalse +\newif\ifbar \bartrue + +\ifoo + \ifbar \else \fi +\else + \ifbar \else \fi +\fi +\stoptyping + +Here the \tex {iffoo} and \tex {ifbar} need to be equivalent to \tex {iftrue} or +\tex {iffalse} in order to succeed well and that is what for instance \tex +{footrue} and \tex {foofalse} will do: change the meaning of \tex {iffoo}. + +But imagine that you want something more complex. You want for instance to let +\tex {ifbar} do some calculations. In that case you want it to behave a bit like +what a so called \type {vardef} in \METAPOST\ does: the end result is what +matters. Now, because \TEX\ macros often are a complex mix of expandable and +non|-|expandable this is not that trivial. One solution is a dedicated definer, +say \tex {cdef} for defining a macro with conditional properties. I actually +implemented such a definer a few years ago but left it so long in a folder with +ideas that I only found it back after I had come up with another solution. It was +probably proof that it was not that good an idea. + +The solution implemented in \LUATEX\ is just a special case of a test: \tex +{ifcondition}. When looking at the next example, keep in mind that from the +perspective of \TEX's scanner it only needs to know if something is a token that +does some test and has a matching \tex {fi}. For that purpose you can consider +\tex {ifcondition} to be \tex {iftrue}. When \TEX\ actually wants to do a test, +which is the case in the true branch, then it will simply ignore this \tex +{ifcondition} primitive and expands what comes after it (which is \TEX's natural +behaviour). Effectively \tex {ifcondition} has no meaning except from when it has +to be skipped, in which case it's a token flagged as \tex {if} kind of command. + +\starttyping +\unexpanded\def\something#1#2% + {\edef\tempa{#1}% + \edef\tempb{#2} + \ifx\tempa\tempb} + +\ifcondition\something{a}{b}% + \ifcondition\something{a}{a}% + true 1 + \else + false 1 + \fi +\else + \ifcondition\something{a}{a}% + true 2 + \else + false 2 + \fi +\fi +\stoptyping + +Wrapped in a macro you can actually make this fully expandable when you use the +previously mentioned immediate assignment. Here is another example: + +\starttyping +\unexpanded\def\onoddpage + {\ifodd\count0 } + +\ifcondition\onoddpage odd \else even \fi page +\stoptyping + +The previously defined comparison macro can now be rewritten as: + +\starttyping +\def\equaltokens#1#2% + {\immediateassignment\edef\tempa{#1}% + \immediateassignment\edef\tempb{#2}% + \ifx\tempa\tempb} + +\def\expandeddoifelse#1#2#3#4% + {\ifcondition\equaltokens{#1}{#2}% + \immediateassignment\def\next{#3}% + \else + \immediateassignment\def\next{#4}% + \fi + \next} +\stoptyping + +When used this way it will of course also work without the \tex {ifcondition} but +when used nested it can be like this. This last example also demonstrates that +this feature probably only makes sense in more complicated cases where more work +is done in the \tex {onoddpage} or \tex {equaltokens} macro. And again, I am not +sure if for instance in \CONTEXT\ I have a real use for it because there are only +a few cases where nesting like this could benefit. I did some tests with a low +level macro where it made the code look nicer. It was actually a bit faster but +most core macros are not called that often. Although the overhead of this feature +can be neglected, performance should not be the reason for using it: in \CONTEXT\ +for instance one can often only measure such possible speed|-|ups on macros that +are called tens or hundreds of thousands of times and that seldom happens in a +real run end even then a change from say 0.827 seconds to 0.815 seconds for 10K +calls of a complex case is just noise as the opposite can also happen. + +Although not strictly necessary these extensions might make some code look better +so that is why they officially will be available in the 1.09 release of \LUATEX\ +in fall 2018. It might eventually inspire me to go over some code and see where I +can improve the look and feel. + +The last few years I have implemented some more ideas as local experiments, for +instance \tex {futurelet} variant or a simple (one level) \tex {expand}, but in +the end rejected them because there is no real benefit in them (no better looking +code, no gain in performance, hard to document, possible side effects, etc.), so +it is very unlikely that we will have more extensions like this. After all, we +could do more than 40 years without them. Although \unknown\ who knows what we +will provide in \LUATEX\ version~2. + +\stopchapter + +\stopcomponent diff --git a/doc/context/sources/general/manuals/onandon/onandon-media.tex b/doc/context/sources/general/manuals/onandon/onandon-media.tex new file mode 100644 index 000000000..f44c3bb19 --- /dev/null +++ b/doc/context/sources/general/manuals/onandon/onandon-media.tex @@ -0,0 +1,220 @@ +% language=uk + +\startcomponent onandon-media + +\environment onandon-environment + +\startchapter[title={The state of \PDF}] + +\startsection[title={Introduction}] + +Below I will spend some words on the state of \PDF\ in \CONTEXT\ mid 2018. These +are just some reflections, not an in|-|depth discussion of the state of affairs. I +sometimes feel the need to wrap up. + +\stopsection + +\startsection[title={Media}] + +For over two decades \CONTEXT\ has supported fancy \PDF\ features like movies and +sound. In fact, as happens more, the flexibility of \TEX\ made it possible to +support such features right after they became available, often even before other +applications supported them. + +The first approach to support such media clips was relatively easy. In \PDF\ one +has the text flow, resulting from the typesetting process, either or not enhanced +with images that are referred to from the flow. In that respect images are an +integral part of \PDF. On a separate layer there can be annotations. There are +many kinds and they are originally a sort of extension mechanism that permits +plugins to add features to a document. Examples of this are hyperlinks and the +already mentioned media clips. Video was supported by the quicktime movie plugin. +As far as I know in the meantime that plugin has been dropped as official part of +Acrobat but one can still plug it in. + +Later an extra mechanism was introduced, tagged renditions. It separates the +views from the media and was more complex. When I first played with it, quite +some media were possible, and I made a demo that could handle mov, mp3, smi and +swf files. But last time I checked none of these really worked, apart from the +swf file. One gets pop|-|ups for missing viewers and a look at the reader +preferences makes one pessimistic about future support anyway. But one should be +able to set up a list of useable players with this mechanism (although only an +Adobe one seems to be okay so we're back to where we started). + +At some point support for u3d was added. Interesting is that there is quite some +infrastructure described in the \PDF\ standard. Also something called rich media +was introduced and that should replace the former video and audio annotations +(definitely in \PDF\ version 2) and probably some day the renditions will no +longer be supported either. Open source \PDF\ viewers just stuck to supporting +text and static images. + +Now, do these rich media work well? Hardly. The standard leaves it to the viewer +and provides ways to define viewers (although it's unclear to me how that works +out in practice.) Basically in \PDF\ version 2 there is no native support for +simple straightforward video. One has to construct a complex set of related +annotations. + +One can give arguments (like security risks) for not supporting all these fancy +features but then why make rich media part of the specification at all? Browsers +beat \PDF\ viewers in showing media and as browsers can operate in kiosk mode I +suppose that it's not that hard to delegate showing whatever you want in an +embedded window in the \PDF\ viewer. Or why not simply support videolan out of +the box. All we need is the ability to view movies and control them (play, pause, +stop, rewind, etc). Where \HTML\ evolved towards easier media support, \PDF\ +evolved to more obscurity. + +So, how bad is it really? There are \PDF\ files around that have video! Indeed, +but the way they're supposed to do this is as follows: currently one actually has +to embed a shockwave video player (a user interface around something built|-|in) +and let that player show for instance an mp4 movie. However, support for +shockwave (flash) will be dropped in 2020 and that renders documents that use it +obsolete. This even makes one wonder about \JAVASCRIPT\ and widgets like form +fields, also a rather moving and somewhat unstable target. (I must have a +document being a calculator somewhere made in the previous century, in the early +days of \PDF.) + +I think that the plugin model failed already rather early in the \PDF\ history if +only because it made no sense to develop them when in a next version of Acrobat +the functionality was copied in the core. In a similar fashion \JAVASCRIPT\ +support seems to have stalled. + +Unfortunately the open source viewers never catched on with media, forms and +\JAVASCRIPT\ and therefore there has been no momentum created to keep things +supported. It all makes efforts spent on supporting this kind of \PDF\ features a +waste of time. It also makes one careful in using them: it only works on the +short term. + +Get me right, I'm not talking of complex media like 3d or animations but of +straightforward video support. I understand that the rich media framework tries +to cover complex cases but it's simple cases that carry the format. On the other +hand, one can wonder why the \PDF\ format makes it possible to specify behaviour +that in practice depends on \JAVASCRIPT\ and therefore could as well have been +delegated to \JAVASCRIPT\ as well. It would probably have been much cleaner. +\footnote {It looks like mu\PDF\ in 2018 got some support related to widgets aka +fields but alas not for layers which would be quite useful.} + +The \PDF\ version 2 specification mentions \type {3D}, \type {Video} and \type +{Audio} as primary content types so maybe future viewers will support video out +of the box. Who knows. We try to keep up in \CONTEXT\ because it's often not that +complex to support \PDF\ features but with hardly any possibility to test them, +they have a low priority. And with Acrobat moving to the cloud and thereby +creating a more of less lifelong dependency on remote resources it doesn't become +much interesting to explore those routes either. + +\stopsection + +\startsection[title={Accessibility}] + +A popular \PDF\ related topic is accessibility. One aspect of that is tagged +\PDF. This substandard is in my opinion not something that deserves a price for +beauty. I know that there are \CONTEXT\ users who need to be compliant but I +always wonder what a publisher really does with such a file. It's a bit like +requiring \XML\ as source but at the same time sacrificing really rich encoded +and sources for tweaks that suite the current limitations of for instance browsers, +tool|-|chains and competence. We've seen it happen. + +Support for tagged \PDF\ has been available in \CONTEXT\ already for a while but +as far as I know only Acrobat professional can do something with it. The reason +for tagging is that a document is then useable for (for instance) visually +impaired users, but aren't they better served with a proper complete and very +structured source in some format that tools suitable for it can use? How many +publishers distribute \PDF\ files while they can still make money on prints? How +many are really interested in distributing enriched content that then can be +reused somehow? And how many are willing to invest in tools instead of waiting +for it to happen for free? It's a bit cheap trick to just expect authors (and +their in the case of \TEX\ free tools) to suit a publishers needs. Anyway, just +as with advanced interactive documents or forms, I wonder if it will catch on. At +least no publisher ever asked us and by the time they might do the competition of +web based dissemination could have driven \PDF\ to the background. But, in +\CONTEXT\ we will keep supporting such features anyway, if only because it's +quite doable. But \unknown\ it's user demand that drives development, not the +market, which means that the motivation for implementing such features depends on +user input as well as challenging aspects that make it somewhat fun to spend time +on them. + +\stopsection + +\startsection[title={Quality assurance}] + +Another aspect popping up occasionally is validation. I'm not entirely sure what +drives that but delegating a problem can be one reason. Often we see publishers +and printers use old versions of \PDF\ related tools. Also, some workflows are +kind of ancient anyway and are more driven by \POSTSCRIPT\ history than \PDF\ +possibilities. I sometimes get the impression that it takes at least a decade for +these things to catch on, and by that time it doesn't matter any more that \TEX\ +and friends were at the front: their users are harassed by what the market +demands by then. + +Support for several standards related to validation is already part of \CONTEXT\ +for quite a while. For instance the bump from \PDF\ 1.7 to 2.0 was hardly worth +noticing, simply because there are not that many fundamental changes. Adapting +\LUATEX\ was trivial (and actually not really needed), and macro packages can +provide what is needed without much problems. So, yes, we can support it without +much hassle. Personally I never ran into a case where validation was really +needed. The danger of validation is that it can give a false impression of +quality. And as with everything quality control created a market. As with other +features it is users who drive the availability of support for this. After all, +they are the ones testing it and figuring out the often fuzzy specifications. +These are things that one can always look at in retrospect (like: it has to be +done this or that way) while in practice in order to be an early adopter one has +to gamble a bit and see where it fails or succeeds. Fortunately it's relatively +easy to adapt macro packages and \CONTEXT\ users are willing to update so it's +not really an issue. + +Putting a stamp of approval on a \PDF\ cannot hide the inconsistencies between +for instance vector graphics produced by a third party. They also don't expose +inconsistent use of color and fonts. The page streams produced by \LUATEX\ are +simple and clean enough to not give problems with validation. The problem lays +more with resources coming from elsewhere. When you're phoned by a printing house +about an issue with \RGB\ images in a file where there is no sign of \RGB\ being +used but where a validator reports an issue, you're lucky when an experienced +printer dating back decades then replies that he already had that impression and +will contact the origin. There is no easy way out of this but educating users +(authors) is an option. However, they are often dependent on the publishers and +departments that deal with these and those tend to come with directives that the +authors cannot really argue with (or about). + +\stopsection + +\startsection[title={Interactivity}] + +This is an area where \TEX\ (an therefore also \CONTEXT) always had an edge, +There is a lot possible and in principle all that \PDF\ provides can be +supported. But the more fancy one goes, the more one depends on Acrobat. +Interactivity in \PDF\ evolved stepwise and is mostly market driven. As a result +it is (or was) not always consistent. This is partly due to the fact that we have +a chicken|-|egg issue: you need typesetting machinery, viewer as well as a +standard. + +The regular hyperlinks, page or named driven are normally supported by viewers. +Some redefined named destinations (like going to a next page, or going back in a +chain of followed links) not always. Launching applications, as it also relates +to security, can be qualified as an unreliable mechanism. More advanced linking, +for instance using \JAVASCRIPT\ is hardly supported. In that respect \PDF\ +viewers lag way behind \HTML\ browsers. I understand that there can be security +risks involved. It's interesting to see that in Acrobat one can mess with +internals of files which makes the \API\ large and complex, but if we stick to +the useful core, the amount of interfacing needed is quite small. Lack of support +in open source viewers (we're talking of about two decades now) made me loose +interest in these features but they are and will be supported in \CONTEXT. We'll +see if and when viewers catch up. + +Comments and attachments are also part of interactivity and of course we +supported them right from the start. Some free viewers also support them by now. +Personally I never use comments but they can be handy for popping up information +or embedding snippets or (structured) sources (like \MATHML\ or bibliographic +data). In \CONTEXT\ we can even support \PDF\ inclusion with (a reasonable) +subset of these so called annotations. As the \PDF\ standard no longer evolves +much we can expect all these features to become stable. + +\stopsection + +\startsection[title={Summary}] + +We have always supported the fancy \PDF\ features and we will continue doing so +in \CONTEXT . However, many of them depends on what viewers support, and after +decades of \PDF\ that is still kind of disappointing, which is not that +motivating. We'll see what happens. + +\stopsection + +\stopchapter diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-000.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-000.tex deleted file mode 100644 index f48af866d..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-000.tex +++ /dev/null @@ -1,116 +0,0 @@ -% \startenvironment onandon-speed-000 - -% \dontcomplain - -\edef\sapolsky{\ignorespaces\cldloadfile{sapolsky}\removeunwantedspaces} - -\startluacode - - function document.ResetSample(title) - document.elapsed = { - title = title, - times = { }, - } - end - - function document.RegisterSample(bodyfont,elapsed) - table.insert(document.elapsed.times, { - bodyfont = bodyfont, - elapsed = elapsed - }) - end - - function document.SaveSample() - if LUATEXENGINE == "luajittex" then - table.save(tex.jobname.."-jit.lua",document.elapsed) - else - table.save(tex.jobname..".lua",document.elapsed) - end - end - - function document.ShowSample(filename) - -- context.typefile(filename..".tex") - local elapsed = table.load(file.nameonly(filename)..".lua") - local elapsedjit = table.load(file.nameonly(filename).."-jit.lua") - if elapsed and elapsedjit then - context.testpage { 6 } - context.starttabulate { "|l|l|lp|" } - context.HL() - context.NC() context.formatted.rlap("\\bf %s",elapsed.title) - context.NC() - context.NC() - context.NC() context.NR() - context.HL() - local times = elapsed.times - local timesjit = elapsedjit.times - for j=1,#times do - local t = times[j] - local tjit = timesjit[j] - context.NC() context(t.bodyfont) - context.NC() context(t.elapsed) - context.NC() context(tjit.elapsed) - context.NC() context.NR() - end - context.HL() - context.stoptabulate() - end - end - - function document.SampleTitle(filename) - local elapsed = table.load(filename..".lua") - if elapsed then - context(elapsed.title) - end - end -\stopluacode - -\appendtoks - \ctxlua{document.SaveSample()}% -\to \everystoptext - -\def\SampleCount{1000} -\def\SampleCount{100} - -\unexpanded\def\RegisterSample#1% - {\ctxlua{document.RegisterSample("#1","\elapsedtime")}} - -\unexpanded\def\ProcessSample#1% - {\page - \ctxlua{document.ResetSample("#1")}% - \resettimer \Sample {modern} \RegisterSample {modern} - \resettimer \Sample {pagella} \RegisterSample {pagella} - \resettimer \Sample {termes} \RegisterSample {termes} - \resettimer \Sample {cambria} \RegisterSample {cambria} - \resettimer \Sample {dejavu} \RegisterSample {dejavu} - \resettimer \Sample {ebgaramond} \RegisterSample {ebgaramond} - \resettimer \Sample {lucidaot} \RegisterSample {lucidaot} - \page } - -\unexpanded\def\ProcessBaselineSample#1% - {\page - \ctxlua{document.ResetSample("#1")}% - \resettimer \Sample {baseline} \RegisterSample {baseline} - \page } - -\unexpanded\def\Sample#1% - {\setupbodyfont[#1]} - -\unexpanded\def\ShowSample#1% - {\ctxlua{document.ShowSample("#1")}} - -\unexpanded\def\SampleTitle#1% - {\ctxlua{document.SampleTitle("#1.lua")}} - -\continueifinputfile{onandon-speed-000.tex} - -\starttext - -\ProcessSample{bodyfont} - -\setbox\scratchbox\vbox{\hsize1pt\tttf\sapolsky} \getnoflines{\htdp\scratchbox} - -\writestatus{!!!!!!}{noflines : \the\noflines} - -\stoptext - -% \stopenvironment diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-001.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-001.tex deleted file mode 100644 index b6c241752..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-001.tex +++ /dev/null @@ -1,15 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \setbox\scratchbox\hbox{\tf\bf\it\bi}% - \stop} - -\ProcessSample{bodyfont switch and 4 style changes (first time)} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-002.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-002.tex deleted file mode 100644 index edd6dd0f7..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-002.tex +++ /dev/null @@ -1,16 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \setbox\scratchbox\hbox{\tf\bf\it\bi}% - \stop} - -\ProcessSample{bodyfont switch and 4 style changes (first time)} -\ProcessSample{bodyfont switch and 4 style changes (follow up)} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-003.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-003.tex deleted file mode 100644 index 4362ccb4f..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-003.tex +++ /dev/null @@ -1,15 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \dorecurse\SampleCount{\setbox\scratchbox\hbox{\sapolsky\space\sapolsky\space\sapolsky\space\sapolsky}}% - \stop} - -\ProcessSample{\SampleCount\space hboxes with 4 texts using one font} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-005.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-005.tex deleted file mode 100644 index 7aeb53b4b..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-005.tex +++ /dev/null @@ -1,17 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \dorecurse\SampleCount{\sapolsky\space\sapolsky\space\sapolsky\space\sapolsky\par}% - \stop} - -\startlayout[page] - \ProcessSample{\SampleCount\space times 4 texts on pages} -\stoplayout - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-006.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-006.tex deleted file mode 100644 index d15ef428e..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-006.tex +++ /dev/null @@ -1,17 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \dorecurse\SampleCount{\tf\sapolsky\space\bf\sapolsky\space\it\sapolsky\space\bi\sapolsky\space\par}% - \stop} - -\startlayout[page] - \ProcessSample{\SampleCount\space times 4 texts on pages using 4 styles} -\stoplayout - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-007.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-007.tex deleted file mode 100644 index 7a4eed497..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-007.tex +++ /dev/null @@ -1,31 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\sapolsky{% - Agriculture is a fairly recent human invention, and in many ways it was one of - the great {\bf stupid} moves of all time. Hunter|-|gatherers have thousands of wild - sources of food to subsist on. Agriculture changed that all, generating an - overwhelming reliance on a few dozen domesticated food sources, making you - extremely vulnerable to the next famine, the next locust infestation, the next - potato blight. Agriculture allowed for stockpiling of surplus resources and thus, - {\bf inevitably}, the unequal stockpiling of them --- stratification of society and - the invention of classes. Thus, it allowed for the invention of poverty. I think - that the punch line of the primate|-|human difference is that when humans - invented poverty, they came up with a way of subjugating the low|-|ranking like - {\bf nothing ever seen before} in the primate world. -}% - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \dorecurse\SampleCount{\sapolsky\par}% - \stop} - -\startlayout[page] - \ProcessSample{\SampleCount\space texts on pages with [1,2,4] bold font switches} -\stoplayout - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-008.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-008.tex deleted file mode 100644 index ae968bc10..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-008.tex +++ /dev/null @@ -1,32 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\sapolsky{% - Agriculture is a fairly recent human invention, and in many ways it was one - of the great \type {stupid} moves of all time. Hunter|-|gatherers have - thousands of wild sources of food to subsist on. Agriculture changed that - all, generating an overwhelming reliance on a few dozen domesticated food - sources, making you extremely vulnerable to the next famine, the next locust - infestation, the next potato blight. Agriculture allowed for stockpiling of - surplus resources and thus, \type {inevitably}, the unequal stockpiling of - them --- stratification of society and the invention of classes. Thus, it - allowed for the invention of poverty. I think that the punch line of the - primate|-|human difference is that when humans invented poverty, they came up - with a way of subjugating the low|-|ranking like \type {nothing ever seen - before} in the primate world. -}% - -\def\Sample#1% - {\start - \switchtobodyfont[#1] - \dorecurse\SampleCount{\sapolsky\par}% - \stop} - -\startlayout[page] - \ProcessSample{\SampleCount\space texts on pages with [1,2,4] word verbatim switches} -\stoplayout - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-009.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-009.tex deleted file mode 100644 index 61116e652..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-009.tex +++ /dev/null @@ -1,15 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \infofont - \dorecurse\SampleCount{\setbox\scratchbox\hpack{\sapolsky\space\sapolsky\space\sapolsky\space\sapolsky}}% - \stop} - -\ProcessBaselineSample{\SampleCount\space hboxes with 4 texts and no font handling} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-010.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-010.tex deleted file mode 100644 index 673c2b1e5..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-010.tex +++ /dev/null @@ -1,15 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\starttext - -\def\Sample#1% - {\start - \infofont - \dorecurse\SampleCount{\setbox\scratchbox\hbox{\sapolsky\space\sapolsky\space\sapolsky\space\sapolsky}}% - \stop} - -\ProcessBaselineSample{\SampleCount\space hboxes with 4 texts and no features} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-011.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-011.tex deleted file mode 100644 index 90d924c00..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-011.tex +++ /dev/null @@ -1,20 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\dontcomplain - -\starttext - -\def\Sample#1% - {\start - \tttf\tx - \dorecurse\SampleCount{\sapolsky\space\sapolsky\space\sapolsky\space\sapolsky\par}% - \stop} - -\startlayout[page] - \ProcessBaselineSample {\SampleCount\space paragraphs with 4 texts and no features} -\stoplayout - - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon-speed-012.tex b/doc/context/sources/general/manuals/onandon/onandon-speed-012.tex deleted file mode 100644 index e2d51e195..000000000 --- a/doc/context/sources/general/manuals/onandon/onandon-speed-012.tex +++ /dev/null @@ -1,20 +0,0 @@ -\environment onandon-speed-000 - -\ProcessSample{bodyfont} \setupbodyfont[dejavu] - -\dontcomplain - -\starttext - -\def\SampleCount{1000} - -\def\Sample#1% - {\start -% \switchtobodyfont[#1] - \dorecurse\SampleCount{\sapolsky\par} - \stop} - -% \ProcessSample{\SampleCount\space pages no features} -\ProcessBaselineSample{\SampleCount\space paragraphs text} - -\stoptext diff --git a/doc/context/sources/general/manuals/onandon/onandon.tex b/doc/context/sources/general/manuals/onandon/onandon.tex index 2352907fc..00b01f9ae 100644 --- a/doc/context/sources/general/manuals/onandon/onandon.tex +++ b/doc/context/sources/general/manuals/onandon/onandon.tex @@ -34,42 +34,19 @@ \startbodymatter \component onandon-decade - \component onandon-ffi - - % \startchapter[title=Variable fonts] First published in user group magazines. \stopchapter - \component onandon-variable - + \component onandon-variable % first published in user group magazines \component onandon-emoji - - \startchapter[title={Children of \TEX}] First published in user group magazines. \stopchapter - % \component onandon-children - \component onandon-performance - \component onandon-editing - - \startchapter[title={Advertising \TEX}] First published in user group magazines. \stopchapter - % \component onandon-perception - - \startchapter[title={Tricky fences}] First published in user group magazines. \stopchapter - % \component onandon-fences - - % \component onandon-media - - \startchapter[title={From 5.2 to 5.3}] First published in user group magazines. \stopchapter - % \component onandon-53 - - \startchapter[title={Executing \TEX}] First published in user group magazines. \stopchapter - % \component onandon-execute - + \component onandon-fences % first published in user group magazines + \component onandon-media + \component onandon-53 % first published in user group magazines + \component onandon-execute % first published in user group magazines \component onandon-modern - - \startchapter[title={More expansion}] Maybe first published in user group magazines. \stopchapter - % \component onandon-expansion - - \component onandon-110 + \component onandon-expansion \component onandon-runtoks + \component onandon-110 \stopbodymatter \stopproduct |