The Communications of the TEX Users Group Volume 30 ... - TUG

More documents

Recommendations

Info

$E-m: Guidelines for Future TEX Extensions - TUG$

$TUG 2001: A TEX Odyssey PROGRAM$

$LATEX Sophisticated professional typesetting for business and ...$

$TEX and Scripting Languages - TUG$

$Geometric Diversions with TEX, METAFONT and METAPOST - TUG$

$Writing Gregg Shorthand with mEtaFoNt and LATEX - TUG$

$Generating LaTeX documents through Matlab - TUG$

186 TUGboat, Volume 30 (2009), No. 2 23 Fonts: future At this moment MkIV is already quite capable of dealing with OpenType fonts. The driving force behind this is the Oriental TEX project which brings along some very complex and feature rich Arabic font technology. Much time has gone into reverse engineering the specification and behaviour of how these fonts behave in Uniscribe (which we use as our reference for Arabic). Dealing with the huge CJK fonts is less a font issue and more a matter of node list processing. Around the annual meeting of the Korean User Groupwegotmuchofthemachineryworking, thanks to discussions on the spot and on the mailing list. 24 Math: future Between LuaTEX versions 0.30 and 0.40 the math machinery was opened up (stage one). In order to test this new functionality, MkIV’s math subsystem (that was then already partially Unicode aware) had to be adapted. First of all Unicode permits us to use only one math family and so MkIV now does that. The implementation uses Microsoft’s Cambria Math font as a benchmark. It creates virtual fonts from the other (old and new) math fonts so they appear to match up to Cambria Math. Because the TEX Gyre math project is not yet up to speed MkIV currently uses virtual variants of these fonts that are created at run time. The missing pieces in for instance Latin Modern and friends are compensated for by means of virtual characters. Because it is now possible to parse the intermediate noad lists MkIV can do some manipulations before the formula is typeset. This is for instance Hans Hagen used for alphabet remapping, forcing sizes, and spacing around punctuation. Although MkIV already supports most of the math that users expect there is still room for improvement once there is even more control over the machinery. This is possible because MkIV is not bound to downward compatibility. As with all other LuaTEX related MkIV code, it is expected that we will have to rewrite most of the current code a few times as we proceed, so MkIV math support is not yet stable either. We can take such drastic measures because MkIV is still experimental and because users are willing to do frequent synchronous updating of macros and engine. In the process we hope to get away from all ad-hoc boxing and kerning and whatever solutions for creating constructs, by using the new accent, delimiter, and radical primitives. 25 Tracing and testing Whenever possible we add tracing and visualization features to ConTEXt because the progress reports and articles need them. Recent extensions concerned tracing math and tracing OpenType processing. The OpenType tracing options are a great help in stepwise reaching the goals of the Oriental TEX project. This project gave the LuaTEX project its initial boost and aims at high quality right-to-left typesetting. In the process complex (test) fonts are made which, combined with the tracing mentioned, help us to reveal the secrets of OpenType. ⋄ Hans Hagen Pragma ADE The Netherlands http://luatex.org
TUGboat, Volume 30 (2009), No. 2 187 LuaTEX and ConTEXt: Where we stand Hans Hagen Abstract We consider the release of LuaTEX 0.50 to be a very important one, both for LuaTEX and for MkIV, so here I will reflect on the state around this release. I will do this from the perspective of processing documents because usability is an important measure. 1 Where do we stand? There are several reasons why LuaTEX 0.50 is an important release, both for LuaTEX and for MkIV. Let’s start with LuaTEX. • Apart from a couple of bug fixes, the current version is pretty usable and stable. Details of what we’ve reached so far have been presented previously. • The code base has been converted from Pascal to C code, and as a result the source tree has become simpler (being CWEB compliant happens around 0.60). This transition also opens up the possibility to start looking into some of the more tricky internals, like page building. • Most of the front end has been opened up and the new backend code is getting into shape. As the backend was partly already done in C code the moment has come to do a real cleanup. Keep in mind that we started with pdfTEX and that much of its extra functionality is rather interwoven with traditional TEX code. If we look at ConTEXt, we’ve also reached a crucial point in the upgrade. • The code base is now divided into MkII and MkIV. This permits us not only to reimplement bits and pieces (something that was already in progress) but also to clean up the code (only MkIV). • If you kept up with the development you already know the kind of tasks we can (and do) delegate to Lua. Just to mention a few: file handling, font loading and OpenType processing, casing and some spacing issues, everything related to graphics and MetaPost, language support, color and other attributes, input regimes, XML, multipass data, etc. • Recently all backend related code was moved to Lua and the code dealing with hyperlinks, widgets and alike is now mostly moved away from TEX. The related cleanup was possible because we no longer have to deal with a mix of DVI drivers too. • Everything related to structure (which includes numbering and multi-pass data like tables of contents and registers) is now delegated to Lua. We move around way more information and will extend these mechanisms in the near future. 2 Performance testing Tracing on Taco’s machine has shown that when processing the LuaTEX reference manual the engine spends about 10% of the time on getting tokens, 15% on macro expansion, and some 50% on Lua (callback interfacing included). Especially the time spent by Lua differs per document and garbage collections seems to be a bottleneck here. So, let’s wrap up how LuaTEX performs around the time of 0.50. We use three documents for testing (intermediate) LuaTEX binaries: the reference manual, the history document ‘mk’, and the revised Metafun manual. The reference manual has a MetaPost graphic on each page which is positioned using the ConTEXt background layering mechanism. This mechanism is active only when backgrounds are defined and has some performance consequences for the page builder. However, most time is spent on constructing the tables (tabulate) and because these can contain paragraphs thatcan run over multiple pages, constructing atabletakesafewanalysispassespertableplussome so-called vsplitting. We load some fonts (including narrow variants) but for the rest this document is not that complex. Of course colors are used as well as hyperlinks. The report at the end of these runs is shown in figure 1. The runtime is influenced by the fact that some startup time and font loading takes place. The more pages your document has, the less the runtime is influenced by this. More demanding is the ‘mk’ document (figure 2). Here we have many fonts, including some really huge CJK and Arabic ones (and these are loaded at several sizes and with different features). The reported font load time is large but this is partly due to the fact that on my machine for some reason passing the tables to TEX involved a lot of pagefaults (we think that the cpu cache is the culprit). Older versions of LuaTEX didn’t have that performance penalty, so probably half of the reported font loading time is kind of wasted. The hnode processing time refers mostly to OpenType font processing and attribute processing time has to do with backend issues (like injecting color directives). The more features you enable, the larger these numbers get. The MetaPost font loading refers to the punk font instances. LuaTEX and ConTEXt: Where we stand
Page 1 and 2: The Communications of the TEX Users
Page 3 and 4: 2009 Conference Proceedings TEX Use
Page 5 and 6: Tuesday July 28 TUG2009program 8:30
Page 7 and 8: TUGboat, Volume 30 (2009), No. 2 15
Page 35: TUGboat, Volume 30 (2009), No. 2 18
Page 87 and 88:
TUGboat, Volume 30 (2009), No. 2 23
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 152 and 153:
RIVER VALLEY TECHNOLOGIES TUG 2010:
Page 154 and 155:
304 TUGboat, Volume 30 (2009), No.
Page 156 and 157:
TUGBOAT Volume 30 (2009), No. 2 Int
show all

The Communications of the TEX Users Group Volume 30 ... - TUG

Create successful ePaper yourself

Delete template?

Save as template?