etex
chedva...@gmail.com
I have several suggestions to improve the e-tex program, particularly
in the context of right to left typesetting. Is there any group or
person in the world that prepare the future version of e-tex?
thx
Donald Arseneau
There is a mailing list for TeX implementors. You can probably find
a link for it on the tug web site.
--
Donald Arseneau as...@triumf.ca
Robin Fairbairns
i doubt there will be any further work on e-tex.
there are active projects that cover bidirectional typesetting,
notably ant (i think), extex and xetex.
a good way to proceed would be to put your suggestions on the web, and
then to post messages pointing to the site, to relevant addresses
(there are web links for all of them in the faq).
you may as well mail nts-l as well: it should get to the supposed etex
developers, but as i say, i think they've thrown in the towel
(developing substantial programs as change files for tex-the-program
isn't anyone's idea of fun[*], afaict.)
[*] scrub that. i expect jonathan fine believes it's fun, but he
doesn't[**] believe in e-tex, so he wouldn't have any sympathy with the
developers...
[**] or didn't last he mentioned it that i recall.
--
Robin Fairbairns, Cambridge
David Kastrup
> you may as well mail nts-l as well: it should get to the supposed
> etex developers, but as i say, i think they've thrown in the towel
> (developing substantial programs as change files for tex-the-program
> isn't anyone's idea of fun[*], afaict.)
>
> [*] scrub that. i expect jonathan fine believes it's fun, but he
> doesn't[**] believe in e-tex, so he wouldn't have any sympathy with
> the developers...
I don't think the question of fun arises with him, but he likely
considers non-Knuthian change files distasteful (as opposed to
changing the source directly, a sacrilege).
> [**] or didn't last he mentioned it that i recall.
It is cheating. You don't tell a chess master that you want to
challenge him to play with pawns that can move diagonally. It ruins
his openings.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Jonathan Fine
And LaTeX 3 has failed to deliver.
--
Jonathan
David Kastrup
> Both etex and NTS have failed to deliver the benefits they promised.
eTeX is used quite more often these days than the TeX daemon. It has
delivered what it promised: new useful primitives agreed upon by
committee. I use them, and they are indispensible. The eTeX project
itself is no longer active independently, but PDFTeX is used as a
similar platform for extension.
> And LaTeX 3 has failed to deliver.
And there is no tooth fairy, either.
Jonathan Fine
> eTeX is used quite more often these days than the TeX daemon.
This is, sadly, very true.
--
Jonathan
Jonathan Fine
The combination of TeX the program and the
LaTeX macros (format) doesn't do all we want
to do.
Some people have said that the fault lies
with TeX. That all would be better if TeX
were extended or replaced.
This was the motive for eTeX and NTS.
My view is otherwise. That it is LaTeX
that is the major cause of the limits.
And that ConTeXt shares the same limits.
--
Jonathan
David Kastrup
> Was Re: etex
>
> The combination of TeX the program and the
> LaTeX macros (format) doesn't do all we want
> to do.
>
> Some people have said that the fault lies
> with TeX. That all would be better if TeX
> were extended or replaced.
>
> This was the motive for eTeX and NTS.
>
> My view is otherwise. That it is LaTeX
> that is the major cause of the limits.
As somebody who has done serious TeX and LaTeX programming actually in
use in the field (as opposed to academical exercises), I beg to
differ. There are things you can't do reasonably in TeX without the
eTeX extensions.
Some of those things can be worked around with awfully complicated
constructs. Others can't. In either case, there is no reasonable
relation between efforts and results when using just TeX.
eTeX helps considerably. It can be likened to digging yourself out of
a dungeon cell by means of a spoon rather than your teeth.
> And that ConTeXt shares the same limits.
You are just making yourself ridiculous, since the common denominator
of LaTeX and ConTeXt is just plain TeX.
Jonathan Fine
> eTeX helps considerably. It can be likened to digging yourself out of
> a dungeon cell by means of a spoon rather than your teeth.
So why are we in a dungeon at all?
--
Jonathan
Jonathan Fine
To answer my own question.
One reason is that we are writing TeX macros to
do things when we would prefer to use XSLT,
Perl, Python and other more suitable languages.
--
Jonathan
David Kastrup
Michele Dondi
wrote:
>Subject: TeX is broken? LaTeX is broken?
No, only awkward. (Which?!? ;-)
Michele
--
>It's because the universe was programmed in C++.
No, no, it was programmed in Forth. See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel in sci.math, thread "Why numbers?"
Jonathan Fine
"David Kastrup" <d...@gnu.org> wrote in message
news:85odut3...@lola.goethe.zz...
> "Jonathan Fine" <J.F...@open.ac.uk> writes:
>
> > "David Kastrup" <d...@gnu.org> wrote
> >
> >> eTeX helps considerably. It can be likened to digging yourself out
> >> of a dungeon cell by means of a spoon rather than your teeth.
> >
> > So why are we in a dungeon at all?
>
> Because only typesetting trivial things is easy.
I don't agree. Much mathematical typesetting is
now easy, thanks to the hard-won knowledge that
TeX has about mathematical typography. Some of
this knowledge also resides in the macros, fonts
and so forth.
But I would not describe typesetting mathematics
as trivial (unless one already has TeX to hand),
and perhaps not easy then.
One of the purposes of computer software is to make
difficult things easier. For example, the
literature search. Or calculating your taxes.
The dungeon cell is your analogy, not mine. However,
perhaps it is possible simple to not walk into the
dungeon cell. How did that happen?
--
Jonathan
David Kastrup
Typesetting is a more diverse field than what is required for "The Art
of Computer Programming", and TeX is designed for the latter.
Taco Hoekwater
> "chedva...@gmail.com" <chedva...@gmail.com> writes:
>
>>I have several suggestions to improve the e-tex program, particularly
>>in the context of right to left typesetting. Is there any group or
>>person in the world that prepare the future version of e-tex?
>
>
> i doubt there will be any further work on e-tex.
>
> there are active projects that cover bidirectional typesetting,
> notably ant (i think), extex and xetex.
As well as LuaTeX (pdfTeX's successor) and Omega2. Both developments
were subject of talks at EuroTeX this year.
> a good way to proceed would be to put your suggestions on the web, and
> then to post messages pointing to the site, to relevant addresses
> (there are web links for all of them in the faq).
> you may as well mail nts-l as well: it should get to the supposed etex
> developers, but as i say, i think they've thrown in the towel
> (developing substantial programs as change files for tex-the-program
> isn't anyone's idea of fun[*], afaict.)
PdfTeX (which incorporates eTeX) has quite a number of new eTeX-style
extensions, so you may want to check that out as well.
Greetings,
Taco
chedva...@gmail.com
> "Jonathan Fine" <J.F...@open.ac.uk> writes:
> As somebody who has done serious TeX and LaTeX programming actually in
> use in the field (as opposed to academical exercises), I beg to
> differ. There are things you can't do reasonably in TeX without the
> eTeX extensions.
>
> Some of those things can be worked around with awfully complicated
> constructs. Others can't. In either case, there is no reasonable
> relation between efforts and results when using just TeX.
>
> eTeX helps considerably. It can be likened to digging yourself out of
> a dungeon cell by means of a spoon rather than your teeth.
Thank you all for your answers.
I completely agree with you David. I have developed a plain Tex
compatible format for right to left typesetting (HebTeX) that has at
least the power of Latex. It is a monumental work, and I couldn't have
done this without the features of e-Tex. But yet, there are things that
are disproportionally difficult (ex: to implant margin notes that
takes into account the depth of the line it is called from, what needs
three passes in the output routine), and other things that are (If I
am not mistaken) impossible (ex: 1) to create macros that process
tables with an arbitrary number of columns, with separation rules that
stretch equally 2) to insert in the margin beside each display formula
the number of the line of the source file it is called from, without
disturbing nothing in the process' of display formulae 3) to make Tex
calculate the width of the line of the paragraph following a display
formula and to use \belowdisplayshortskip or \belowdisplayskip
according as the display formula is 2em larger than this line or not,
as what is done automatically by TeX for the line preceeding display
formulae ). Even more problems occur for right to left typesetting: in
the color process or hyperling process, one usually uses \specials to
insert commands directed to the drivers. All things work fine for left
to right typesetting, but not at all for right to left one; indeed, the
drivers always read a file from left to right, so a command such as
\begincolor ... \endcolor will not at all do what we want: an
insoluble problem. Surprisingly enough, most of the problems evoqued
here (and others), could have very simple solutions of type "to make
some (preexisting) dimension informations available to the user", and
other solutions that lie in the creation of simple primitive commands.
I would like to suggest these solutions to those who develop extentions
of Tex.
David Kastrup
> David Kastrup wrote:
>> "Jonathan Fine" <J.F...@open.ac.uk> writes:
>
>> As somebody who has done serious TeX and LaTeX programming actually
>> in use in the field (as opposed to academical exercises), I beg to
>> differ. There are things you can't do reasonably in TeX without
>> the eTeX extensions.
>>
>> Some of those things can be worked around with awfully complicated
>> constructs. Others can't. In either case, there is no reasonable
>> relation between efforts and results when using just TeX.
>>
>> eTeX helps considerably. It can be likened to digging yourself out
>> of a dungeon cell by means of a spoon rather than your teeth.
>
> Thank you all for your answers.
> I completely agree with you David. I have developed a plain Tex
> compatible format for right to left typesetting (HebTeX) that has at
> least the power of Latex.
That is a strong claim.
> It is a monumental work, and I couldn't have done this without the
> features of e-Tex. But yet, there are things that are
> disproportionally difficult (ex: to implant margin notes that takes
> into account the depth of the line it is called from, what needs
> three passes in the output routine),
Using struts to achieve a constant depth can help.
> and other things that are (If I am not mistaken) impossible (ex: 1)
> to create macros that process tables with an arbitrary number of
> columns, with separation rules that stretch equally
&& template \cr does not help?
> 2) to insert in the margin beside each display formula the number of
> the line of the source file it is called from, without disturbing
> nothing in the process' of display formulae
Actually, in LaTeX showkeys.sty does a pretty good job at something
similar.
chedva...@gmail.com
> > I completely agree with you David. I have developed a plain Tex
> > compatible format for right to left typesetting (HebTeX) that has at
> > least the power of Latex.
>
> That is a strong claim.
Well, I don't say that all the packages that thousands of people
developed for Latex are available for my format, but it gives very good
tools (in my opionion better than Latex), and has all one needs for
mathematical typesetting (margin notes, cross referencing environment,
multiple column envir., comment and verbatim environ. etc.).
Furthermore, it is built on the basis of bidirectional design, and last
but not least for hebrew typesetters, has all things needed for hebrew
typesetting.
> > It is a monumental work, and I couldn't have done this without the
> > features of e-Tex. But yet, there are things that are
> > disproportionally difficult (ex: to implant margin notes that takes
> > into account the depth of the line it is called from, what needs
> > three passes in the output routine),
> Using struts to achieve a constant depth can help.
Of course, I know this, but what happens if a box of depth greater that
the strut appears in the line, and even if not, the natural
\baselineskip stretching would be broken for this particular line.
> > and other things that are (If I am not mistaken) impossible (ex: 1)
> > to create macros that process tables with an arbitrary number of
> > columns, with separation rules that stretch equally
> && template \cr does not help?
I know this too, and I have designed several table macros that use the
&& feature. The problem is, as I said, to create macros that process
tables with an arbitrary number of columns, WITH SEPARATION RULES THAT
STRETCH EQUALLY (see "TeX by Topics, a Texnician's reference" by Victor
Eijkhout, p.186 end of section 25.3.4).
> > 2) to insert in the margin beside each display formula the number of
> > the line of the source file it is called from, without disturbing
> > nothing in the process' of display formulae
> Actually, in LaTeX showkeys.sty does a pretty good job at something
> similar.
Well, I am interrested in knowing what LaTeX showkeys precisely does,
and how it does it.
Michael.
David Kastrup
>> > Thank you all for your answers. I completely agree with you
>> > David. I have developed a plain Tex compatible format for right
>> > to left typesetting (HebTeX) that has at least the power of
>> > Latex.
>>
>> That is a strong claim.
>
> Well, I don't say that all the packages that thousands of people
> developed for Latex are available for my format, but it gives very
> good tools (in my opionion better than Latex), and has all one needs
> for mathematical typesetting (margin notes, cross referencing
> environment, multiple column envir., comment and verbatim
> environ. etc.).
Multipage tables, language listings with highlighted keywords, support
of input and fonts with multiple encodings (and translating \"a into a
single letter in appropriate encodings, permitting hyphenation and
kerning), cross referencing across documents, the facilities of
AMSLaTeX (listing them all would be tedious), and quite a bit of other
stuff...
>> > and other things that are (If I am not mistaken) impossible (ex:
>> > 1) to create macros that process tables with an arbitrary number
>> > of columns, with separation rules that stretch equally
>
>> && template \cr does not help?
>
> I know this too, and I have designed several table macros that use
> the && feature. The problem is, as I said, to create macros that
> process tables with an arbitrary number of columns, WITH SEPARATION
> RULES THAT STRETCH EQUALLY (see "TeX by Topics, a Texnician's
> reference" by Victor Eijkhout, p.186 end of section 25.3.4).
It is probably easiest to add a prototype row with empty boxes to a
table at the end, deconstruct and measure the stuff, and use it to
insert appropriate info at the front next pass round. longtable.sty
does something like that.
chedva...@gmail.com
> > developed for Latex are available for my format, but it gives very
> > good tools (in my opionion better than Latex), and has all one needs
> > for mathematical typesetting (margin notes, cross referencing
> > environment, multiple column envir., comment and verbatim
> > environ. etc.).
>
> Multipage tables, language listings with highlighted keywords, support
> of input and fonts with multiple encodings (and translating \"a into a
> single letter in appropriate encodings, permitting hyphenation and
> kerning), cross referencing across documents, the facilities of
> AMSLaTeX (listing them all would be tedious), and quite a bit of other
> stuff...
Ok. I admit: HebTex do not have the power of Latex. It has at least the
power of what is described in Latex 2e user guide by Leslie Lamport,
1994 (excepted the graphic features, because I believe metapost, xypics
or others do a much better job). According to what you described, Latex
probably evoluated since 1994.
> >> > and other things that are (If I am not mistaken) impossible (ex:
> >> > 1) to create macros that process tables with an arbitrary number
> >> > of columns, with separation rules that stretch equally
> >
> >> && template \cr does not help?
> >
> > I know this too, and I have designed several table macros that use
> > the && feature. The problem is, as I said, to create macros that
> > process tables with an arbitrary number of columns, WITH SEPARATION
> > RULES THAT STRETCH EQUALLY (see "TeX by Topics, a Texnician's
> > reference" by Victor Eijkhout, p.186 end of section 25.3.4).
>
> It is probably easiest to add a prototype row with empty boxes to a
> table at the end, deconstruct and measure the stuff, and use it to
> insert appropriate info at the front next pass round. longtable.sty
> does something like that.
I am not sure that this is what I meant, but if so, this comes in the
rubric "things that are disproportionally difficult to do with e-tex".
I will have a look at longtable.sty.
chedva...@gmail.com
> > the line of the source file it is called from, without disturbing
> > nothing in the process' of display formulae
>
> Actually, in LaTeX showkeys.sty does a pretty good job at something
> similar.
I had a look at showkeys.sty. What is done there is not at all similar
to what I asked: showkeys only put keys in margin for labels that are
called from ordinary paragraphs, what is not difficult to do as soon as
one has designed a \marginnote macro; what is asked is a method to put
keys in margins BESIDE DISPLAY FORMULAE, or even more difficult, to
create a \marginnote macro that work even if called inside a display
formula, all this without disturbing \eqno, math \halign etc.
Morten Høgholm
No, showkeys works for display math as well - there are even examples in
the manual.
--
Morten
chedva...@gmail.com
> the manual.
True, I have missed this. But it works in a very "dirty" way, and in
fact, it would work very bad (or wouln't work at all) if the user would
define, say, his own math environments. Furthermore, even if it works,
it puts the keys sometimes near the math formula, and sometimes in the
margin, what is not uniform and elegant. In a word, I persist to say
that even with e-tex, there is no good solutions to this problem: what
is needed is a new primitive that put a whatsit item at the beginning
of the line it is called from, at the reference point position. Such a
primitive would not only solve the above problem, but also give a very
simple and natural solution to the problem of making margin note
macros.
Jonathan Fine
> margin, what is not uniform and elegant. In a word, I persist to say
> that even with e-tex, there is no good solutions to this problem: what
> is needed is a new primitive that put a whatsit item at the beginning
> of the line it is called from, at the reference point position. Such a
> primitive would not only solve the above problem, but also give a very
> simple and natural solution to the problem of making margin note
> macros.
TeX (not pdfTeX) is currently used to produce dvi files.
However, by tracingoutput it can be made to produce boxes.
These boxes can then be read and manipulated by an
external program.
I outline this in my 2005 EuroTeX paper:
http://www.pytex.org/doc/index.html#eurotex2005
Now for your requested new primitive.
Have your macros place a special, say
\special{chedva:xxx}
at appropriate points in your document.
Then process the output boxes to migrate these specials
to the desired locations.
If you don't believe me, try doing as you say. Write
your macros, and add
\tracingoutput = 1
\showboxbreadth = \maxdimen
\showboxdepth = \maxdimen
to the top of your document.
Then look at the log file. It will contain all the
information you need, to do your subsequent
processing.
BTW, given that TeX should be producing boxes rather
than dvi, then pdfTeX is most definitely a step in
the wrong direction.
More exactly, using David K's analogy, it locks
you deeper in the dungeon cell (while perhaps
giving you some 'extras' as consolation).
--
Jonathan
David Kastrup
> <chedva...@gmail.com> wrote
>
>> margin, what is not uniform and elegant. In a word, I persist to say
>> that even with e-tex, there is no good solutions to this problem: what
>> is needed is a new primitive that put a whatsit item at the beginning
>> of the line it is called from, at the reference point position. Such a
>> primitive would not only solve the above problem, but also give a very
>> simple and natural solution to the problem of making margin note
>> macros.
>
> TeX (not pdfTeX) is currently used to produce dvi files.
> However, by tracingoutput it can be made to produce boxes.
>
> These boxes can then be read and manipulated by an
> external program.
>
> I outline this in my 2005 EuroTeX paper:
> http://www.pytex.org/doc/index.html#eurotex2005
You have a penchant for infeasible "solutions". Of course, that
neither you nor anybody else is able to apply them to real-world
problems will not convince you otherwise.
Jonathan Fine
> You have a penchant for infeasible "solutions". Of course, that
> neither you nor anybody else is able to apply them to real-world
> problems will not convince you otherwise.
It is you, not I, who is digging their way out
of a dungeon cell with a spoon.
--
Jonathan
David Kastrup
Well, at least I don't waste my time proving it should be possible to
use cardboard for fabricating a spoon twice the size.
Jonathan Fine
"David Kastrup" <d...@gnu.org> wrote
> > It is you, not I, who is digging their way out
> > of a dungeon cell with a spoon.
>
> Well, at least I don't waste my time proving it should be possible to
> use cardboard for fabricating a spoon twice the size.
Nor do I. Does anyone?
--
Jonathan
Heiko Oberdiek
> TeX (not pdfTeX) is currently used to produce dvi files.
> However, by tracingoutput it can be made to produce boxes.
>
> These boxes can then be read and manipulated by an
> external program.
> Have your macros place a special, say
> \special{chedva:xxx}
> at appropriate points in your document.
>
> Then process the output boxes to migrate these specials
> to the desired locations.
>
> If you don't believe me, try doing as you say. Write
> your macros, and add
> \tracingoutput = 1
> \showboxbreadth = \maxdimen
> \showboxdepth = \maxdimen
> to the top of your document.
>
> Then look at the log file. It will contain all the
> information you need, to do your subsequent
> processing.
Jonathan, you should know TeX better. The .log file isn't
reliable. The mapping between a TeX box and the output
of \showbox isn't injective:
\showboxbreadth=\maxdimen
\showboxdepth=\maxdimen
\tracingonline=1
\def\a{0123456789}
\def\b{\a\a\a\a\a\a\a}
\def\c{\b funny text}
\setbox0=\hbox{\special{\b}}
\setbox1=\hbox{\special{\c}}
\showbox0
\showbox1
\bye
The boxes differ, but TeX truncates the output and
the difference isn't shown in the .log file.
Another example, it is easy to fool you about the contents
of a box:
\showboxbreadth=\maxdimen
\showboxdepth=\maxdimen
\tracingonline=1
\setbox0=\hbox{XYZ}
\showbox0
\newlinechar=10
\def\x{%
tenrm X^^J.\string\tenrm\space Y^^J.\string\tenrm%
}
\expandafter\font\csname\x\endcsname=cmssbx10 scaled 2000
\setbox1=\hbox{\csname\x\endcsname Z}
\ht1=\ht0
\wd1=\wd0
\showbox1
\box0
\kern20pt
\box1
\bye
You can see even in the DVI output that the boxes differ, but
in the .log file both boxes are equal.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
> Jonathan, you should know TeX better. The .log file isn't
> reliable. The mapping between a TeX box and the output
> of \showbox isn't injective:
To simplify matters, I did not tell the full truth.
There are exceptions, which you have found.
> \showboxbreadth=\maxdimen
> \showboxdepth=\maxdimen
> \tracingonline=1
> \def\a{0123456789}
> \def\b{\a\a\a\a\a\a\a}
> \def\c{\b funny text}
> \setbox0=\hbox{\special{\b}}
> \setbox1=\hbox{\special{\c}}
> \showbox0
> \showbox1
> \bye
>
> The boxes differ, but TeX truncates the output and
> the difference isn't shown in the .log file.
I am well aware that the log file truncates the
contents of specials and writes and marks.
I doubt that this will in practice be a problem.
> Another example, it is easy to fool you about the contents
> of a box:
I've studied your example below, and would not
describe it as easy. Or at all likely to arise
in practice.
However, it shows a formidable knowledge of TeX
arcana.
> \showboxbreadth=\maxdimen
> \showboxdepth=\maxdimen
> \tracingonline=1
>
> \setbox0=\hbox{XYZ}
> \showbox0
>
> \newlinechar=10
> \def\x{%
> tenrm X^^J.\string\tenrm\space Y^^J.\string\tenrm%
> }
> \expandafter\font\csname\x\endcsname=cmssbx10 scaled 2000
> \setbox1=\hbox{\csname\x\endcsname Z}
> \ht1=\ht0
> \wd1=\wd0
> \showbox1
>
> \box0
> \kern20pt
> \box1
> \bye
>
> You can see even in the DVI output that the boxes differ, but
> in the .log file both boxes are equal.
Yes, indeed. And you have achieved this by defining
a font that has a most unusual name. The font name
contains newline characters, and that is why the
trick works.
More worrying, and something that has bitten me in
practice, is something like
\font\xxivrm cmr10 at 25pt \hbox{\xxivrm ABC}
\font\xxivrm cmr10 at 24.8pt \hbox{\xxivrm ABC}
I think the esoteric and limited nature of the
exceptions indicates that in practice this process
can be made to work.
And thank you Heiko, for the unusual font name.
Certainly a cunning hack.
--
Jonathan
David Kastrup
> "Heiko Oberdiek" <ober...@uni-freiburg.de> wrote
>
>> Jonathan, you should know TeX better. The .log file isn't
>> reliable. The mapping between a TeX box and the output
>> of \showbox isn't injective:
>
> To simplify matters, I did not tell the full truth.
If the ultimate goal is showing off, this may simplify matters. If
the ultimate goal is getting a working solution, it is oversimplifying
matters.
The condescension you demonstrate by intentionally misleading people
is not making a compelling case.
Jonathan Fine
"David Kastrup" <d...@gnu.org> wrote
> If the ultimate goal is showing off, this may simplify matters. If
> the ultimate goal is getting a working solution, it is oversimplifying
> matters.
>
> The condescension you demonstrate by intentionally misleading people
> is not making a compelling case.
David. You are, by your own admission, in a
dungeon cell, slowly excavating your way to
freedom armed only with a spoon (and your
sharp wit, of course).
I have come to help you, and you reject my
help, and are in addition rude.
Stay in the dungeon if you wish.
--
Jonathan
Heiko Oberdiek
> "Heiko Oberdiek" <ober...@uni-freiburg.de> wrote
>
> > Jonathan, you should know TeX better. The .log file isn't
> > reliable. The mapping between a TeX box and the output
> > of \showbox isn't injective:
>
> To simplify matters, I did not tell the full truth.
> There are exceptions, which you have found.
>
> > \showboxbreadth=\maxdimen
> > \showboxdepth=\maxdimen
> > \tracingonline=1
> > \def\a{0123456789}
> > \def\b{\a\a\a\a\a\a\a}
> > \def\c{\b funny text}
> > \setbox0=\hbox{\special{\b}}
> > \setbox1=\hbox{\special{\c}}
> > \showbox0
> > \showbox1
> > \bye
> >
> > The boxes differ, but TeX truncates the output and
> > the difference isn't shown in the .log file.
>
> I am well aware that the log file truncates the
> contents of specials and writes and marks.
>
> I doubt that this will in practice be a problem.
For example, you cannot compare the contents of boxes
in a reliable way.
> > Another example, it is easy to fool you about the contents
> > of a box:
>
> I've studied your example below, and would not
> describe it as easy. Or at all likely to arise
> in practice.
It proofs that the .log file cannot be parsed in a reliable
way.
> However, it shows a formidable knowledge of TeX
> arcana.
For the successfully fooling example, yes. But it is
enough to have code that disturb parsing the .log
file.
> More worrying, and something that has bitten me in
> practice, is something like
> \font\xxivrm cmr10 at 25pt \hbox{\xxivrm ABC}
> \font\xxivrm cmr10 at 24.8pt \hbox{\xxivrm ABC}
Good example. It shows that the data in the .log
file aren't sufficient, the used font is unknown.
> I think the esoteric and limited nature of the
> exceptions indicates that in practice this process
> can be made to work.
These are examples that proof that your way parsing
the .log file is impossible and not reliable.
I don't want to have code that succeeds by pure luck.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
David Kastrup
> "David Kastrup" <d...@gnu.org> wrote
>
>> If the ultimate goal is showing off, this may simplify matters. If
>> the ultimate goal is getting a working solution, it is oversimplifying
>> matters.
>>
>> The condescension you demonstrate by intentionally misleading people
>> is not making a compelling case.
>
> David. You are, by your own admission, in a
> dungeon cell, slowly excavating your way to
> freedom armed only with a spoon (and your
> sharp wit, of course).
>
> I have come to help you,
By offering a cardboard spoon? If you yourself know your "help" to be
non-workable, you'll have to pardon me if I consider the loss of it
not really lamentable.
> and you reject my help, and are in addition rude.
By calling a non-spade a non-spade?
> Stay in the dungeon if you wish.
That's not correlated in either way to your intellectual games.
chedva...@gmail.com
> However, by tracingoutput it can be made to produce boxes.
>
> These boxes can then be read and manipulated by an
> external program.
>
> I outline this in my 2005 EuroTeX paper:
> http://www.pytex.org/doc/index.html#eurotex2005
This is of course a disproportionally difficult solution. I don't
understand why adopt solutions like this, while it would suffice to add
a dozen of new simple primitives to e-tex to make it a really PERFECT
mathematical typesetting program, that allow us to do everything in a
reasonable way.
David Kastrup
>> TeX (not pdfTeX) is currently used to produce dvi files.
>> However, by tracingoutput it can be made to produce boxes.
>>
>> These boxes can then be read and manipulated by an
>> external program.
>>
>> I outline this in my 2005 EuroTeX paper:
>> http://www.pytex.org/doc/index.html#eurotex2005
>
> This is of course a disproportionally difficult solution. I don't
> understand why adopt solutions like this,
Nobody is adopting them, including Jonathan himself. He is merely
proposing them.
> while it would suffice to add a dozen of new simple primitives to
> e-tex to make it a really PERFECT mathematical typesetting program,
> that allow us to do everything in a reasonable way.
Now _you_ are having your head in the clouds.
Jonathan Fine
news:1155218970.4...@i3g2000cwc.googlegroups.com...
This is, in my view, a more reasonable response. Namely
that it is a solution, but that it is unduly difficult.
I doubt that adding 12 primitives would make etex PERFECT.
After all, how many primitives have they added already?
And how much closer to PERFECT did that bring us?
--
Jonathan
Jonathan Fine
> These are examples that proof that your way parsing
> the .log file is impossible and not reliable.
Yes, that is the case for some very special out of all
the possible log files.
But in practice the exceptions can, in my view, be
avoided.
> I don't want to have code that succeeds by pure luck.
Nor do I. I suggest you follow this google search on
hyperref and conflict.
<http://groups.google.co.uk/groups/search?q=hyperref+conflict&hl=en&>
This will give some examples of the dangers in code
that has (unpredictable) side effects.
--
Jonathan
Jonathan Fine
"David Kastrup" <d...@gnu.org>
> Nobody is adopting them, including Jonathan himself. He is merely
> proposing them.
I would adopt them, if I had sufficient resources
to develop them. But for now, all I can do is
promote the idea.
And hope that some of the spoon-wielding inhabitants
of the LaTeX dungeon (oh - that will confuse the
search engines) will join my efforts.
--
Jonathan
chedva...@gmail.com
> After all, how many primitives have they added already?
They don't add so many primitives (~ 35), 1/3 of them are tracing
primitives, and many of them are not really new conceptual primitives,
but only extentions of existing ones.
> And how much closer to PERFECT did that bring us?
Much Much closer, trust me.
David Kastrup
I am afraid that our notions of either "perfect" or "much closer"
don't quite agree.
Jonathan Fine
"David Kastrup" <d...@gnu.org> wrote in message
news:853bc4h...@lola.goethe.zz...
> "chedva...@gmail.com" <chedva...@gmail.com> writes:
>
> >> I doubt that adding 12 primitives would make etex PERFECT.
> >> After all, how many primitives have they added already?
> >
> > They don't add so many primitives (~ 35), 1/3 of them are tracing
> > primitives, and many of them are not really new conceptual primitives,
> > but only extentions of existing ones.
> >
> >> And how much closer to PERFECT did that bring us?
> >
> > Much Much closer, trust me.
>
> I am afraid that our notions of either "perfect" or "much closer"
> don't quite agree.
I'm with David on this one. He really is in the
dungeon.
This is, in my view, a consequence of using TeX
macro programming language to do things that
are well outside its real capabilities.
And so applies whenever LaTeX is used to solve
'tricky' and 'advanced' problems.
As I said in the subject:
TeX is broken? LaTeX is broken?
--
Jonathan
chedva...@gmail.com
> don't quite agree.
1) right to left typesetting would not be possible without \beginR..
\endR, so TeX simply do not allow right to left typesetting.
2) \marks n allows many things that would be impossible with TeX
3) as I developed calendar conversion macros (and the hebrew calendar
is very complicated), the expressional features of e-tex made things
much more easier.
4) \protected is a very useful primitive, isn't it?
4) \detokenize, \scantokens, \lastnodetype, \currentgrouplevel
simplifies greatly the work with TeX.
I don' t know what you expect from e-tex, but for what I expect, it
would suffice about 20 new primitives (I correct "a dozen") to make it
PERFECT. If you don't thing so, let me know a list of problems that
can't be solved in a reasonable way, if one allow 20 more new
primitives.
Robin Fairbairns
>David. You are, by your own admission, in a
>dungeon cell, slowly excavating your way to
>freedom armed only with a spoon (and your
>sharp wit, of course).
what he actually wrote:
eTeX helps considerably. It can be likened to digging yourself out
of a dungeon cell by means of a spoon rather than your teeth.
as you can see, he likens your situation to digging yourself out with
your teeth.
>I have come to help you, and you reject my help,
you appear to believe that partial solutions are good enough.
practical computer scientists tend to know, from bitter experience,
that the once-in-a-lifetime extraordinary case is likely to turn up
tomorrow: it's no surprise, to me, that david rejects your
"solution". (inverted quotes, because it has to be said that your
proposal seems not to be offered in the context of practical support.)
>and are in addition rude.
david is rude to everyone. however, he's practical and remarkably
often very helpful, so sensible people accept his contributions with
good grace.
>Stay in the dungeon if you wish.
on my reckoning, he'll be gone long before you're calling for the
jailer to bring you a dentist.
--
Robin Fairbairns, Cambridge
David Kastrup
>> I am afraid that our notions of either "perfect" or "much closer"
>> don't quite agree.
>
> 1) right to left typesetting would not be possible without \beginR..
> \endR, so TeX simply do not allow right to left typesetting.
> 2) \marks n allows many things that would be impossible with TeX
> 3) as I developed calendar conversion macros (and the hebrew calendar
> is very complicated), the expressional features of e-tex made things
> much more easier.
> 4) \protected is a very useful primitive, isn't it?
> 4) \detokenize, \scantokens, \lastnodetype, \currentgrouplevel
> simplifies greatly the work with TeX.
Yes? Do you even bother to distinguish your discussion partners? It
was not me that claimed e-TeX was useless.
> I don' t know what you expect from e-tex, but for what I expect, it
> would suffice about 20 new primitives (I correct "a dozen") to make
> it PERFECT.
Oh, naturally a single one switching to a perfect system would be
completely sufficient. But if we are talking about "primitive that
has an impact on the existing code comparable to existing primitives",
then I am afraid that 20 does not cut it.
Robin Fairbairns
>
>Nor do I. I suggest you follow this google search on
>hyperref and conflict.
> <http://groups.google.co.uk/groups/search?q=hyperref+conflict&hl=en&>
>
>This will give some examples of the dangers in code
>that has (unpredictable) side effects.
cheap (and feeble) jibe.
when you get to the position of maintaining something that's as widely
used and is as much of a boon to its users as is hyperref, you'll
start to realise quite _how_ feeble the jibe was.
--
Robin Fairbairns, Cambridge
Jonathan Fine
<snip>
> cheap (and feeble) jibe.
Yes. Perhaps it was. Although no justification,
I think I was replying in kind.
Gandhi said "An eye for eye only ends up
making the whole world blind."
However, I think the subject of this thread is one
well worth discussing.
--
Jonathan
Heiko Oberdiek
> "Heiko Oberdiek" <ober...@uni-freiburg.de> wrote
>
> > These are examples that proof that your way parsing
> > the .log file is impossible and not reliable.
>
> Yes, that is the case for some very special out of all
> the possible log files.
Only some special .log files can be parsed.
> But in practice the exceptions can, in my view, be
> avoided.
You have already given a counterexample yourself.
> > I don't want to have code that succeeds by pure luck.
>
> Nor do I. I suggest you follow this google search on
> hyperref and conflict.
> <http://groups.google.co.uk/groups/search?q=hyperref+conflict&hl=en&>
>
> This will give some examples of the dangers in code
> that has (unpredictable) side effects.
hyperref is a good example for the many nasty workarounds due to
limitations of TeX.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
"Heiko Oberdiek" <ober...@uni-freiburg.de> wrote
> hyperref is a good example for the many nasty workarounds due to
> limitations of TeX.
Here we have the nub of it. In my view:
hyperref is a good example for the many nasty workarounds due to
limitations of LaTeX.
See subject: TeX is broken? LaTeX is broken?
--
Jonathan
David Kastrup
I'd say your record is broken. Your favorite solution of
LaTeX-bashing is no substitute for doing serious typesetting work.
And it gets more ridiculous if you add ConTeXt-bashing to it, since
the only common denominator of those two is plain TeX. So what does
this tell you, if all encompassing typesetting solutions employing TeX
are "broken"? The most benevolent conclusion should be that you can't
expect anybody but yourself to come up with a non-broken system on
command.
So you should stop pestering others and do it yourself if you think it
feasible.
Jonathan Fine
> I'd say your record is broken.
Yes, there is an element of repetition ...
repetition ... repetition ... repetition ...
in this discussion.
Like a broken record.
> Your favorite solution of
> LaTeX-bashing is no substitute for doing serious typesetting work.
And your favourite solution of TeX-bashing ...
Oh - I'm falling into the 'eye for an eye makes the
world blind' trap.
--
Jonathan
David Kastrup
> "David Kastrup" <d...@gnu.org> wrote
>
>> I'd say your record is broken.
>
> Yes, there is an element of repetition ...
> repetition ... repetition ... repetition ...
> in this discussion.
>
> Like a broken record.
>
>> Your favorite solution of
>> LaTeX-bashing is no substitute for doing serious typesetting work.
>
> And your favourite solution of TeX-bashing ...
In contrast to you, I happen to be doing serious typesetting work
employing TeX and LaTeX.
> Oh - I'm falling into the 'eye for an eye makes the world blind'
> trap.
You wish.
Jonathan Fine
> In contrast to you, I happen to be doing serious typesetting work
> employing TeX and LaTeX.
No contrast. Same for me. And I also face real problems.
But this is, I think, off-topic.
--
Jonathan
David Kastrup
> "David Kastrup" <d...@gnu.org> wrote
>
>> In contrast to you, I happen to be doing serious typesetting work
>> employing TeX and LaTeX.
>
> No contrast. Same for me. And I also face real problems.
Too bad we only get to see your toy problems.
Jonathan Fine
> "Jonathan Fine" <J.F...@open.ac.uk> writes:
>
> > "David Kastrup" <d...@gnu.org> wrote
> >
> >> In contrast to you, I happen to be doing serious typesetting work
> >> employing TeX and LaTeX.
> >
> > No contrast. Same for me. And I also face real problems.
>
> Too bad we only get to see your toy problems.
Not so. Two days ago I posted "diff for boxes":
http://groups.google.co.uk/group/comp.text.tex/msg/e431a571b61dd32c
Worth comparing with "diff for dvi files", from Michael Downes:
http://groups.google.co.uk/group/comp.text.tex/msg/d8b00c7a936e62d4
Note that diff for boxes is highly relevant for shipping
out boxes from TeX, and reprocessing them.
--
Jonathan
David Kastrup
> "David Kastrup" <d...@gnu.org> wrote in message
> news:85irl0e...@lola.goethe.zz...
>> "Jonathan Fine" <J.F...@open.ac.uk> writes:
>>
>> > "David Kastrup" <d...@gnu.org> wrote
>> >
>> >> In contrast to you, I happen to be doing serious typesetting work
>> >> employing TeX and LaTeX.
>> >
>> > No contrast. Same for me. And I also face real problems.
>>
>> Too bad we only get to see your toy problems.
>
> Not so. Two days ago I posted "diff for boxes":
> http://groups.google.co.uk/group/comp.text.tex/msg/e431a571b61dd32c
>
> Worth comparing with "diff for dvi files", from Michael Downes:
> http://groups.google.co.uk/group/comp.text.tex/msg/d8b00c7a936e62d4
>
> Note that diff for boxes is highly relevant for shipping
> out boxes from TeX, and reprocessing them.
So what kind of books have been typeset using that technique?
Jonathan Fine
> > Note that diff for boxes is highly relevant for shipping
> > out boxes from TeX, and reprocessing them.
>
> So what kind of books have been typeset using that technique?
At this time, sadly, none.
But I am sure that the future lies in that direction.
--
Jonathan
"It is better to light one candle than to curse the
darkness." - Chinese proverb
David Kastrup
> "David Kastrup" <d...@gnu.org> wrote
>
>> > Note that diff for boxes is highly relevant for shipping
>> > out boxes from TeX, and reprocessing them.
>>
>> So what kind of books have been typeset using that technique?
>
> At this time, sadly, none.
I guess we have a different notion of "serious typesetting work" then.
Mine happens to involve the production of books.
> But I am sure that the future lies in that direction.
Your track record of predicting the future in TeX development is not
exactly making me hold my breath.
Heiko Oberdiek
> "Heiko Oberdiek" <ober...@uni-freiburg.de> wrote
>
> > hyperref is a good example for the many nasty workarounds due to
> > limitations of TeX.
>
> Here we have the nub of it. In my view:
> hyperref is a good example for the many nasty workarounds due to
> limitations of LaTeX.
And many of these limitations of LaTeX are due to limitations of TeX.
Transitvity yields my original hypothesis.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
Heiko, earlier in this thread I said, as I recall
TeX = TeX the program
LaTeX = macros written for use with TeX
I'll repeat my view.
It is not TeX that is broken, it is LaTeX.
(Although LaTeX + TeX is fine for ordinary articles,
theses and books. It's the harder stuff where the
problems arise.)
--
Jonathan
Brooks Moses
> I don' t know what you expect from e-tex, but for what I expect, it
> would suffice about 20 new primitives (I correct "a dozen") to make it
> PERFECT. If you don't thing so, let me know a list of problems that
> can't be solved in a reasonable way, if one allow 20 more new
> primitives.
First, an example of something that cannot be solved without changing a
fundamental key component of the TeX language:
* Declaring fractions with \over _after_ the numerator means that one
cannot know whether a given bit of mathematics is in text style or
display style when it is being processed; see section 4 of the
_Technical Notes on the AMSMATH Package_ for details and why this makes
many things far more difficult than they ought to be. (Jonathan, you
should particularly read this, as a refutation of the claim that TeX is
not broken.)
Next, some things that, while they could have an interface that's
limited to just a few primitives, would require substantial and
fundamental changes in a number of core TeX algorithms to actually
implement:
* Document-level line-break optimization instead of merely paragraph-level.
* Fitting of running text (including equations, etc.) into arbitrary
text-area shapes rather than merely into rectangles, as a language
built-in rather than by unpleasant hacks.
* Intelligent automated line-breaking in multiline equations.
I'm sure I'll think of more as soon as I send this. ... Oh, right; the
ability to do page layout (including graphics inclusion and text-area
shapes) using a MetaFont-like system of equations, including feedback
from the typesetting engine into the equations for cases where adjusting
the size of a figure a bit might improve the line-break situation. That
would certainly be a component of a "perfect" typesetting engine.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
chedva...@gmail.com
> theses and books. It's the harder stuff where the
> problems arise.)
Please, can you be more specific, I am simply interrested: what exactly
are these great problems that can not be solved in a reasonable way. It
is important for me to know them in order to improve my own format. Of
course, I have my own small list of problems, but, as I said, nothing
that can't be solved by implanting a few number of new primitives. So,
please, in order to make things more concrete, where exactly do you
think e-tex fails, and can you describe in few words the main
problems?
thx.
David Kastrup
Try numbering lines on the page. Try nesting footnotes (or other
insertions) to several levels. In LaTeX, for both tasks incredibly
complicated packages exist. But their complexity and their thorough
messing with output routines also means that uniting them would be
hardly possible.
chedva...@gmail.com
> fundamental key component of the TeX language:
>
> * Declaring fractions with \over _after_ the numerator means that one
> cannot know whether a given bit of mathematics is in text style or
> display style when it is being processed; see section 4 of the
> _Technical Notes on the AMSMATH Package_ for details and why this makes
> many things far more difficult than they ought to be. (Jonathan, you
> should particularly read this, as a refutation of the claim that TeX is
> not broken.)
This never disturbed me but I admit this can be a problem;
interresting!
> Next, some things that, while they could have an interface that's
> limited to just a few primitives, would require substantial and
fundamental changes in a number of core TeX algorithms to actually
> implement:
> * Document-level line-break optimization instead of merely paragraph-level.
In my opinion, the simple paragraph-level optimization does a very good
job. But, ok, even a PERFECT typeseting system can be made MORE
PERFECT (-:
> * Fitting of running text (including equations, etc.) into arbitrary
> text-area shapes rather than merely into rectangles, as a language
> built-in rather than by unpleasant hacks.
I don't understand what you mean.
> * Intelligent automated line-breaking in multiline equations.
What exactly is an intelligent automated line-breaking in multiline
equations?
> I'm sure I'll think of more as soon as I send this. ... Oh, right; the
> ability to do page layout (including graphics inclusion and text-area
> shapes) using a MetaFont-like system of equations, including feedback
> from the typesetting engine into the equations for cases where adjusting
> the size of a figure a bit might improve the line-break situation. That
> would certainly be a component of a "perfect" typesetting engine.
Again, I don't understand what you mean. What has the the metafont
system of equation to do with Tex? Do you mean the ability to draw a
curve if it is given an equation?
chedva...@gmail.com
This problem (and many others) can be solved by creating a new
primitive \everyline that expand at the beginning of every line of the
vertical line, at the reference point. This primitive could also be
used to solve the problem of \special{begincolor} ...\special{endcolor}
in right to left typesetting (it would be too long to explain how).
Try nesting footnotes (or other
> insertions) to several levels. In LaTeX, for both tasks incredibly
> complicated packages exist. But their complexity and their thorough
> messing with output routines also means that uniting them would be
> hardly possible.
I don't completely understand what you mean, but I am sure that with a
bit of skill, these problems can be solved by the creation of a few
number of primitives.
David Kastrup
>> Next, some things that, while they could have an interface that's
>> limited to just a few primitives, would require substantial and
> fundamental changes in a number of core TeX algorithms to actually
>> implement:
>> * Document-level line-break optimization instead of merely paragraph-level.
>
> In my opinion, the simple paragraph-level optimization does a very
> good job.
A lot of books have a strict requirement: no widows, and unless
absolutely impossible, no clubs. Together with rigid typesetting on a
grid and no flexible interline material. The only way to do that
without changing the text itself is by adapting the looseness of
paragraphs to the page layout. TeX does not lend itself to that.
Jonathan Fine
Brooks, thank you for your thought out contribution on this
topic. You clearly see that there is something to be discussed
here.
> First, an example of something that cannot be solved without changing a
> fundamental key component of the TeX language:
>
> * Declaring fractions with \over _after_ the numerator means that one
> cannot know whether a given bit of mathematics is in text style or
> display style when it is being processed; see section 4 of the
> _Technical Notes on the AMSMATH Package_ for details and why this makes
> many things far more difficult than they ought to be. (Jonathan, you
> should particularly read this, as a refutation of the claim that TeX is
> not broken.)
The syntax of \over can be somewhat inconvenient, and few if any
people use it nowawadays in their documents. Actually, I guess
Don Knuth probably does, but I don't know.
Perl has all sorts of strange syntax, inherited from the past.
I don't think that is enough to say that Perl is broken, and
to TeX I extend the same generosity.
One does not have to use the \over syntax, and by doing
\let\@@over\over
\let\over\undefined
\long\def\over#1#2{{#1\over#2}}
one essentially hides the syntax from the document author.
> Next, some things that, while they could have an interface that's
> limited to just a few primitives, would require substantial and
> fundamental changes in a number of core TeX algorithms to actually
> implement:
>
> * Document-level line-break optimization instead of merely paragraph-level.
I discuss this in my TUG2000 paper (and the then supposedly-impossible
problem of suppressing hyphenation on the last line of a page).
<http://www.pytex.org/doc/index.html#tug2000>
By the way, in that paper I point out to fully deal with this, one needs
a \totaldemerits primitive, which TeX does not have.
> * Fitting of running text (including equations, etc.) into arbitrary
> text-area shapes rather than merely into rectangles, as a language
> built-in rather than by unpleasant hacks.
I think here there are two problems
a) algorithms
b) implementation
TeX macros are not a suitable language for the implementation of
such algorithms.
But if you have TeX ship out boxes, for subsequent page makeup,
then one can use Python, or C, or whatever to implement the
algorithms.
> * Intelligent automated line-breaking in multiline equations.
>
> I'm sure I'll think of more as soon as I send this. ... Oh, right; the
> ability to do page layout (including graphics inclusion and text-area
> shapes) using a MetaFont-like system of equations, including feedback
> from the typesetting engine into the equations for cases where adjusting
> the size of a figure a bit might improve the line-break situation. That
> would certainly be a component of a "perfect" typesetting engine.
Again, the two issues are algorithms and implementation.
As I recall, Michael Downes did some work (published in TUGboat) on
this sort of thing. And again, as I recall, it was LaTeX as macros
rather than TeX as typesetting primitives that provided the
problem. Maybe someone might want to spawn this off as a
separate thread.
Brooks, you have put forward some real problems, whose solution
would help us. My view is that using TeX differently much
progress can be made, and that using an extension of TeX in
the same way as before little progress can be made.
--
Jonathan
David Kastrup
>> Try numbering lines on the page.
>
> This problem (and many others) can be solved by creating a new
> primitive \everyline that expand at the beginning of every line of the
> vertical line, at the reference point.
The beginning of every line is not known until the paragraph is set
completely. And this would not help when one wants to reference the
current line (footnotes in humanities are often referenced by line
number rather than by footnote markers in order to avoid cluttering
the original text).
> This primitive could also be used to solve the problem of
> \special{begincolor} ...\special{endcolor} in right to left
> typesetting (it would be too long to explain how).
>
> Try nesting footnotes (or other
>> insertions) to several levels. In LaTeX, for both tasks incredibly
>> complicated packages exist. But their complexity and their thorough
>> messing with output routines also means that uniting them would be
>> hardly possible.
>
> I don't completely understand what you mean, but I am sure that with
> a bit of skill, these problems can be solved by the creation of a
> few number of primitives.
A bit of skill. Sure. I am afraid that you underestimate the
complexity of the page builder.
TeX already fails in a number of situations quite devastatingly. For
example, it can't split a footnote successfully if the next line of
the main matter after the footnote reference has to be on the same
page (for example, when \widowpenalty=10000). In that case, it will
move footnote and reference to the next page, leaving a big hole.
The insertion arrangement and splitting mechanism is pretty much
outside of TeX's page optimization: once insertions come into play,
TeX's "best fit" algorithm is replaced essentially by "first fit
without waiting for vital information".
The skill of Knuth was not sufficient to get that right. Good luck
with adding your bit.
Jonathan Fine
Don Knuth and Pierre MacKay wrote an extension to TeX, called TeX-XeT,
that provides bidirectional typesetting. They did this in 1987, and
it is described in Knuth's "Digital Typography".
etex is, from this, a step backwards.
Knuth and MacKay rightly recognise that bidirectional typesetting
requires an extension to the DVI standard. So they define DVI-IVD,
which has additional opcodes for begin_reflect and end_reflect.
etex reduces the output to ordinary DVI, and so discards information
about the reading order of the text. For print this is not a
problem, but for cutting and pasting from PDF, or accessibility?
In addition, etex gets this reversal wrong for write commands.
The fragment
\shipout\hbox{\beginR\write16{hello}\write16{world}\endR}
writes out
world
hello
I think this is enough to be getting on with.
--
Jonathan
Jonathan Fine
> Try numbering lines on the page. Try nesting footnotes (or other
> insertions) to several levels. In LaTeX, for both tasks incredibly
> complicated packages exist. But their complexity and their thorough
> messing with output routines also means that uniting them would be
> hardly possible.
These are examples of problems that are difficult in LaTeX. And
the LaTeX supporters say this is because TeX is broken.
Have TeX send these items out as boxes, and use your favourite
language (mine is Python) to solve these problems.
Output routines (or page makeup) is a prime example of something
that should NOT be written in TeX macros.
Unless, that is, one enjoys sitting in a dungeon cell, digging
ones way out (or perhaps even deeper) armed only with the
enhanced spoon provided by etex.
We don't have to write output routines using TeX macros.
That is our choice.
Just as most of us don't have to live and work in a
dungeon cell.
--
Jonathan
Jonathan Fine
> A lot of books have a strict requirement: no widows, and unless
> absolutely impossible, no clubs. Together with rigid typesetting on a
> grid and no flexible interline material. The only way to do that
> without changing the text itself is by adapting the looseness of
> paragraphs to the page layout. TeX does not lend itself to that.
David is, or in my view should be, aware of my TUG2000 article
"Line breaking and page breaking"
<http://www.pytex.org/doc/index.html#tug2000>
David writes
> TeX does not lend itself to that.
My view, as expressed in that article, is that
> LaTeX does not lend itself to that.
--
Jonathan
Jonathan Fine
> "chedva...@gmail.com" <chedva...@gmail.com> writes:
>
>
>>>Try numbering lines on the page.
>>
>>This problem (and many others) can be solved by creating a new
>>primitive \everyline that expand at the beginning of every line of the
>>vertical line, at the reference point.
>
>
> The beginning of every line is not known until the paragraph is set
> completely. And this would not help when one wants to reference the
> current line (footnotes in humanities are often referenced by line
> number rather than by footnote markers in order to avoid cluttering
> the original text).
David: You evidently know a lot about this.
Please write, in the language of your choice, or in pseudo-code,
the algorithm that should be followed.
We could then discuss the problems of implementing that
algorithm.
--
Jonathan
David Kastrup
> David Kastrup wrote:
>
>> Try numbering lines on the page. Try nesting footnotes (or other
>> insertions) to several levels. In LaTeX, for both tasks incredibly
>> complicated packages exist. But their complexity and their
>> thorough messing with output routines also means that uniting them
>> would be hardly possible.
>
> These are examples of problems that are difficult in LaTeX. And the
> LaTeX supporters say this is because TeX is broken.
>
>
> Have TeX send these items out as boxes, and use your favourite
> language (mine is Python) to solve these problems.
Have you ever solved a single problem in that manner? Typesetting a
single real-world document?
> Output routines (or page makeup) is a prime example of something
> that should NOT be written in TeX macros.
Oh, there is a lot that should not be written in TeX macros, no
question about that. But TeX does not lend itself smoothly to
alternatives.
> We don't have to write output routines using TeX macros. That is
> our choice.
There is no other way within TeX, and that is a problem of TeX, not
LaTeX. And TeX is not designed for communicating or sharing its
internal structures with any outside programs.
The extension language of TeX, for better and worse, is Pascal. That
is what it is designed to do, and that means that some brokenness
can't be fixed while staying within the TeX infrastructure.
David Kastrup
Oh, TeX does not lend itself to it either. It might be possible to
drag it screaming and kicking into typesetting parts of trivial toy
documents in that manner (or rather, look helplessly while one does
most of the work oneself), but unless you actually can show a book
typeset in that manner, this is quite academical.
LaTeX does not come much into play here: you are pretty much out of
the reign of manageable code with plain TeX, either.
chedva...@gmail.com
> that provides bidirectional typesetting. They did this in 1987, and
> it is described in Knuth's "Digital Typography".
>
> etex is, from this, a step backwards.
>
> Knuth and MacKay rightly recognise that bidirectional typesetting
> requires an extension to the DVI standard. So they define DVI-IVD,
> which has additional opcodes for begin_reflect and end_reflect.
>
> etex reduces the output to ordinary DVI, and so discards information
> about the reading order of the text. For print this is not a
> problem, but for cutting and pasting from PDF, or accessibility?
I agree with you (and Knuth) that the best solution would be to extend
the DVI standart, but what about PDF and PS, can we extend them? too
late. So, we need some macro trickery.
> In addition, etex gets this reversal wrong for write commands.
> The fragment
> \shipout\hbox{\beginR\write16{hello}\write16{world}\endR}
> writes out
> world
> hello
>
> I think this is enough to be getting on with.
I think this is probably a bug, that need to be corrected (I have found
another bug in Etex for Right to left typesetting, posted in this
forum).
David Kastrup
Every line on a page needs to get prefixed with a number in the print,
and reference points in the input text need to be able to refer to the
number they are in.
Omega's \localleftbox would do most of the trick with regard to the
referencing: just putting a "\write" in there and interspersing it
with \write from the reference points would solve the reference
problem, but placing the actual number is, of course, not as easy, as
the \localleftbox is fixed (unless you do the counter management in
PostScript). Placing the numbers from the output routine would be one
possibility, but that does not help if lines in footnotes or figures
should be numbered, too, and then we again get into the area of
complexity close to lineno.sty: where things simply become infeasible.
> We could then discuss the problems of implementing that algorithm.
Pretty pointless using just TeX. That's what lineno.sty does, and it
does a pretty good job, at a horrible cost.
chedva...@gmail.com
> completely. And this would not help when one wants to reference the
> current line (footnotes in humanities are often referenced by line
> number rather than by footnote markers in order to avoid cluttering
> the original text).
I know this. You bring me to tell what new primitives I have in mind.
Here are some of them:
1) \everyline, that put a whatsit at the beginning of every line at the
reference point position.
2) make the following informations available inside a \vadjust: the
depth, height and width of the horizontal line \vadjust is called from
(this solves trivially the problem of margin notes), and the number of
the line \vadjust is called from (this solves the problem of making
footnotes that reference the line number, using \vadjust together with
\everyline that globally increases the counter). So, it suffices to
create the primitives
\adjustlinedepth, \adjustlineheight, \adjustlinewidth and
\adjustlinepos.
3) a \madjust that does the same thing in a display vertical list, with
correlated
\madjustlinedepth, \madjustlineheight, \madjustlinewidth and
\madjustlinepos. This solve the problem of putting margin notes beside
display math formulae.
4) make the total width of a display math formula available after its
end. If it spans on two pages, make the two informations available (say
\firstsplitdspwidth, \scdsplitdspwidth that generally agree excepted if
the display spans on two pages).
5) make a \phantompar primitive that acts exactly as \par, but without
skipping one line after par: this solve problem 7) p. 392 of the
TeXbook.
Note: the same effect can apparently be obtained with the following
(dirty) macro:
\newdimen\lastlinedepth
\newdimen\lastlinewidth
\def\phantompar{%
\ifhmode
\null %in order to include space tokens before \phantompar
\begingroup
\displaywidowpenalty\widowpenalty
$$
\predisplaypenalty \@M \postdisplaypenalty \@M
\lineskiplimit -999\p@
\abovedisplayskip -\tw@\baselineskip
\abovedisplayshortskip -\tw@\baselineskip
\belowdisplayskip \z@ \belowdisplayshortskip \z@
\halign{##\cr\noalign{\global\lastlinedepth \prevdepth}\cr}%
%get depth of line above
\global\lastlinewidth\predisplaysize
%get the width of the last line of the paragraph that just ended
$$\endgroup
\endgraf \nolocalindent
\hskip \dimexpr \lastlinewidth -\tw@\em \ifheb+ \hsize \fi \relax
\vrule \width \z@ \height \z@ \depth \lastlinedepth \relax
\fi
}%
For example, try:
{\raggedright some_long_sentence \phantompar}{\raggedleft
some_long_sentence\par}
6) make a primitive \noholemode=1 | 0 such that if on, TeX will
calculate the width of the line following a display math formula, and
will use \belowdisplayshortskip or \belowdisplayskip according as if is
2em shorter than the display formula or not, as is done for
\predisplaysize.
> A bit of skill. Sure. I am afraid that you underestimate the
> complexity of the page builder.
> TeX already fails in a number of situations quite devastatingly. For
> example, it can't split a footnote successfully if the next line of
> the main matter after the footnote reference has to be on the same
> page (for example, when \widowpenalty=10000). In that case, it will
> move footnote and reference to the next page, leaving a big hole.
> The insertion arrangement and splitting mechanism is pretty much
> outside of TeX's page optimization: once insertions come into play,
> TeX's "best fit" algorithm is replaced essentially by "first fit
> without waiting for vital information".
> The skill of Knuth was not sufficient to get that right. Good luck
> with adding your bit.
Perhaps a group of Texnicians could do better than Knuth?
David Kastrup
>> The beginning of every line is not known until the paragraph is set
>> completely. And this would not help when one wants to reference the
>> current line (footnotes in humanities are often referenced by line
>> number rather than by footnote markers in order to avoid cluttering
>> the original text).
>
> I know this. You bring me to tell what new primitives I have in mind.
> Here are some of them:
>
> 1) \everyline, that put a whatsit at the beginning of every line at the
> reference point position.
>
> 2) make the following informations available inside a \vadjust: the
> depth, height and width of the horizontal line \vadjust is called
> from (this solves trivially the problem of margin notes), and the
> number of the line \vadjust is called from (this solves the problem
> of making footnotes that reference the line number, using \vadjust
> together with \everyline that globally increases the counter). So,
> it suffices to create the primitives \adjustlinedepth,
> \adjustlineheight, \adjustlinewidth and \adjustlinepos.
You seem to be confused about when the line breaks actually get
established. That happens long after the contents of a vadjust item
have already been executed and typeset.
>> A bit of skill. Sure. I am afraid that you underestimate the
>> complexity of the page builder.
>
>> TeX already fails in a number of situations quite devastatingly.
>> For example, it can't split a footnote successfully if the next
>> line of the main matter after the footnote reference has to be on
>> the same page (for example, when \widowpenalty=10000). In that
>> case, it will move footnote and reference to the next page, leaving
>> a big hole. The insertion arrangement and splitting mechanism is
>> pretty much outside of TeX's page optimization: once insertions
>> come into play, TeX's "best fit" algorithm is replaced essentially
>> by "first fit without waiting for vital information". The skill of
>> Knuth was not sufficient to get that right. Good luck with adding
>> your bit.
>
> Perhaps a group of Texnicians could do better than Knuth?
TeX's code base does not lend itself well to distributed/modular
programming management models.
chedva...@gmail.com
> established. That happens long after the contents of a vadjust item
> have already been executed and typeset.
You're right. Is it impossible to create a \pseudovadjust command that
will be expanded only \after the paragraph has broken into lines?
David Kastrup
It would have to be in a sort of asynchronous context like the output
routine. And it is not clear in what list context this would be
executed (the output routine runs in an internal vertical list).
chedva...@gmail.com
> routine. And it is not clear in what list context this would be
> executed (the output routine runs in an internal vertical list).
I think that to create an "asynchronous" context would be an excellent
idea, that could be applied to other areas. I am not an expert of the
grammar of Tex (an even not a TeX expert), so, I can only suggest that.
The technical question "how to do that" is out of my competences.
Brooks Moses
>>* Fitting of running text (including equations, etc.) into arbitrary
>>text-area shapes rather than merely into rectangles, as a language
>>built-in rather than by unpleasant hacks.
>
> I don't understand what you mean.
Suppose that I'm creating a document (like, say, a brochure for a
conference) that has a lot of random pictures scattered on the pages,
and the text should flow around the edges of these pictures. Moreover,
the pictures are not simple rectangles, but interesting shapes, so the
text lines are all different lengths to align with a curved edge around
the picture.
On a brochure, I might have three columns of text like this, and the
text should flow from one to the next and the next, and the typesetting
engine should figure out how to set things out to fit.
The \parshipe intrinsic can be used for this, with a lot of effort, and
it's not especially good in cases where the line heights might vary.
And one has to special-case things like equations and headings and so
forth, too.
>>* Intelligent automated line-breaking in multiline equations.
>
> What exactly is an intelligent automated line-breaking in multiline
> equations?
When I write an equation that's too long to fit on the page in one line,
I would like to be able to just write it out as if it were a single-line
equation and have the typesetting engine figure out how to arrange it
into multiple lines.
>>I'm sure I'll think of more as soon as I send this. ... Oh, right; the
>>ability to do page layout (including graphics inclusion and text-area
>>shapes) using a MetaFont-like system of equations, including feedback
>>from the typesetting engine into the equations for cases where adjusting
>>the size of a figure a bit might improve the line-break situation. That
>>would certainly be a component of a "perfect" typesetting engine.
>
> Again, I don't understand what you mean. What has the the metafont
> system of equation to do with Tex? Do you mean the ability to draw a
> curve if it is given an equation?
No, I mean how one specifies the proportions of letters in MetaFont.
For instance, a very simple version of the letter E might be specified
by (in pseudocode):
bottom_height = 1.5 * top_height
top_length = 0.9 * bottom_length
middle_length = 0.6 * bottom_length
y_top - y_bottom = top_height
y_middle - y_bottom = bottom_height
x_middle_right - x_left = middle_length
x_bottom_right - x_left = bottom_length
x_top_right - x_left = top_length
x_left = 0
y_bottom = 0
x_bottom_length = 0.7 charwidth
y_top = charheight
draw (x_left, y_bottom) -- (x_bottom_right, y_bottom)
draw (x_left, y_middle) -- (x_middle_right, y_middle)
draw (x_left, y_top) -- (x_top_right, y_top)
draw (x_left, y_bottom) -- (x_left, y_top)
Then, given values for charwidth and charheight, MetaFont will solve the
given equations to determine where to put the relevant lines, and then
draw them. Note that this is a very simple example, but even here I
have constraints that the bottom half of the "E" should be 50% larger
than the top half, and it would be quite possible to imagine much more
complicated sets of constraints -- have a look at some of the letters in
CMR for examples.
This sort of thing would also work very well for text layout -- I want
the overall textarea width to be 80% of the paper width; I want the left
margin half the right margin, I want two columns that are the same
width, and I want a space between them of 5mm. In MetaFont, one can
just write out that sort of thing in equation form, and the program
handles figuring out what it means -- and, if the paper size changes,
everything updates.
What I use this for is in graphics I draw with MetaPost -- I can draw a
generic piece of a figure once, and then include it in more complicated
figures in various sizes and proportions, and it adjusts to keep the
right proportions and "look" regardless of the size or proportion I draw
it in. What would be really nice (and ConTeXt does have some ability to
do this, with multiprogram hacks) is combine that with the text layout
in TeX, so that if I change the column width on my thesis, all of the
full-width figures are automatically redrawn to expand to the
appropriate width and maintain the appropriate line weights and font sizes.
Aditya Mahajan
Have you looked at ConTeXt's linenumbering and linenote mechanisms?
ConTeXt's implementation of linenumbering is at
http://source.contextgarden.net/page-lin.tex and linenotes at
http://source.contextgarden.net/core-lnt.tex
I know nothing about the implementation details of either the ConTeXt
or LaTeX solution, but there can be ideas that one can borrow from the
other. ConTeXt linenumbering can handle plain texts and lists, but
fails on sections and equations.
An example of using linenotes (taken from the sources)
\setupcolors[state=start]
\starttext
\startbuffer[test]
\startlinenumbering[100]
test \linenote {first} test test test test test test
test \startlinenote [well] {second} test test test test test test
test \linenote {third} test test test test test test
test \linenote {fourth} test test test test test test
test \linenote {fifth} test test test test test test
test \linenote {sixth} test test test test test test
test \stoplinenote [well] test test test test test test
\stoplinenumbering
\stopbuffer
\setupnotedefinition[linenote] [location=serried,distance=.5em]
{\typebuffer[test] \getbuffer[test]} \page
\startbuffer[setup]
\setuplinenumbering
[align=left]
\stopbuffer
{\typebuffer[setup] \getbuffer[setup,test]} \page
\startbuffer[setup]
\setuplinenumbering
[width=1em,
align=left]
\stopbuffer
{\typebuffer[setup] \getbuffer[setup,test]} \page
\startbuffer[setup]
\setuplinenumbering
[width=2em,
distance=.5em,
align=left]
\stopbuffer
{\typebuffer[setup] \getbuffer[setup,test]} \page
\startbuffer[setup]
\setuplinenumbering
[width=2em,
align=middle]
\stopbuffer
{\typebuffer[setup] \getbuffer[setup,test]} \page
\startbuffer[setup]
\setuplinenumbering
[conversion=romannumerals,
start=1,
step=1,
location=text,
style=slanted,
color=blue,
width=1.5em]
\stopbuffer
{\typebuffer[setup] \startnarrower\getbuffer[setup,test]\stopnarrower}
\page
\startbuffer[setup]
\setuplinenumbering
[width=4em,
left=--,
right=--,
align=middle]
\stopbuffer
{\typebuffer[setup] \getbuffer[setup,test]} \page
\startbuffer[setup-1]
\setuplinenumbering
[style=\bfxx,
command=\WatchThis]
\stopbuffer
\startbuffer[setup-2]
\def\WatchThis#1%
{\ifodd\linenumber
\definecolor[linecolor][red]%
\else
\definecolor[linecolor][green]%
\fi
\inframed
[offset=1pt,frame=off,background=color,backgroundcolor=linecolor]
{#1}}
\stopbuffer
{\typebuffer[setup-1,setup-2] \getbuffer[setup-1,setup-2,test]} \page
\startbuffer[setup-1]
\setuplinenumbering
[location=inright,
style=\bfxx,
command=\WatchThis]
\stopbuffer
{\typebuffer[setup-1] \getbuffer[setup-1,setup-2,test]} \page
\stoptext
Aditya
Brooks Moses
> Brooks Moses wrote:
>>First, an example of something that cannot be solved without changing a
>>fundamental key component of the TeX language:
>>
>>* Declaring fractions with \over _after_ the numerator means that one
>>cannot know whether a given bit of mathematics is in text style or
>>display style when it is being processed; see section 4 of the
>>_Technical Notes on the AMSMATH Package_ for details and why this makes
>>many things far more difficult than they ought to be. (Jonathan, you
>>should particularly read this, as a refutation of the claim that TeX is
>>not broken.)
>
> The syntax of \over can be somewhat inconvenient, and few if any
> people use it nowawadays in their documents. Actually, I guess
> Don Knuth probably does, but I don't know.
The problem here is not merely something that arises when \over is
actually used, however. It arises when \over _might_ be used -- which,
because it follows the text it applies to, is any time when math is
being typeset.
One example of the problems created is that, as the _Technical Notes_
point out, whenever a \mathchoice is executed, it does not generally at
that point know what math style will eventually be used for its
contents, and thus must process and typeset all of the four possible
options.
> Perl has all sorts of strange syntax, inherited from the past.
> I don't think that is enough to say that Perl is broken, and
> to TeX I extend the same generosity.
>
> One does not have to use the \over syntax, and by doing
> \let\@@over\over
> \let\over\undefined
> \long\def\over#1#2{{#1\over#2}}
> one essentially hides the syntax from the document author.
Certainly; LaTeX does this. But one does not thereby do anything to
solve the problem I'm speaking of.
Please read the document I was referencing; it explains this much more
clearly than I have time for. The problem is not with \over itself; the
problem is with fundamentals of how the TeX math engine must process
things in order to allow \over to work. And removing \over from the
user's view does not change how the math engine works.
>>* Fitting of running text (including equations, etc.) into arbitrary
>>text-area shapes rather than merely into rectangles, as a language
>>built-in rather than by unpleasant hacks.
>
> I think here there are two problems
> a) algorithms
> b) implementation
>
> TeX macros are not a suitable language for the implementation of
> such algorithms.
>
> But if you have TeX ship out boxes, for subsequent page makeup,
> then one can use Python, or C, or whatever to implement the
> algorithms.
But this is a line-break problem, as well as a page-break problem -- the
difficulty with non-rectangular text areas is that the location of the
page breaks affects the line lengths. Are you proposing that we simply
ditch the TeX line-break algorithm entirely in cases where the text area
isn't a rectangle? If so, what about things like \discretionary, where
the line breaks affect which boxes get shipped out?
> Brooks, you have put forward some real problems, whose solution
> would help us. My view is that using TeX differently much
> progress can be made, and that using an extension of TeX in
> the same way as before little progress can be made.
Thank you, though I should note that none of these are original to me;
they're merely things I've seen remarked on over the years.
I will agree with you that by using TeX differently, many of these could
in theory be solved. I am much more dubious, however, that in practice
one can do this without effectively reducing TeX to a system for
converting letters obtained from macros expanded in a preprocessor into
boxes that are fed into a page-layout postprocessor, at which point it
becomes superfluous to use TeX at all.
Heiko Oberdiek
> I'll repeat my view.
>
> It is not TeX that is broken, it is LaTeX.
And I said, both TeX and so LaTeX are not without limitations.
EOT.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> But if you have TeX ship out boxes, for subsequent page makeup,
> then one can use Python, or C, or whatever to implement the
> algorithms.
Thus TeX is broken, because it does not have a reliable
export interface for boxes.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Patrick TJ McPhee
Jonathan Fine <jf...@pytex.org> wrote:
% These are examples of problems that are difficult in LaTeX. And
% the LaTeX supporters say this is because TeX is broken.
%
% Have TeX send these items out as boxes, and use your favourite
% language (mine is Python) to solve these problems.
%
% Output routines (or page makeup) is a prime example of something
% that should NOT be written in TeX macros.
It seems to me you're arguing that LaTeX is broken specifically
because it attempts to use TeX's macro language to do the things
that TeX's macro language was designed to do. It sounds remarkably
like an argument that TeX is broken.
It seems a bit churlish to argue that LaTeX should have deferred its
output routine processing to some external process written in your
favourite language, when your favourite language didn't exist at
the time.
Having decided to write an output routine in python, what's it supposed
to do? I mean, shipping the boxes out is easy enough, modulo the fact that
it doesn't always work, but then what?
Here's a box which I believe is shipped out the way you mean. Please
post the python code which produces a page layed out the way plain TeX
would lay it out if I were so foolish as to choose to use its default
output routine to set the same paragraph.
% example begins
\tracingoutput = 1
\showboxbreadth = \maxdimen
\showboxdepth = \maxdimen
\setbox0=\vbox{
``Bravo, Watson! A very dignified and logical remonstrance. Let me see,
what were the points? Take the last one first---the cab. You observe
that you have some splashes on the left sleeve and shoulder of your
coat. Had you sat in the centre of a hansom you would probably have had
no splashes, and if you had they would certainly have been symmetrical.
Therefore it is clear that you sat at the side. Therefore it is equally
clear that you had a companion.''
}
\showbox0
\end
% example ends
Having managed to do something useful with the log from that bit of
text, I don't see how the approach in general solves any of the problems
that I personally have with TeX's approach to layout. For instance, the
paragraph above is part of a larger text, and I'd like to put a small
illustration at the upper-outer corner of the page on which that
paragraph appears. I'd like the text at the top of the page to wrap
around the illustration. How does shipping out boxes get me closer to
solving that problem?
--
Patrick TJ McPhee
North York Canada
pt...@interlog.com
Jonathan Fine
<snip>
>>We don't have to write output routines using TeX macros. That is
>>our choice.
>
>
> There is no other way within TeX, and that is a problem of TeX, not
> LaTeX. And TeX is not designed for communicating or sharing its
> internal structures with any outside programs.
Even though TeX was not _designed_ to communicate its internal
structures, it is _capable_ of so doing.
And that is _precisely_ what I am suggesting. It can be done.
--
Jonathan
Jonathan Fine
<snip>
> Oh, TeX does not lend itself to it either. It might be possible to
> drag it screaming and kicking into typesetting parts of trivial toy
> documents in that manner (or rather, look helplessly while one does
> most of the work oneself), but unless you actually can show a book
> typeset in that manner, this is quite academical.
David will not accept that it is possible until he sees a book
typeset in that manner. This is, I believe, too high a hurdle.
I am trained as a mathematician, and have confidence in the
power of abstract thought.
David, I think, is saying he won't believe it is possible until
he sees that it has been done. If we all thought that way,
nothing new would happen, except by accident.
--
Jonathan
Jonathan Fine
>>Don Knuth and Pierre MacKay wrote an extension to TeX, called TeX-XeT,
>>that provides bidirectional typesetting. They did this in 1987, and
>>it is described in Knuth's "Digital Typography".
>>
>>etex is, from this, a step backwards.
>>
>>Knuth and MacKay rightly recognise that bidirectional typesetting
>>requires an extension to the DVI standard. So they define DVI-IVD,
>>which has additional opcodes for begin_reflect and end_reflect.
>>
>>etex reduces the output to ordinary DVI, and so discards information
>>about the reading order of the text. For print this is not a
>>problem, but for cutting and pasting from PDF, or accessibility?
>
>
> I agree with you (and Knuth) that the best solution would be to extend
> the DVI standart, but what about PDF and PS, can we extend them? too
> late. So, we need some macro trickery.
Thank you for this. I don't recall what bidirectional support PS and
PDF provides. Might post more on this later.
>>In addition, etex gets this reversal wrong for write commands.
>>The fragment
>> \shipout\hbox{\beginR\write16{hello}\write16{world}\endR}
>>writes out
>> world
>> hello
>>
>>I think this is enough to be getting on with.
>
>
> I think this is probably a bug, that need to be corrected (I have found
> another bug in Etex for Right to left typesetting, posted in this
> forum).
In my opinion, etex has not been as well done as TeX has.
This is, in part, due to the strongly political way in
which it was developed. NTS suffered the same problem to
a much greater degree.
--
Jonathan
Jonathan Fine
>>David: You evidently know a lot about this.
>>
>>Please write, in the language of your choice, or in pseudo-code,
>>the algorithm that should be followed.
>
>
> Every line on a page needs to get prefixed with a number in the print,
> and reference points in the input text need to be able to refer to the
> number they are in.
OK. So let's assume that we have the page, as a box.
And that we have labels and references.
We need a two-pass process, which perhaps can be
optimised to one. I'm using Python. Here's the code.
===
line_no = 0
label_dict = {}
for line in page:
line_no += 1
line[:0] = leftlap(line_no) # prefix the line no
for label in line.labels():
label_dict[label] = line_no
for ref in page.refs():
line_no = label_dict(ref.label)
ref[:] = hbox(line_no)
===
Thank you, David, for the example. It's allowed useful progress
to be made.
--
Jonathan
David Kastrup
> David Kastrup wrote:
>
> <snip>
>
>> Oh, TeX does not lend itself to it either. It might be possible to
>> drag it screaming and kicking into typesetting parts of trivial toy
>> documents in that manner (or rather, look helplessly while one does
>> most of the work oneself), but unless you actually can show a book
>> typeset in that manner, this is quite academical.
>
> David will not accept that it is possible until he sees a book
> typeset in that manner.
What about "it might be possible" did you not understand?
> This is, I believe, too high a hurdle.
Typesetting is about books. Not toy problems. And you are certainly
qualified enough as a TeX wizard that there is no sense in expecting
others to do the heavy lifting for your pet peeves. If you won't take
that hurdle of creating something that can at least be _used_ for book
typesetting without further modification (and that means actually
making it work with one major TeX format), nobody else will.
> I am trained as a mathematician, and have confidence in the
> power of abstract thought.
Well, too bad. You also think that all one needs to do with a problem
is to prove a solution exists, and move on. But we are talking about
real life here. The question is not the existence of a solution, but
its feasibility.
> David, I think, is saying he won't believe it is possible until
> he sees that it has been done.
I suggest that you put more focus on what I actually say rather than
what you think I say.
> If we all thought that way, nothing new would happen, except by
> accident.
Sure, I am too chicken to attempt any non-trivial TeX programming.
You figured me out completely.
Jonathan Fine
<snip>
> I will agree with you that by using TeX differently, many of these could
> in theory be solved. I am much more dubious, however, that in practice
> one can do this without effectively reducing TeX to a system for
> converting letters obtained from macros expanded in a preprocessor into
> boxes that are fed into a page-layout postprocessor, at which point it
> becomes superfluous to use TeX at all.
I am proposing that we use TeX only as a typesetting languge. We use
it for
* breaking lines into paragraphs
* mathematical typography
* handling of fonts
and not for
* macro programming language
I almost agree with your statement above. My only difference is
that the use of TeX would then be superfluous. We would be using
only (or mostly) the typesetting capabilities of TeX.
--
Jonathan
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
>
>
>>But if you have TeX ship out boxes, for subsequent page makeup,
>>then one can use Python, or C, or whatever to implement the
>>algorithms.
>
>
> Thus TeX is broken, because it does not have a reliable
> export interface for boxes.
I believe that in practice, the interface is reliable. And if
not, a minor extension to TeX could be made that did not have
this problem.
--
Jonathan
Brooks Moses
> David will not accept that it is possible until he sees a book
> typeset in that manner. This is, I believe, too high a hurdle.
>
> I am trained as a mathematician, and have confidence in the
> power of abstract thought.
Abstract mathematical thought is excellent for determining whether
something is possible. I'm perfectly willing to grant that this is
possible.
Abstract mathematical thought is, however, incapable of determining how
difficult a given solution will be to implement, because it is a system
of idealizing away those details. I believe your proposed system, while
possible, is sufficiently difficult to implement that it would be easier
to solve the problems by starting from scratch rather than trying to
include TeX at the core of the system.
I should note that my idea of the effort required to write this thing is
being influenced by the fact that I've spent the last three years of my
dissertation research writing the code to implement a set of
calculations that I could have explained on a single sheet of paper when
I started. And, now that it's done, some thousands of lines of code
later, it does exactly what I thought it would. The abstract theory
about what was possible was completely correct -- but it sure didn't
happen in the couple of months I thought it would when I started out.
So I'm particularly cranky about "possible" programs right now.
> David, I think, is saying he won't believe it is possible until
> he sees that it has been done. If we all thought that way,
> nothing new would happen, except by accident.
No, nothing new would happen except for things done by people who are
sufficiently passionate and stubborn about their own ideas to spend a
year or two working on the implementation until they get it to a point
where other people can see that it works.
Which, in my experience, is a pretty good description of how almost
every new thing in the world of software has been written, except in the
cases where they're heavily-funded corporate projects. Linux, TeX, the
C programming language, the GFortran compiler, even down to things like
the Listings package, they all boil down to one passionate person who
built a working proof of concept and _then_ got other people to build on
what they'd started.
Heiko Oberdiek
> Heiko Oberdiek wrote:
> > Jonathan Fine <jf...@pytex.org> wrote:
> >
> >
> >>But if you have TeX ship out boxes, for subsequent page makeup,
> >>then one can use Python, or C, or whatever to implement the
> >>algorithms.
> >
> >
> > Thus TeX is broken, because it does not have a reliable
> > export interface for boxes.
>
> I believe that in practice, the interface is reliable.
Look at \special commands in hyperref. Many exceed the limits.
And look at the DVI specification. There are more than on
op code for \specials, each for different size. And compare
these sizes with the limit of the .log file output.
> And if not, a minor extension to TeX could be made that did not have
> this problem.
For example, a structured logging is needed in an unambiguous
language. If you call that a "minor" extension, then many of
the eTeX features are tiny extensions.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> David Kastrup wrote:
>
> <snip>
>
>
> >>We don't have to write output routines using TeX macros. That is
> >>our choice.
> >
> >
> > There is no other way within TeX, and that is a problem of TeX, not
> > LaTeX. And TeX is not designed for communicating or sharing its
> > internal structures with any outside programs.
>
> Even though TeX was not _designed_ to communicate its internal
> structures, it is _capable_ of so doing.
It isn't. Another example than boxes are macros. \meaning, \show,
or \tracingmacros produce just text. The tokens of the macro
definition and parameter text are lost.
And inside TeX you cannot even access box internals if whatits are
involved.
Thus I hope that luaTeX will provide more reliable possibilities.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Robin Fairbairns
>Even though TeX was not _designed_ to communicate its internal
>structures, it is _capable_ of so doing.
>
>And that is _precisely_ what I am suggesting. It can be done.
great. let's see an experimental tool that, for example, reverses the
lines of every paragraph and puts line numbers on the reversed lines.
seems to me pretty simple, given the flexibility you claim you have.
personally, i'll go for something like ant, built for modularity and
with a sane extension language ... until someone proves it's not the
thing to do.
--
Robin Fairbairns, Cambridge