check http://luatex.bluwiki.com/ Le 5 déc. 07 à 15h52, Jonathan Sauer a écrit :

Well, as soon as I have figured out how to correctly load OpenType fonts ... incidentally, that is an place the manual could use some work: Section 4.12.2 explains how to get a metrics table from an OpenType font -- but now, what this metrics table contains. That makes it quite difficult to convert it to a tfm font table.

-- +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis.haralambous@enst-bretagne.fr | | Directeur d'Études http://omega.enstb.org/yannis | | Tel. +33 (0)2.29.00.14.27 | | Fax +33 (0)2.29.00.12.82 | | Département Informatique | | TÉLÉCOM Bretagne | | Technopôle de Brest Iroise, CS 83818, 29238 Brest CEDEX 3, France | | Coordonnées Google-Earth : 48°21'31.57"N 4°34'16.76"W | +--------------------------------------------------------------------+ ...pour distinguer l'extérieur d'un aquarium, mieux vaut n'être pas poisson ...the ball I threw while playing in the park has not yet reached the ground Es gab eine Zeit, wo ich nur ungern über Schubert sprechen, nur Nächtens den Bäumen und Sternen von ihm vorerzählen mögen.

Hello, [loading OpenType fonts]

check http://luatex.bluwiki.com/

I did. Unfortunately, the result was a PDF file with invisible text. Also, the example seems to be quite incomplete, i.e. slanted fonts are not handled correctly. That's why I'm interested in the format of the OTF font metrics table: To be able to take a more complete and also more systematic approach. I want to understand what I am copying where and why. Jonathan

Hello,

...

I did. Unfortunately, the result was a PDF file with invisible text.

That's interesting :-) What font did you use? Could you maybe send it offline?

Tomorrow, after incorporating some fixes from this mailing list. I used Latin Modern Roman. The characters were in the PDF, the font as well, but they were invisible and all at the same position.

...

slanted fonts are not handled correctly.

Again, what sort of slanted fonts? Any font with a non-zero slant?

Well, any italic font should have a non-zero slant to be used by TeX for italic correction. At least as far as I remember.

Arthur

Jonathan

Arthur Reutenauer wrote:

Oh, italic correction. Then sure :-)

there is no such feature in open type but we're discussing (tex gyre team) to register such a feature 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 -----------------------------------------------------------------

Hello,

...

Tomorrow, after incorporating some fixes from this mailing list. I used Latin Modern Roman. The characters were in the PDF, the font as well, but they were invisible and all at the same position.

Strange, that's not what I have here with a very simple test. If you could send an exact example file some day, I would be very interested, and I'm sure Taco would be as well.

First of all, an apology: While complaining about a missing fontforge table documentation, I completely overlooked section 13. Now, after incorporating the fixes (concerning scaling), everything worked. I attached the PlainTeX source as a UTF-8 document (please remove the BOM at the beginning to prevent LuaTeX from complaining about a missing character 65xxx). However (an excerpt from the attached document, I hope the diacritics are not lost): ---------------------------------------------------------------------- \font\textfont=lmroman10-regular at 10pt % (A) % \font\textfont=lmroman10-bold scaled 1000 % (B) % \font\textfont=lmroman10-bold % (C) \textfont Lûátèx sürė ĩs grēăt! fi ffi AV \bye ---------------------------------------------------------------------- (A) works perfectly. (B) and (C) produce (C most likely because 'scaled 1000' is the default): This is LuaTeX, Version snapshot-0.20.0-2007120515 (Web2C 7.5.6) (OTFTest.texLoading font /usr/local/teTeX/share/texmf.tetex/fonts/opentype/publ ic/lm/lmroman10-bold.otf [1{/usr/local/teTeX/share/texmf.local/fonts/map/pdftex /updmap/pdftex.map} ! pdfTeX error (arithmetic): divided by zero. \plainoutput ...headline \pagebody \makefootline } \advancepageno \ifnum \out... <output> {\plainoutput } \supereject ->\par \penalty -\@MM \bye ->\par \vfill \supereject \end l.91 \bye ! ==> Fatal error occurred, no output PDF file produced Changing the output routine to '\output{}' only changes the "stack trace". (D) creates some strange output: 012345678901234567890123456789 012345678901234567890123456789 0 12345678901234567890123456789 012345678901234567890123456789 It seems that texio.write does not reset its internal line length counter then writing a "\n". Also, there is a leading space for some reason. BTW: Is it possible to add a function which does not wrap after 80 characters? Or maybe the wrapping is completely obsolete (though I am not sure about tracing TeX code). Another weird thing: The Latin Modern font contains ligatures, but they are not put inside a "ligatures" table. Example: "f" (simple output of the fontforge glyph table using code from the Lua wiki): [{boundingbox={33,0,357,705},kerns={{char="quotedblright.cm",off=28,lookup="pp_ l_1_s"},{char="quotedblleft.cm",off=28,lookup="pp_l_1_s"},{char="quotedblright" ,off=28,lookup="pp_l_1_s"},{char="quotedblleft",off=28,lookup="pp_l_1_s"},{char ="quoteright",off=28,lookup="pp_l_1_s"},{char="quoteleft",off=28,lookup="pp_l_1 _s"},{char="bracketright",off=28,lookup="pp_l_1_s"},{char="question",off=28,loo kup="pp_l_1_s"},{char="parenright",off=28,lookup="pp_l_1_s"},{char="exclam",off =28,lookup="pp_l_1_s"}},name="f",unicodeenc=102,width=306}] "f" contains a "fi" ligature: [{lookups={ls_l_10_s={{type="ligature",specification={char="f_i",components="f i"}}}},boundingbox={27,0,527,705},name="f_i",unicodeenc=64257,width=556}] But this ligature is not associated with the "f" letter in any way. Is this a bug in the font? In LuaTeX? In the manual? I installed the font in OS X 10.4 and used it in TextEdit (which supports OpenType ligatures), and fi and other ligatures were inserted correctly. So I would guess that the font is OK. The font's version is 1.010. And finally: "design_size" vs. "designsize" ...

Arthur

Jonathan

Now, after incorporating the fixes (concerning scaling), everything worked.

Thanks, that's reassuring. Probably in an earlier version (where I used completely ad hoc numbers) the glyphs were reduced to 1/1000th or so :-) I'll look into the rest later. Arthur

Jonathan Sauer wrote:

Hello,

...

I have just released the new beta for luatex, with version number now at 0.20.0. This will be the last beta with big changes in it for a while: I will start work on the mplib project now, and that will be my main focus for the coming two/three months. I have planned for bug-fix releases for this beta, though.

Great news!

What does this mean for the further development of LuaTeX? I would guess that the fourth stage, as defined on LuaTeX's homepage, is now finished. Still:

- Apart from integrating MetaPost and the TODO list in the manual, is LuaTeX feature-complete?

No, there will be more callbacks, for instance in the page building stage, more control over inserts, etc. Also, the backend will be redone (separation, more control over pdf, image inclusions). Parts will be rewritten in C instead of pascal. Font data structures will be extended (esp protruding and hz vectors), etc etc

- Can the Lua interface be considered as being (more or less) stable?

no, it's a beta after all, but for the existing features and interfaces no fundamental changes will take place; between the previous and current beta there have been changes; around tug 2008 much will be stable (first formal release), at eurotex 2009 we plan to release the version where at least documented parts of the interface are frozen.

- What is planned between 2008 and 2010?

well, we have a wish list, but hen we have enough lua callbacks we may not need to add much; eventually there will be a tex kernel (in c) with a c interface; currently global properties will become structures, maybe we will be abel to run multiple instances .. who knowns

...

* Completely overhauled hyphenation and ligkern application, including the addition of a new "lang" table in lua to interface to the language parameters, some extra functions in the "node" table, and a few extra callbacks ("hyphenate", "ligaturing", "kerning", "post_linebreak_filter").

This is a really, really great change from the original TeX, especially:

intended -)

- "--" does not insert a discretionary (well, if \exhyphenchar is set to 0).

- \hyphenation can contain complex discretionaries, thus allowing automatic changes such as backen => bak-ken ("to bake").

...

* a bunch of bugs reported on the mailing list have been fixed (I hope all of them).

I'm afraid to ask: What about font expansion? ;-)

next year ... data tables (currently global) will move to fonts, maybe real alternative glyph support, etc

...

Have fun,

I will. I guess I will dump eTeX as the required engine for my private format and use LuaTeX all the way. No more active characters for input and output encoding, better key-value processing ... nice!

Well, as soon as I have figured out how to correctly load OpenType fonts ... incidentally, that is an place the manual could use some work: Section 4.12.2 explains how to get a metrics table from an OpenType font -- but now, what this metrics table contains. That makes it quite difficult to convert it to a tfm font table.

this is not for the manual, since there are many implementations possible and the whole idea behind luatex is that we only provide interfaces, no solutions; we have plans to write a luatex book (starting next year) that may contain example code so, for the moment, consider it an experiment, next year, consider it reality and after that integration with macropackages will follow (well, up to he macro package writers of course) 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 -----------------------------------------------------------------

Jonathan Sauer wrote:

Hello,

...

...

- What is planned between 2008 and 2010? well, we have a wish list, but hen we have enough lua callbacks we may

...

not need to add much; eventually there will be a tex kernel (in c) with a c interface; currently global properties will become structures, maybe we will be abel to run multiple instances .. who knowns

What do you mean by the latter?

if a tex engine can be properly isolated one can think of starting a new instance

Sure, but examples on how to use these interfaces can go a long way. And IMO a documentation of the OpenType font metrics table is indeed for the manual. Otherwise, how should one be able to create a solution?

by consulting documentation (fontforge, ms site, adobe) ... of just looking into the lua table ... there are many variations in fonts and features; type 1, open type, what-comes-next ... such standards (sic) have their own documentation

A book on dead trees? Considering the pace at which LuaTeX develops (and most likely will continue to develop, considering above roadmap), I wonder if this book will not either be in the stores too late or out of date.

well, at some point luatex will be pretty stable ... just like tex itself; what macro packages do with luatex is not part of that kin dof documentation

Who can only write code if they have the documentation.

indeed, but look at good old tex ... eventually macro packages evolved that go way behind plain tex; also, i could write thousands of pages about how *i* do thinsg but that may not be the way you want to do it (and i'm pretty sure that the context mkiv color model is different from what e.g. latex does). 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 -----------------------------------------------------------------

I think that would be a bad idea. The TeXbook, for example, does not restrict itself to documenting only primitives. Instead, a reasonable working macro set plainTeX (including allocation and user-level accent generating macros and lots of other basic stuff built from primitives) is the basis of the book throughout.

So the obvious solution would be Hans and Yannis sitting down together to write a book about both the technical and theoretical aspects, with Hans describing ConTeXt and Yannis enhancing _Fonts and Encodings_ And Taco supervising :-) (Yeah, never gonna happen. *I know*) Arthur ;-)

Aditya Mahajan wrote:

Lets make things simpler. How about a book just explaining the techincal aspects of ConTeXt MkIV (yeah, yeah, I know ... but worth a try :-)

maybe ... combined with a practical mkiv manual ... definitely not a one-author project, but also not something to discuss on this list -) 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 -----------------------------------------------------------------

Hello,

...

...

we will be abel to run multiple instances .. who knowns

What do you mean by the latter?

if a tex engine can be properly isolated one can think of starting a new instance

I'm still confused. Right now, I can run luatex several times in different consoles, typesetting different documents. It also should be possible to use os.execute to run luatex out of luatex, since the operating system gives each instance its own memory etc.

...

Sure, but examples on how to use these interfaces can go a long way. And IMO a documentation of the OpenType font metrics table is indeed

...

for the manual. Otherwise, how should one be able to create a solution?

by consulting documentation (fontforge, ms site, adobe) ...

Well, fontforge's documentation mostly deals with the font designer itself. I found a little bit about the data structures, but that only dealt with the internal data structures, not how a font is "exported".

of just looking into the lua table ...

That amounts to reverse-engineering. The tables can be mis-interpreted.

there are many variations in fonts and features; type 1, open type, what-comes-next ... such standards (sic) have their own documentation

Of course. But this documentation does not tell me how LuaTeX maps the font's data structures to Lua tables.

...

Who can only write code if they have the documentation.

indeed, but look at good old tex ... eventually macro packages evolved that go way behind plain tex; also, i could write thousands of pages about how *i* do thinsg but that may not be the way you want to do it (and i'm pretty sure that the context mkiv color model is different from what e.g. latex does).

Sure. But it would still be useful to have this information just to see how others (you, in that case) solved a given problem. That way, the wheel does not need to be reinvented all the time.

Hans

Jonathan

Jonathan Sauer wrote:

...

of just looking into the lua table ...

That amounts to reverse-engineering. The tables can be mis-interpreted.

The lua table from fontforge.to_table() is written by me only (not George), and it is currently just a serialization of the fontforge internal data structure. The resulting table is about as "documented" as the internal data structure is, which is not very much. The end goal is to have a nicely documented return table that is not as reliant on the fontforge internals, but the available time for both development and documentation is limited (as always ...) Best wishes, Taco