Patrice: sure, I understand.
Gavin: let me add one more point: if the warning is not reenabled by
default, you are essentially forcing every maintainer of every manual to
add a new flag to their makeinfo invocation, conditional on the makeinfo
version. This seems ... bad. --thanks, karl.
Hi Patrice,
then they can set CHECK_NORMAL_MENU_STRUCTURE on
explicitely.
It's easy to say that, but it creates an incompatibility for the 99.99%
case. I can't set it for makeinfo 7.x without giving people using 6.x
(which is most everyone, downstream) a useless warning. Nor can I omit
This goes against the practice of the vast majority of existing Texinfo
manuals, so this existing practice should be well supported.
Indeed. That is the crucial point. Those warnings are needed in well
over 99% of existing manuals, as far as I've seen :).
I think that it could be
Hi Gavin,
The problem as I remember it was that the error messages are awful:
No argument, but having any message at all is infinitely better than
silence. I urge you to restore them by default, suboptimal as they are.
It's true that those msgs as such have never made a great deal of sense
I believe this is an intentional feature in recent Texinfo versions.
To get the warnings back, you need to run makeinfo with the
command-line option "-c CHECK_NORMAL_MENU_STRUCTURE=1".
Thanks for the hint. I reported a similar thing in July 2023,
I think I'd suggest omitting the \vtop if LOC is set to some new value,
like "longfloat". If table material was ever actually floated, including
"here", it would need to be in a vbox since it should not be split
across pages, as Gavin already pointed out.
Actually doing something sensible with a
So I've commited the change
...
Please let us know if the change works ok with your manual and if
there are any regressions.
Indeed, current texinfo.tex in git fixes the overfull hbox bug in the
toc, and I haven't noticed any regressions or other problems. Thanks!
Please push it
Hi Gavin - with this input file:
\input texinfo
@contents
@chapter Test
@section Sec
@subsection
foofoo@code{\DeclareRobustCommand@{@var{cmd}@}[@var{num}][@var{default}]@/@{@var{definition}@}
}
@bye
I get an overfull box in the toc (texinfo.tex version 2023-09-12.17):
Overfull \hbox
Subject: Re: toc multiline section titles misaligned in TeX
Thank you for doing all that, Gavin. It looks good to me.
Can the new version be pushed out to ftp.gnu.org? --thanks, karl.
It's possible to do this by reading the toc file another time for
the sole purpose of getting the widths of the section numbers in
each chapter.
Yeah. Why I never did it. Thanks for tackling it.
I think the output does not necessarily look ideal.
Not ideal, but a vast
I have done some work on this and it should be aligned in the
latest version (2023-07-17.15, git commit 64c51c055836b9980).
Thanks Gavin. It looks fine now. I appreciate your doing this.
I couldn't remember if it ever aligned either :).
Another (separate but sort of related) problem that
In the toc, if a chapter/section/whatever titles breaks across lines,
the second line is not aligned with the first. The output in the main
text is ok. Example doc follows. I'll attach the output I get
with texinfo.tex [version 2023-07-02.10]. --thanks, karl.
\input texinfo
@contents
@node
+ gendocs: support chapter- and section-level split
Seems sensible to me. Basically making the html-by-node part of the
template conditional along with the other split options?
(Overall, it seems to me that several of these variants are pretty
pointless nowadays, but never mind.)
FWIW, in
Hi Gavin - not that it's terribly crucial, but the setting
htmlxrefversion=2022-01-10.18; # UTC
is apparently out of date by 9 months or so:
$ ls -l htmlxref.cnf
-rw-r--r-- 1 karl karl 22555 Oct 8 23:52
/home/ftp/tex/texinfo-latest/htmlxref.cnf
-k
gavin> Is it the same story with lmodern which is another frequently
recommended font package?
I don't know. Norbert, is lm a recommends in Debian? That might be
enough reason to \usepackage{lmodern} by default. If not, for the sake
of minimalism, I would suggest just sticking with the
Patrice, Gavin - I've been talking with my friend Norbert Preining, who
used to be the Debian maintainer of the texlive packages. (He's also one
of the principal maintainers, with me and a couple others, of upstream
TeX Live.)
He confirms that cm-super is not installed as part of the
pdfTeX error (font expansion): auto expansion is only possible with
scalable fonts.
Indeed, font expansion is only usable with scalable fonts. I don't
believe it's possible to test at the TeX level whether a given font
(e.g., cmr10) will ultimately be rendered as outlines or bitmaps :(.
kb> Regarding typewriter: I reiterate the need to turn it off for display
kb> environments.
On second thought, for the LaTeX backend, I can see how it would be
better to simply take the default, that is, \usepackage{microtype}, and
let it be as it is. Going along with "make a natural LaTeX
If the output is better with microtype on, we should try to have it on.
If Texinfo has microtype on by default, I agree the LaTeX backend should
also have microtype on by default. That's fine.
microtypee off if is causes issues in LaTeX output,
Are you talking about the typewriter
There is a new converter in texi2any of Texinfo to LaTeX,
I didn't know. Cool! People have long wanted this. Mainly so they can
change fonts. So I hope you will support that -- which I think amounts
to allowing the user to add stuff to the preamble after your builtings.
On my debian
Hi Patrice - If you write to the tex-live list, more than likely I will
end up being the one who answers, so we might as well continue here :).
What is the question? I don't understand how or why we got on to LaTeX.
LaTeX cannot possibly enable microtype by default, if that's what you
were
Hi Gavin,
I've committed the code and set it on by default. It is controlled
by @microtype on|off.
Thanks!!
makes me suspect that special treatment of @example and @verbatim
may not be required,
I'm pretty sure it is.
as these environments are not filled and lines
Hi Werner,
According to the table on page 6 in the current microtype package,
XeTeX *does* support character protrusion!
I said that in my first mail. XeTeX supports protrusion, but
(unfortunately) not expansion. In my experience, protrusion has little
effect; expansion is where the
I am mainly unsure about if/how this should be turned on in Texinfo
files.
Just make it an option, say, @microtype on|off. Off by default. (And
forced to "off" when output is dvi.) That way it doesn't disturb
anyone. I would not advocate for it to be on by default.
This would
I don't understand why \lastlinefit causes the underful hboxes
Because there isn't any infinite glue any more to stretch as far as is
needed.
but I've removed the setting.
Thanks much!
Hi Gavin. I've found that the microtype package for LaTeX
(https://ctan.org/pkg/microtype) helps significantly in eliminating
overfull lines without the need for rewriting text. (It also improves
the esthetic appearance of the typeset text.)
Therefore I suggest adding it to Texinfo. Maybe with a
Hi Gavin - the new (since August) setting of \lastlinefit in texinfo.tex
can cause numerous new underfull hboxes in existing documents.
Essentially every last line of a paragraph now becomes a candidate for
being underfull, while before the infinite \parfillskip avoided this. An
example is below.
@kbd{@key{TAB}}
Indeed. A feature specifically requested, of course. Implemented by rms
in 1989. (Or maybe I sent the patch and rms installed it, no idea any more.)
Ah, for the days of apple-gunkies ...
Mon Aug 28 00:21:33 1989 Richard Stallman (rms at apple-gunkies.ai.mit.edu)
[...]
There seemed to be a general feeling in the 2018 discussion I linked
to that consistently unslanted fonts are good for @key.
Then
@kbd{foo @key{RET} bar}
would have "foo" and "bar" slanted (by default), and "RET"
unslanted. That seems weird to me. But whatever. -k
I found an inconsistency in the HTML output in the output for @key,
depending on whether it was in @kbd or not. It would be slanted only
if inside @kbd.
Certainly that was an intentional feature, not a random "inconsistency".
Maybe @key should use the same font as @kbd, rather than
Hi Gavin and all - the Texinfo input
@code{@l{} and @L{}}
outputs visible space characters before regular l and L, llapped in the
case of the L, instead of Polish l and L.
(Complete input file and my output below.) It happens with the latest
released texinfo.tex and the one in the source repo.
Does tex4ht ever produce acceptible output?
Certainly. Many people use it for complex math-heavy documents.
But, as far as I know, they are all in LaTeX, which is where essentially
all the work has gone for years now, since that's where the users are.
I don't believe anyone has tried the
I will certainly add it but could you explain what difference it
makes? Does this fix the "font boosting" issue?
It should help (as noted), yes. The practical result is that mobile
devices skip the step of laying out the page with a large size and then
shrinking it, but just render it
Gavin - I suggest adding
to the standard HTML ... block. This will make the result
noticeably better on mobile/pads and is, so far as I have seen, harmless
on larger screens.
It looks like this would be in tp/Texinfo/Convert/HTML.pm,
where the charset http-equiv is output. FWIW ... --best, karl.
Hi Gavin - could you please install an entry for dejagnu in
htmlxref.cnf, as follows? It seems they only have a split html manual
online, which is fine. (It's referred to in the automake manual, where
I'm trying to clean up broken links.) Thanks! (Sorry, I don't think I
have a writable texinfo
Should be only one "as":
% Use \ in index files by default. texi2dvi didn't support @ as as the escape
Should be only one "with":
% Finished with with double columns.
Also, the console messages:
Writing index file eplain.fn
...
trying to print index fn
seem like leftovers from
According to the "Customization Variables for @-Commands" node
(https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Customization-Variables-for-_0040_002dCommands)
there are customization variables for the various head/foot @-commands.
But I guess the implication of the text there:
... api ...
... post-process the HTML files ...
Sure, but isn't this a basic enough feature to be worth providing in
Texinfo? I have always missed a link to package home pages from Texinfo
manual web pages.
I'm not sure what the best way of achieving this is.
Patrice, are you still
Hi Gavin and all - I suggest it would be useful to support a
user-defined navigation "button" that would appear next to [Contents]
xand [Index]. (If it's already possible, please let me know. I couldn't
find it in the doc or souces.)
Just one user variable seems like it would suffice, say
I'm leaning towards agreeing, but I'd like to see
if anyone has an argument for the other choice.
FWIW, I lean towards agreeing too, and have no new arguments. -k
was invented in around 1976,
It was later than that -- 1984-86, based on "Bolio". (See History
section.) rms developed Texinfo soon after starting to (re)write GNU
Emacs, GDB, and the other initial GNU programs.
mouses didn't exist to click on links
I don't see that it had or has
Can't locate TeXLive/TLConfig.pm
As surmised, you're missing tons of stuff. Without knowing how you
installed it, no way to guess what went wrong.
You might be able to recover with "update-tlmgr-latest.sh".
See the "disaster recovery" section in:
http://tug.org/texlive/tlmgr.html
Or you
That's strange, unless this file is dynamically generated,
It isn't.
I could not find it or any reference to it in the
texlive-source-20160605 distribution.
The "source" tarball for TL does not include the runtime files (hundreds
of megabytes of stuff), only the compilable sources.
+ = ($ENV{SOURCE_DATE_EPOCH} ? gmtime($ENV{SOURCE_DATE_EPOCH})
FWIW, seems like SOURCE_DATE_EPOCH should be supported in (upstream) Texinfo.
At least, I can't think of a reason why not ... -k
TeX4ht could be an alternative for what I'd like to achieve.
Speaking as one of the (sort of) maintainers of tex4ht ... sure, give it
a try, I'll be curious what you think, but I doubt it'd be easy to make
use of it. tex4ht has lots of complications of its own. It can, in
general, output
Hi Oliver and Gavin and all,
support for a program called tex2ht, but I've never used it.
tex4ht
> - I have to find a way to bundle / integrate / use the other perl module
> LaTeXML into Texinfo.
LaTeXML (http://dlmf.nist.gov/LaTeXML) is a fantastic program, but it is
huge -- 7MB,
Indeed, I don't believe there is any perfect way to support filenames
with spaces. Double-quoted "foo bar.tex" is the most likely.
I don't know if that works in miktex. Multiple consecutive spaces is
even harder, e.g., see thread starting at
<>| are not valid in filenames
They are on Unix. -k
You cannot expect bash behaviour then.
It's bourne behavior not bash behavior. As you know, we go to great
lengths to avoid bash dependencies in texi2dvi (and in all other core
GNU shell scripts).
However, as I recall, there is a bug in some versions of bash that
require
case "$foo"
On another front:
@iftex
@macro cl{name}
{@smallertt@phantom{concurrency:}@llap{cl:}}\name\
@end macro
@end iftex
What's inside @iftex is supposed to be valid Texinfo.
(Just like @ifinfo, etc.) To lapse into plain/raw TeX,
@tex should be used. That's why it exists.
How can it be correct to omit output from the @node and @unnumbered?
Docbook cannot know the name I want to give to my index. And the whole
node tree would be screwed up. And what if there is other text in the
node besides the @printindex? I don't get it. Not that it's my
I really don't understand the code in \pdfgettoks in texinfo.tex.
Not sure if this is still relevant, but it's not just about page
numbers, is it? I thought that crazy stuff was at least partly about
handling brace characters that should show up literally in the pdf
bookmarks. I believe
tex4ht may also be usable for this purpose, but I couldn't find an
easy way to install
If you want to play with it, install a scheme-minimal TeX Live
(http://tug.org/texlive/acquire-netinstall.html) and then run
tlmgr add tex4ht.
In practice, there is no other practical way to get tex4ht
However, LuaTeX team changed them significantly after ver. 0.80.
Yes. And more changes will surely come, at any and every level -- no
stability has ever been guaranteed until 1.0, for which there is no ETA.
E.g., the latest news is that (as I understand it) LuaTeX ignores
\language0 and
I meant the [motivation for] change in October 2014, but thanks for
the history anyway.
The original idea was to give better error messages (@chapter should be
an error inside @example, etc.), and the subsequent report was about
allowing @heading cmds after all.
In the ChangeLog entry, I
Evidently most web browsers aren't intended to be used as viewers for
XML files following arbitrary DTD's.
Evidently. So I think the manual should say this, that the XML output
cannot be viewed directly in a browser, and is thus only intended for
further processing by other software.
I can't figure it out from info info-stnd cus.
Perhaps that node should explicitly say that only keystrokes passed from
the terminal emulator can be bound, i.e., that info is not an X
application and therefore cannot see non-ASCII things like Shift+Space
or CTRL- or whatever. -k
I believe that it does not follow the uri in the document DOCTYPE
definition
Well, evidently not, since
http://www.gnu.org/software/texinfo/dtd/6.0/texinfo.dtd is found just
fine when visited directly. Unless there is an error in the dtd
preventing it from being applied, which is
Hi Gavin - another long-pending thing I haven't had a chance to get to the
bottom of. The TexinfoXML file generated here,
http://svn.gna.org/viewcvs/*checkout*/latexrefman/trunk/latex2e.xml
visited in a browser, gives the error:
XML Parsing Error: undefined entity
Location:
motivation for this change in the first place.
The motivation was simple enough: compatibility (what else).
For many years, every Texinfo file had @contents (and optionally
@shortcontents) at the end, because that was the way rms originally
wrote texinfo.tex, so that the TOC would be typeset
@setfilename foo.info
@setcontentsaftertitlepage
@settitle Foo
@titlepage
@title Foo
@end titlepage
@contents
As far as I can imagine (I didn't try it), in this example document,
@contents is already "after the title page", so you wouldn't see any
differences in the
ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt">
Clearly it's just a bug to insert the , or anything else, inside
the href="" url argument. Maybe that is all that really needs to be
fixed.
I sadly don't remember what I did (if anything, as I claimed to P@) in
6.0, and I have to be offline
Web browsers don't hyphenate words anyway.
Yes they do, or can. I think it's abominable, but no one asked me :).
In code, they take it upon themselves to consider breaking lines at
explicit hyphens.
So that's the whole reason the is there, and I don't think it
should just go away. There
Gavin -- just as you've squashed one old bug, sending on this one from
P@draig ... didn't check the pretest, sorry. tx.
Date: Wed, 20 Jan 2016 14:28:12 +
From: =?UTF-8?Q?P=c3=a1draig_Brady?= <p...@draigbrady.com>
To: Karl Berry <k...@freefriends.org>
Subject: Re: span class=
Hi Gavin - somewhere in all the brace/indexing changes to texinfo.tex,
it seems that using @{ or @} inside @xref or other ref commands started
to fail (or maybe it never worked, I guess I'm not entirely sure, come
to think of it). Now, something like
@xref{a@}b}
gets (with texinfo.tex
I know there are "virtual fonts" in the TeX world
TeX virtual fonts (that is, .vf files) are irrelevant to the current
discussion. -k
> include every single Unicode character?
Masamichi - Gavin means "all". The vast majority of fonts cover basic
European. That's not the issue.
Gavin - there are a few fonts that "aim to" include every character,
though none actually does. Here's a page with some basic info:
> For example, if you want to use Japanese characters,
> I think that it is possible to set the Japanese font in txi-ja.tex.
To reiterate: as far as I know, it is not possible to set the font for
Japanese only in texinfo[.tex]. Thus the ja font, wherever it is
specified, would be used
it means that you want to use native UTF-8 support in my humble opinion.
Not necessarily. The problem isn't encodings, it's fonts. The two
things are intimately and fundamentally tied together, and that cannot
be escaped.
By switching to native UTF-8, the support in texinfo.tex for
Here's a file that I ran with pdftex and with luatex: both worked.
Worked for me too (also tex and etex; xetex still fails, of course, but
that's ok). Nice job. I could ask my LuaTeX friends if we're missing
anything, but it looks straightforward.
My only comment is merely stylistic: for
Gnulib people - Eli Z reported seeing this familiar shell diagnostic
with the current Texinfo configure:
./configure: line 22339: test: =: unary operator expected
That line turns out to be:
if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
And looking at gnulib/m4, indeed that
I agree it should be skipped.
In some ideal world, but in this world, I think doing so would lead to
huge problems. For the present, it seems far more feasible to me to
keep using the UTF-8 code in texinfo.tex for the immediate problem than
refactor all the font stuff, all the character
Processing the attached document with luatex, I get
I guess we're talking about U+00A7, the section sign, \S in plain.tex?
I suppose something somewhere is overwriting that definition, and we
should \let the plain \S as some other longer name to avoid the problem.
(Plain LuaTeX itself does
ag> of its new atomic file-swap ability:
http://lists.gnu.org/archive/html/coreutils/2015-11/msg00068.html
Nice, but no "new" facility can be assumed for general use. That's why
I hoped there would be a gnulib module that make use of such fancy new
facilities where possible, and fall
My $0.1, fwiw:
1) a signal handler seems crazy to me. That would imply every program
that writes anything should catch every signal just because someone
might interrupt it.
2) if I type "gcc foo.c" and hit ^C while it's compiling, I do not
expect gcc to detect that and keep my
1) In principle, there should be no line breaks within @w. That is the
purpose of @w. (Even if fixed, I agree that's hardly a practical
solution for the problem at hand, of course.)
2) Why is makeinfo considering that mid-text location to be a valid
place to break the line? I don't see a
Follow-up Comment #3, bug #46083 (project texinfo):
don't define unicode characters in documents based on the texinfo.tex version
(surely unmaintainable), but simply on whether they are defined or not
(\csname uni:\endcsname being defined).
For that matter, it would be trivial for
> many manuals have indexed items starting with a backslash that are
> better indexed under a letter following the backslash (an example from
> Texinfo's manual is \mathopsup, better indexed under "M").
I suppose this decision is already made, but I feel compelled to kibitz,
sorry:
I think that not removing the last end of line of raw blocks would
probably be better, but some manuals may expect the end of line to be
We can be sure that any change regarding behavior of newlines and macros
will break some manuals. It happens every time. -k
come up with for a tick was the radical sign.
The lineless radical looks surprisingly ok to my eyes. I hadn't thought
of that. Sounds fine. The complication is that we're not currently
loading cmex at different sizes at all, so that will take some tweaking
a la cmmi to do it right.
Actually, the "File:" and "Node:" parts are redundant: they also
appear in the mode line.
I am well aware of that (obviously). However, even though it is
redundant, the the top of the screen and the bottom of the screen are
two different things. I find having the basic info useful in
Since you ask ...
Personally, I detest all forms of terminal manipulation, be it reverse
video, underlining, fake bold, colorization, or what have you. For me,
all such things merely distract from reading the content, which is what
I'm interested in. (For me, this is the case for everything,
To reiterate Gavin's reply ...
1. Any definitions for Unicode characters that you have that we don't
have, and are supported in the CM fonts, we want to add.
2. I added the error check because it is too easy to make incorrect
duplicate definitions within texinfo.tex itself. I did it more than
I notice that the second line usually doesn't reach the start of the
"Next:" text on the first line, so if the "File:" and "Node:" parts
are hidden, it will usually fit on one line.
I find the File: and Node: parts of the hdr line the most useful.
At least Node:, for sure, much more
+ if test $generated_files_get_method = generated_files_get_from_fls; then
+if test -f "$in_noext.fl"; then
+ report 'WARNING!! You may typeset garbage!' # goes to stderr
+fi
+ fi
(Aside: I usually find test -r more useful than test -f, because if by
some weird
Hi Gavin,
gs> If someone uses an "fl" index with the recorder, I expect either
the index to be blank, or to be the recorder file interpreted as TeX
source (a great ugly mess).
There's a comment in texi2dvi that says
# The default behaviour is `nomaybe'.
But the actual default for
gs> Can anybody try the script with LaTeX source with BibTeX, or
else send me a test case? I want to make sure the BibTeX files are
checked properly.
% bibsimple.tex
\documentclass{article}
\begin{document}
\nocite{*}
\bibliographystyle{plain}
\bibliography{xampl}
I would guess that bonus is there to try to get an @example not to
span more than one page.
Right.
On the other hand, it's true enough that the text before an example
usually leads into the example. It seems like this is true of any
environment. Thus perhaps the \penalty-50 should
are the TeXLive engine MSys application ?
There is no explicit support for msys in TeX Live, as far as I can
recall. There is support for cygwin and native Windows.
How do you handle texi2xxx
tools for MSW in TeXLive ?
I'm not sure what you're asking, but as you know, texi2dvi is
Follow-up Comment #1, bug #45912 (project texinfo):
the enhancement you propose is an enhancement, not a regression. it seems a
nontrivial and confusing idea imho. certainly making up new cmdline syntax is
not at all desirable.
it is true that arnold and i did not implement the actual texindex
gs> Remove env var from help message - there should be no need for the
gs> user to think about this.
...
vb> Anyway, let us give Karl the final word about that...
0) I don't know what the current state is, since changes are apparently
not committed yet.
1) I'm not sure that it's
Follow-up Comment #1, bug #45859 (project texinfo):
my view, with which you may disagree, is: do nothing.
i don't understand why it's info's place to solve every locale problem in the
world. every single program that displays text from files has the same basic
issue, as far as i can see. to me
Can someone tell me why there is all this stuff in texi2dvi for
processing LaTeX files?
A contributor (Akim Demaille) wrote the LaTeX support many years ago, on
the theory that the general process is identical. I don't know how many
people actually use it, but I would be leery of
I can't look at the patch any time soon, sorry. I'm sure Gavin will do
a good review :).
I think using -recorder (when it's available) should be the default, as
I wrote privately to Gavin a few days ago. I don't know what he thinks.
k
\initial {\\}
As I recall, Arnold and I did that as part of the new texindex, so that
backslashes could be properly sorted, etc. It seems semantically
correct to me. Trying to treat {\tt \indexbackslash } as equivalent
to \ seemed poor design.
(Ultimately, what I really want is for the
But I don't understand why the change was made in the first place.
Presumably because Stepan constructed a texinfo document with a horribly
stretched index. I'm not enthusiastic about the change as you've shown
it, though, and don't mind reverting to the \penalty-300 until we have a
At this point, I guess I have to conclude it is better to use -recorder
if it is available.
k
I'm not sure what the Makefile.PL is doing there;
As I understood it, it was for the sake of making a texi2any Perl module
that could be uploaded to CPAN and installed in the normal CPAN way. (I
don't believe that has actually happened yet, but that was the theory.)
FWIW:
1) Personally, I find it convenient sometimes to just hold down the
PageUp (or Down) key and autorepeat and get to the top/bottom of the
first/final node. It seems intuitive that, if you're not at the top,
PageUp will go up as far as possible.
2) A message is nice, but I would think of it
lots of mails here
Indeed. I'm afraid I can't keep up, so after these short replies, I'm
bowing out of this thread.
I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting to be able to *check* all of them.
I don't
1 - 100 of 1358 matches
Mail list logo
