Hi Martin,
I answering this as it goes for any software project.
Those papers are nice and can help in general understanding, but
they are to be of real use to a real programmer. Furthermore,
if the are really relevant than then should be part of the source code
distribution.
There are different kinds of Documentation. TeX has a literate programming
documentation style. In the TeX-world of today the source code documentation
is minimal, where the API documentation is decent enough, if you know TeX.
Then problem is that all that information in the papers should be in the source
code!!
Yes, it bloats the source code ten fold! But, all one needs to do is look at
the header
files and you understand what is being done. You do not need to understand the
programming language, because it is all in the comments.
Then the is the Program Specification. This is where you put in the rational,
the design choices,
the Graphics. What is all this good for you might ask.
1) Program varifiblity
2) Program mantainace
4) Porgram portabibilty
5) Cooperation during development
It is all good software engineering. You do not need everything state of art.
Yet, a little more
natural language goes a long way.
XeTeX could profit from this. As well as all other project.
The bigger the project, the more people involved, the more technologies
involved, the more
important good documentation practices are needed. A decent programmer just
needs a halfway
decent specification to program anything. A programmer does not need to
understand XeTeX, inorder
to write the engine he needs to know what needs to go inside the engine.
Lets take the XeTeX Font Manager and ATSUI. ATSUI was a comfortable way for
handling
the AAT-Font features. Know if it where documented in the source what data
structures and
which routine XeTeX used internally for handling the AAT-Font features It would
not be hard
to replace ATSUI with something else, because all you need to do is read the
Advance True Type
Font tables and put them into the internal data structures and maybe patch a
routine or two.
But, that is not documented anywhere. Come to think of it I believe, the
problem is that there should
have been another layer in there and XeTeX would not have the problem it has
today with ATSUI
So, my advice is now, who ever, when ever and another layer into the Font
Manager of XeTeX, so that
when the next pradigma change comes around the calls to ATSUI, or Core Text, or
what ever only need to be
updated and not the entire Font Manager for AAT-Fonts.
And that was not a negative critic, just good advice form a programmers point
of view.
Am 02.08.2012 um 15:22 schrieb Martin Schröder <mar...@oneiros.de>:
> 2012/8/1 Keith J. Schultz <keithjschu...@web.de>:
>> As has been mentioned the source and programming rational behind
>> LuaTeX is not documented, at least not publically. Even if one would
>> do the programming their is no guarantee that the code will be used or
>> allowed.
>
> There have been numerous papers and talks by the team.
> Patches are always welcome.
>
> Everybody is free to take the code and fork the project.
>
> EOD: This is not the place for discussions about LuaTeX.
>
> Best
> Martin
>
>
> --------------------------------------------------
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
