Hanging Indentation
Marc van Dongen
I'm currently playing with paragraphs with hanging indentation where
the indentation lasts for a given length.
The TeX Book provides (at least) two techniques to implement these:
(1) use \hangindent and \hangafter, or (2) use \parshape. Both
techniques let you define the duration of the hanging indentation in
terms of the number of lines. I've also noticed that some LateX
packages use these techniques but I haven't seen other solutions.
However, with lines not having a uniform height, it is difficult to
guess how many lines are needed and I'd like to make hanging
indentation (almost) bullet proof.
Does anybody know a technique that lets you define the duration of
hanging indentation in terms of a fixed maximum length?
Thanks in advance for your help.
Regards,
Marc van Dongen
GL
You'd better explain what's your purpose. hanging indentation seldom
go further than a few lines, thus the number of lines does not depend
on their height (unless height varies dramatically...)
zappathustra
If I understand correctly:
- You want, say, 40pt worth of line with hanging indentation;
- Your lines don't have the same height, because some of them contain
exotic material, like math;
- So you can't simply divide 40pt by \baselineskip, because
\baselineskip isn't a reliable measure;
Am I right?
I can see four solutions:
1. Mimick the paragraph builder by breaking lines by yourself in a
Word-like way (i.e. make a line when it has as much material as it can
accommodate); measure the boxes by yourself;
2. Ask a wizard. A guy who won't be afraid to grasp all lines and glues
and measure them with such things as \lastnodetype (I'm not sure it can
be done unfailingly, though);
3. Use LuaTeX; build a paragraph with first one line hanging, see if it
fits, if not try two lines, see if it's ok, or three lines, and so on. I
say ``Use LuaTeX,'' because that's the same method as above, except you
don't need a wizard: you have callbacks;
4. Use LuaTeX; rewrite the paragraph builder; once you control it, you
can ask whatever you want; and no, I don't know how it can be done, but
there's hope (see H. Hagen's paper in the last /TUGboat/ issue);
Solution 3 is really doable. But perhaps you don't use LuaTeX. I've been
told some people don't :)
Best,
Paul
Marc van Dongen
The purpose was to see if there's a way to implement hanging
indentation in such a way that it can be implemented in terms of
length, not lines. I agree about variability of the height of lines.
Regards,
Marc
zappathustra
Le 22/10/2010 22:16, Marc van Dongen a �crit :
> On Oct 22, 8:50 pm, zappathustra<zappathus...@free.fr> wrote:
>> Le 22/10/2010 18:36, Marc van Dongen a �crit :
>>
>>
>>
>>
>>
>>> Dear all,
>>> I'm currently playing with paragraphs with hanging indentation where
>>> the indentation lasts for a given length.
>>> The TeX Book provides (at least) two techniques to implement these:
>>> (1) use \hangindent and \hangafter, or (2) use \parshape. Both
>>> techniques let you define the duration of the hanging indentation in
>>> terms of the number of lines. I've also noticed that some LateX
>>> packages use these techniques but I haven't seen other solutions.
>>> However, with lines not having a uniform height, it is difficult to
>>> guess how many lines are needed and I'd like to make hanging
>>> indentation (almost) bullet proof.
>>> Does anybody know a technique that lets you define the duration of
>>> hanging indentation in terms of a fixed maximum length?
>> If I understand correctly:
>>
>> - You want, say, 40pt worth of line with hanging indentation;
>> - Your lines don't have the same height, because some of them contain
>> exotic material, like math;
>> - So you can't simply divide 40pt by \baselineskip, because
>> \baselineskip isn't a reliable measure;
>>
>> Am I right?
> Yes.
>
>> I can see four solutions:
>>
>> 1. Mimick the paragraph builder by breaking lines by yourself in a
>> Word-like way (i.e. make a line when it has as much material as it can
>> accommodate); measure the boxes by yourself;
>> 2. Ask a wizard. A guy who won't be afraid to grasp all lines and glues
>> and measure them with such things as \lastnodetype (I'm not sure it can
>> be done unfailingly, though);
>> 3. Use LuaTeX; build a paragraph with first one line hanging, see if it
>> fits, if not try two lines, see if it's ok, or three lines, and so on. I
>> say ``Use LuaTeX,'' because that's the same method as above, except you
>> don't need a wizard: you have callbacks;
>> 4. Use LuaTeX; rewrite the paragraph builder; once you control it, you
>> can ask whatever you want; and no, I don't know how it can be done, but
>> there's hope (see H. Hagen's paper in the last /TUGboat/ issue);
>>
>> Solution 3 is really doable. But perhaps you don't use LuaTeX. I've been
>> told some people don't :)
> Hi Paul,
>
> Thanks for your suggestions.
>
> (1) I don't think I'd like to use Option 1 because I'd like the lines
> at the top of my paragraphs are very narrow and I'd like to have good
> linebreaks.
>
> (2) I don't understand Option 2, but I'll have a look at it.
>
> (3--4) LuaTex may be an option but for the moment I prefer to stay
> with (pdf)latex.
LuaTeX doesn't mean no LaTeX. There exists LuaLaTeX. If you're using
pdfTeX, I'd say you can switch to LuaTeX; I guess the
pdfTeX-compatiblity is ok now, and bugs and/or unfinished things happen
only in areas that don't exist in pdfTeX anyway (like node manipulation
here). So, as a replacement for pdfTeX, I guess LuaTeX is totally up to
the task, but Taco might say otherwise.
> Option 4 may not be so trivial because the hanging paragraph(s) may
> have side effects. For example, they may change global macro
> definitions.
I don't follow you. In option 2, that's true: you rebuild the paragraph
as many times as necessary in a \vbox and perhaps call the same macro
several times. In option 3 that's not true because once you're on the
the Lua level, you can just recycle nodes. And option 4 is still less so
since we're talking about TeX's paragraph builder, which really has
nothing to do with macros, and could really take the height of the line
it builds into account. But perhaps I misunderstood you here.
> However, I have been thinking of this option in a latex
> context. For example, it may be possible to estimate the required
> number of hanging lines in successive latex runs.
Yes, I guess that's option 5, and a good one. I generally forget about
multiple runs.
... But actually it can't work. The question is: What do you write to
your external file? That you used 3 lines with hanging indentation, but
how do you know it meets the requirements or it is too much or not enough?
Paul
Dan Luecking
<zappat...@free.fr> wrote:
> Le 22/10/2010 18:36, Marc van Dongen a �crit :
>3. Use LuaTeX; build a paragraph with first one line hanging, see if it
>fits, if not try two lines, see if it's ok, or three lines, and so on. I
>say ``Use LuaTeX,'' because that's the same method as above, except you
>don't need a wizard: you have callbacks
What is a callback? And don't tell me to read the manual:
it has over 100 instances of the word callback and I gave
up trying to find out what they are after examining the
first 50 or so instances.
If callbacks are so great there should be a definition
of them and a few examples of their use.
Dan
To reply by email, change LookInSig to luecking
zappathustra
> On Fri, 22 Oct 2010 21:50:36 +0200, zappathustra
> <zappat...@free.fr> wrote:
>
>> Le 22/10/2010 18:36, Marc van Dongen a �crit :
>> 3. Use LuaTeX; build a paragraph with first one line hanging, see if it
>> fits, if not try two lines, see if it's ok, or three lines, and so on. I
>> say ``Use LuaTeX,'' because that's the same method as above, except you
>> don't need a wizard: you have callbacks
> What is a callback? And don't tell me to read the manual:
> it has over 100 instances of the word callback and I gave
> up trying to find out what they are after examining the
> first 50 or so instances.
I won't tell you so. The manual isn't meant as an introduction, and will
never be, I suppose. Some day one of us (meaning all TeX users) will
write a /LuaTeX by Topic/ or launch a LuaTeX wiki.
> If callbacks are so great there should be a definition
> of them and a few examples of their use.
>
Pay attention when you receive your next issue of /TUGboat/, if you do...
For the moment: a callback is a point where you can interrupt TeX's
normal operations, and throw in some (Lua) code of your own. There are
many such points, for many different operations: managing the input
buffer, reading a file, loading a font, building a paragraph, etc.
And here's an example of use. It's a piece of code I use to add the
right kerns before some punctuation marks (in French). So it avoids the
need to make "?" active, for instance. It's terribly simplified here,
since the important thing is seeing a callback at work, not the real code:
%%%
\directlua{%
local mark_kern = node.new(11, 1)
mark_kern.kern = tex.sp(".15em")
function french_punc (head)
for mark in node.traverse_id(37, head) do
if mark.char == string.byte("?") or mark.char == string.byte("!") then
node.insert_before(head, mark, node.copy(mark_kern))
end
end
return head
end
callback.register("pre_linebreak_filter", french_punc)
}
Does it work? Yes!
\bye
%%%
Let's begin with the last line: it means ``add the french_punc function
in the pre_linebreak_filter.'' The latter (a callback) is called when
TeX is ready to break some material into lines; thus we allow the
french_punc function to act on this material, which is a list of nodes
(glyphs and glues, mostly).
The first two lines mean: create a kern node with width 0.15em. I.e.
what you'd get if you said \kern.15em.
And the function, finally, does the following: it scans our list of
nodes (that is going to be passed to the paragraph builder), find those
nodes that are glyphs (they have id 37), select only those glyphs whose
char[aracter] is either "?" or "!", and insert in the list (head) a copy
of the kern node just before those glyphs (mark). Finally, we return the
list, passing it to the paragraph builder.
And that's it. It doesn't cope properly with French punctuation, but
that would require nothing fancier, only details that would obfuscate
the point (as would other details omitted here about the Lua code
generally).
Last note: the % after the opening brace is totally useless, but I'm
totally unable to get rid of it. My fingers don't ask for permission.
Best,
Paul
Marc van Dongen
> Le 22/10/2010 22:16, Marc van Dongen a écrit :
> LuaTeX doesn't mean no LaTeX. There exists LuaLaTeX. If you're using
> pdfTeX, I'd say you can switch to LuaTeX; I guess the
> pdfTeX-compatiblity is ok now, and bugs and/or unfinished things happen
> only in areas that don't exist in pdfTeX anyway (like node manipulation
> here). So, as a replacement for pdfTeX, I guess LuaTeX is totally up to
> the task, but Taco might say otherwise.
Thanks, but I'm still a bit hesitant.
> > Option 4 may not be so trivial because the hanging paragraph(s) may
> > have side effects. For example, they may change global macro
> > definitions.
>
> I don't follow you. In option 2, that's true: you rebuild the paragraph
> as many times as necessary in a \vbox and perhaps call the same macro
> several times. In option 3 that's not true because once you're on the
> the Lua level, you can just recycle nodes. And option 4 is still less so
> since we're talking about TeX's paragraph builder, which really has
> nothing to do with macros, and could really take the height of the line
> it builds into account. But perhaps I misunderstood you here.
OK, thanks. Still, I'm not quite convinced this will work because of
writes to files.
> > However, I have been thinking of this option in a latex
> > context. For example, it may be possible to estimate the required
> > number of hanging lines in successive latex runs.
>
> Yes, I guess that's option 5, and a good one. I generally forget about
> multiple runs.
> ... But actually it can't work. The question is: What do you write to
> your external file? That you used 3 lines with hanging indentation, but
> how do you know it meets the requirements or it is too much or not enough?
Well, you could also take the height and the number of lines in the
typeset paragraphs into account. You can determine each of them.
Still, it doesn't seem this is enough information for a proper
algorithm.
Anyway, as I said, I haven't studied the TeX book in full. Perhaps I
should spend more time on studying plain TeX first!
Regards,
Marc van Dongen
GL
>> Yes, I guess that's option 5, and a good one. I generally forget about
>> multiple runs.
>> ... But actually it can't work. The question is: What do you write to
>> your external file? That you used 3 lines with hanging indentation, but
>> how do you know it meets the requirements or it is too much or not enough?
If pdfTeX, there is \pdfsavepos that can help. Interface to use this
primitive is provided by zref-savepos. Otherwise, I can't see ;-(
Regards
> Marc van Dongen
Dan
> Le 22/10/2010 23:01, Dan Luecking a écrit :
>
> > What is a callback? And don't tell me to read the manual:
> > it has over 100 instances of the word callback and I gave
> > up trying to find out what they are after examining the
> > first 50 or so instances.
>
> normal operations, and throw in some (Lua) code of your own. There are
> many such points, for many different operations: managing the input
> buffer, reading a file, loading a font, building a paragraph, etc.
>
> And here's an example of use. It's a piece of code I use to add the
> right kerns before some punctuation marks (in French). So it avoids the
> need to make "?" active, for instance. It's terribly simplified here,
> since the important thing is seeing a callback at work, not the real code:
>
> %%%
> \directlua{%
> local mark_kern = node.new(11, 1)
> mark_kern.kern = tex.sp(".15em")
> function french_punc (head)
> for mark in node.traverse_id(37, head) do
> if mark.char == string.byte("?") or mark.char == string.byte("!") then
> node.insert_before(head, mark, node.copy(mark_kern))
> end
> end
> return head
> end
> callback.register("pre_linebreak_filter", french_punc)
>
> }
Thank you so much for that.
It seems to me this is called a "hook" in most contexts. My editor's
macro or (TSE) calls them that and has a similar syntax for adding
a function call to them.
> Last note: the % after the opening brace is totally useless, but I'm
> totally unable to get rid of it. My fingers don't ask for permission.
I totally understand.
Regards,
Dan
Khaled Hosny
> On Fri, 22 Oct 2010 21:50:36 +0200, zappathustra
>
> > Le 22/10/2010 18:36, Marc van Dongen a écrit :
> >3. Use LuaTeX; build a paragraph with first one linehanging, see if it
> >fits, if not try two lines, see if it's ok, or three lines, and so on. I
> >say ``Use LuaTeX,'' because that's the same method as above, except you
> >don't need a wizard: you have callbacks
>
> What is a callback? And don't tell me to read the manual:
> it has over 100 instances of the word callback and I gave
> up trying to find out what they are after examining the
> first 50 or so instances.
Searching Google for "callback", the first hit is very helpful:
http://en.wikipedia.org/wiki/Callback_(computer_science)
> If callbacks are so great there should be a definition
> of them and a few examples of their use.
If it such a general computing term, I don't expect a software manual
to define it, and there examples in the manual.
Regards,
Khaled
Norman Gray
Dan, greetings.
In article
<d3157077-1bdb-490a...@g25g2000yqn.googlegroups.com>,
Dan <luec...@uark.edu> wrote:
> On Oct 22, 5:18�pm, zappathustra <zappathus...@free.fr> wrote:
> > � Le 22/10/2010 23:01, Dan Luecking a �crit :
> >
> > > What is a callback?
> >
> > For the moment: a callback is a point where you can interrupt TeX's
> > normal operations,
> It seems to me this is called a "hook" in most contexts. My editor's
> macro or (TSE) calls them that and has a similar syntax for adding
> a function call to them.
(At the risk of drifting off-topic, and of splitting hairs:) I think
they're basically the same thing, though I think that a callback may be
a more general notion, since it includes the possibility that the object
registering the callback may potentially have quite a bit of state, as
opposed to being simply a block of code, which is how I think of a
'hook'.
I think that GUIs quite often interact with the guts of their
application by using callbacks. Another very clear illustration of
callbacks is in the way that SAX (XML) parsers work in Java: the object
that wants to process the XML registers its methods as callbacks in the
parser: for example, it's invoked whenever the parser comes across a new
element. The parser is driving the processing, but it's the
called-back-to object which is doing all of the work.
(I mention this because, oddly, I hadn't previously thought of the
similarity between callbacks and hooks, but realise that there's a
distinction in degree which one can draw between them. Back to the
scheduled programming...)
Best wishes,
Norman
--
Norman Gray : http://nxg.me.uk
Dan Luecking
<khale...@eglug.org> wrote:
>On 22 Oct, 23:01, Dan Luecking <LookIn...@uark.edu> wrote:
>> On Fri, 22 Oct 2010 21:50:36 +0200, zappathustra
>>
>> <zappathus...@free.fr> wrote:
>> > �Le 22/10/2010 18:36, Marc van Dongen a �crit :
>> >3. Use LuaTeX; build a paragraph with first one linehanging, see if it
>> >fits, if not try two lines, see if it's ok, or three lines, and so on. I
>> >say ``Use LuaTeX,'' because that's the same method as above, except you
>> >don't need a wizard: you have callbacks
>>
>> What is a callback? And don't tell me to read the manual:
>> it has over 100 instances of the word callback and I gave
>> up trying to find out what they are after examining the
>> first 50 or so instances.
>
>Searching Google for "callback", the first hit is very helpful:
>
>http://en.wikipedia.org/wiki/Callback_(computer_science)
>
That is rather general, and doesn't impart a whole lot
of information to me. A good example, with the parts
explained and not too much (or no) code knowledge
required would be great. Also, more than one example
would be almost a requirement
So, having now read that page I can only say I'm glad
I had a good explanation already, as I would have been
unlikely to be able to apply what I learned there to
obtain much of an understanding of the luatex manual.
>> If callbacks are so great there should be a definition
>> of them and a few examples of their use.
>
>If it such a general computing term, I don't expect a software manual
>to define it, and there examples in the manual.
I would expect a manual that describes a programing language
to not assume too much. My programing knowledge includes
several obsolete languages (compiled, interpreted and
assembled), TeX, Metafont, some C (from "A Book of C"), small
bits of Perl (from some book I don't have at hand),
DOS/Windows/4NT batch file language and SAL (my editor's
control language). Not a single reference to "callback" in
the lot.
I haven't slogged through all of the manual (so much of it
depends on understanding things that are not explained),
so I can't say there are no examples, but could you point
to one that doesn't require one to know to much computer
science? TeX knowledge I think I can deal with.
zappathustra
> Dan, greetings.
>
> In article
> <d3157077-1bdb-490a...@g25g2000yqn.googlegroups.com>,
> Dan<luec...@uark.edu> wrote:
>
>> On Oct 22, 5:18 pm, zappathustra<zappathus...@free.fr> wrote:
>>> Le 22/10/2010 23:01, Dan Luecking a �crit :
>>>
>>>> What is a callback?
>>> For the moment: a callback is a point where you can interrupt TeX's
>>> normal operations,
>> It seems to me this is called a "hook" in most contexts. My editor's
>> macro or (TSE) calls them that and has a similar syntax for adding
>> a function call to them.
> (At the risk of drifting off-topic, and of splitting hairs:) I think
> they're basically the same thing, though I think that a callback may be
> a more general notion, since it includes the possibility that the object
> registering the callback may potentially have quite a bit of state, as
> opposed to being simply a block of code, which is how I think of a
> 'hook'.
I really don't know the difference between hooks, callbacks, etc., since
my knowledge of callbacks is limited to LuaTeX.
But my description was slightly misguiding: some callbacks simply add
code between TeX's normal operations but some others replace TeX's
processing. The "pre_linebreak_filter" illustrated here is just a gate
between unrestricted horizontal mode and the paragraph builder; i.e. the
function is inserted between the moment when TeX reads \par and the
moment it builds the paragraph, so to speak, two operations that are
normally contiguous. So this code replaces nothing. Such callbacks can
be spotted in the manual thanks to the sentence: ``This callback does
not replace any internal code.''
But the "linebreak_filter", for instance, does replace something: the
paragraph builder! So callbacks aren't simply additional code, they may
very well turn TeX into something quite different.
Best,
Paul
Taco Hoekwater
>>
>> If it such a general computing term, I don't expect a software manual
>> to define it, and there examples in the manual.
>
> I would expect a manual that describes a programing language
> to not assume too much.
The luatex reference manual is terse for a very simple reason:
it is exactly the level of documentation that I can force myself
to write even when my main focus is actually on the coding.
For as long as I am supposed to be a main manual writer as well
as a main programmer, the choice is between this terse format,
or no incremental updates to the reference manual, or no
development. It is simply not workable for me to attempt
proper coding and proper teaching at the same time.
Taco
Khaled Hosny
> >> If callbacks are so great there should be a definition
> >> of them and a few examples of their use.
>
> >If it such a general computing term, I don't expect a software manual
> >to define it, and there examples in the manual.
>
> I would expect a manual that describes a programing language
> to not assume too much.
I missed the part where luatex manual is "a manual that describes a
programming language", it is a software manual documenting a piece of
software, luatex, to the best of my knowledge, is not a programming
language. It is like expecting Emacs manual to discuss the terminology
of extending an editor by an extension language, just because it has a
Lisp extension.
Regards,
Khaled
zappathustra
Come on, folks, let's not start a petty war on this. LuaTeX is still
being developped, and as Taco has stated, he has better things to do
than write an introduction. Someday callbacks will be documented,
illustrated, etc., as will most parts of LuaTeX, without assuming much
knowledge about programming languages. You can't indeed understand much
about LuaTeX's callback from a general Wikipedia article (it produces no
enlightenment for me, and I use LuaTeX's callbacks everyday), but the
current manual is a technical document, where you find uninviting but
precise technical descriptions, for those who want (and have time) to
experiment with the program. The self-contained practical
introduction(s) is/are still to come, and it/they'll be no small
task(s), because from font loading and tweaking to node manipulation,
there'll be much to explain indeed.
Best,
Paul
Khaled Hosny
> Le 25/10/2010 21:29, Khaled Hosny a écrit :
>
> > On 25 Oct, 19:09, Dan Luecking<LookIn...@uark.edu> wrote:
> >>>> If callbacks are so great there should be a definition
> >>>> of them and a few examples of their use.
> >>> If it such a general computing term, I don't expect a software manual
> >>> to define it, and there examples in the manual.
> >> I would expect a manual that describes a programing language
> >> to not assume too much.
> > I missed the part where luatex manual is "a manual that describes a
> > programming language", it is a software manual documenting a piece of
> > software, luatex, to the best of my knowledge, is not a programming
> > language. It is like expecting Emacs manual to discuss the terminology
> > of extending an editor by an extension language, just because it has a
> > Lisp extension.
>
> Come on, folks, let's not start a petty war on this. LuaTeX is still
> being developped, and as Taco has stated, he has better things to do
> than write an introduction. Someday callbacks will be documented,
> illustrated, etc., as will most parts of LuaTeX, without assuming much
> knowledge about programming languages. You can't indeed understand much
> about LuaTeX's callback from a general Wikipedia article (it produces no
> enlightenment for me, and I use LuaTeX's callbacks everyday),
I did not say it does, I was just pointing that it is a general
programming concept not something the authors of luatex has invented
so it is very acceptable for them to not define it. The more
documentations the better no doubt, but the fact that we have an
extensive up to date manual for a piece of software under active
development is something you hardly and I happen to appreciate that
very much (compare it to the anaemic eTeX manual, or the almost non-
existent Omega documentation, or even the outdated pdfTeX manual).
Regards,
Khaled
Dan Luecking
<ta...@elvenkind.com> wrote:
>On 10/25/10 19:09, Dan Luecking wrote:
>>>
>>> If it such a general computing term, I don't expect a software manual
>>> to define it, and there examples in the manual.
>>
>> I would expect a manual that describes a programing language
>> to not assume too much.
>
>The luatex reference manual is terse for a very simple reason:
>it is exactly the level of documentation that I can force myself
>to write even when my main focus is actually on the coding.
Taco: I thank you so much for the efforts you put into luatex
(and metapost and everything else).
I was not criticizing the terseness of the manual, I was
merely explaining why I didn't find what I asked about
in the manual. I recognize that the manual is a reference
and not a text book. My specific comment above was solely
meant to express disagreement with the sentence quoted
above it about expectations.
If someone else could step in and write something that
supplied some of the explanations I seem to be missing,
I (and probably many others) would be ever so grateful.
Dan Luecking
<khale...@eglug.org> wrote:
>On 25 Oct, 19:09, Dan Luecking <LookIn...@uark.edu> wrote:
>> >> If callbacks are so great there should be a definition
>> >> of them and a few examples of their use.
>>
>> >If it such a general computing term, I don't expect a software manual
>> >to define it, and there examples in the manual.
>>
>> I would expect a manual that describes a programing language
>> to not assume too much.
>
>I missed the part where luatex manual is "a manual that describes a
>programming language", it is a software manual documenting a piece of
>software, luatex, to the best of my knowledge, is not a programming
>language.
I didn't say it was "a manual that describes a
programming language". The sentence was an analogy.
I chose it because I have a number of those manuals,
and none of them assumes I know any specialized
computer science terminology (and none mentions
callbacks).
Let me rephrase for you:
I would expect _any_ manual not to assume too much.
Very specifically: while I fully expected the luatex
manual to assume TeXbook level knowledge of TeX, eTeX
and pdfTeX, and some experience with the lua language,
I did not expect it to assume knowledge of jargon.
I realize my original comments could be taken as
criticism of the luatex manual, but it was more an
expression of frustration. I was replying to someone
touting callbacks as being so useful, when I couldn't
figure out what they _were_, much less how to use them.
>It is like expecting Emacs manual to discuss the terminology
>of extending an editor by an extension language, just because it has a
>Lisp extension.
I would expect _any_ terminology of _any_ sort used in
_any_ manual on _any_ subject, to be either within the
working knowledge of the average reader of the of the
manual, or else be first sufficiently described to allow
such a reader to understand the manual.
Will Robertson
> Taco: I thank you so much for the efforts you put into luatex
> (and metapost and everything else).
Seconded: many thanks again.
> I was not criticizing the terseness of the manual, I was
> merely explaining why I didn't find what I asked about
> in the manual. I recognize that the manual is a reference
> and not a text book.
Furthermore, I'm absolutely floored by the quality of the LuaTeX
manual, which is complete and detailed to a far greater degree than I
would expect for an evolving software project: fantastic effort.
Will
Taco Hoekwater
>
> I was not criticizing the terseness of the manual, I was
> merely explaining why I didn't find what I asked about
> in the manual. I recognize that the manual is a reference
> and not a text book. My specific comment above was solely
> meant to express disagreement with the sentence quoted
> above it about expectations.
I understood that that was what you meant (but I must say that
your good reputation helped in parsing your remarks. at first
glance your post did appear quite harsh, but then I figured you
could not have meant it that way).
> If someone else could step in and write something that
> supplied some of the explanations I seem to be missing,
> I (and probably many others) would be ever so grateful.
Seconded. If someone (looks at Paul expectantly ...) can write a
short introduction on the nature of callbacks in luatex, I will
happily add them to the reference manual.
Best wishes,
Taco
Dan Luecking
<ta...@elvenkind.com> wrote:
>On 10/26/2010 08:34 PM, Dan Luecking wrote:
>>
>> I was not criticizing the terseness of the manual, I was
>> merely explaining why I didn't find what I asked about
>> in the manual. I recognize that the manual is a reference
>> and not a text book. My specific comment above was solely
>> meant to express disagreement with the sentence quoted
>> above it about expectations.
>
>I understood that that was what you meant (but I must say that
>your good reputation helped in parsing your remarks. at first
>glance your post did appear quite harsh, but then I figured you
>could not have meant it that way).
I apologize for the harshness of my comments.
The manual listed no author, only "copyright: LuaTeX
development team", which suggested that the resources
available included more than just one person.
If I had known that there was only one person working on
the manual, and that this one person was also busy developing
the luatex program, I would have paused and softened my
comments before hitting send.