Hans' presentation: using plain TEX (from TUG 2009) [apologies if OT]
Dear Hans, Taco et al I hope this is the appropriate place to ask my question --- if not, my apologies. I've compiled LuaTeX on Windows and have been using Hans' presentation "using plain TEX" (from TUG 2009) to construct a minimal working runtime environment based on plain tex. Basically, a hand-coded texmf.cnf and a minimal (non-ConTeXt) environment/TDS constructed around the "build" directory created by build.sh. The reason for doing this is to start with a setup which is the minimum possible, as a way to learn. ConTeXt is very powerful and orders of magnitude more complex than plain (obviously...) so I needed to strip that away, for now. It seems to work well, so far. My question relates to fonts. In the luatex-plain example: \input plain \directlua {tex.enableprimitives('', tex.extraprimitives())} \pdfoutput=1 \everyjob \expandafter {% \the\everyjob \input luatex-basics\relax \input luatex-fonts\relax \input luatex-mplib\relax } \edef\fmtversion{\fmtversion+luatex} ===> luatex --ini luatex-plain.tex You include some ConTeXt font machinery which I'd like to experiment with using fonts I have in .afm/.pfb format only. I ran mtxrun --script font --names to generate a font name database (luatex-fonts-names.lua) ["mappings"]={ ["aharonibold"]={ "Aharoni Bold", "C:/Windows/fonts/ahronbd.ttf" }, ["andalus"]={ "Andalus", "C:/Windows/fonts/andlso.ttf" }, ["angsananew"]={ "Angsana New", "C:/Windows/fonts/angsa.ttf" }, ["angsananewbold"]={ "Angsana New Bold", "C:/Windows/fonts/angsab.ttf" <<snip lots>> and copied it across to my plain tex texmf tree. Works fine, PDF outputs perfectly, so it enables lots more fonts in the plain format. However, the database is clearly restricted to TrueType and OpenType fonts so my question is: Does the font machinery included by: \input luatex-basics\relax \input luatex-fonts\relax \input luatex-mplib\relax provide support for afm/pfb fonts? TrueType etc are OK like this: \font\testf=[arialbolditalicmt] at 12pt (name taken from database) However, as soon as I try to use this with afm/pfb files it fails, unable to find the metrics. For example: \font\testa=file:MinionRegularItalic_wt350_wd450_op10 at 34pt It may be potentially bad names that I'm using with underscores (they are all named like this Minion_wtX_wdY_opZ) (X,Y,Z are values for weight, width and optical size) But it also failed with simple font names. I checked that the fonts can be found: \directlua { local found = kpse.find_file("MinionRegularItalic_wt350_wd450_op10","afm") tex.print("$$"..found.."$$") local ifound = kpse.find_file("MinionRegularItalic_wt350_wd450_op10","type1 fonts") tex.print("$$"..ifound.."$$") } ($$ is a silly hack due to the _) So, is it possible to find and load .afm/.pfb with your luatex-plain example. Is that font machinery included in luatex-plain? If so, can you suggest why the luatex-plain example might be failing with the .afm/.pfb files? I would be very grateful for any insights you can provide. Many, many thanks in advance. And another busy day on the list!!! Warm wishes Graham
On 3-4-2010 7:51, Graham Douglas wrote:
So, is it possible to find and load .afm/.pfb with your luatex-plain example. Is that font machinery included in luatex-plain?
the 'generic' code is only providing opentype support and type1/afm goes via the regular tex specific tfm route and believe me: i don't even want to know how plain users of latex users deal with type 1 as it's already messy enough in context; keep in mind that when one uses type 1 one often operates in the 8 bit environment and therefore in font encoding land; of course you can convert a type 1 into an open type font using fontforge context mkiv can deal with afm/type1 but this is rather context specific and i'm not going to impose context methods and strategies as i'm pretty sure that non context users are not that willing to adapt to context methods sticking to type 1 is a bad idea anyway and the less it is supported in the new engines the better as it forces users to move on the same is true for math ... the loader does load math fonts but math support is always rather macro package specific so one needs to define whatever needed (families, symbols etc) the way uses in the specific macro package (the same applies here .. in a few years all math fonts will be available in open type) for instance in the lua-latex code, they use the context otf loader for open type but it gets encapsulated in latex ways of defining and using and as type1 handling is already present in latex (and is shared with xetex code i assume) it is not related to lua etc at all, so there is no need for additional code concerning plain: plain has no font system so there's nothing to hook code in and as soon as one starts to make a system one should wonder if using plain is a good idea; it does not gain you much using plain instead of context concernign context being large ... occasionally i do experiment with metatex, a more layered approach for making smaller formats but that's a long term effort
If so, can you suggest why the luatex-plain example might be failing with the .afm/.pfb files?
because you need to load the tfm file (which is probably someplace in your tex tree) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
<<snip much good advice from Hans>> Hi Hans Thank you for your commnts. Oh, for sure, tinkering with plain is just an interim step along the (long...) road. A very minimal "harness setup" to write minimal code --- to play with the various LuaTeX API functions via GNU's gdb debugger. By building a small test environment/playground from scratch, including compiling LuaTeX, and hacking together a basic TDS, gives me a way to learn about stuff like kpathsea etc. Whether or not it's a good way to learn, the right stuff to learn, I'm not sure, but I have learnt a lot through trial + error and not a little frustration, at times... And it keeps me pleasantly occupied with an absorbing and very low-cost hobby :-) If there would be any interest, I'd be happy to write it up at some point if anyone would benefit --- but it'd need scrutiny from resident experts prior to publication: peer review :-) Warm wishes Graham
Hello Graham,
Thank you for your commnts. Oh, for sure, tinkering with plain is just an interim step along the (long...) road. A very minimal "harness setup" to write minimal code --- to play with the various LuaTeX API functions via GNU's gdb debugger. By building a small test environment/playground from scratch, including compiling LuaTeX, and hacking together a basic TDS, gives me a way to learn about stuff like kpathsea etc.
Besides the gdb part, this is pretty much how I "learned" LuaTeX (still on my path). I suggest you stay with plain, then add features as you go along: * write your own font handler (see the bluewiki page) - LuaTeX supports many different kinds of fonts * write your own kpathsea module (and thus replace kpathsea) * do a nodelist traversal and find out about the different node types * create a nodelist and write it out to TeX (node.write(...)) * use tex.linebreak() for creating a paragraph. ... Hans' font stuff is rather advanced and therefore complex (IIRC > 10000 lines of code), so don't try to understand it as your first exercise. There is no need to use ConTeXt if all you want is knowledge of the LuaTeX API. If you understand german or use google translate, have a look at http://www.luatex.de Patrick
Hello Patrick who said...
Besides the gdb part, this is pretty much how I "learned" LuaTeX (still on my path). I suggest you stay with plain, then add features as you go along:
* write your own font handler (see the bluewiki page) - LuaTeX supports many different kinds of fonts * write your own kpathsea module (and thus replace kpathsea) * do a nodelist traversal and find out about the different node types * create a nodelist and write it out to TeX (node.write(...)) * use tex.linebreak() for creating a paragraph. ...
Good to know that I'm not the only one going down the "simple" path. My plans are indeed along the lines you indicate. I have the utmost admiration and respect for the work that has gone into ConTeXt, a great piece of work. For now, I just need to get back to the "very basics" and a minimal installation of LuaTeX with plain seems to do that nicely, for now.
If you understand german or use google translate, have a look at
Sadly, I do not read German, a real pity as there are some interesting bits of code on there. Google Translate, here I come.... :-) Warm regards and thanks again for your time to reply. Cheers! Graham
On 3-4-2010 8:56, Graham Douglas wrote:
<<snip much good advice from Hans>>
Hi Hans
Thank you for your commnts. Oh, for sure, tinkering with plain is just an interim step along the (long...) road. A very minimal "harness setup" to write minimal code --- to play with the various LuaTeX API functions via GNU's gdb debugger. By building a small test environment/playground from scratch, including compiling LuaTeX, and hacking together a basic TDS, gives me a way to learn about stuff like kpathsea etc. Whether or not it's a good way to learn, the right stuff to learn, I'm not sure, but I have learnt a lot through trial + error and not a little frustration, at times... And it keeps me pleasantly occupied with an absorbing and very low-cost hobby :-)
If there would be any interest, I'd be happy to write it up at some point if anyone would benefit --- but it'd need scrutiny from resident experts prior to publication: peer review :-)
just write articles for the MAPS then (NTG journal) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Graham Douglas -
Hans Hagen -
Patrick Gundlach