diff options
Diffstat (limited to 'doc')
27 files changed, 1711 insertions, 107 deletions
diff --git a/doc/context/documents/general/manuals/evenmore.pdf b/doc/context/documents/general/manuals/evenmore.pdf Binary files differindex e8f7e737c..532d5b578 100644 --- a/doc/context/documents/general/manuals/evenmore.pdf +++ b/doc/context/documents/general/manuals/evenmore.pdf diff --git a/doc/context/documents/general/manuals/luametatex.pdf b/doc/context/documents/general/manuals/luametatex.pdf Binary files differindex 7794b070c..3d27d72ce 100644 --- a/doc/context/documents/general/manuals/luametatex.pdf +++ b/doc/context/documents/general/manuals/luametatex.pdf diff --git a/doc/context/documents/general/manuals/luatex.pdf b/doc/context/documents/general/manuals/luatex.pdf Binary files differindex fc4d4b49c..553b1613d 100644 --- a/doc/context/documents/general/manuals/luatex.pdf +++ b/doc/context/documents/general/manuals/luatex.pdf diff --git a/doc/context/documents/general/qrcs/setup-cs.pdf b/doc/context/documents/general/qrcs/setup-cs.pdf Binary files differindex c861b3af1..f3c813efa 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 fc89adc60..398456abc 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 f80e50193..3ae23f53b 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 f381aa9a2..87d636c24 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 fba974ab1..47be61e2c 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 1c52028b4..0296eeb31 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 cbbc30dde..307c0c92c 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 0291cddee..8f428e238 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 fb118b2f6..7b8f577d2 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 bfebe3eae..407b87119 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 0ac3cb52a..bdb1e3a1b 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 258206e6b..2909492dd 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 1fa0b9e02..d7cb1d3a6 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 ba5c480cb..89b593550 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/evenmore/evenmore-fonts.tex b/doc/context/sources/general/manuals/evenmore/evenmore-fonts.tex new file mode 100644 index 000000000..fea3f7ac5 --- /dev/null +++ b/doc/context/sources/general/manuals/evenmore/evenmore-fonts.tex @@ -0,0 +1,732 @@ +% language=us + +\environment evenmore-style + +\disabledirectives[fonts.svg.cached] + +% \usemodule[scite] +% \usemodule[article-basic] +% \usemodule[abbreviations-logos] + +\startcomponent evenmore-fonts + +\startchapter[title=Modern Type 3 fonts] + +Support for \TYPETHREE\ fonts has been on my agenda for a couple of years now. +Here I will take a look at them from the perspective of \LUAMETATEX. \footnote +{This chapter appeared in \TUGBOAT\ 40:3. Thanks to Karl Berry for corrections.} +The reason is that they might be useful for embedding (for instance) runtime +graphics (such as symbols) in an efficient way. In \TEX\ systems \TYPETHREE\ +fonts are normally used for bitmap fonts, the \PK\ output that comes via +\METAFONT. Where for instance \TYPEONE\ fonts are defined using a set of font +specific rendering operators, a \TYPETHREE\ font can contain arbitrary code, in +\PDF\ files these are \PDF\ (graphic and text) operators. + +A program like \LUATEX\ supports embedding of several font formats natively. A +quick summary of relevant formats is the following: \footnote {Technically one +can embed anything in the \PDF\ file.} + +\startitemize[headintext][headstyle=bold] +\starthead {\TYPEONE:} + these are outline fonts using \type {cff} descriptions, a compact format for + storing outlines. Normally up to 256 characters are accessible but a font can + have many more (as Latin Modern and \TEX\ Gyre demonstrate). +\stophead +\starthead {\OPENTYPE:} + these also use the \type {cff} format. As with \TYPEONE\ the outlines are + mostly cubic Bezier curves. Because there is no bounding box data stored in + the format the engine has to pseudo|-|render the glyphs to get that + information. When embedding a subset the backend code has to flatten the + subroutine calls, which is another reason the \type {cff} blob has to be + disassembled. +\stophead +\starthead {\TRUETYPE:} + these use the \type {ttf} format which uses quadratic B|-|splines. The font + can have a separate kerning table and stores information about the bounding + box (which is then used by \TEX\ to get the right heights and depths of + glyphs). Of course those details never make it into the \PDF\ file as such. +\stophead +\starthead {\TYPETHREE:} + as mentioned this format is (traditionally) used to store bitmap fonts but as + we will see it can do more. It is actually the easiest format to deal with. +\stophead +\stopitemize + +In \LUATEX\ any font can be a \quotation {wide} font, therefore in \CONTEXT\ a +\TYPEONE\ font is not treated differently than an \OPENTYPE\ font. The \LUATEX\ +backend can even disguise a \TYPEONE\ font as an \OPENTYPE\ font. In the end, as +not that much information ends up in the \PDF\ file, the differences are not that +large for the first three types. The content of a \TYPETHREE\ font is less +predictable but even then it can have for instance a \type {ToUnicode} vector so +it has no real disadvantages in, say, accessibility. In \CONTEXT\ \LMTX, which +uses \LUAMETATEX\ without any backend, all is dealt with in \LUA: loading, +tweaking, applying and embedding. + +The difference between \OPENTYPE\ and \TRUETYPE\ is mostly in the kind of curves +and specific data tables. Both formats are nowadays covered by the \OPENTYPE\ +specification. If you Google for the difference between these formats you can +easily end up with rather bad (or even nonsense) descriptions. The best +references are \typ {https://en.wikipedia.org/wiki/Bézier_curve} and the +ever|-|improving \typ {https://docs.microsoft.com/en-us/typography} website. + +Support for so|-|called variable fonts is mostly demanding of the front|-|end +because in the backend it is just an instance of an \OPENTYPE\ or \TRUETYPE\ font +being embedded. In this case the instance is generated by the \CONTEXT\ font +machinery which interprets the \type {cff} and \type {ttf} binary formats in +doing~so. This feature is not widely used but has been present from the moment +these fonts showed up. + +\TYPETHREE\ fonts don't have a particularly good reputation, which is mainly due +to the fact that viewers pay less attention in displaying them, at least that was +the case in the past. If they describe outlines, then all is okay, apart from the +fact that there is no anti|-|aliasing or hinting but on modern computers that is +hardly an issue. For bitmaps the quality depends on the resolution and +traditionally \TEX\ bitmap fonts are generated for a specific device, but if you +use a decent resolution (say 1200 dpi) then all should be okay. The main drawback +is that viewers will render such a font and cache the (then available) bitmap +which in some cases can have a speed penalty. + +Using \TYPETHREE\ fonts in a \PDF\ backend is not something new. Already in the +\PDFTEX\ era we were playing with so|-|called \PDF\ glyph containers. In practice +that worked okay but not so much for \METAPOST\ output from \METAFONT\ fonts. As +a side note: it might actually work better now that in \METAFUN\ we have some +extensions for rendering the kind of paths used in fonts. But glyph containers +were dropped long ago already and \TYPETHREE\ was limited to traditional \TEX\ +bitmap inclusion. However, in \LUAMETATEX\ it is easier to mess around with fonts +because we no longer need to worry about side effects of patching font related +inclusion (embedding) for other macro packages. All is now under \LUA\ control: +there is no backend included and therefore no awareness of something built|-|in +as \TYPETHREE. + +So, as a prelude to the 2019 \CONTEXT\ meeting, I picked up this thread and +turned some earlier experiments into production code. Originally I meant to +provide support for \METAPOST\ graphics but that is still locked in experiments. +I do have an idea for its interface, now that we have more control over user +interfaces in \METAFUN. + +In addition to \quote {just graphics} there is another candidate for \TYPETHREE\ +fonts \emdash\ extensions to \OPENTYPE\ fonts: + +\startitemize[packed,n] +\startitem Color fonts where stacked glyphs are used (a nice method). \stopitem +\startitem Fonts where \SVG\ images are used. \stopitem +\startitem Fonts that come with bitmap representations in \PNG\ format. \stopitem +\stopitemize + +It will be no surprise that we're talking of emoji fonts here although the second +category is now also used for regular text fonts. When these fonts showed up +support for them was not that hard to implement and (as often) we could make +\TEX\ be among the first to support them in print (often such fonts are meant for +the web). + +For category one, the stacked shapes, the approach was to define a virtual font +where glyphs are flushed while backtracking over the width in order to get the +overlay. Of course color directives have to be injected too. The whole lot is +wrapped in a container that tells a \PDF\ handler what character actually is +represented. Due to the way virtual fonts work, every reference to a character +results in the same sequence of glyph references, (negative) kern operations and +color directives plus the wrapper in the page stream. This is not really an issue +for emoji because these are seldom used and even then in small quantities. But it +can explode a \PDF\ page stream for a color text font. All happens at runtime and +because we use virtual fonts, the commands are assembled beforehand for each +glyph. + +For the second category, \SVG\ images, we used a different approach. Each symbol +was converted to \PDF\ using Inkscape and cached for later use. Instead of +injecting a glyph reference, a reference to a so|-|called \type {XForm} is +injected, again with a wrapper to indicate what character we deal with. Here the +overhead is not that large but still present as we need the so|-|called \quote +{actual text} wrapper. + +The third category is done in a similar way but this time we use GraphicsMagick +to convert the images beforehand. The drawbacks are the same. + +In \CONTEXT\ \LMTX\ a different approach is followed. The \PDF\ stream that +stacks the glyphs of category one makes a perfect stream for a \TYPETHREE\ +character. Apart from some juggling to relate a \TYPETHREE\ font to an \OPENTYPE\ +font, the page stream just contains references to glyphs (with the proper related +\UNICODE\ slot). The overhead is minimal. + +For the second category \CONTEXT\ \LMTX\ uses its built|-|in \SVG\ converter. The +\XML\ code of the shape is converted to (surprise): \METAPOST. We could go +directly to \PDF\ but the \METAPOST\ route is cheap and we can then get support +for color spaces, transformations, efficient paths and high quality all for free. +It also opens up the possibility for future manipulations. The \TYPETHREE\ font +eventually has a sequence of drawing operations, mixed with transformations and +color switches, but only once. Most of the embedded code is shared with the other +categories (a plug|-|in model is used). + +The third category follows a similar route but this time we use the built|-|in +\PNG\ inclusion code. Just like the other categories, the page stream only +contains references to glyphs. + +It was interesting to find that most of the time related to the inclusion went +into figuring out why viewers don't like these fonts. For instance, in Acrobat +there needs to be a glyph at index zero and all viewers seem to be able to handle +at most 255 additional characters in a font. But once that, and a few more +tricks, had become clear, it worked out quite well. It also helps to set the font +bounding box to all zero values so that no rendering optimizations kick in. Also, +some dimensions can are best used consistently. With \SVG\ there were some issues +with reference points and bounding boxes but these could be dealt with. A later +implementation followed a slightly different route anyway. + +The implementation is reasonably efficient because most work is delayed till a +glyph (shape) is actually injected (and most shapes in these fonts aren't used at +all). The viewers that I have installed, Acrobat Reader, Acrobat X, and the +mupdf|-|based Sumatra\PDF\ viewer can all handle the current implementation. + +An example of a category one font is \MICROSOFT's \type {seguiemj}. I have no +clue about the result in the future because some of these emoji fonts change +every now and then, depending also on social developments. This is a category one +font which not only has emoji symbols but also normal glyphs: + +\startbuffer[1a] +\definefontfeature[colored][default][colr=yes] +\definefont[TestA][file:seguiemj.ttf*colored] +\definesymbol[bug1][\getglyphdirect{file:seguiemj.ttf*colored} {\char"1F41C}] +\definesymbol[bug2][\getglyphdirect{file:seguiemj.ttf*colored} {\char"1F41B}] +\stopbuffer + +\typebuffer[1a][option=TEX] \getbuffer[1a] + +The example below demonstrates this by showing the graphic glyph surrounded by +the \type {x} from the emoji font, and from a regular text font. + +\startbuffer[1b] +{\TestA x\char"1F41C x\char"1F41B x}% +\quad +{x\symbol[bug1]x\symbol[bug2]x}% +\quad +{\showglyphs x\symbol[bug1]x\symbol[bug2]x}% +\stopbuffer + +\typebuffer[1b][option=TEX] + +\startlinecorrection +\scale[width=\textwidth]{\getbuffer[1b]} +\stoplinecorrection + +In this mix we don't use a \TYPETHREE\ font for the characters that don't need +stacked (colorful) glyphs, which is more efficient. So the \type {x} characters +are references to a regular (embedded) \OPENTYPE\ font. + +The next example comes from a manual and demonstrates that we can (still) +manipulate colors as we wish. + +\startbuffer[1c] +\definecolor[emoji-red] [r=.4] +\definecolor[emoji-blue] [b=.4] +\definecolor[emoji-green] [g=.4] +\definecolor[emoji-yellow][r=.4,g=.5] +\definecolor[emoji-gray] [s=1,t=.5,a=1] + +\definefontcolorpalette + [emoji-red] + [emoji-red,emoji-gray] + +\definefontcolorpalette + [emoji-green] + [emoji-green,emoji-gray] + +\definefontcolorpalette + [emoji-blue] + [emoji-blue,emoji-gray] + +\definefontcolorpalette + [emoji-yellow] + [emoji-yellow,emoji-gray] + +\definefontfeature[seguiemj-r][default][ccmp=yes,dist=yes,colr=emoji-red] +\definefontfeature[seguiemj-g][default][ccmp=yes,dist=yes,colr=emoji-green] +\definefontfeature[seguiemj-b][default][ccmp=yes,dist=yes,colr=emoji-blue] +\definefontfeature[seguiemj-y][default][ccmp=yes,dist=yes,colr=emoji-yellow] + +\definefont[MyColoredEmojiR][seguiemj*seguiemj-r] +\definefont[MyColoredEmojiG][seguiemj*seguiemj-g] +\definefont[MyColoredEmojiB][seguiemj*seguiemj-b] +\definefont[MyColoredEmojiY][seguiemj*seguiemj-y] +\stopbuffer + +\typebuffer[1c][option=TEX] \getbuffer[1c] + +\startbuffer[1d] +\MyColoredEmojiR\resolvedemoji{man}\resolvedemoji{woman}% +\MyColoredEmojiG\resolvedemoji{man}\resolvedemoji{woman}% +\MyColoredEmojiB\resolvedemoji{man}\resolvedemoji{woman}% +\MyColoredEmojiY\resolvedemoji{man}\resolvedemoji{woman}% +\stopbuffer + +\startlinecorrection + \scale[width=\textwidth]{\getbuffer[1d]} +\stoplinecorrection + +Let's look in more detail at the woman emoji. On the left we see the default +colors, and on the right we see our own: + +\definefontfeature[seguiemj][default][ccmp=yes,dist=yes,colr=yes] +\definefont[MyColoredEmojiD][seguiemj*seguiemj] + +\startlinecorrection +\scale[height=2cm] + {\MyColoredEmojiD\resolvedemoji{woman}% + \MyColoredEmojiR\resolvedemoji{woman}} +\stoplinecorrection + +The multi|-|color variant in \CONTEXT\ \MKIV\ ends up as follows in the page +stream: + +\starttyping +/Span << /ActualText <feffD83DDC69> >> BDC +q +0.000 g +BT +/F8 11.955168 Tf +1 0 0 1 0 2.51596 Tm [<045B>]TJ +0.557 0.337 0.180 rg +1 0 0 1 0 2.51596 Tm [<045C>]TJ +1.000 0.784 0.239 rg +1 0 0 1 0 2.51596 Tm [<045D>]TJ +0.000 g +1 0 0 1 0 2.51596 Tm [<045E>]TJ +0.969 0.537 0.290 rg +1 0 0 1 0 2.51596 Tm [<045F>]TJ +0.941 0.227 0.090 rg +1 0 0 1 0 2.51596 Tm [<0460>]TJ +ET +Q +EMC +\stoptyping + +and the reddish one becomes: + +\starttyping[option=PDF] +/Span << /ActualText <feffD83DDC69> >> BDC +q +0.400 0 0 rg 0.400 0 0 RG +BT +/F8 11.955168 Tf +1 0 0 1 0 2.51596 Tm [<045B>]TJ +1 g 1 G /Tr1 gs +1 0 0 1 0 2.51596 Tm [<045C>1373<045D>1373<045E>1373<045F>1373<0460>]TJ +ET +Q +EMC +\stoptyping + +Each time this shape is typeset these sequences are injected. In \CONTEXT\ \LMTX\ +we get this in the page stream: + +\starttyping[option=PDF] +BT +/F2 11.955168 Tf +1 0 0 1 0 2.515956 Tm [<C8>] TJ +ET +\stoptyping + +This time the composed shape ends up in the \TYPETHREE\ character procedure. In +the colorful case (reformatted because it actually is a one|-|liner): + +\starttyping[option=PDF] +2812 0 d0 +0.000 g BT /V8 1 Tf [<045B>] TJ ET +0.557 0.337 0.180 rg BT /V8 1 Tf [<045C>] TJ ET +1.000 0.784 0.239 rg BT /V8 1 Tf [<045D>] TJ ET +0.000 g BT /V8 1 Tf [<045E>] TJ ET +0.969 0.537 0.290 rg BT /V8 1 Tf [<045F>] TJ ET +0.941 0.227 0.090 rg BT /V8 1 Tf [<0460>] TJ ET +\stoptyping + +and in the reddish case (where we have a gray transparent color): + +\starttyping[option=PDF] +2812 0 d0 +0.400 0 0 rg 0.400 0 0 RG +BT /V8 1 Tf [<045B>] TJ ET +1 g 1 G /Tr1 gs +BT /V8 1 Tf [<045C>] TJ ET +BT /V8 1 Tf [<045D>] TJ ET +BT /V8 1 Tf [<045E>] TJ ET +BT /V8 1 Tf [<045F>] TJ ET +BT /V8 1 Tf [<0460>] TJ ET +\stoptyping + +but this time we only get these verbose compositions once in the \PDF\ file. We +could optimize the last variant by a sequence of indices and negative kerns but +it hardly pays off. There is no need for \type {ActualText} here because we have +an entry in the \type {ToUnicode} vector: + +\starttyping[option=PDF] +<C8> <D83DDC69> +\stoptyping + +To be clear, the \type {/V8} is a sort of local reference to a font which can +have an \type {/F8} counterpart elsewhere. These \TYPETHREE\ fonts have their own +resource references and I found it more clear to use a different prefix in that +case. If we only use a few characters of this kind, of course the overhead of +extra fonts has a penalty but as soon we refer to more characters we gain a lot. + +When we have \SVG\ fonts, the gain is a bit less. The \PDF\ resulting from the +\METAPOST\ run can of course be large but they are included only once. In \MKIV\ +these would be (shared) so|-|called \type {XForm}s. In the page stream we then +see a simple reference to such an \type {XForm} but again wrapped into an \type +{ActualText}. In \LMTX\ we get just a reference to a \TYPETHREE\ character plus +of course an extra font. + +The \typ {emojionecolor-svginot} font is somewhat problematic (although maybe in +the meantime it has become obsolete). As usual with new functionality, +specifications are not always available or complete (especially when they are +application specs turned into standards). This is also true with for instance +\SVG\ fonts. The current documentation on the \MICROSOFT\ website is reasonable +and explains how to deal with the viewport but when I first implemented support +for \SVG\ it was more trial and error. The original implementation in \CONTEXT\ +used Inkscape to generate \PDF\ files with a tight bounding box and mix that with +information from the font (in \MKIV\ and the generic loader we still use this +method). This results in a reasonable placement for emoji (that often sit on top +of the baseline) but not for characters. More accurate treatment, using the +origin and bounding box, fail for graphics with bad viewports and strange +transform attributes. Now one can of course argue that I read the specs wrong, +but inconsistencies are hard to deal with. Even worse is that successive versions +of a font can demand different hacks. (I would not be surprised if some programs +have built|-|in heuristics for some fonts that apply fixes.) Here is an example: + +\starttyping +<svg transform="translate(0 -1788) scale(2.048)" viewBox="0 0 64 64" ...> + <path d="... all within the viewBox ..." ... /> +</svg> +\stoptyping + +It is no problem to scale up the image to normal dimensions, often 1000, or 2048 +but I've also seen 512. The 2.048 suggests a 2048 unit approach, as does the 1788 +shift. Now, we could scale up all dimensions by 1000/64 and then multiply by +2.048 and eventually shift over 1788, but why not scale the 1788 by 2.048 or +scale 64 by 2.048? Even if we can read the standard to suit this specification +it's just a bit too messy for my taste. In fact I tried all reasonable +combinations and didn't (yet) get the right result. In that case it's easier to +just discard the font. If a user complains that it (kind of) worked in the past, +a counter|-|argument can be that other (more recent) fonts don't work otherwise. +In the end we ended up with an option: when the \type {svg} feature value is +\type {fixdepth} the vertical position will be fixed. + +\startbuffer[2a] +\definefontfeature[whatever][default][color=yes,svg=fixdepth] +\definefont[TestB][file:emojionecolor-svginot.ttf*whatever] +\stopbuffer + +\typebuffer[2a][option=TEX] \getbuffer[2a] + +\startbuffer[2b] +x{\TestB \char"1F41C \char"1F41B}x +\stopbuffer + +\startlinecorrection + \scale[height=1cm]{\getbuffer[2b]} +\stoplinecorrection + +The newer \type {emojionecolor} font doesn't need this because it has a \type +{viewBox} of \type {0 54.4 64 64} which fixes the baseline. + +\startbuffer[2c] +\definefontfeature[whatever][default][color=yes,svg=yes] +\definefont[TestB][file:emojionecolor.otf*whatever] +\stopbuffer + +\typebuffer[2c][option=TEX] \getbuffer[2c] + +\startlinecorrection + \scale[height=1cm]{\getbuffer[2b]} +\stoplinecorrection + +Another example of a pitfall is running into category one glyphs made from +several pieces that all have the same color. If that color is black, one starts +to wonder what is wrong. In the end the \CONTEXT\ code was doing the right thing +after all, and I would not be surprised if that glyph gets colors in an update of +the font. For that reason it makes no sense to include them as examples here. +After all, we can hardly complain about free fonts (and I'm also guilty of +imposing bugs on users). By the way, for the font referred to here (\type +{twemojimozilla}), another pitfall was that all shapes in my copy had a zero +bounding box which means that although a width is specified, rendering in +documents can give weird side effects. This can be corrected by the \type +{dimensions} feature that forces the ascender and descender values to be used. + +\startbuffer[3a] +\definefontfeature[colored:x][default][colr=yes] +\definefontfeature[colored:y][default][colr=yes,dimensions={1,max,max}] +\definefont[TestC][file:twemojimozilla.ttf*colored:x] +\definefont[TestD][file:twemojimozilla.ttf*colored:y] +\stopbuffer + +\typebuffer[3a][option=TEX] \getbuffer[3a] + +\startbuffer[3b] +{\TestC\char 128028}\quad{\showglyphs\TestC\char 128028}\quad +{\TestD\char 128028}\quad{\showglyphs\TestD\char 128028} +\stopbuffer + +\startlinecorrection + \scale[height=2cm]{\getbuffer[3b]} +\stoplinecorrection + +An example of a \PNG|-|enhanced font is the \type {applecoloremoji} font. The +bitmaps are relatively large for the quality they provide and some look like +scans. + +\startbuffer[4a] +\definefontfeature[sbix][default][sbix=yes] +\definefont[TestE][file:applecoloremoji.ttc*sbix at 10bp] +\stopbuffer + +\typebuffer[4a][option=TEX] \getbuffer[4a] + +\startbuffer[4b] +\red \TestE \char 35 \char 9203 \char 9202 +\stopbuffer + +\startlinecorrection + \scale[height=1cm]{\getbuffer[4b]} +\stoplinecorrection + +As mentioned above, there are fonts that color characters other than emoji. We +give two examples (sometimes fonts are mentioned on the \CONTEXT\ mailing list). + +\startbuffer[5a] +\definefontfeature + [whatever] + [default,color:svg] + [script=latn, + language=dflt] + +\definefont[TestF][file:Abelone-FREE.otf*whatever @ 13bp] +\definefont[TestG][file:Gilbert-ColorBoldPreview5*whatever @ 13bp] +\definefont[TestH][file:ColorTube-Regular*whatever @ 13bp] +\stopbuffer + +\typebuffer[5a][option=TEX] \getbuffer[5a] + +Of course one can wonder about the readability of these fonts and unless one used +random colors (which bloats the file immensely) it might become boring, but +typically such fonts are only meant for special purposes. + +\startbuffer[5b] + {\TestF\setupinterlinespace[0.7]\input zapf \par} +\stopbuffer + +\startbuffer[5c] + {\TestG\setupinterlinespace \input zapf \par} +\stopbuffer + +\startbuffer[5d] + {\TestH\setupinterlinespace[0.7]\input zapf \par} +\stopbuffer + +\start \setupalign[tolerant] \getbuffer[5b] \stop + +The previous font is the largest and as a consequence also puts some strain on +the viewer, especially when zooming in. But, because viewers cache \TYPETHREE\ +shapes it's a one|-|time penalty. + +\start \setupalign[tolerant] \getbuffer[5c] \stop + +This font is rather lightweight. Contrary to what one might expect, there is no +transparency used (but of course we do support that when needed). + +\start \setupalign[tolerant] \getbuffer[5d] \stop + +This third example is again rather lightweight. Such fonts normally have a rather +limited repertoire although there are some accented characters included. But they +are not really meant for novels anyway. If you look closely you will also notice +that some characters are missing and kerning is suboptimal. + +I considered testing some more fonts but when trying to download some interesting +looking ones I got a popup asking me for my email address in order to subscribe +me to something: a definite no|-|go. + +%\section{\SVG\ to MetaPost} + +I already mentioned that we have a built|-|in converter that goes from \SVG\ to +\METAPOST. Although this article deals with fonts, the following code +demonstrates that we can also access such graphics in \METAFUN\ itself. The nice +thing is that because we get pictures, they can be manipulated. + +\startbuffer +\startMPcode{doublefun} + picture p ; p := lmt_svg [ filename = "mozilla-svg-001.svg" ] ; + numeric w ; w := bbwidth(p) ; + draw p ; + draw p xscaled -1 shifted (2.5*w,0); + draw p rotatedaround(center p,45) shifted (3.0*w,0) ; + draw image ( + for i within p : if filled i : + draw pathpart i withcolor green ; + fi endfor ; + ) shifted (4.5*w,0); + draw image ( + for i within p : if filled i : + fill pathpart i withcolor red withtransparency (1,.25) ; + fi endfor ; + ) shifted (6*w,0); +\stopMPcode +\stopbuffer + +\typebuffer[option=TEX] + +This graphic is a copy from a glyph from an emoji font, so we have plenty of such +images to play with. The above manipulations result in: + +\startlinecorrection + \getbuffer +\stoplinecorrection + +Now that we're working with \METAPOST\ we may as well see if we can also load a +specific glyph, and indeed this is possible. + +\startbuffer[1] +\startMPcode{doublefun} + picture lb, rb ; + lb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 123 ] ; + rb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 125 ] ; + numeric dx ; dx := 1.25 * bbwidth(lb) ; + draw lb ; + draw rb shifted (dx,0) ; + pickup pencircle scaled 2mm ; + for i within lb : + draw lmt_arrow [ + path = pathpart i, + pen = "auto", + alternative = "curved", + penscale = 8 + ] + shifted (3dx,0) + withcolor "darkblue" + withtransparency (1,.5) + ; + endfor ; + for i within rb : + draw lmt_arrow [ + path = pathpart i, + pen = "auto", + alternative = "curved", + penscale = 8 + ] + shifted (4dx,0) + withcolor "darkred" + withtransparency (1,.5) + ; + endfor ; +\stopMPcode +\stopbuffer + +% Ok, I should make a macro ... + +\startbuffer[2] +\startMPcode{doublefun} + picture lb, rb ; + lb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 42 ] ; + rb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 64 ] ; + numeric dx ; dx := 1.25 * bbwidth(lb) ; + draw lb ; + draw rb shifted (dx,0) ; + pickup pencircle scaled 2mm ; + for i within lb : + draw lmt_arrow [ + path = pathpart i, + pen = "auto", + alternative = "curved", + penscale = 6 + ] + shifted (3.5dx,0) + withcolor "darkgreen" + withtransparency (1,.5) + ; + endfor ; + for i within rb : + draw lmt_arrow [ + path = pathpart i, + pen = "auto", + alternative = "curved", + penscale = 6 + ] + shifted (4.5dx,0) + withcolor "darkyellow" + withtransparency (1,.5) + ; + endfor ; +\stopMPcode +\stopbuffer + +\typebuffer[1][option=TEX] + +Here we first load two character shapes from a font. The \UNICODE\ slots (which +here are the same as the \ASCII\ slots) might look familiar: they indicate the +curly brace characters. We get two pictures and use the \type {within} loop to +run over the paths within these shapes. Each shape is made from three curves. As +a bonus a few more characters are shown. + +\startlinecorrection + \dontleavehmode + \scale[height=3cm]{\getbuffer[1]}% + \quad\quad\quad\quad + \scale[height=3cm]{\getbuffer[2]} +\stoplinecorrection + +It is not hard to imagine that a collection of such graphics could be made into a +font (at runtime). One only needs to find the motivation. Of course one can +always use a font editor (or Inkscape) and tweak there, which probably makes more +sense, but sometimes a bit of \METAPOST\ hackery is a nice distraction. Editing +the \SVG\ code directly is not that much fun. The overall structure often doesn't +look that bad (apart from often rather redundant grouping): + +\starttyping[option=XML] +<svg xmlns="http://www.w3.org/2000/svg"> + <path fill="#d87512" d="..."/> + <g fill="#bc600d"> + <path d="..."/> + </g> + <g fill="#d87512"> + <path d="..."/> + <path d="..."/> + </g> + <g fill="#bc600d"> + <path d="..."/> + </g> + ... +</svg> +\stoptyping + +In addition to \type {path}s there can be \type {line}, \type {circle} and +similar elements but often fonts just use the \type {path} element. This element +has a \type {d} attribute that holds a sequence of one character commands that +each can be followed by numbers. Here are the start characters of four such +attributes: + +\starttyping +M11.585 43.742s.387 1.248.104 3.05c0 0 2.045-.466 1.898-2.27 ... +M53.33 39.37c0-4.484-35.622-4.484-35.622 0 0 10.16.05 ... +M42.645 56.04c1.688 2.02 9.275.043 10.504-2.28 5.01-9.482-.006 ... +M54.2 41.496s-.336 4.246-4.657 9.573c0 0 4.38-1.7 5.808-4.3 ... +\stoptyping + +Indeed, numbers can be pasted together, also with the operators, which doesn't +help with seeing at a glance what happens. Probably the best reference can be +found at \typ {https://developer.mozilla.org/en-US/docs/Web/SVG} where it is +explained that a path can have move, line, curve, arc and other operators, as +well use absolute and relative coordinates. How that works is for another +article. + +How would the \TEX\ world look like today if Don Knuth had made \METAFONT\ +support colors? Of course one can argue that it is a bitmap font generator, but +in our case using high resolution bitmaps might even work out better. In the +example above the first text fragment uses a font that is very inefficient: it +overlays many circles in different colors with slight displacements. Here a +bitmap font would not only give similar effects but probably also be more +efficient in terms of storage as well as rendering. The \METAPOST\ successor does +support color and with \MPLIB\ in \LUATEX\ we can keep up quite well \unknown\ as +hopefully has been demonstrated here. + + +% It's no fun messing with these things that survive only for short time before +% being replaced by the next hyped fashion. Typical work than one needs to be paid +% for but never is. + +\stopchapter + +\stopcomponent diff --git a/doc/context/sources/general/manuals/evenmore/evenmore-pi.tex b/doc/context/sources/general/manuals/evenmore/evenmore-pi.tex new file mode 100644 index 000000000..197e86826 --- /dev/null +++ b/doc/context/sources/general/manuals/evenmore/evenmore-pi.tex @@ -0,0 +1,134 @@ +% language=us + +\environment evenmore-style + +% This appeared in TB 126, thanks to Karl Berry for fixing the English. + +\startcomponent evenmore-pi + +\startchapter[title=\TEX\ and Pi] + +This is a short status report \footnote {This chapter appeared in \TUGBOAT\ 40:3. +Thanks to Karl Berry for corrections.} on Pi, not the famous version number of +\TEX\ (among other things), but the small machine, meant for education but +nowadays also used for Internet Of Things projects, process control and toy +projects. While the majority of \TEX\ installations run on an Intel processor, +the Raspberry Pi has an \ARM\ central processing unit. In fact, its main chip has +the same foundation as those found in settop boxes all around the world. It's +made for entertainment, not for number crunching. + +At the \CONTEXT\ meetings, it has become tradition to play with electronic +gadgets. Every year we are curious what Harald K\"onig might bring this time. The +last couple of meetings we also had talks about using \TEX\ and \METAPOST\ for +designing (home|-|scale, automated) railroad systems, using \LUATEX\ for running +domotica applications, using \METAPOST\ for rendering high quality graphics from +data from appliances, presenting \TEX\ at computer and electronics bootcamps, and +more. This year Frans Goddijn also brought back memories of low speed modem +sounds, from the early days of \TEX\ support. It is these things that make the +meetings fun. + +This year the meeting was in Belgium, close to the border of the Netherlands, and +on the way there Mojca Miklavec traveled via my home, where the contextgarden +compile farm runs on a server with plenty of cores, lots of memory and big disks. +But the farm also has an old Mac connected as well as a tiny underpowered +Raspberry Pi 2 for \ARM\ binaries that we had to fix: the small micro \SSD\ card +in it had finally given up. This is no surprise if you realize that it does a +daily compilation of the whole \TEX\ Live setup and also compiles \LUATEX, +\LUAMETATEX\ and pplib when changes occur. Replacing the card worked out but +nevertheless we decided to take the small machine with us to the meeting. We also +took an external (2.5 inch) \SSD\ box with us. The idea was to order a Raspberry +Pi~4 on location, the much praised successor of the older models, the one with +4~\GB\ of memory, real \USB~3 ports and proper Ethernet. + +At the meeting Harald showed us that he had version~1, 3 and~4 machines with him +because he was looking into an energy control setup based on Zigbee devices. So +we had the full range of Pi's there to play with. + +This is a long introduction but the message is that we are dealing with a small +but popular device with up to now four generations, using an architecture +supported in \TEX\ distributions. So how does that relate to \CONTEXT ? One of +the reasons for \LUAMETATEX\ going lean and mean is that computers are no longer +getting much faster and \quote {multiple small} energy|-|wise has more appeal +than \quote {one large}. So then the question is: how can we make \TEX\ run fast +on small instead of gambling on big becoming even bigger (which does not seem to +be happening anyway). + +At the meeting Harald gave a talk \quotation {Which Raspberry Pi is the best for +\CONTEXT ?} and I will use his data to give an overview: see Table~\ref{rpispec}. + +\starttabulate[||c|c|c|c|] +\BC model \BC 1 \BC 2 \BC 3 \BC 4 \NC \NR +\BC chipset \NC BCM2835 \NC BCM2835 \NC BCM2835 \NC BCM2835 \NC \NR +\BC CPU core \NC v6l rev 7 \NC v7l rev 5 \NC v7l rev 4 \NC v7l rev 3 \NC \NR +\BC cores \NC 1 \NC 4 \NC 4 \NC 4 \NC \NR +\BC free mem \NC 443080 \NC 948308 \NC 948304 \NC 3999784 \NC \NR +\BC idlemips \NC 997.08 \NC 38.40 \NC 38.40 \NC 108.00 \NC \NR +\BC bogomips \NC 997.08 \NC 57.60 \NC 76.80 \NC 270.00 \NC \NR +\BC read SD \NC 23.0 MB/s \NC 23.2 MB/s \NC 23.2 MB/s \NC 45.1 MB/s \NC \NR +\BC read USB \NC \NC 30.0 MB/s \NC 30.0 MB/s \NC 320.0 MB/s \NC \NR +\stoptabulate + +After some discussion at the presentation we decided to discard the (absurd) +bogomips value for the tiny Pi~1 computing board and not take the values for the +others too seriously. But it will be clear that, especially when we consider the +external drive that things have improved. The table doesn't mention Ethernet +speed but because the~4 now has real support for it (instead of sharing the \USB\ +bus) we get close to 1~\GB/s there. + +The real performance test is of course processing a \TEX\ document and what +better to test than the \TEX\ book. The processing time in seconds, after initial +caching of files and fonts is: + +\starttabulate[||c|c|c|c|] +\BC model \BC 1 \BC 2 \BC 3 \BC 4 \NC \NR +\BC \TEX book \NC 13.649 \NC 7.023 \NC 4.553 \NC 1.694 \NC \NR +\BC {\tt context --make} \NC \NC 19.949 \NC 11.796 \NC 6.034 \NC \NR +\BC {\tt context --make} TL \NC 89.454 \NC 46.578 \NC 29.256 \NC 14.146 \NC \NR +\stoptabulate + +The test of making the \CONTEXT\ format using \LUATEX\ gives an indication of how +well the \IO\ performs: it loads the file database, some 460 \LUA\ modules and +355 \TEX\ source files. On my laptop with Intel i7-3840QM with 16GB memory and +decent \SSD\ it takes 3.5 seconds (and 1 second less for \LUAMETATEX\ because +there we don't compress the format file). Somehow a regular \TEXLIVE\ +installation performs much worse than the one from the contextgarden. + +We didn't test real \CONTEXT\ documents at the meeting but when I came home the +Pi~4 was bound again to the compile farm. Harald and Mojca had prepared the +machine to boot from the internal micro \SSD\ and use the external disk for the +rest. So, when we could compile \LUAMETATEX\ again, I made an \ARM\ installer for +\LMTX, and after that could not resist doing a simple test. First of course came +generating the format. It took 6.3 seconds to make one, which is a bit more than +Harald measured. I see a hiccup at the end so I guess that it has to do with the +(external) disk or maybe there is some throttling going on because the machine +sits on top of a (warm) server. + +More interesting was testing a real document: the upcoming \LUAMETATEX\ manual. +It has 226 pages, uses 21 font files, processes 225 \METAPOST\ graphics, and in +order to get it \LUAMETATEX\ does more than 50\% of the work in \LUA, including +all font and backend|-|related operations. On my laptop it needs 9.5~seconds and +on the Pi~4 it uses 33~seconds. Of course, if I take a more modern machine than +this 8|-|year|-|old workhorse, I probably need half the time, but still the +performance of the Raspberry Pi~4 is quite impressive. It uses hardly any energy +and can probably compete rather well with a virtual machine on a heavily loaded +machine. It means that when we ever have to upgrade the server, I can consider +replacement by an Ethernet switch, with power over Ethernet, connected to a bunch +of small Raspberries, also because normally one would connect to some shared +storage medium. + +Because I was curious how the dedicated small Fitlet that I use for controlling +my lights and heating performs I also processed the manual there. After making +the format, which takes 6~seconds, processing the manual took a little less than +30~seconds. In that respect it performs the same as a Raspberry Pi~4. But, inside +that small (way more expensive) computer is an dual core AMD A10 Micro-6700T APU +(with AMD Radeon R6 Graphics), running a recent 64|-|bit Ubuntu. It does some +2400 bogomips (compare that to the values of the Pi). I was a bit surprised that +it didn't outperform the Raspberry because the (fast \SSD) disk is connected to +the main board and it has more memory and horsepower. It might be that in the end +an \ARM\ processor is simply better suited for the kind of byte juggling that +\TEX\ does, where special \CPU\ features and multiple cores don't contribute +much. It definitely demonstrates that we cannot neglect this platform. + +\stopchapter + +\stopcomponent diff --git a/doc/context/sources/general/manuals/evenmore/evenmore-threesix.tex b/doc/context/sources/general/manuals/evenmore/evenmore-threesix.tex new file mode 100644 index 000000000..d75f9b683 --- /dev/null +++ b/doc/context/sources/general/manuals/evenmore/evenmore-threesix.tex @@ -0,0 +1,739 @@ +% language=us + +\environment evenmore-style + +\useMPlibrary[threesix] + +\startcomponent evenmore-threesix + +\startchapter[title={ThreeSix, Don Knuths first colorfont?}] + +In the process of reaching completion and perfection Don Knuth occasionally posts +links to upcoming parts of the TAOCP series on his web pages. Now, I admit that +much is way beyond me but I do understand (and like) the graphics and I know that +Don uses \METAPOST. The next example code is just a proof of concept but might +eventually become a decent module (with helpers) for making (runtime) fonts. +After all, we need to adapt to current developments and \TEX ies always are +willing to adapt and experiment. This chapter was written at the same time as +the previous one on \TYPETHREE\ fonts so you might want to read that first. + +The font explored here is \type {FONT36}, used in \quotation {A potpourri of +puzzles} and flagged as \quotation {a special font designed for dissection +puzzles} (in fascicle 9b for Volume 4). Playing with and visualizing for me often +works better than formulas, which then distracts me from the original purpose, +but let's have a closer look anyway. + +\startlinecorrection + \scale[width=\textwidth]{\DEKFontA 1234567890} \vskip1ex + \scale[width=\textwidth]{\DEKFontA ABC{\red DE}FGHIJ{\red K}LM} \vskip1ex + \scale[width=\textwidth]{\DEKFontA NOPQRSTUVWXYZ} +\stoplinecorrection + +The font has a fixed maximum height of 8~quantities. There is no depth in the +characters. Some characters are wider. In this example we use a tight bounding +box. In \CONTEXT\ speak this font is just a regular font but with a special +feature enabled. + +\starttyping +\definefontfeature + [fontthreesix] + [default] + [metapost=fontthreesix] + +\definefont[DEKFontA][Serif*fontthreesix] +\stoptyping + +After this the \type {\DEKFontA} command will set this font as current font. The +definition mentions \type {Serif} as font name. In \CONTEXT\ this name will +resolve in the currently defined Serif, so when your document uses Latin Modern +that will be the one. The \type {fontthreesix} will make this instance use that +feature set, and the feature definition has the defaults as parent (so we get +kerning, ligatures, etc.) but as extra feature also \type {metapost}. This means +that the new glyphs that are about to be defined will actually be injected in the +\type {Serif}! We will replace characters in that instance. So, the following: + +\startbuffer[taocp] +This font is used in \quotation {The Art Of Computer Programming} by +Don Knuth, not in volume~1, 2 or~3, but in number~4! +\stopbuffer + +\typebuffer[taocp] + +comes out as: + +\startnarrower +\DEKFontA \getbuffer[taocp] +\stopnarrower + +But that doesn't look too good, so we will tweak the font a bit: + +\starttyping +\definefontfeature + [fontthreesix-color] + [default] + [metapost={category=fontthreesix,spread=.1}] + +\definefont[DEKFontD][Serif*fontthreesix] +\stoptyping + +The \type {spread} (multiplied by the font unit, which is 12 basepoints here) +will add a bit more spacing around the blob: + +\startnarrower +\DEKFontD \getbuffer[taocp] +\stopnarrower + +Now, keep in mind that we're talking of a real font here. You can cut and paste +these characters. It's just the default uppercase Latin alphabet plus digits. + +Before we go and look at some of the code needed to render this, a few more +examples will be given. + +\startlinecorrection + \scale[width=\textwidth]{\DEKFontB 1234567890} \vskip4pt + \scale[width=\textwidth]{\DEKFontB ABCDEFGHIJKLM} \vskip4pt + \scale[width=\textwidth]{\DEKFontB NOPQRSTUVWXYZ} +\stoplinecorrection + +In the above example we not only use color, but also a different shape and random +colors (that is: random per \TEX\ job). The feature definition for this is: + +\starttyping +\definefontfeature + [fontthreesix-color] + [default] + [metapost={% + category=fontthreesix,shape=diamond,% + color=random,pen=fancy,spread=.1% + }] +\stoptyping + +Possible shapes are \type {circle}, \type {diamond} and \type {square} and +instead of a random color one can give a known color name. Using transparency +makes no sense in this font. + +A nice usage for this font are initials: % 4 for lm + +\startbuffer +\setupinitial[font=Serif*fontthreesix-initial sa 5] +{\DEKFontB \placeinitial \input zapf\par} +\stopbuffer + +\typebuffer + +The initial feature is defined as: + +\starttyping +\definefontfeature + [fontthreesix-initial] + [metapost={category=fontthreesix,color=random,shape=circle}] +\stoptyping + +We use this in quoting Hermann Zapf, one that for sure is very applicable in +a case like this: + +\startnarrower +\getbuffer +\stopnarrower + +Some combinations of sub|-|features are shown in \in {figure} [threesix:dek]. We +blow up the diamond with fancy pen example in \in {figure} [threesix:tex]. Alas, +the \TEX\ logo doesn't look that good in such a font. Using it for acronyms is +not a good idea anyway, but maybe you can figure out \in {figure} +[threesix:taocp]. + +% todo penx peny penr + +\definefontfeature + [fontthreesix-circle] + [metapost={category=fontthreesix,shape=circle,color=random}] +\definefontfeature + [fontthreesix-square] + [metapost={category=fontthreesix,shape=square,color=random}] +\definefontfeature + [fontthreesix-diamond] + [metapost={category=fontthreesix,shape=diamond,color=random}] +\definefontfeature + [fontthreesix-circle-pen] + [metapost={category=fontthreesix,shape=circle,color=random,pen=fancy}] +\definefontfeature + [fontthreesix-square-pen] + [metapost={category=fontthreesix,shape=square,color=random,pen=fancy}] +\definefontfeature + [fontthreesix-diamond-pen] + [metapost={category=fontthreesix,shape=diamond,color=random,pen=fancy}] +\definefontfeature + [fontthreesix-circle-random] + [metapost={category=fontthreesix,random=yes,shape=circle,color=random}] +\definefontfeature + [fontthreesix-square-random] + [metapost={category=fontthreesix,random=yes,shape=square,color=random}] +\definefontfeature + [fontthreesix-diamond-random] + [metapost={category=fontthreesix,random=yes,shape=diamond,color=random}] + +\definefontfeature + [fontthreesix-circle-random-spread] + [metapost={category=fontthreesix,random=yes,shape=circle,color=random,spread=.1}] + +\startplacefigure[reference=threesix:dek] + \startcombination[3*3] + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-circle]D\kern1pt E\kern 1ptK}} {\type{shape=circle}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-square]D\kern1pt E\kern 1ptK}} {\type{shape=square}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-diamond]D\kern1pt E\kern 1ptK}} {\type{shape=diamond}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-circle-pen]D\kern1pt E\kern 1ptK}} {\type{shape=circle,pen=fancy}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-square-pen]D\kern1pt E\kern 1ptK}} {\type{shape=square,pen=fancy}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-diamond-pen]D\kern1pt E\kern 1ptK}} {\type{shape=diamond,pen=fancy}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-circle-random]D\kern1pt E\kern 1ptK}} {\type{shape=circle,random=yes}} + {\scale[width=.3\textwidth]{\definedfont [Serif*fontthreesix-square-random]D\kern1pt E\kern 1ptK}} {\type{shape=square,random=yes}} + {\scale[width=.3\textwidth]{\definedfont[Serif*fontthreesix-diamond-random]D\kern1pt E\kern 1ptK}} {\type{shape=diamond,random=yes}} + \stopcombination +\stopplacefigure + +\startplacefigure[reference=threesix:tex] +\scale[width=\textwidth]{\definedfont[Serif*fontthreesix-diamond-pen]T\lower.5ex\hbox spread .1em{\hss E\hss}X} +\stopplacefigure + +\startplacefigure[reference=threesix:taocp] +\scale[width=\textwidth]{\definedfont[Serif*fontthreesix-circle-random-spread]TAOCP} +\stopplacefigure + +You can quit reading now or expose yourself to how this is coded. We use a +combination of \LUA\ and \METAPOST, but different solutions are possible. The +shapes are entered (or course) with zeros and ones. + +\starttyping +\startluacode +local font36 = { + ["0"] = "00111100 01111110 11000011 11000011 11000011 ...", + ["1"] = "00011100 11111100 11101100 00001100 00001100 ...", + ..... + ["D"] = "11111100 11100010 01100011 01100011 01100011 ...", + ["E"] = "1111111 1110001 0110101 0111100 0110100 0110001 ...", + ..... + ["K"] = "11101110 11100100 01101000 01110000 01111000 ...", + ..... +} +\stopluacode +\stoptyping + +We also use \LUA\ to register this font. The actual code looks slightly different +because it uses some helpers from the \CONTEXT\ \LUA\ libraries. We remap the +bits pattern onto \METAPOST\ macro calls. + +\starttyping +\startluacode +local replace = { + ["0"] = "N;", + ["1"] = "Y;", + [" "] = "L;", +} + +function MP.registerthreesix(name) + fonts.dropins.registerglyphs { + name = name, + units = 12, + usecolor = true, + } + for u, v in table.sortedhash(font36) do + local ny = 8 + local nx = (#v - ny + 1) // ny + local height = ny * 1.1 - 0.1 + local width = nx * 1.1 - 0.1 + local code = string.gsub(v,".",replace) + fonts.dropins.registerglyph { + category = name, + unicode = utf.byte(u), + width = width, + height = height, + code = string.format("ThreeSix(%s);",code), + } + end +end + +MP.registerthreesix("fontthreesix") +\stopluacode +\stoptyping + +So, after this the font \type {fontthreesix} is known to the system but we still +need to provide \METAPOST\ code to generate it. The glyphs themselves are now +just sequences of \type {N}, \type {Y} and \type {L} with some wrapper code +around it. The definitions are put in the \type {MP} namespace simply because a +first version initialized in \METAPOST, and there could create variants, but in +the end I settled on the parameter interface at the \TEX\ end. + +The next definition looks a bit complex but normally such a macro is +stepwise constructed. Notice how we can query the sub features. In order to make +that possible the regular \METAFUN\ parameter handling code is used. We just push +the sub|-|features into to \type {mpsfont} namespace. + +\starttyping +\startMPcalculation{simplefun} + +def InitializeThreeSix = + save Y, N, L, S ; save dx, dy, nx, ny ; save currentpen ; + save shape, fillcolor, mypen, random, spread, hoffset ; + string shape, fillcolor, mypen ; boolean random ; + pen currentpen ; + dx := 11/10 ; + dy := - 11/10 ; + nx := - dx ; + ny := 0 ; + shape := getparameterdefault "mpsfont" "shape" "circle" ; + random := hasoption "mpsfont" "random" "true" ; + fillcolor := getparameterdefault "mpsfont" "color" "" ; + mypen := getparameterdefault "mpsfont" "pen" "" ; + spread := getparameterdefault "mpsfont" "spread" 0 ; + hoffset := 12 * spread / 2 ; + currentpen := pencircle + if mypen = "fancy" : + xscaled 1/20 yscaled 2/20 rotated 45 + else : + scaled 1/20 + fi ; + if shape == "square" : + def S = + unitsquare if random : randomized 1/10 fi + shifted (nx,ny) + enddef ; + elseif shape = "diamond" : + def S = + unitdiamond if random : randomized 1/10 fi + shifted (nx,ny) + enddef ; + else : + def S = + unitcircle if random : randomizedcontrols 1/20 fi + shifted (nx,ny) + enddef ; + fi ; + def N = + nx := nx + dx ; + draw S ; + enddef ; + if fillcolor = "random" : + def Y = + nx := nx + dx ; + fillup S withcolor white randomized (2/3,2/3,2/3) ; + enddef ; + elseif fillcolor = "" : + def Y = + nx := nx + dx ; + fillup S ; + enddef ; + else : + def Y = + nx := nx + dx ; + fillup S withcolor fillcolor ; + enddef ; + fi ; + def L = + nx := - dx ; + ny := ny + dy ; + enddef ; +enddef ; + +vardef ThreeSix (text code) = + InitializeThreeSix ; % todo: once per instance run + draw image (code) shifted (hoffset,-ny) ; +enddef ; + +\stopMPcalculation +\stoptyping + +This code is not that efficient in the sense that there's quite some +\METAPOST|-|\LUA|-|\METAPOST\ traffic going on, for instance each parameter check +involves this, but in practice performance is quite okay, certainly for such a +small font. There will be an initializer option some day soon. The \type +{simplefun} is a reference to an \MPLIB\ instance that does load \METAFUN\ but +only the modules that make no sense for this kind of usage. It also enforces +double mode. The calculations wrapper just executes the code and does not place +some (otherwise empty) graphic. + +% After playing with the font I see the beauty of the descriptions in the +% pre|-|fascicle 9b but I still feel pretty stupid. Lucky for me there are +% exercises like 999, tagged as \quote {for dummies}, so I'm not alone. + +Those who have seen (and|/|or read) \quotation {Concrete Mathematics} will have +noticed the use of inline images, like dice. Dice are also used in \quotation +{pre-fascicle 5a} (I need a few more lives to grasp that, so I stick to the +images for now!). So, to compensate the somewhat complex code above, I will show +how to accomplish that. This time we do all in \METAPOST: + +\startMPcalculation{simplefun} + +def DiceFrame = + pickup pencircle scaled 1/2 ; + draw unitsquare scaled 8 ; + pickup pencircle scaled 3/2 ; +enddef ; + +vardef DiceOne = + DiceFrame ; + draw (4,4) ; +enddef ; +vardef DiceTwoA = + DiceFrame ; + draw (2,6) ; draw (6,2) ; +enddef ; +vardef DiceTwoB = + DiceFrame ; + draw (6,6) ; draw (2,2) ; +enddef ; +vardef DiceTwo = + if hasoption "mpsfont" "option" "reverse" : + DiceTwoB + else : + DiceTwoA + fi ; +enddef ; +vardef DiceThreeA = + DiceFrame ; + draw (2,6) ; draw (4,4) ; draw (6,2) ; +enddef ; +vardef DiceThreeB = + DiceFrame ; + draw (6,6) ; draw (4,4) ; draw (2,2) ; +enddef ; +vardef DiceThree = + if hasoption "mpsfont" "option" "reverse" : + DiceThreeB + else : + DiceThreeA + fi ; +enddef ; +vardef DiceFour = + DiceFrame ; + draw (2,6) ; draw (6,6) ; draw (2,2) ; draw (6,2) ; +enddef ; +vardef DiceFive = + DiceFrame ; + draw (2,6) ; draw (6,6) ; draw (4,4) ; draw (2,2) ; draw (6,2) ; +enddef ; +vardef DiceSix = + DiceFrame ; + draw (2,6) ; draw (6,6) ; draw (2,4) ; draw (6,4) ; draw (2,2) ; draw (6,2) ; +enddef ; + +vardef DiceBad = + pickup pencircle scaled 1/2 ; + draw unitsquare scaled 8 ; + draw (1,7) -- (7,1) ; draw (1,1) -- (7,7) ; +enddef ; + +lmt_registerglyphs [ + name = "dice", + units = 12, + width = 8, + height = 8, + depth = 0, + usecolor = true, +] ; + +lmt_registerglyph [ category = "dice", unicode = "0x2680", code = "DiceOne;" ] ; +lmt_registerglyph [ category = "dice", unicode = "0x2681", code = "DiceTwo;" ] ; +lmt_registerglyph [ category = "dice", unicode = "0x2682", code = "DiceThree;" ] ; +lmt_registerglyph [ category = "dice", unicode = "0x2683", code = "DiceFour;" ] ; +lmt_registerglyph [ category = "dice", unicode = "0x2684", code = "DiceFive;" ] ; +lmt_registerglyph [ category = "dice", unicode = "0x2685", code = "DiceSix;" ] ; + +lmt_registerglyph [ category = "dice", private = "invaliddice", code = "DiceBad;" ] ; + +\stopMPcalculation + +This is not that hard to follow. We define some shapes first. These could have +been assigned to the \type {code} parameter directly but this is nicer. Next we +register the font itself and after that we set glyphs. We also set the official +\UNICODE\ slots. So, copying a dice can either result in a digit or in a +\UNICODE\ slot for a dice. In the example below we switch to a color which +demonstrates that our dice can be colored at the \TEX\ end. It's either that or +coloring at the \METAPOST\ end as both demand a different kind of \TYPETHREE\ +embedding trickery. + +We actually predefine three features. The digits one will map regular digit in +the input to dice. We accomplish that via a font feature: + +\startbuffer +\startluacode +fonts.handlers.otf.addfeature("dice:digits", { + type = "substitution", + order = { "dice:digits" }, + nocheck = true, + data = { + [0x30] = "invaliddice", + [0x31] = 0x2680, + [0x32] = 0x2681, + [0x33] = 0x2682, + [0x34] = 0x2683, + [0x35] = 0x2684, + [0x36] = 0x2685, + [0x37] = "invaliddice", + [0x38] = "invaliddice", + [0x39] = "invaliddice", + }, +} ) +\stopluacode +\stopbuffer + +\typebuffer \getbuffer + +This kind of trickery is part of the font machinery used in \CONTEXT\ and permits +runtime adaption of fonts, so we just use the same mechanism. The \type {nocheck} +is needed to avoid this feature not kicking in due to lack of (at the time of +checking) yet undefined dice. + +\startbuffer +\definefontfeature + [dice:normal] + [default] + [metapost={category=dice}] +\definefontfeature + [dice:reverse] + [default] + [metapost={category=dice,option=reverse}] +\definefontfeature + [dice:digits] + [dice:digits=yes] + +\definefont[DiceN] [Serif*dice:normal] +\definefont[DiceD] [Serif*dice:normal,dice:digits] +\definefont[DiceR] [Serif*dice:reverse,dice:digits] + +{\DiceD Does 1 it 4 work? And {\darkgreen 3} too?} {\DiceR And how about +{\darkred 3} then? But 8 should sort of fail!} +\stopbuffer + +\typebuffer \getbuffer + +The six digits and \UNICODE\ characters come out the same: + +\startbuffer +\red \DiceD \dostepwiserecurse {`1} {`6}{1}{\char#1\quad}% +\blue \DiceN \dostepwiserecurse{"2680}{"2685}{1}{\char#1\quad}% +\stopbuffer + +\typebuffer + +\startlinecorrection + \scale[width=\textwidth]{\getbuffer\unskip} +\stoplinecorrection + +It is tempting to implement for instance~7 as two dice (a one to multi mapping in +\OPENTYPE\ speak) but then one has to decide what combination is taken. One can +also implement ligatures so that for instance 12 results in two six dice. But I +think that's over the top and only showing \TEX\ muscles. It is anyway not that +hard to do as we have an interface for that already. + +So why not do the dominos as well? Because there are so many dominos we predefine +the shapes and then register the lot in a loop. We have horizontal and vertical +variants. Being lazy I just made two helpers while one could have done but with +some rotation and shifting of the horizontal one. The loop could be a macro but +we don't save much code that way. + +\startbuffer +\startMPcalculation{simplefun} + +picture Dominos[] ; + +Dominos[0] := image() ; +Dominos[1] := image(draw(4,4);) ; +Dominos[2] := image(draw(2,6);draw(6,2);); +Dominos[3] := image(draw(2,6);draw(4,4);draw(6,2);); +Dominos[4] := image(draw(2,6);draw(6,6);draw(2,2);draw(6,2);); +Dominos[5] := image(draw(2,6);draw(6,6);draw(4,4);draw(2,2);draw(6,2);); +Dominos[6] := image(draw(2,6);draw(4,6);draw(6,6);draw(2,2);draw(4,2);draw(6,2);); + +lmt_registerglyphs [ + name = "dominos", + units = 12, + width = 16, + height = 8, + depth = 0, + usecolor = true, +] ; + +def DrawDominoH(expr a, b) = + draw image ( + pickup pencircle scaled 1/2 ; + if (getparameterdefault "mpsfont" "color" "") = "black" : + fillup unitsquare xyscaled (16,8) ; + draw (8,.5) -- (8,7.5) withcolor white ; + pickup pencircle scaled 3/2 ; + draw Dominos[a] + withpen currentpen + withcolor white ; + draw Dominos[b] shifted (8,0) + withpen currentpen + withcolor white ; + else : + draw unitsquare xyscaled (16,8) ; + draw (8,0) -- (8,8) ; + pickup pencircle scaled 3/2 ; + draw Dominos[a] + withpen currentpen ; + draw Dominos[b] shifted (8,0) + withpen currentpen ; + fi ; + ) ; +enddef ; + +def DrawDominoV(expr a, b) = % is H rotated and shifted + draw image ( + pickup pencircle scaled 1/2 ; + if (getparameterdefault "mpsfont" "color" "") = "black" : + fillup unitsquare xyscaled (8,16) ; + draw (.5,8) -- (7.5,8) withcolor white ; + pickup pencircle scaled 3/2 ; + draw Dominos[a] rotatedaround(center Dominos[a],90) + withpen currentpen + withcolor white ; + draw Dominos[b] rotatedaround(center Dominos[b],90) shifted (0,8) + withpen currentpen + withcolor white ; + else : + draw unitsquare xyscaled (8,16) ; + draw (0,8) -- (8,8) ; + pickup pencircle scaled 3/2 ; + draw Dominos[a] rotatedaround(center Dominos[a],90) + withpen currentpen ; + draw Dominos[b] rotatedaround(center Dominos[b],90) shifted (0,8) + withpen currentpen ; + fi ; + ) ; +enddef ; + +begingroup + save unicode ; numeric unicode ; unicode := 127025 ; % 1F031 + + for i=0 upto 6 : + for j=0 upto 6 : + lmt_registerglyph [ + category = "dominos", + unicode = unicode, + code = "DrawDominoH(" & decimal i & "," & decimal j & ");", + width = 16, + height = 8, + ] ; + unicode := unicode + 1 ; + endfor ; + endfor ; + + save unicode ; numeric unicode ; unicode := 127075 ; + + for i=0 upto 6 : + for j=0 upto 6 : + lmt_registerglyph [ + category = "dominos", + unicode = unicode, + code = "DrawDominoV(" & decimal i & "," & decimal j & ");", + width = 8, + height = 16, + ] ; + unicode := unicode + 1 ; + endfor ; + endfor ; +endgroup ; + +\stopMPcalculation +\stopbuffer + +\typebuffer \getbuffer + +Again we predefine a couple of features: + +\startbuffer +\definefontfeature + [dominos:white] + [default] + [metapost={category=dominos}] + +\definefontfeature + [dominos:black] + [default] + [metapost={category=dominos,color=black}] + +\definefontfeature + [dominos:digits] + [dominos:digits=yes] +\stopbuffer + +\typebuffer \getbuffer + +This last feature is yet to be defined. We could deal with the invalid dominos +with some substitution trickery but let's keep it simple. + +\startbuffer +\startluacode +local ligatures = { } +local unicode = 127025 + +for i=0x30,0x36 do + for j=0x30,0x36 do + ligatures[unicode] = { i, j } + unicode = unicode + 1 ; + end +end + +fonts.handlers.otf.addfeature("dominos:digits", { + type = "ligature", + order = { "dominos:digits" }, + nocheck = true, + data = ligatures, +} ) +\stopluacode +\stopbuffer + +\typebuffer \getbuffer + +That leaves showing an example. We define a few fonts and again we just extend +the Serif: + +\startbuffer +\definefont[DominoW][Serif*dominos:white] +\definefont[DominoB][Serif*dominos:black] +\definefont[DominoD][Serif*dominos:white,dominos:digits] +\stopbuffer + +\typebuffer \getbuffer + +The example is: + +\startbuffer +\DominoW + \char"1F043\quad 🀱\quad + \char"1F052\quad 🀲\quad + \char"1F038\quad 🀳\quad + \darkgreen\char"1F049\quad \char"1F07B\quad +\DominoB + \char"1F087\quad + \char"1F088\quad + \char"1F089\quad +\DominoD + \darkred 12\quad56\quad64 +\stopbuffer + +\typebuffer + +Watch the ligatures in action: + +\startlinecorrection + \scale[width=\textwidth]{\getbuffer\unskip} +\stoplinecorrection + +To what extent the usage of symbols like dice and dominos as characters in the +mentioned book are responsible for them being in \UNICODE, I don't know. Now with +all these emoji showing up one can wonder about graphics in such a standard +anyway. But for sure, even after more than three decades, Don still makes nice +fonts. + +A treasure of tiny graphics can be found in \quotation {pre-fascicle 5c} and many +are in color! In fact, it has dominos too. It must have been a lot of fun writing +this! I'm thinking of turning the pentominoes into a font where a \type {GPOS} +feature can deal with the inter|-|pentomino kerning (which mighty work out okay +for example~36. The windmill dominos also make a nice example for a font where +ligatures will boil down to the base form and the (one or more) blades are laid +over. It's definitely an inspiring read. + +\stopchapter + +\stoptext diff --git a/doc/context/sources/general/manuals/evenmore/evenmore.tex b/doc/context/sources/general/manuals/evenmore/evenmore.tex index 9a5052e26..a23fe7af4 100644 --- a/doc/context/sources/general/manuals/evenmore/evenmore.tex +++ b/doc/context/sources/general/manuals/evenmore/evenmore.tex @@ -11,27 +11,12 @@ \stopfrontmatter \startbodymatter - \component evenmore-introduction - - % \component evenmore-pi - \startchapter[title={\TEX\ and Pi}] - First in TUGboat. - \stopchapter - - % \component evenmore-fonts - \startchapter[title={Modern Type 3 fonts}] - First in TUGboat. - \stopchapter - - % \component evenmore-threesix - \startchapter[title={ThreeSix, Don Knuths first colorfont?}] - After the his new book comes out. - \stopchapter - + \component evenmore-pi + \component evenmore-fonts + \component evenmore-threesix \component evenmore-normalization \component evenmore-expansion - \stopbodymatter \stopdocument diff --git a/doc/context/sources/general/manuals/evenmore/mozilla-svg-001.svg b/doc/context/sources/general/manuals/evenmore/mozilla-svg-001.svg new file mode 100644 index 000000000..5e46d8467 --- /dev/null +++ b/doc/context/sources/general/manuals/evenmore/mozilla-svg-001.svg @@ -0,0 +1,72 @@ +<svg xmlns="http://www.w3.org/2000/svg"> + <path fill="#d87512" d="M17.786 44.63c-.606.115-1.23.173-1.854.173-2.444 0-4.644-.864-6.04-2.375-.855-.92-1.394-2.147-1.517-3.47-.126-1.243.067-2.638.58-4.163.325-1.016.83-2.01 1.365-3.064.216-.426.437-.858.65-1.302.702-1.454 1.504-3.164 2.11-5.05.715-2.188.943-4.287.682-6.23-.267-2.102-.994-3.972-1.74-5.685a2.992 2.992 0 0 0-4.15-1.446c-.71.375-1.23 1-1.467 1.77a2.983 2.983 0 0 0 .218 2.292c.632 1.19 1.314 2.596 1.592 3.977.238 1.137.18 2.41-.184 3.897-.37 1.538-.976 3.143-1.522 4.518-.16.406-.33.816-.507 1.234-.507 1.215-1.032 2.47-1.364 3.838-.55 2.14-.666 4.152-.348 5.97.36 2.163 1.41 4.14 2.955 5.567 2.027 1.88 4.808 2.914 7.826 2.914 1.14 0 2.274-.146 3.375-.437l-.66-2.923"/> + <g fill="#bc600d"> + <path d="M11.585 43.742s.387 1.248.104 3.05c0 0 2.045-.466 1.898-2.27 0 0-.815-.29-2-.78M9.19 41.484S8.98 42.94 7.93 44.43c0 0 2.103.42 2.774-1.265 0 0-.696-.66-1.515-1.68M8.398 37.21s-.926 1.432-3.23 2.322c0 0 1.514 2.303 3.53.904 0 0-.237-1.388-.3-3.226M12.964 15.833s-1.685.798-3.783 3.45c0 0 2.1 1.55 4.663 2.228 0 0 .285-3.093-.88-5.677M13.5 23.873s-2.988.544-5.57 2.794c0 0 1.615 1.708 3.583 2.62 0 0 1.678-3.39 1.987-5.414M10.32 31.73s-1.483 0-4.483.812c0 0-.01 2.873 2.94 2.823 0 0 .747-1.75 1.544-3.635"/> + </g> + <g fill="#d87512"> + <path d="M53.33 39.37c0-4.484-35.622-4.484-35.622 0 0 10.16.05 10.25 17.81 10.25 17.762 0 17.812-.09 17.812-10.25"/> + <path d="M42.645 56.04c1.688 2.02 9.275.043 10.504-2.28 5.01-9.482-.006-13.58-.006-13.58l-10.5 1.313s-2.154 11.977 0 14.547"/> + </g> + <g fill="#bc600d"> + <path d="M54.2 41.496s-.336 4.246-4.657 9.573c0 0 4.38-1.7 5.808-4.3 0 0 .448-3.02-1.15-5.274M55.08 48.69s-1.065 1.88-3.563 3.872c0 0 1.78-.03 2.576-.785 0 0 .77-1.41.987-3.086"/> + </g> + <path fill="#f29a2e" d="M35.484 60.38c1.87 2.23 8.547 2.09 10.574 0 2.904-2.995 2.78-16.656 2.904-23.314l-12.418-1.053s-3.444 21.52-1.06 24.367"/> + <g fill="#bc600d"> + <path d="M48.21 53.53s-3.578-3.443-8.738-.013c0 0 5.754 2.455 7.365 5.672 0 0 1.126-2.245 1.373-5.66M48.775 46.06s-3.852-3.09-7.938 1.43c0 0 4.452-.47 7.632 3.635 0 0 .493-3.05.305-5.065"/> + </g> + <g fill="#3e4347"> + <path d="M43.847 61.57l-.397-2.765 1.344 2.445zM40.41 61.996l.502-3.294.498 3.294zM36.713 61.3l1.317-2.26-.372 2.59z"/> + </g> + <path fill="#d87512" d="M28.388 56.04c-1.688 2.02-9.277.043-10.504-2.28-5.01-9.482.004-13.58.004-13.58l10.5 1.313s2.154 11.977 0 14.547"/> + <g fill="#bc600d"> + <path d="M16.833 41.496s.336 4.246 4.657 9.573c0 0-4.38-1.7-5.807-4.3 0 0-.448-3.02 1.15-5.274M15.957 48.69s1.066 1.88 3.563 3.872c0 0-1.782-.03-2.576-.785 0 0-.772-1.41-.987-3.086"/> + </g> + <path fill="#f29a2e" d="M35.548 60.38c-1.87 2.23-8.548 2.09-10.575 0-2.904-2.995-2.78-16.656-2.904-23.314l12.417-1.053s3.446 21.52 1.06 24.367"/> + <g fill="#bc600d"> + <path d="M22.822 53.53s3.58-3.443 8.74-.013c0 0-5.754 2.455-7.367 5.672 0 0-1.125-2.245-1.373-5.66M22.255 46.06s3.852-3.09 7.94 1.43c0 0-4.453-.47-7.633 3.635 0 0-.493-3.05-.307-5.065"/> + </g> + <g fill="#3e4347"> + <path d="M26.24 61.25l1.345-2.445-.395 2.765zM29.62 61.996l.5-3.294.5 3.294zM33.375 61.63L33 59.04l1.32 2.26zM35.516 60.46c-.395-2.48-.482-4.96-.5-7.438.015-2.48.104-4.96.5-7.44.396 2.48.485 4.96.5 7.44-.018 2.48-.106 4.96-.5 7.438"/> + </g> + <path fill="#f29a2e" d="M27.777 6.994c0 3.82-2.727 6.987-6.086 6.915C11.83 13.7 15.893 2 15.893 2c3.36 0 11.885 1.176 11.885 4.994"/> + <path fill="#af5a31" d="M24.05 7.752c0 2.037-1.454 3.727-3.248 3.688-5.26-.11-3.093-6.353-3.093-6.353 1.792 0 6.34.628 6.34 2.665"/> + <path fill="#f29a2e" d="M43.26 6.994c0 3.82 2.726 6.987 6.086 6.915 9.86-.21 5.8-11.91 5.8-11.91C51.782 2 43.26 3.176 43.26 6.994"/> + <path fill="#af5a31" d="M46.983 7.752c0 2.037 1.455 3.727 3.247 3.688 5.26-.11 3.094-6.353 3.094-6.353-1.794 0-6.34.628-6.34 2.665"/> + <path fill="#f29a2e" d="M55.806 33.378c0 7.155-9.517 8.13-20.288 8.13-10.776 0-20.29-.975-20.29-8.13 0-29.96 11.596-29.14 20.29-29.14 8.69 0 20.288-.82 20.288 29.14"/> + <g fill="#3e4347"> + <path d="M35.54 7.59c3.24 0 6.15 1.084 8.156 2.81-.77-2.945-4.135-5.16-8.173-5.16-4.06 0-7.442 2.238-8.186 5.204 2.01-1.753 4.938-2.855 8.204-2.855"/> + <path d="M35.535 11.193c2.217 0 4.21.744 5.584 1.925-.528-2.02-2.835-3.534-5.6-3.534-2.78 0-5.095 1.533-5.605 3.564 1.376-1.198 3.383-1.955 5.62-1.955"/> + </g> + <path fill="#ffe8bb" d="M29.553 43.727l-18.408-7.01 4.24-9.06s2.704 3.85 13.29 6.82l.878 9.243"/> + <path fill="#3e4347" d="M29.37 39.77c-7.462-1.27-16.325-6.673-16.48-6.75l.992-2.168c.184.092 8.806 5.342 15.853 6.544l-.366 2.374"/> + <path fill="#ffe8bb" d="M41.48 43.727l18.406-7.01-4.24-9.06s-2.704 3.85-13.29 6.82l-.876 9.243"/> + <path fill="#3e4347" d="M41.663 39.77c7.46-1.27 16.325-6.673 16.48-6.75l-.993-2.168c-.184.092-8.808 5.342-15.852 6.544l.365 2.374"/> + <g fill="#ffe8bb"> + <path d="M43.524 45.57C38.752 42.023 41.4 33.86 41.4 33.86c-5.657 5.906-12.662 8.74-12.662 8.74 1.608 5.446 5.77 6.412 5.77 6.412-.34-1.835.663-3.302.663-3.302 1.68 2.22 5.03 2.986 5.03 2.986-1.287-1.508-.948-3.835-.948-3.835 2.326.875 4.27.71 4.27.71"/> + <path d="M42.29 42.97c-2.634 2.247-10.917 2.247-13.553 0-2.856-2.435-2.495-7.144.1-9.884 2.397-2.527 10.958-2.527 13.355 0 2.595 2.74 2.956 7.45.098 9.883"/> + </g> + <g fill="#3e4347"> + <path d="M36.18 40.48a.69.69 0 0 1-.644-.477c-.227-.67-.77-3.293-.71-5.498.01-.398.325-.71.7-.698.38.01.674.343.663.74-.057 2.01.46 4.466.633 4.974.127.375-.06.786-.414.92a.607.607 0 0 1-.23.04"/> + <path d="M30.504 43.25c.21-.202.394-.408.582-.61.188-.204.378-.405.57-.604.385-.396.782-.78 1.2-1.145a14.125 14.125 0 0 1 2.745-1.9c.504-.263 1.032-.49 1.59-.654s1.153-.273 1.772-.253c.31.01.623.055.928.146.307.088.602.23.86.416.263.19.485.422.652.684.17.257.287.54.35.83a4.247 4.247 0 0 0-.677-.448 2.567 2.567 0 0 0-.68-.237c-.447-.088-.887-.04-1.33.06-.89.216-1.786.65-2.69 1.114-.905.466-1.818.983-2.776 1.466-.48.24-.97.473-1.48.682-.256.103-.517.202-.783.285-.27.078-.546.155-.833.167"/> + </g> + <path fill="#f15a61" d="M41.34 31.743c-1.17-.528-4.757-.57-5.83-.57-1.07 0-4.66.042-5.83.57-.832.376-.187 1.31 2.027 2.116 1.397.506 2.733.666 3.803.666 1.07 0 2.405-.16 3.805-.667 2.213-.808 2.856-1.74 2.025-2.117"/> + <g fill="#3e4347"> + <path d="M29.917 23.48l1.61 5.292L26.954 26z"/> + <path d="M22.645 31.828c-.522 0-.932-.056-1.17-.098-2.986-.52-4.632-1.996-6.09-4.067l.185-2.472c1.52 1.446 3.953 3.76 6.28 4.167 1.156.2 2.853-.016 4.15-1.234 1.537-1.44 2.263-4.05 2.1-7.547l1.635.132c.2 4.312-.116 7.244-2.212 9.212-1.692 1.59-3.613 1.908-4.878 1.908M41.12 23.48l-1.613 5.292L44.08 26z"/> + <path d="M48.39 31.828c.52 0 .93-.056 1.167-.098 2.99-.52 4.637-1.996 6.09-4.067l-.182-2.472c-1.52 1.446-3.955 3.76-6.28 4.167-1.156.2-2.855-.016-4.154-1.234-1.532-1.44-2.258-4.05-2.095-7.547l-1.636.132c-.202 4.312.114 7.244 2.213 9.212 1.69 1.59 3.61 1.908 4.877 1.908"/> + </g> + <path fill="#ffe8bb" d="M30.25 22.09c-.852 5.282-3.728 5.87-6.696 5.577-2.986-.294-5.396-2.667-5.396-6.743 0-4.28 0-4.28 6.647-5.752 6.728-1.49 6 3.437 5.445 6.918"/> + <path fill="#3e4347" d="M29.16 22.547c-.244 2.534-2.61 4.357-5.287 4.072-2.674-.286-4.645-2.57-4.402-5.102s.28-2.75 5.108-2.237c4.83.514 4.824.737 4.582 3.267"/> + <path fill="#fff" d="M27.59 21.884c-.16 1.688-1.74 2.903-3.522 2.714-1.785-.19-3.096-1.712-2.936-3.4.163-1.69.186-1.835 3.406-1.493 3.22.344 3.215.49 3.053 2.18"/> + <g fill="#3e4347"> + <ellipse cx="25.5" cy="21.08" rx="1.45" ry="1.647"/> + <path d="M31.27 17.896c.42 0 .807-.284.936-.728.16-.546-.133-1.122-.65-1.29l-5.98-1.924c-.516-.166-1.065.14-1.225.685-.155.543.136 1.12.652 1.287l5.98 1.924a.95.95 0 0 0 .288.046"/> + </g> + <path fill="#ffe8bb" d="M40.78 22.09c.855 5.282 3.73 5.87 6.7 5.577 2.984-.294 5.395-2.667 5.395-6.743 0-4.28-.002-4.28-6.646-5.752-6.73-1.49-6.01 3.437-5.45 6.918"/> + <path fill="#3e4347" d="M41.873 22.547c.243 2.534 2.61 4.357 5.287 4.072 2.674-.286 4.646-2.57 4.402-5.102-.242-2.533-.28-2.75-5.107-2.237-4.83.514-4.824.737-4.582 3.267"/> + <path fill="#fff" d="M43.44 21.884c.16 1.688 1.737 2.903 3.522 2.714 1.783-.19 3.098-1.712 2.936-3.4-.16-1.69-.188-1.835-3.404-1.493-3.22.344-3.217.49-3.054 2.18"/> + <g fill="#3e4347"> + <ellipse cx="47.722" cy="20.932" rx="1.45" ry="1.647"/> + <path d="M39.76 17.896a.982.982 0 0 1-.935-.728c-.16-.546.132-1.122.65-1.29l5.98-1.924c.517-.166 1.063.14 1.224.685.155.543-.136 1.12-.653 1.287l-5.98 1.924a.96.96 0 0 1-.287.046"/> + </g> +</svg> diff --git a/doc/context/sources/general/manuals/luametatex/luametatex-introduction.tex b/doc/context/sources/general/manuals/luametatex/luametatex-introduction.tex index 24dd5c65a..56d5c7436 100644 --- a/doc/context/sources/general/manuals/luametatex/luametatex-introduction.tex +++ b/doc/context/sources/general/manuals/luametatex/luametatex-introduction.tex @@ -8,12 +8,13 @@ Around 2005 we started the \LUATEX\ projects and it took about a decade to reach a state where we could consider the experiments to have reached a stable state. -Already for a while one could use \LUATEX\ in production but some of the -interfaces evolved. In 2018 the functionality was more or less frozen. Of course -we might add some features in due time but nothing fundamental will change as we -consider version 1.10 to be reasonable feature complete. Among the reasons is -that this engine is now used outside \CONTEXT\ too which means that we cannot -simply change much without affecting other macro packages. +Pretty soon \LUATEX\ could be used in production, even if some of the interfaces +evolved, but \CONTEXT\ was kept in sync so that was not really a problem. In 2018 +the functionality was more or less frozen. Of course we might add some features +in due time but nothing fundamental will change as we consider version 1.10 to be +reasonable feature complete. Among the reasons is that this engine is now used +outside \CONTEXT\ too which means that we cannot simply change much without +affecting other macro packages. However, in reaching that state some decisions were delayed because they didn't go well with a current stable version. This is why at the 2018 \CONTEXT\ meeting @@ -21,7 +22,7 @@ those present agreed that we could move on with a follow up tagged \METATEX, a name we already had in mind for a while, but as \LUA\ is an important component, it got expanded to \LUAMETATEX. This follow up is a lightweight companion to \LUATEX\ that will be maintained alongside. More about the reasons for this -follow up as well as the philosophy behind it can be found on the document(s) +follow up as well as the philosophy behind it can be found in the document(s) describing the development. During \LUATEX\ development I kept track of what happened in a series of documents, parts of which were published as articles in user group journals, but all are in the \CONTEXT\ distribution. I did the same @@ -42,19 +43,19 @@ consequences for the interface at the system level. This manual currently has quite a bit of overlap with the \LUATEX\ manual but some chapters are removed, others added and the rest has been (and will be -further) adapted. We also discusses the (main) differences. Some of the new +further) adapted. It also discusses the (main) differences. Some of the new primitives or functions that show up in \LUAMETATEX\ might show up in \LUATEX\ at some point, others might not, so don't take this manual as reference for \LUATEX ! For now it is an experimental engine in which we can change things at will but with \CONTEXT\ in tandem so that this macro package will keep working. -For \CONTEXT\ users the \LUAMETATEX\ engine will become the default. Because we -can keep both \LUAMETATEX\ and \CONTEXT\ in sync. The \CONTEXT\ variant is tagged -\LMTX. The pair can be used in production, just as with \LUATEX\ and \MKIV. In -fact, most users will probably not really notice the difference. In some cases -there will be a drop in performance, due to more work being delegated to \LUA, -but on the average performance will be better, also due to some changes below the -hood of the engine. +For \CONTEXT\ users the \LUAMETATEX\ engine will become the default. The +\CONTEXT\ variant for this engine is tagged \LMTX. The pair can be used in +production, just as with \LUATEX\ and \MKIV. In fact, most users will probably +not really notice the difference. In some cases there will be a drop in +performance, due to more work being delegated to \LUA, but on the average +performance will be better, also due to some changes below the hood of the +engine. As this follow up is closely related to \CONTEXT\ development, and because we expect stock \LUATEX\ to be used outside the \CONTEXT\ proper, there will be no @@ -107,6 +108,14 @@ Braslau, who love playing with the three languages involved. Testing is done by \LUATEX, these will be applied in the experimental branch first, so that there is no interference with the stable release. +{\bf remark:} Most \CONTEXT\ users seem always willing to keep up with the latest +versions which means that \LMTX\ is tested well. We can therefore safely claim +that end of 2019 the code has become quite stable. There are no complaints about +performance (on my laptop this manual compiles at 22.5 pps with \LMTX\ versus +20.7 pps for the \LUATEX\ manual with \MKIV). Probably no one notices it, but +memory consumption stepwise got reduced too. And \unknown\ the binary is still +below 3~MegaBytes on all platforms. + \stopchapter \stopcomponent @@ -127,4 +136,6 @@ no interference with the stable release. % the sake of showing that there's still some progress. So I decided to bump to % 2.01.0 then. Just as a reminder for myself: it was the day when I watched % Jacob Collier perform Lua (feat. MARO) live on YouTube (of course that is not -% about the language at all, but still a nice coincidence). +% about the language at all, but still a nice coincidence). Just for the fun of +% it the number bumped a few more times, just to catch up, so end 2019 we're at +% 2.03.5. diff --git a/doc/context/sources/general/manuals/luametatex/luametatex-logos.tex b/doc/context/sources/general/manuals/luametatex/luametatex-logos.tex deleted file mode 100644 index be75971d8..000000000 --- a/doc/context/sources/general/manuals/luametatex/luametatex-logos.tex +++ /dev/null @@ -1,21 +0,0 @@ -\startenvironment luametatex-logos - -\usemodule[abr-02] - -\logo[DFONT] {dfont} -\logo[CFF] {cff} -\logo[CMAP] {CMap} -\logo[PATGEN] {patgen} -\logo[MP] {MetaPost} -\logo[METAPOST] {MetaPost} -\logo[MPLIB] {MPlib} -\logo[COCO] {coco} -\logo[SUNOS] {SunOS} -\logo[BSD] {bsd} -\logo[SYSV] {sysv} -\logo[DPI] {dpi} -\logo[DLL] {dll} -\logo[OPENOFFICE]{OpenOffice} -\logo[OCP] {OCP} - -\stopenvironment diff --git a/doc/context/sources/general/manuals/luametatex/luametatex-style.tex b/doc/context/sources/general/manuals/luametatex/luametatex-style.tex index 88fbb4d90..3f4b0ad21 100644 --- a/doc/context/sources/general/manuals/luametatex/luametatex-style.tex +++ b/doc/context/sources/general/manuals/luametatex/luametatex-style.tex @@ -419,7 +419,7 @@ \dontcomplain -\environment luametatex-logos +\usemodule[abbreviations-mixed] \defineregister[topicindex] \defineregister[primitiveindex] diff --git a/doc/context/sources/general/manuals/luametatex/luametatex.tex b/doc/context/sources/general/manuals/luametatex/luametatex.tex deleted file mode 100644 index a0bc823bc..000000000 --- a/doc/context/sources/general/manuals/luametatex/luametatex.tex +++ /dev/null @@ -1,51 +0,0 @@ -% language=uk - -\environment luametatex-style -\environment luametatex-private - -\startdocument - [manual=LuaMeta\TeX, - status=experimental, - version=2.02] - -\component luametatex-titlepage -\component luametatex-firstpage - -\startfrontmatter - % \component luametatex-contents - \component luametatex-introduction -\stopfrontmatter - -\startbodymatter - - \startparagraph \em - This is a placeholder for the \LUAMETATEX\ manual. On my system I already - have most of it wrapped up, but it will probably take till late 2019 or - sometime 2020 before I will decide to add the whole manual to the - \CONTEXT\ distribution. - \stopparagraph - - % \component luametatex-preamble - % \component luametatex-differences - % \component luametatex-modifications - % \component luametatex-lua - % \component luametatex-enhancements - % \component luametatex-fonts - % \component luametatex-math - % \component luametatex-nodes - % \component luametatex-callbacks - % \component luametatex-tex - % \component luametatex-metapost - % \component luametatex-pdf - % \component luametatex-libraries - % \component luametatex-additions - % \component luametatex-primitives - -\stopbodymatter - -\startbackmatter -% \component luametatex-registers -% \component luametatex-statistics -\stopbackmatter - -\stopdocument diff --git a/doc/context/sources/general/manuals/luatex/luatex.tex b/doc/context/sources/general/manuals/luatex/luatex.tex index 0230af738..5a98f2243 100644 --- a/doc/context/sources/general/manuals/luatex/luatex.tex +++ b/doc/context/sources/general/manuals/luatex/luatex.tex @@ -44,6 +44,9 @@ % after adding primitives: context mult-prm.mkiv +% \enabledirectives[pdf.stripzeros] +% \enabledirectives[metapost.stripzeros] + \environment luatex-style \startmode[book] |
