Re: Texinfo.tex, problem with too-long table inside @float
arn...@skeeve.com wrote:
> Attached is a diff that uses the longtable package. It seems to
> do the trick, at least for what I need. It also looks like I
> can script the edits to convert makeinfo's output to this.
Attached is the script I'm using to munge the LaTeX output
to using the longtable package. Totally FYI, nothing necessarily
actionable.
Thanks again everyone.
Arnold
#! /usr/local/bin/gawk -f
/^% use hidelinks/ {
print "\\usepackage{longtable}"
print
next
}
/^\\begin\{table\}/ {
getline caption # \caption{GLIBC values for \texttt{errno}}
getline tabular # \begin{tabular}{m{.18\textwidth}
m{.20\textwidth} m{.62\textwidth}}%
sub(/^\\begin\{tabular\}/, "", tabular) # get just the {m...} part
print "\\begin{longtable}" tabular
print caption " "
in_table_env = 1
next
}
in_table_env && /^\\end\{tabular\}/ {
getline label # \label{anchor:table_002derrno_002dvalues}%
getline endtable# not used
sub(/%$/, "", label)
print label " "
print "\\end{longtable}"
in_table_env = 0
next
}
{ print }
Re: Texinfo.tex, problem with too-long table inside @float
Thanks Karl.
Attached is a diff that uses the longtable package. It seems to
do the trick, at least for what I need. It also looks like I
can script the edits to convert makeinfo's output to this.
My knowledge of LaTeX is nil, and is likely to stay that way.
I developed this fix by pattern matching against examples on the
Internet. Examples from other packages were extremely opaque, at
least to me.
I'll agree w/Karl that texinfo.tex doesn't really need significant
multi-page table support.
Gavin --- I'll leave it up to you as to what you do for the
long term. Some kind of simple improvements would be nice, but
my immediate problems are under control.
Much thanks, everyone!
Arnold
Karl Berry wrote:
> 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 multi-page table is a much
> bigger problem (repeating headers, what to do with the caption, etc.).
> I know that's not Arnold's immediate problem, but looking ahead,
> I could imagine having makeinfo --latex use one of the longtable
> packages in the event of a long float. (Implementing it in texinfo.tex
> would not be sensible IMHO.)
>
> I think the best package for that nowadays is xltabular
> (https://ctan.org/pkg/xltabular), but which LaTeX
> package gets loaded should presumably be configurable.
>
> Happy Texinfoing,
> Karl
--- progex.tex 2023-12-03 21:11:29.509779772 +0200
+++ progex.tex.good22023-12-03 21:10:39.345984362 +0200
@@ -13,6 +13,7 @@
\usepackage[framemethod=tikz]{mdframed}
\usepackage{enumitem}
\usepackage{float}
+\usepackage{longtable}
% use hidelinks to remove boxes around links to be similar to Texinfo TeX
\usepackage[hidelinks]{hyperref}
@@ -5376,9 +5377,8 @@
other Unix-like systems. In your code, you should \emph{always}
use the symbolic names.
-\begin{table}
-\caption{GLIBC values for \texttt{errno}}
-\begin{tabular}{m{.18\textwidth} m{.20\textwidth} m{.62\textwidth}}%
+\begin{longtable}{m{.18\textwidth} m{.20\textwidth} m{.62\textwidth}}%
+\caption{GLIBC values for \texttt{errno}} \\
Name &Numeric Value &Meaning\\
\texttt{EPERM} &1 &Operation not permitted.\\
\texttt{ENOENT} &2 &No such file or directory.\\
@@ -5514,9 +5514,8 @@
\texttt{ENOTRECOVERABLE} &131 &State not recoverable.\\
\texttt{ERFKILL} &132 &Operation not possible due to RF-kill.\\
\texttt{EHWPOISON} &133 &Memory page has hardware error.\\
-\end{tabular}%
-\label{anchor:table_002derrno_002dvalues}%
-\end{table}
+\label{anchor:table_002derrno_002dvalues} \\
+\end{longtable}
Many systems provide other error values as well, and older systems may not
have all the errors just listed. You should check your local \emph{intro}(2)
Re: Texinfo.tex, problem with too-long table inside @float
Hi. Gavin Smith wrote: > The \vbox is not moved around for texinfo.tex but it is possible that > the @float may be moved around in other output formats: LaTeX or DocBook, > for example. Yes, I got that. And that's OK. > (For LaTeX, there is the 'longtable' package > (https://ctan.org/pkg/longtable?lang=en) which appears to allow splitting > tables across pages, although using this would require you to edit > the LaTeX output manually.) I will be looking into that. It might be that eventually makeinfo --latex should use that instead of the regular table package. > The solution that occurs to me is to recognise a third argument for > @float. . > > % #3 is the optional positioning argument; for now, it is ignored. It > % will somehow specify the positions allowed to float to (here, top, bottom). > > (I can't find any discussions from the time about the new feature > in the mailing list archives.) 2004 is about the time I was writing the first edition of the book I'm now updating. :-) IIRC, @float came about as the result of private email between me and Karl, which is why you're not finding anything on the list. > If the position is given as "here" (or whatever we decide), we could > then omit the \vtop wrapping. So in your example, the @float line > would become > > @float Table,table-errno-values,here > > This would also need modifications to texi2any to recognise the additional > argument. I'm good with that for the long term solution. For the short term, I've removed the \vtop from my copy of texinfo.tex, and I will look into scripting edits of the generated LaTeX. (Last time I delivered the book in Dockbook XML. These days the publisher wants LaTeX. [I guess that's progress!]) > As I said before, with the label at the bottom of the table, if the > table is split across pages, then it does not function properly as > a label. So simply removing the \vtop wrapping may not produce > satisfactory output. I think it did, but I will double check this. In any case, it just needs to be good enough for reviewers to read the book for review; production will be done with LaTeX. Much thanks! Arnold
Re: Texinfo.tex, problem with too-long table inside @float
Removing the \vtop from texinfo.tex did the trick for me. Not sure about makeinfo --latex though... Thanks, Arnold arn...@skeeve.com wrote: > Hi. > > Thanks for the response. I do have a number of floats (it's a good- > sized book) but this may be the only table that is so large. > It is important that I refer to the floats from the text with an xref. > > Since the \vbox is never actually moved around, maybe just don't > put the enclosed stuff inside one? That would suit me fine for both > texinfo.tex and makeinfo --latex (which I will use to submit the > book for production). > > Thanks! > > Arnold > > Gavin Smith wrote: > > > On Fri, Dec 01, 2023 at 10:45:14AM +0200, Aharon Robbins wrote: > > > Hi. > > > > > > Using version 2023-10-19.19 of texinfo.tex, there is a problem if > > > a table inside @float goes over one page. See the attached file. > > > > > > If the table is not inside @float, it formats just fine across > > > multiple pages. > > > > Unfortunately, it's inherent in the meaning of the @float command that > > the enclosed material will fit on a single page. As long as it is output > > inside a \vbox or \vtop, it can't be split across pages. > > > > If I convert your test file to LaTeX with 'texi2any --latex', and then > > process the output with pdflatex, the output PDF has exactly the same > > problem, with the table disappearing off the bottom of the page. > > > > You could use an @anchor to refer to the table, although without > > the automatic numbering of the table, unfortunately. @float has > > the dual purpose of providing numbering and cross-referencing, > > as well as controlling the formatting of the block. > > > > (It seems that the @float command at one time was intended to change > > the position of the block on the page, but this was never implemented > > in texinfo.tex.) > > > > The float caption would not be satisfactorily placed even if the > > table did split across pages, as it is placed at the end of the > > float, so would not be visible on the first page where the table > > appears. > > > > How important is it to you that you can refer to tables with text > > like "See Table 1"? Do you have many numbered tables in the document? > > > > Could it be appropriate to place such long tables as these in a section > > of their own which then could be cross-referenced as usual? > > > > > This example is culled from a book I'm working on. I need the @float > > > in order to be able to use an @ref to the table from the inline prose. > > > > > > Much thanks! > > > > > > Arnold > >
Re: Texinfo.tex, problem with too-long table inside @float
Hi. Thanks for the response. I do have a number of floats (it's a good- sized book) but this may be the only table that is so large. It is important that I refer to the floats from the text with an xref. Since the \vbox is never actually moved around, maybe just don't put the enclosed stuff inside one? That would suit me fine for both texinfo.tex and makeinfo --latex (which I will use to submit the book for production). Thanks! Arnold Gavin Smith wrote: > On Fri, Dec 01, 2023 at 10:45:14AM +0200, Aharon Robbins wrote: > > Hi. > > > > Using version 2023-10-19.19 of texinfo.tex, there is a problem if > > a table inside @float goes over one page. See the attached file. > > > > If the table is not inside @float, it formats just fine across > > multiple pages. > > Unfortunately, it's inherent in the meaning of the @float command that > the enclosed material will fit on a single page. As long as it is output > inside a \vbox or \vtop, it can't be split across pages. > > If I convert your test file to LaTeX with 'texi2any --latex', and then > process the output with pdflatex, the output PDF has exactly the same > problem, with the table disappearing off the bottom of the page. > > You could use an @anchor to refer to the table, although without > the automatic numbering of the table, unfortunately. @float has > the dual purpose of providing numbering and cross-referencing, > as well as controlling the formatting of the block. > > (It seems that the @float command at one time was intended to change > the position of the block on the page, but this was never implemented > in texinfo.tex.) > > The float caption would not be satisfactorily placed even if the > table did split across pages, as it is placed at the end of the > float, so would not be visible on the first page where the table > appears. > > How important is it to you that you can refer to tables with text > like "See Table 1"? Do you have many numbered tables in the document? > > Could it be appropriate to place such long tables as these in a section > of their own which then could be cross-referenced as usual? > > > This example is culled from a book I'm working on. I need the @float > > in order to be able to use an @ref to the table from the inline prose. > > > > Much thanks! > > > > Arnold >
Re: weird bug texinfo.tex 2023-03-21.06
Gavin Smith wrote: > I've attempted to fix it in version 2023-03-27.21. I tried to > support different configurations of manual (e.g. @contents at start, > @contents at end, no @contents) but it is quite possible I've missed > some possibilities. Looks good to me. Thanks! Arnold
Re: weird bug texinfo.tex 2023-03-21.06
Gavin Smith wrote: > On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote: > > Hi. > > > > I just formatted the gawk manual to PDF. The pages themselves > > look fine. However, using evince on Ubuntu 22.04, the side bar showing > > the sections and pages, has all the page numbers in roman numerals! > > > > I'm using texi2pdf 7.0.1. > > > > Let me know if you want a screen shot. > > > > Thanks, > > > > Arnold > > > > I've attempted to fix it in version 2023-03-27.21. I tried to > support different configurations of manual (e.g. @contents at start, > @contents at end, no @contents) but it is quite possible I've missed > some possibilities. Much thanks. I will try it out. Arnold
Re: weird bug texinfo.tex 2023-03-21.06
Hi. Gavin Smith wrote: > On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote: > > Hi. > > > > I just formatted the gawk manual to PDF. The pages themselves > > look fine. However, using evince on Ubuntu 22.04, the side bar showing > > the sections and pages, has all the page numbers in roman numerals! > > > > I'm using texi2pdf 7.0.1. > > > > Let me know if you want a screen shot. > > > > Thanks, > > > > Arnold > > I replicated the issue with a version of gawk.texi I have installed. I > don't need a screenshot. > > I expect I will be able to fix this, but it may take a day or two. There's no rush. But I did think you'd want to know about it. :-) > The roman numerals are only supposed to be used for the front matter > where the page numbers are also printed with roman numerals. One would think so, yes. :-) Thanks, Arnold
weird bug texinfo.tex 2023-03-21.06
Hi. I just formatted the gawk manual to PDF. The pages themselves look fine. However, using evince on Ubuntu 22.04, the side bar showing the sections and pages, has all the page numbers in roman numerals! I'm using texi2pdf 7.0.1. Let me know if you want a screen shot. Thanks, Arnold
Re: bug in texinfo.tex 2022-12-19.22
Hi. Gavin Smith wrote: > On Mon, Jan 02, 2023 at 10:36:20PM +0200, Arnold Robbins wrote: > > Hi. > > > > When I format the gawk manual using texinfo.tex 2022-12-19.22 > > there is a problem on the very first two pages. These are the > > pages from @shorttitlepage. > > > > The bug is that these pages have page numbers! The first page > > has a simple "1". The second (otherwise blank) page has a > > full header and the number "2". > > > > This didn't use to happen. > > Many thanks for the report; this is definitely a bug and I'm glad > you've reported it so quickly. What else are friends for? :-) > It should be fixed in commit 400d2ebbe47, version 2023-01-02.21. > > I have uploaded the new version to ftp.gnu.org as this bug was > present in the previously-uploaded version. Works great. I will get this into my repo in the next day or so. Thank you very much for the quick turnaround! Arnold
bug in texinfo.tex 2022-12-19.22
Hi.
When I format the gawk manual using texinfo.tex 2022-12-19.22
there is a problem on the very first two pages. These are the
pages from @shorttitlepage.
The bug is that these pages have page numbers! The first page
has a simple "1". The second (otherwise blank) page has a
full header and the number "2".
This didn't use to happen.
To reproduce:
git clone https://git.savannah.gnu.org/r/gawk.git
cd gawk
./bootstrap.sh && ./configure && make
cd doc
make pdf
Thanks,
Arnold
Re: feature request for sidebars
Gavin Smith wrote: > On Wed, Dec 21, 2022 at 10:55:41PM -0700, arn...@skeeve.com wrote: > > Hi. > > > > I have fixed that sidebar to be a subsection and made other changes > > for LaTeX support. It's now integrated into the gawk-5.2-stable and > > master branches in the gawk git repo. > > > > W.R.T. sidebars, please let me know when texinfo.tex supports > > @cartouche with a title. > > Hello Arnold I have committed an implementation of this feature in > texinfo.tex. The title is centred and in bold. Please try it with > your manual and report if it looks right or not. > > The left and right inner margins of @cartouche may be too tight but this > was a problem before. This is really cool. Thanks. At first glance, it looks great! I will send you privately links to copies of the manual formatted before and after. I will wait until the next texinfo release before actually switching the manual over. I like to use released tools for my infrastructure. This is really lovely - thanks everyone! Texinfo has gradually evolved over the years to a rich enough language that I can use it for publishing; this was the last item on my wishlist! Thanks, Arnold
Re: feature request for sidebars
pertu...@free.fr wrote: > Here is the a commit that fix the issue of @float in @cartouche: > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=afc41f26aeefe90ee86c3086955e24a4b645085b > > It won't float, but should be otherwise ok. Great, thanks! Arnold
Re: feature request for sidebars
Hi. pertu...@free.fr wrote: > > In any case, making this an explicit parse error would probably help. > > After some thinking it is not so clear to me that we should flag it as > an error, as it could also be in the formatting backends that the float > is made non floating. In texi2any at least it could be relatively easy. > We could have an extra key stating that the float is actually floating > or not. I'm OK with that. I have already converted the problematic sidebar into a subsection, and I'm OK with that situation. Thanks, Arnold
Re: feature request for sidebars
Hi.
I have fixed that sidebar to be a subsection and made other changes
for LaTeX support. It's now integrated into the gawk-5.2-stable and
master branches in the gawk git repo.
W.R.T. sidebars, please let me know when texinfo.tex supports
@cartouche with a title.
This has been an interesting and fun thread. I feel like we've
accomplished something worthwhile, even if just in a small way.
Thanks very much!
Arnold
arn...@skeeve.com wrote:
> Hi.
>
> Thanks for figuring this out. The problem is that in this case
> there is no way to directly give the table a title and anchor for cross
> referencing from the main text except by wrapping it in @float.
>
> I suppose that I could just make this particular sidebar a regular
> subsection, but the general problem of tables and figures inside @cartouche
> remains.
>
> In any case, making this an explicit parse error would probably help.
>
> Thanks!
>
> Arnold
>
>
> pertu...@free.fr wrote:
>
> > Hello,
> >
> > The error actually comes from a construct like
> >
> > @cartouche
> >
> > @float Table,label
> > @caption{Return}
> > @end float
> >
> > @end cartouche
> >
> > My feeling is that @float should only be valid at top-level, not in a
> > block command, such as @cartouche, if in a block, the float cannot
> > float.
> >
> > I would propose to have an error during parsing for that case. Looks
> > good to you?
> >
> > --
> > Pat
Re: feature request for sidebars
Hi.
Thanks for figuring this out. The problem is that in this case
there is no way to directly give the table a title and anchor for cross
referencing from the main text except by wrapping it in @float.
I suppose that I could just make this particular sidebar a regular
subsection, but the general problem of tables and figures inside @cartouche
remains.
In any case, making this an explicit parse error would probably help.
Thanks!
Arnold
pertu...@free.fr wrote:
> Hello,
>
> The error actually comes from a construct like
>
> @cartouche
>
> @float Table,label
> @caption{Return}
> @end float
>
> @end cartouche
>
> My feeling is that @float should only be valid at top-level, not in a
> block command, such as @cartouche, if in a block, the float cannot
> float.
>
> I would propose to have an error during parsing for that case. Looks
> good to you?
>
> --
> Pat
Re: feature request for sidebars
Hi Patrice,
> > Going through ps nowadays is not really needed, such that this can be
> > simplified in
> >
> > makeinfo --latex gawk.texi
> > pdflatex gawk.tex
> > pdflatex gawk.tex
>
> Thanks. I'm getting errors. Once I've pushed things to Git
> where folks can get to it I will send more information.
Please clone the gawk repo and switch to feature/latex-support.
git clone https://git.savannah.gnu.org/r/gawk.git
cd gawk
git checkout feature/latex-support
./bootstrap.sh && ./configure && make -j
cd doc
makeinfo --latex gawk.texi
pdflatex gawk.tex
For me it dies like so:
| ! LaTeX Error: Not in outer par mode.
|
| See the LaTeX manual or LaTeX Companion for explanation.
| Type H for immediate help.
| ...
|
| l.9513 \caption
|{Return values from \texttt{close()} of a pipe}
If you wish to make changes and test, please edit gawktexi.in and then
use 'make gawk.texi' to get input for makeinfo.
I'm using makeinfo 7.0.1 and the texinfo.tex from the texinfo-7.0.1
distribution.
Much thanks,
Arnold
Re: feature request for sidebars
pertu...@free.fr wrote: > Going through ps nowadays is not really needed, such that this can be > simplified in > > makeinfo --latex gawk.texi > pdflatex gawk.tex > pdflatex gawk.tex Thanks. I'm getting errors. Once I've pushed things to Git where folks can get to it I will send more information. Arnold
Re: feature request for sidebars
pertu...@free.fr wrote: > On Tue, Dec 20, 2022 at 02:00:18AM -0700, arn...@skeeve.com wrote: > > Does makeinfo generate LaTeX these days? > > Yes, and we'd welcome feedback, in particular on customization of the > LaTeX output. > > > Can that be done for TeX and Info? > > It is done for all the texi2any output formats: > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=6de28d2066040582e983ba1f7db609598011e99d > > -- > Pat Lovely! Looking forward to seeing it in texinfo.tex also. Then once it's formally released, I will switch the gawk manual over to it. WRT makeinfo --latex, I need to go through the manual and add appropriate @iflatex / @ifnotlatex stuff and then try to format it. I've never used latex. I assume the sequence is something like makeinfo --latex gawk.texi # should have no errors / warnings latex gawk.tex latex gawk.tex # second time for xrefs and indexing dvi2ps gawk.dvi gawk.ps ps2pdf gawk.ps gawk.pdf If not, what's the right incantation(s)? Thanks! Arnold
Re: feature request for sidebars
Thanks Patrice for the makeinfo change!
pertu...@free.fr wrote:
> On Mon, Dec 19, 2022 at 10:43:08PM +, Gavin Smith wrote:
> > On Sun, Dec 18, 2022 at 01:01:11AM -0700, arn...@skeeve.com wrote:
> > > Hi Patrice.
> > >
> > > Having @cartouche take an optional title and render as in
> > > Docbook would be a perfect solution for me. I don't need the @sidebar
> > > command specifically, just the fucntionality. So, I really like this
> > > suggestion.
> >
> > I agree; there seems to be no reason that this shouldn't be implemented
> > and it is a good use of the @cartouche command, avoiding the need for
> > any new command to be added.
>
> For LaTeX there is an optional argument of mdframed that could be used,
Does makeinfo generate LaTeX these days?
> for HTML cartouche is in a table, so a table title should be ok. Any
> idea on how the @cartouche title should be formatted in Plaintext/Info?
> Maybe simply output the line followed by an empty line?
I transformed @sidebar into
@cartouche
@center{@b{Title Stuff Here}}
@end cartouche
Can that be done for TeX and Info?
Thanks!
Arnold
Re: feature request for sidebars
Hi Patrice. Having @cartouche take an optional title and render as in Docbook would be a perfect solution for me. I don't need the @sidebar command specifically, just the fucntionality. So, I really like this suggestion. I don't think there are specific constraints to what can go into a sidebar (I assume you mean within the docbook context). I remember trying to get sidebars working as macros a long time ago and it not working very well. I would like it to work in TeX as well as in everything else since I use texi2pdf a lot. Thanks! Arnold Patrice Dumas wrote: > Hello, > > On Sat, Dec 17, 2022 at 01:28:21PM -0700, arn...@skeeve.com wrote: > > Hi. > > > > I'd like to request a feature. > > > > I would like to have > > > > @sidebar Sidebar Title Here > > > > @end sidebar > > This looks like @cartouche in Texinfo. The difference is that > @cartouche never has a title. Maybe the best would be to add a title to > @cartouche instead? > > > For docbook, this becomes something like > > > > Sidebar Title Here > > > > > > I think that it would be better to render @cartouche as in > DocBook in any case. Are there specific constraints on what can be > nested within a ? > > > I currently use an awk script to generate this for the gawk > > manual, bug I'd like to have it built-in. :-) > > @macro + @ifdocbook + @inlineraw should work without a need for an external > script? Thought maybe not in TeX. > > -- > Pat
feature request for sidebars
Hi.
I'd like to request a feature.
I would like to have
@sidebar Sidebar Title Here
@end sidebar
For docbook, this becomes something like
Sidebar Title Here
and for everything else
@cartouche
@center @b{Sidebar Title Here}
...
@end cartouche
I currently use an awk script to generate this for the gawk
manual, bug I'd like to have it built-in. :-)
O'Reilly books often have sidebars; they are boxed-off sections
of text with a title used to explain interesting or important
side points. The gawk manual has a number of them.
Much thanks,
Arnold
Re: `texindex` output depends on locale settings
Eli Zaretskii wrote: > Since texi2any just went through the same process, I think Perl is > probably a good candidate to replace Gawk as an implementation language > for texindex. Another possibility is Python. I have no objection to someone else (re)writing texindex in another language. It's not that big a program to start with, 648 lines in the current texinfo repo. Gavin, please sync with me offline as to what, if anything, you want me to do. Thanks, Arnold
Re: `texindex` output depends on locale settings
Eli Zaretskii wrote: > > and similarly capable C libraries > > Are there such libraries in existence, when locale data is considered? > Which ones? macOS, and Solaris, to name two. I think AIX as well. > > provided this is well documented and probably shown in the output of > > `--version`. That's not doable. Werner's idea of a shell wrapper is what I was thinking about. Obviously texindex, and gawk underneath it, can't do more than what the underlying C library and installed locales enable. But on systems where they can (which is not just GLIBC), it should be possible to do more than they currently do now. Arnold
Re: `texindex` output depends on locale settings
Eli Zaretskii wrote: > Sure, but is the issue only with lower-case letters? What about > collation order or even determining what is and isn't a character (as > opposed to incomplete byte sequence)? I have some thoughts about this. I'd have to do some research and try them out. > I mean: what if the document is encoded in Latin-1, but the locale's > codeset is UTF-8? Then the 0xE0 byte (à in Latin-1 encoding) will > probably not be identified as lower-case. Again, I have some thoughts, I'll have to work with the texinfo maintainer on this. Thanks, Arnold
Re: `texindex` output depends on locale settings
Eli Zaretskii wrote:
> Are you sure this Werner's request can be fulfilled:
>
> > > I consider it very bad that `texindex` is locale-dependent. IMHO
> > > the proper solution is to make `texinfo.tex` emit a document
> > > encoding statement to the (unsorted) index file that in turn gets
> > > acknowledged by `texindex`.
Sure? No. But I have some thoughts.
> FWIW, I don't even understand how can this be accomplished, unless the
> program reinvents all the library functions that deal with characters
> from scratch, instead of using libc functions (which are
> locale-dependent). And Gawk does use libc functions for that.
The current islower() is
function islower(c)
{
return index("abcdefghijklmnopqrstuvwxyz", c) > 0
}
It could instead be
function islower(c)
{
return c ~ /[[:lower:]]/
}
And similar for the others. That would work for any unicode character.
Arnold
Re: `texindex` output depends on locale settings
Hi.
Thanks for the report. As written, texindex is indeed suitable only
for English; when I wrote it ~ 9 years ago, nobody said anything about
support for other languages.
I think this can be remedied, although there may be issues with
awk versions besides gawk as most don't support Unicode or other
multibyte character sets.
Arnold
Werner LEMBERG wrote:
>
> [texindex (GNU texinfo) 6.8dev]
> [GNU Awk 4.2.1, API: 2.0]
> [openSUSE Leap 15.4]
>
>
> There are two bugs with texindex, making it basically unusable for
> everything except English as the main document language. For the
> report below, here is an input file.
>
> ```
> \input texinfo.tex
>
> @documentencoding UTF-8
> @documentlanguage ca
>
> @findex a
> @findex à
> @findex u
> @findex ù
>
> @printindex fn
>
> @bye
> ```
>
> * The first, really severe bug is that the resulting output is
> completely broken if `texindex` is called with `LANG=C`. Saying
>
> ```
> LANG=C texi2pdf sort-ca.texi
> ```
>
> creates the following `.fns` output
>
> ```
> \initial {0xc3}
> \entry{\code {à}}{1}
> \entry{\code {ù}}{1}
> \initial {A}
> \entry{\code {a}}{1}
> \initial {U}
> \entry{\code {u}}{1}
> ```
>
> As can be seen, the `\initial` line contains a single byte (where
> '0xc3' is a real byte), which suprisingly doesn't make pdftex abort,
> but both xetex and luatex stop with errors. I have to use a UTF-8
> locale like `en_US.utf8` to get decent output.
>
> I consider it very bad that `texindex` is locale-dependent. IMHO
> the proper solution is to make `texinfo.tex` emit a document
> encoding statement to the (unsorted) index file that in turn gets
> acknowledged by `texindex`.
>
> * While `texindex` is sensitive to the locale regarding the input
> encoding, it isn't for collation: any `LANG` or `LC_COLLATE` setting
> gets ignored. Similarly, it ignores the `@documentlanguage`
> instruction to derive a sorting order. For example, the Catalan
> order for the above example should be 'aàuù', however, in the output
> it is sorted as `àùau'.
>
> The proper fix would be to make `texinfo.tex` emit a document
> language statement to the (unsorted) index file that in turn gets
> acknowledged by `texindex`.
>
>
> Werner
Re: Feature request: multilevel indexing for TeX
Glad to hear it! Enjoy.
Arnold
Raymond Toy wrote:
> On Sun, May 19, 2019 at 8:44 AM Raymond Toy wrote:
>
> > Thanks for looking into this. I think I'm getting confused on which
> > version of makeinfo and texindex.tex is getting used. (I have 3 version on
> > my system).
> >
>
> Redid this on a different system which had just one installed texinfo. I
> installed the dev version into its own prefix, and everything works fine.
> The multi-level index looks great and of course works fine with html (in a
> different fashion, of course).
>
> Not sure what's going on with my other system, but I'm quite happy with the
> results on this system.
>
> Thanks for your hard work on this!
>
> >
> > I think the issue I reported here is that I was using pdftex to create the
> > doc. Using makeinfo --pdf doesn't have that problem. But it complains
> > about something else. I want to make sure it's from the dev texinfo stuff
> > and not some older 6.6 (or earlier) version.
> >
> > On Sun, May 19, 2019 at 2:54 AM Gavin Smith
> > wrote:
> >
> >> On 5/18/19, Raymond Toy wrote:
> >> > With my old hack. With the new texinfo, I changed the macro to say
> >> >
> >> > @cindex \topic\ @subentry \subtopic\
> >> >
> >> > makeinfo --pdf foo.texi
> >> >
> >> > has errors like:
> >> >
> >> > Unde
> >> > fined control sequence.
> >> > \temp ->\xeatspaces {unix} \subentry
> >> > \xeatspaces { pathnames}
> >> > \dosubindwrite ...mpty \xdef \indexsortkey {\temp
> >> > }\ifx \indexsortkey
> >> > \empty...
> >> >
> >> > \safewhatsit ... \else \vskip -\whatsitskip \fi #1
> >> > \ifx \lastskipmacro
> >> > \zeros...
> >> >
> >> > \dosubind ...dcsname }\safewhatsit \dosubindwrite
> >> > }\fi
> >> > l.2 ...s {unix} @subentry @xeatspaces { pathnames}
> >> >
> >> > \scanmacro ...\\=\active \scantokens {#1@texinfoc}
> >> > \aftermacro \catcode
> >> > `\@=\...
> >> > l.1657 @cpsubindex{unix, pathnames}
> >>
> >> I couldn't reproduce the problem. I found that @subentry worked OK
> >> with macros, although it is not surprising that there should be a
> >> problem here.
> >>
> >
> >
> > --
> > Ray
> >
>
>
> --
> Ray
Re: Feature request: multilevel indexing for TeX
Hi.
Gavin is the TeXpert, but
> It's easy enough for me to work around this by just globally replacing
> @cpsubindex{foo, bar} with @cindex foo @subentry bar
Doing that is probably your best bet, IMHO.
Arnold
Raymond Toy wrote:
> Found a small issue and I'm not sure of the cause. I can easily workaround
> this since @subentry works for all output formats that I care about (pdf,
> html, info).
>
> Before @subentry was available I used this macro:
>
> @macro cpsubindex {topic,subtopic}
> @iftex
> @cindex \topic\!\subtopic\
> @end iftex
> @ifnottex
> @cindex \topic\, \subtopic\
> @end ifnottex
> @end macro
>
> With my old hack. With the new texinfo, I changed the macro to say
>
> @cindex \topic\ @subentry \subtopic\
>
> makeinfo --pdf foo.texi
>
> has errors like:
>
> Unde
> fined control sequence.
> \temp ->\xeatspaces {unix} \subentry
> \xeatspaces { pathnames}
> \dosubindwrite ...mpty \xdef \indexsortkey {\temp
> }\ifx \indexsortkey
> \empty...
>
> \safewhatsit ... \else \vskip -\whatsitskip \fi #1
> \ifx \lastskipmacro
> \zeros...
>
> \dosubind ...dcsname }\safewhatsit \dosubindwrite
> }\fi
> l.2 ...s {unix} @subentry @xeatspaces { pathnames}
>
> \scanmacro ...\\=\active \scantokens {#1@texinfoc}
> \aftermacro \catcode
> `\@=\...
> l.1657 @cpsubindex{unix, pathnames}
>
> I'm assuming the macro call @cpsubindex{unix, pathnames} expands into
>
> @cindex {unix} @subentry @xeatspaces { pathnames}
>
> and that @xeatspaces is causing problems.
>
> It's easy enough for me to work around this by just globally replacing
> @cpsubindex{foo, bar} with @cindex foo @subentry bar
>
>
> On Fri, May 10, 2019 at 12:41 AM wrote:
>
> > You're welcome. Gavin did most of the work.
> >
> > I've revised (but not yet merged) the index for the gawk manual to take
> > advantage of the new features, and it too looks wonderful. I'm pleased
> > with the new features and am glad other people are using them too.
> >
> > Regards,
> >
> > Arnold
> >
> > Raymond Toy wrote:
> >
> > > Thanks so much for implementing this! I can get rid of the hacks I had
> > and
> > > make use of it in other docs.
> > >
> > > I did use this new version to generate Maxima's manual in pdf. The index
> > > entries and subentries look fine for the most part, but there are a few
> > > oddities. I don't know if I messed up or if it's a bug in texinfo.
> > When I
> > > isolate the problem, I'll let you know.
> > >
> > > But in general it looks fantastic! And much better than the hack I was
> > > using!
> > >
> > >
> > > On Sun, Apr 28, 2019 at 2:20 AM Gavin Smith
> > > wrote:
> > >
> > > > On Sun, Apr 28, 2019 at 02:33:25AM -0600, arn...@skeeve.com wrote:
> > > > > Gavin Smith wrote:
> > > > >
> > > > > > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote:
> > > > > > > Implemented as @subentry in git commit 372cfab.
> > > > > > >
> > > > > > > A test file is attached. Please feel free to experiment.
> > > > > > >
> > > > > > > It still needs to be implemented in texi2any, once the syntax is
> > > > > > > finalised. Volunteers are welcome.
> > > > > >
> > > > > > I've added some support for @seeentry and @seealso in index
> > entries in
> > > > > > texi2any. They are ignored except for DocBook output.
> > > > >
> > > > > Truly awesome!!!
> > > > >
> > > > > How do mean "ignored"? Do you simply remove the @subentry and use
> > > > > the rest of the line as the index text, in Info, for example?
> > > >
> > > > I mean entries with @seeentry and @seealso do not add any index entries
> > > > for HTML and Info output. @subentry isn't ignored.
> > > >
> > > > > I'd suggest something like s/ *@subentry +/, /g in sed syntax
> > > > > for Info, if that makes sense to you.
> > > >
> > > > In HTML and Info output, this is what is done already - the parts are
> > > > separated by commas.
> > > >
> > > > > And once again, a huge THANK YOU for working with me to add this
> > feature
> > > > > to Texinfo. I have been working on the gawk manual's index to take
> > > > > advantage of this and it makes for an incredible improvement.
> > > >
> > > > That is very good to hear. Thank you for suggesting the new features
> > > > and working to implement them in texindex. I'm sure others will find
> > > > them useful too.
> > > >
> > > >
> > >
> > > --
> > > Ray
> >
>
>
> --
> Ray
Re: Feature request: multilevel indexing for TeX
You're welcome. Gavin did most of the work. I've revised (but not yet merged) the index for the gawk manual to take advantage of the new features, and it too looks wonderful. I'm pleased with the new features and am glad other people are using them too. Regards, Arnold Raymond Toy wrote: > Thanks so much for implementing this! I can get rid of the hacks I had and > make use of it in other docs. > > I did use this new version to generate Maxima's manual in pdf. The index > entries and subentries look fine for the most part, but there are a few > oddities. I don't know if I messed up or if it's a bug in texinfo. When I > isolate the problem, I'll let you know. > > But in general it looks fantastic! And much better than the hack I was > using! > > > On Sun, Apr 28, 2019 at 2:20 AM Gavin Smith > wrote: > > > On Sun, Apr 28, 2019 at 02:33:25AM -0600, arn...@skeeve.com wrote: > > > Gavin Smith wrote: > > > > > > > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote: > > > > > Implemented as @subentry in git commit 372cfab. > > > > > > > > > > A test file is attached. Please feel free to experiment. > > > > > > > > > > It still needs to be implemented in texi2any, once the syntax is > > > > > finalised. Volunteers are welcome. > > > > > > > > I've added some support for @seeentry and @seealso in index entries in > > > > texi2any. They are ignored except for DocBook output. > > > > > > Truly awesome!!! > > > > > > How do mean "ignored"? Do you simply remove the @subentry and use > > > the rest of the line as the index text, in Info, for example? > > > > I mean entries with @seeentry and @seealso do not add any index entries > > for HTML and Info output. @subentry isn't ignored. > > > > > I'd suggest something like s/ *@subentry +/, /g in sed syntax > > > for Info, if that makes sense to you. > > > > In HTML and Info output, this is what is done already - the parts are > > separated by commas. > > > > > And once again, a huge THANK YOU for working with me to add this feature > > > to Texinfo. I have been working on the gawk manual's index to take > > > advantage of this and it makes for an incredible improvement. > > > > That is very good to hear. Thank you for suggesting the new features > > and working to implement them in texindex. I'm sure others will find > > them useful too. > > > > > > -- > Ray
Re: Feature request: multilevel indexing for TeX
Gavin Smith wrote: > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote: > > Implemented as @subentry in git commit 372cfab. > > > > A test file is attached. Please feel free to experiment. > > > > It still needs to be implemented in texi2any, once the syntax is > > finalised. Volunteers are welcome. > > I've added some support for @seeentry and @seealso in index entries in > texi2any. They are ignored except for DocBook output. Truly awesome!!! How do mean "ignored"? Do you simply remove the @subentry and use the rest of the line as the index text, in Info, for example? I'd suggest something like s/ *@subentry +/, /g in sed syntax for Info, if that makes sense to you. Thanks! And once again, a huge THANK YOU for working with me to add this feature to Texinfo. I have been working on the gawk manual's index to take advantage of this and it makes for an incredible improvement. Thanks again, Arnold
Re: @subentry now implemented in texi2any
Gavin Smith wrote: > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote: > > It still needs to be implemented in texi2any, once the syntax is > > finalised. Volunteers are welcome. > > I have implemented @subentry in texi2any. It works for Info, HTML and > DocBook output, as well as converting back to Texinfo. (I haven't > touched the output formats that nobody uses: TexinfoXML, TexinfoSXML, > IXIN and IXINSXML.) > > I haven't done anything extra for @sortas yet. Before we complicate > things with @sortas and other commands like @see or @seealso, it might > be good to see if the current approach with @subentry works for people. This is all really cool. I will see if I can't get a revised texindex done by the end of the week and start testing. It should not be hard, I just have to steal some time... Thanks, Arnold
Re: Feature request: multilevel indexing for TeX
Hi.
Gavin Smith wrote:
> I found that text in the number field would have to be surrounded in
> braces, like this:
No problem dealing with that.
> I am not sure about the regex for matching Roman numerals is a good
> idea. There are more features for index formatting that we haven't
> considered: page numbers having styles such as bold or italic is
> something that occurs in some indices in books or articles. Then we
> might want e.g. @b{23} or @i{56} in the number field - that wouldn't be
> a "see also". I can imagine an obscure bug where the word "mix" appears
> in the page number field when it does not mean 1009. I'd prefer
> something more explicit.
This is easy; we match against @see(also)? in that field. If it doesn't
match, it's a page number.
> > I guess these become:
> >
> > @cindex output record separator @see{@code{ORS} variable}
> > @cindex @code{print} statement @seealso{redirection@comma{} of output}
After more thought, I'd like this to turn into
@entry{output record separator}{{@see{@code{ORS} variable}}{output
record separator}
@entry{print statement}{{@seealso{redirection@comma{} of
output}}}{@code{print} statement}
The part before the @see or @seealso is the text and sort key; I want to
be able to allow for
@cindex output record separator @see{@code{ORS} variable}
@cindex output record separator
I will sort "see" and "see" also before entries with page numbers.
(It's probably bad practice to have such things but why should we limit it?)
Output from texindex would be:
@entry{output record separator, @see{@code{ORS} variable}}{}
@entry{@code{print} statement, @seealso{redirection@comma{} of
output}}{}
That is, the page number field will be empty for "see" and "see also".
> What is this supposed to look like in the kind of index formatting
> that texinfo.tex uses, with the dot leaders? Should the leaders be
> present or not for a "see"? (I guess not.)
I agree, no dots.
> Where does a "see also" appear in relation to the leaders and the other
> page numbers? (I guess after all the page numbers, after the leaders.)
I would put it before the entries with the page numbers.
> What precedent is there for this?
For see and see also? Take a look at any O'Reilly book, for example.
> It is much more common for there to be no leaders
> when an index is formatted and for the page numbers to follow the
> index entry immediately. I tried to check if similar output could
> be output for LaTeX, but I didn't find how to get the dot leaders type
> of index formatting in the time I spent on it.
The source for Karl's "TeX for the Impatient" is available, as a GNU
project even. That might be a useful reference.
I kind of like the leaders (or at least the right justified page
numbers) myself.
In any case, those are my current thoughts.
Thanks!
Arnold
Re: Feature request: multilevel indexing for TeX
Gavin Smith wrote:
> On Mon, Mar 04, 2019 at 12:34:42AM -0700, arn...@skeeve.com wrote:
> > No. As per the mail you discovered, Karl just said "make it work with both"
> > so I did. But we're five years later, let's just make the change, please.
>
> Made in commit 2405caa.
Awesome!
> texindex should continue to recognize \ as the escape character for
> compatibility with old versions of texinfo.tex.
OK. It complicates things some, but not terribly.
> > > > Or we could go with keywords, to ensure that the user gets what they
> > > > wanted:
> > > >
> > > > @cindex espresso makers @see{coffee makers}
> > > > @cindex coffee @seealso{instant coffee}
> > >
> > > I think keywords are the way to go here.
> >
> > All sounds good. I will assume that if the second entry doesn't
> > have a number in it that it's a "see" or "see also" entry and
> > treat it approriately.
> >
> > Hmm. Do we ever get roman numerals in the number field of an entry?
>
> I tested it and yes, this can happen.
OK. No problem. The number field must match /^([ivxdlcm]+|([0-9]+)$/
to be a number. Otherwise it's a see/see also.
> Is the "see also" feature something that anybody
> wants or is it just theoretical?
I want it. The gawk manual has both See and See Also in its index.
Hmm... Here are two entries in the current manual:
@cindex output record separator, See @code{ORS} variable
@cindex @code{print} statement, See Also redirection@comma{} of output
I guess these become:
@cindex output record separator @see{@code{ORS} variable}
@cindex @code{print} statement @seealso{redirection@comma{} of output}
(Can texinfo.tex add back the comma before the @see/@seealso?)
Leading to:
@entry{output record separator, See ORS variabale}{}{output record
separator @see{@code{ORS} variable}}
@entry{print statement, See Also redirection, of output}{}{@code{print}
statement @seealso{redirection@comma{} of output}}
Thoughts?
Thanks!
Arnold
Re: imperfect support in texindex for @ as escape character (was multilevel indexing for TeX)
Hi.
Fix is pushed to git.
Thanks,
Arnold
arn...@skeeve.com wrote:
> Hi.
>
> Gavin Smith wrote:
>
> > On Sun, Mar 03, 2019 at 08:51:05PM +, Gavin Smith wrote:
> > > As far as I know the only barrier to changing the escape character is
> > > that old texindex is still installed.
> >
> > texindex 6.6 doesn't appear to handle @ properly as an index initial. With
> > the input
> >
> > @entry{\, backslash}{1}{{@tt @backslashcurfont }, backslash}
> > @entry{{@indexlbrace }, open brace}{1}{@lbracechar {}, open brace}
> > @entry{{@indexrbrace }, close brace}{1}{@rbracechar {}, close brace}
> > @entry{@@, at sign}{1}{@@, at sign}
> > @entry{@@, at sign}{1}{@atchar {}, at sign}
> >
> > it gives the output
> >
> > @initial {@}
> > @entry {@@, at sign}{1}
> > @initial {\}
> > @entry {{@tt @backslashcurfont }, backslash}{1}
> > @initial {{@indexlbrace }}
> > @entry {@lbracechar {}, open brace}{1}
> > @initial {{@indexrbrace }}
> > @entry {@rbracechar {}, close brace}{1}
> >
> > - it should be @initial{@@} instead.
> >
> > It doesn't work with \\ in an index entry either (outputing \initial{\}
> > if \ is the escape character), but that doesn't matter because
> > texinfo.tex is not putting \\ in the index files.
>
> The fix is simple:
>
> $ git diff ti.twjr
> diff --git a/texindex/ti.twjr b/texindex/ti.twjr
> index ec59f68a5..7d5621f89 100644
> --- a/texindex/ti.twjr
> +++ b/texindex/ti.twjr
> @@ -443,7 +443,7 @@ function beginfile(filename)
>|| substr($0, 2, 5) != "entry")
> fatal(_"%s is not a Texinfo index file\n", filename)
>
> - Special_chars = "{}"
> + Special_chars = "{}" Command_char
> }
> @
>
> I will push this later or you can beat me to it. :-)
>
> Thanks,
>
> Arnold
Re: imperfect support in texindex for @ as escape character (was multilevel indexing for TeX)
Hi.
Gavin Smith wrote:
> On Sun, Mar 03, 2019 at 08:51:05PM +, Gavin Smith wrote:
> > As far as I know the only barrier to changing the escape character is
> > that old texindex is still installed.
>
> texindex 6.6 doesn't appear to handle @ properly as an index initial. With
> the input
>
> @entry{\, backslash}{1}{{@tt @backslashcurfont }, backslash}
> @entry{{@indexlbrace }, open brace}{1}{@lbracechar {}, open brace}
> @entry{{@indexrbrace }, close brace}{1}{@rbracechar {}, close brace}
> @entry{@@, at sign}{1}{@@, at sign}
> @entry{@@, at sign}{1}{@atchar {}, at sign}
>
> it gives the output
>
> @initial {@}
> @entry {@@, at sign}{1}
> @initial {\}
> @entry {{@tt @backslashcurfont }, backslash}{1}
> @initial {{@indexlbrace }}
> @entry {@lbracechar {}, open brace}{1}
> @initial {{@indexrbrace }}
> @entry {@rbracechar {}, close brace}{1}
>
> - it should be @initial{@@} instead.
>
> It doesn't work with \\ in an index entry either (outputing \initial{\}
> if \ is the escape character), but that doesn't matter because
> texinfo.tex is not putting \\ in the index files.
The fix is simple:
$ git diff ti.twjr
diff --git a/texindex/ti.twjr b/texindex/ti.twjr
index ec59f68a5..7d5621f89 100644
--- a/texindex/ti.twjr
+++ b/texindex/ti.twjr
@@ -443,7 +443,7 @@ function beginfile(filename)
|| substr($0, 2, 5) != "entry")
fatal(_"%s is not a Texinfo index file\n", filename)
- Special_chars = "{}"
+ Special_chars = "{}" Command_char
}
@
I will push this later or you can beat me to it. :-)
Thanks,
Arnold
Re: Feature request: multilevel indexing for TeX
Hi.
> Maybe it will just have to be accepted that out-of-date versions of
> texindex shouldn't be used with multi-level index entries, otherwise
> the index will appear somewhat mangled.
I think we just have to say that.
> Implemented as @subentry in git commit 372cfab.
>
> A test file is attached. Please feel free to experiment.
Excellent! Will do.
A few questions.
1. texindex.awk has provision for both \ and @ to be the command character
(\entry vs. @entry). Do we still need that? Or will it always be backslash?
2. What do we wish to do about "see" and "see also"? I have a thought...
With respect to output from texindex.awk, I suggest that each macro
allow empty page number arguments. Thus
@cindex coffee makers @subentry electic
@cindex coffee makers @subentry gerbel-driven
with no
@cindex coffee makers
would yield
\entry {coffee makers}{}
\secondary {electric}{3, 12}
\secondary {gerbel-driven}{9, 42}
and similar for \secondary if there are following \tertiary entries.
If that's the case, then texindex could also special case stuff like
\entry {espresso makers, see coffee makers}{23}{espresso makers, see
coffee makers}
as input and and turn it into
\entry {espresso makers, see coffee makers}{}
on output.
And similar for "see also".
Or we could go with keywords, to ensure that the user gets what they
wanted:
@cindex espresso makers @see{coffee makers}
@cindex coffee @seealso{instant coffee}
How much of this works for you?
Thanks!
Arnold
Re: Feature request: multilevel indexing for TeX
Hi.
> * What happens if there is an index entry with no secondary term and an
> identical index entry with a secondary term, e.g.
>
> @cindex foo
> @cindex foo @sub bar
>
> I think that both should be kept. When I tested it with C texindex, one
> of them was lost in the output.
I agree. We need to put together a "torture test" for texindex.
> * Do we keep @defop, and the other commands in texinfo.tex currently using
> \dosubind, as creating single-level index entries? I assume yes, even
> if it was different before: no-one to my knowledge ever complained that
> the behaviour changed, and it is more stable to keep things as they are,
> even if in the past they were possibly different. I suspect not many
> are using these commands anyway.
I agree.
> Perhaps sort keys could be generated for primary, secondary and
> tertiary entry text separately, and simply concatenated to produce the
> sort key.
Separate keys, yes. Concatenataed, no.
> Maybe a special marker character could be output that texindex treats
> specially: e.g. the above would be output as
>
> \entry{aa^_a}{1}{aa}{a}
> \entry{aa^_z}{3}{aa}{z}
> \entry{aah}{5}{aah}
>
> where ^_ is a 0x1F byte.
Yes, perfect, that's real easy to handle in awk.
> Using a space instead may even suffice:
>
> \entry{aa a}{1}{aa}{a}
> \entry{aa z}{3}{aa}{z}
> \entry{aah}{5}{aah}
I don't like that; if a sort key has spaces it, we're in trouble.
> * If somebody uses contradictory sort keys for the primary text: this
> doesn't make sense, and unpredictable results are acceptable: e.g.
>
> @cindex foo @sortas{aaa} @sub one
> @cindex foo @sortas{zzz} @sub two
>
> Here the "foo" entries could be sorted as "aaa" or "zzz" and it wouldn't
> matter much which.
Right. Garbage In, Garbage Out. No problem with that.
> * We cannot actually use @sub because this clashes with the subscript
> command. Using @tab or @indent instead may be a possibility.
@indent makes sense, since that's what happens on the page, but I
can live with @tab also, or something like @subind might be good too.
I don't have strong feelings, as long as it makes reasonable sense
and is easy to convert an existing entry to it.
This is starting to come together in my head, at least in terms of what
texindex will need to do.
Thanks!
Arnold
Re: Feature request: multilevel indexing for TeX
Hi. Sorry for the slow reply.
Gavin Smith wrote:
> The existing \primary macro does not take a page argument. This could
> be used to give you:
>
> coffee makers
> electric ... 32
>
> To get
>
> coffee makers . 15, 21
> electric ... 32
>
> you would use \entry instead of \primary.
>
> See attached files: these work with the current texinfo.tex.
Nice.
> Another idea:
>
> @cindex coffee makers @sub electric @sub pink
I like this one. It is similar to @tab in tables.
You could then do:
@cindex @sortas{...} coffee makers @sub @sortas{...} electric @sub
@sortas{...} pink
I.e., each term could have its own (optional) @sortas clause.
> I remember there were problems with the positioning of @sortas: I'd like
> to see if they could be fixed.
Can you elaborate?
> > Could we do \tertiary also? Or is that asking too much?
>
> I don't see why not, it would just require more sorting logic in
> texindex.
Excellent. If you can give me a clear spec on the input and output
to texindex I can dive into it. (When you have one, of cousre.)
I'm pretty sure I still have committer rights to the project.
> > How do we move forward?
>
> Think of more problems that might occur and send mail about them.
See above. :-)
> Wait for me to implement it, or learn enough TeX and Perl, and enough
> about the Texinfo codebase to implement it yourself. Otherwise it is
> quite likely I will get to this some time in the next month.
I am starting to learn about TeX. It's a hard hill to climb though...
Much thanks!
Arnold
Re: Feature request: multilevel indexing for TeX
Hi. Thanks for the answer.
Gavin Smith wrote:
> On Thu, Feb 21, 2019 at 03:08:30AM -0700, arn...@skeeve.com wrote:
> > I have a feature request, please. It relates to indexing in texinfo.tex.
> > Packages like LaTeX and professional publishing packages provide for
> > multiple levels of index entries, usually up to three keys. For example
> >
> > coffee makers . 15, 21
> >electric ... 32
> > pink 45
> >
> > I would very much like to see this available in texinfo.tex. In
> > the gawk manual I have up to three items, separated by commas; if
> > more are needed for what I want to say, I use @comma{}.
> >
> > I took a look a texinfo.tex to see what's there for this kind of thing.
> > I'm not at all a TeX hacker, but it looks like there's some half-completed
> > support for two levels of items (not three). Sort of like someone
> > thought about it, but it doesn't seem to have been carried through.
>
> If my understanding is correct, this code used to be used for some
> of the commands for indexing methods in object-oriented languages, like
> @defop, but these were changed long ago. Possibly in the change on
> 2001-02-02 in the ChangeLog.
>
> 2001-02-02
>
> * texinfo.tex (\secondary): handle pdf case.
> (\dosubind): secondary index entry not written as separate arg for
> texindex.
> From: Trevin Beattie
> Date: Tue, 21 Mar 2000 13:04:06 -0700
>
> I've attached the mail for historical interest, which Karl provided to me.
>
> The C implementation of texindex did actually sort \primary and \secondary
> correctly last time I checked (some years ago).
I took a quick look. It looks like the output was
\entry ...
\primary ...
\secondary ...
\secondary ...
\secondary ...
> > For backwards compatibility, this would probably have to be done as
> > a new command, something like
> >
> > @cindex2 {coffee makers}{electic}{pink}
> >
> > or more likely:
> >
> > @cindex2{coffee makers, electic, pink}
> >
> > (Yes, that's a bad name, it's just an example for discussion.)
>
> I think @cindextwo (no digits in TeX macro names) could be called as
>
> @cindextwo coffee makers, electic, pink
>
> This would be consistent with the arguments to @node, which are also separated
> by commas. But let's make sure that the interface is as consistent as
> possible
> with other Texinfo commands.
So why not just make it work with @cindex? Or do we really need
a new command?
> > I would be willing to update texindex to support multiple sort
> > keys if this would help. Unfortunately, I don't think I can help
> > with the TeX part or the makeinfo part.
>
> I think it should work with \primary and \secondary the same as C texindex
> did.
Could we do \tertiary also? Or is that asking too much?
> I don't think implementing it would be too much of a barrier. The more
> important thing is to get the interface right.
>
> > Does all this make sense? Is it something that can be added to
> > the TODO list?
>
> Yes, I don't see why not.
How do we move forward?
Thanks!
Arnold
Feature request: multilevel indexing for TeX
Hi.
I have a feature request, please. It relates to indexing in texinfo.tex.
Packages like LaTeX and professional publishing packages provide for
multiple levels of index entries, usually up to three keys. For example
coffee makers . 15, 21
electric ... 32
pink 45
I would very much like to see this available in texinfo.tex. In
the gawk manual I have up to three items, separated by commas; if
more are needed for what I want to say, I use @comma{}.
I took a look a texinfo.tex to see what's there for this kind of thing.
I'm not at all a TeX hacker, but it looks like there's some half-completed
support for two levels of items (not three). Sort of like someone
thought about it, but it doesn't seem to have been carried through.
For backwards compatibility, this would probably have to be done as
a new command, something like
@cindex2 {coffee makers}{electic}{pink}
or more likely:
@cindex2{coffee makers, electic, pink}
(Yes, that's a bad name, it's just an example for discussion.)
I suspect that makeinfo could rewrite
@cindex2 {coffee makers}{electic}{pink}
as:
@cindex coffee makers, electic, pink
and things would be happy for Info and HTML; DocBook could certainly
leverage multilevel indexing since it has something like
coffee makers
electric
pink
I would be willing to update texindex to support multiple sort
keys if this would help. Unfortunately, I don't think I can help
with the TeX part or the makeinfo part.
Does all this make sense? Is it something that can be added to
the TODO list?
Please cc me on replies, as I'm not on this list.
Much thanks!
Arnold
Re: crop marks?
Gavin Smith wrote: > @afourpaper is in the same class of commands as @smallbook itself. So in > theory @cropmarks could be used with @afivepaper and then you would want a way > to say whether it is being printed on A4 paper or letter size paper or > whatever. Ah, I see what you mean. Something like: @smallbook @printingonletter @c or @printingona4 @cropmarks > Clearly it's not a feature that anybody uses. Can we just remove the feature > and revisit it if somebody is actually going to use it for printing a book? I asked about it exactly because I am thinking about self-publishing a book and using @smallbook for it ... OTOH, I don't want to overburden you for a feature that truly is rarely used. You're the maintainer, so your call. If you choose to kill the feature now I'll let you know when I get close to being ready to print. Thanks! Arnold
Re: crop marks?
Hi. Gavin Smith wrote: > I looked at older versions of texinfo.tex and there does not seem to be > any directive to change the physical page size in the output. So > originally @smallbook was intended for use with letter size paper. Sounds right. > For @cropmarks to be implemented properly, there would probably have to > be a directive to set the paper size it is going to be printed on. Don't we have such? @a4paper or something? > If you want to disable changing the physical page size for PDF output > too, this change does that: That will be helpful. > This does show all the crop marks, although the page is not centred properly. > It was centred properly with some older versions of texinfo.tex I tried. I thought that was what I remembered. > Also I'm not confident that the crop marks are in the right place. In what sense? I will try to print a page and measure the dimensions of what the cropmarks delineate. Much thanks! Arnold
Re: crop marks?
Hi.
> If I disable changing the papersize in \internalpapersizes, like this:
>
> Index: texinfo.tex
> ===
> --- texinfo.tex (revision 8191)
> +++ texinfo.tex (working copy)
> @@ -11328,7 +11328,7 @@
> \pdfvorigin = 1 true in
>\else
> \ifx\XeTeXrevision\thisisundefined
> - \special{papersize=#8,#7}%
> + %\special{papersize=#8,#7}%
> \else
>\pdfpageheight #7\relax
>\pdfpagewidth #8\relax
>
> and use @smallbook and @cropmarks, the lower cropmarks are indeed
> visible. They were invisible before because they had disappeared off
> the bottom of the page - probably they are being printed too far down.
With Texinfo 2018-09-21.20 and this change, I still don't see the
bottom crop marks. I'm using texi2pdf to make the PDF and evince
to view it.
Thanks,
Arnold
Re: crop marks?
Gavin Smith wrote:
> On Tue, Nov 20, 2018 at 7:07 AM wrote:
> > When printing an @smallbook book on regular paper (as an author would
> > do while working on a book), the pages are (supposed to be) centered
> > on the larger paper. You can't tell where the physically smaller borders
> > really are. The cropmarks give you a visual clue as to what the end
> > result will really be.
>
> The page size is set in the output file - for PDF output, and also for
> DVI output, provided your DVI viewing program recognizes the page size
> directive (since 2017-03-05). Thus there shouldn't be anything extra
> you need to do to see what the page looks like.
On the screen, it's hard (for me) to be sure, but I can try again.
I'm both getting old and old fashioned - it's MUCH easier for me to review
things on paper than on the screen. I miss things on screen that I
catch when I read paper.
> If I disable changing the papersize in \internalpapersizes, like this:
>
> Index: texinfo.tex
> ===
> --- texinfo.tex (revision 8191)
> +++ texinfo.tex (working copy)
> @@ -11328,7 +11328,7 @@
> \pdfvorigin = 1 true in
>\else
> \ifx\XeTeXrevision\thisisundefined
> - \special{papersize=#8,#7}%
> + %\special{papersize=#8,#7}%
> \else
>\pdfpageheight #7\relax
>\pdfpagewidth #8\relax
>
> and use @smallbook and @cropmarks, the lower cropmarks are indeed
> visible. They were invisible before because they had disappeared off
> the bottom of the page - probably they are being printed too far down.
I will try this out.
Much thanks!
Arnold
Re: crop marks?
Hi. Gavin Smith wrote: > However, they probably aren't in the right place. I don't really > understand what the cropmarks are for in the first place. Doesn't it > depend on what areas of a page a printer is capable of printing on, > which depends on the printer? When printing an @smallbook book on regular paper (as an author would do while working on a book), the pages are (supposed to be) centered on the larger paper. You can't tell where the physically smaller borders really are. The cropmarks give you a visual clue as to what the end result will really be. > I suspect the code is wrong even for the top crop marks. [] > It all seems very arbitrary to me. I would think it'd be a straightforward calculation to determine where to place them, if indeed the @smallbook pages are centered, or even if they start at the top like regular pages. I don't doubt that that bit of texinfo.tex is suffering terribly from bit rot. :-( Maybe Karl can help? Thanks for looking into this. It's not at all urgent, but it'd be nice if it got attended to sometime in the next months. Much thanks, Arnold
Re: crop marks?
Gavin Smith wrote: > On Tue, Nov 13, 2018 at 07:56:39AM -0700, arn...@skeeve.com wrote: > > Once upon a time there was an @cropmarks command in texinfo.tex that > > put cropmarks in the corners of the page. This was particularly helpful > > for working with @smallbook in order to visualize what would actually > > come back if a book was printed and bound. > > > > The command seems to still be there but I only get the cropmarks > > on the top of the page. > > > > I'm fairly sure this is an undocumented feature, but if it could be > > restored to working order sometime soon, I'd appreciate it. > > Can you tell me when it worked properly? I tried with various versions of > Texinfo. As far back as Texinfo 4.5 I only got the top cropmarks. I > tried with Texinfo 3.12 and I do get the bottom cropmarks, but they look > like they are in the wrong place unless @smallbook is also given. Oh lordy. It's been *years*. And indeed they may only have worked correctly with @smallbook --- that sounds right. I would be happy if that would be restored, since I actually was trying to see what a particular document would look like in @smallbook. I'm starting to think about self-publishing something written in Texinfo, which is why I wanted to see what @smallbook looked like. Much thanks! Arnold
crop marks?
Hi. Once upon a time there was an @cropmarks command in texinfo.tex that put cropmarks in the corners of the page. This was particularly helpful for working with @smallbook in order to visualize what would actually come back if a book was printed and bound. The command seems to still be there but I only get the cropmarks on the top of the page. I'm fairly sure this is an undocumented feature, but if it could be restored to working order sometime soon, I'd appreciate it. Thanks, Arnold
Re: texinfo.tex problem formatting index
arn...@skeeve.com wrote: > Gavin Smith wrote: > > > On Thu, Nov 16, 2017 at 08:12:10PM +, Gavin Smith wrote: > > > I've committed a fix. I can't guarantee that it's right for all > > > circumstances as the implementation of the double-column index format is > > > a complex area. > > > > I've realised my fix is wrong and only appeared to work by accident > > (I wrote \ht\pagetotal instead of \pagetotal by mistake). I'll look at > > it and see if it can be fixed but I can't guarantee anything. > > Much thanks! I appreciate the effort. Maybe you can drag Karl out > of retirement for a bit to help. :-) > > Thanks, > > Arnold I just updated and tried it out. It looks great now! Thanks! Arnold
Re: texinfo.tex problem formatting index
Gavin Smith wrote: > On Thu, Nov 16, 2017 at 08:12:10PM +, Gavin Smith wrote: > > I've committed a fix. I can't guarantee that it's right for all > > circumstances as the implementation of the double-column index format is > > a complex area. > > I've realised my fix is wrong and only appeared to work by accident > (I wrote \ht\pagetotal instead of \pagetotal by mistake). I'll look at > it and see if it can be fixed but I can't guarantee anything. Much thanks! I appreciate the effort. Maybe you can drag Karl out of retirement for a bit to help. :-) Thanks, Arnold
texinfo.tex problem formatting index
Hi. I just saw a weird case where texinfo.tex put a blank page in the middle of the index. To reproduce: git clone https://github.com/arnoldrobbins/prepinfo cd prepinfo make Look at the index in the PDF. This is with the current texinfo.tex. Please cc me on any responses, I'm not on the bug-texinfo list. Thanks! Arnold
Re: Updating contrib/prepinfo.awk
Gavin Smith wrote: > On Tue, Nov 07, 2017 at 09:58:49PM +0200, Arnold Robbins wrote: > > I would just update the .awk file. I think I still have commit access > > to the SVN repo, so I'll just do it directly, but I wanted to let > > the maintainers know this is coming. > > OK fine, I can't see that it would do any harm. Much thanks. Done! Arnold
Updating contrib/prepinfo.awk
Hi. I'd like to update contrib/prepinfo.awk with the current version, if that's ok. (It's only been, like, 19 years... :-). The latest version is a literate program, now available at https://github.com/arnoldrobbins/prepinfo. I would just update the .awk file. I think I still have commit access to the SVN repo, so I'll just do it directly, but I wanted to let the maintainers know this is coming. If it's not OK, please let me know. Thanks! Arnold
Re: texinfo.tex - part header in long table of contents
Hi. > > It's both lines that are outdented. Format the doc and look at > > the page, it'll be very clear. :-) > > > > OK, I understand the problem now. I don't know how I missed that. :-) > I've made a change that should fix the problem. Please try the latest > version (2017-08-23.19). Thanks for the report. Looks great! Glad to help, and much thanks for the fix. THANK YOU for keeping Texinfo healthy. I've been working in it for over two decades (!) and it's still the best markup language I've ever used. Thanks, Arnold
Re: texinfo.tex - part header in long table of contents
Gavin Smith wrote: > On Tue, Aug 22, 2017 at 01:13:32PM -0600, arn...@skeeve.com wrote: > > The main problem is that the the first line is outdented instead > > of indented correctly. It about lines up under the '9' of the > > chapter title. I don't mind how it's split. > > OK, I'll be happy to look at how to change how the continuation line is > indented. It's both lines that are outdented. Format the doc and look at the page, it'll be very clear. :-) Thanks, Arnold
Re: texinfo.tex - part header in long table of contents
Hi. Gavin Smith wrote: > This was a deliberate change. I think the new layout looks better. In > fact, they both look bad, but the reason for that is that the section > title is long, so there isn't a good way to format it. I'm willing to > consider changing it back. Do you have arguments why you think the old > layout is better? The main problem is that the the first line is outdented instead of indented correctly. It about lines up under the '9' of the chapter title. I don't mind how it's split. Format the document and look at the page in a PDF viewer and you'll see what I am talking about. See also the mail I just sent today indicating at which SVN commit it broke. Thanks, Arnold
gawk TOC issue - section 9.1.3.1 on page vii
Hi. In an earlier message on a different thread, I reported that the TOC for the gawk manual has a problem with a subsubsection with a long title. You can see this on page vii of the TOC for section 9.1.3.1. To reproduce: git clone git://git.savannah.gnu.org/gawk.git cd gawk ./bootstrap.sh && ./configure && make cd doc make gawk.pdf I imported the SVN repo into git and did a git bisect. The guilty commit is | $ git bisect good | ece37d8497e1b06780d481ac02f31192fa841e9c is the first bad commit | commit ece37d8497e1b06780d481ac02f31192fa841e9c | Author: gavin | Date: Sat Aug 6 12:49:21 2016 + | | use new macro \ourunvbox | | git-svn-id: http://svn.savannah.gnu.org/svn/texinfo@7305 39fee189-59d7-47db-b5d4-205258b72aed | | :04 04 9c2298535bbe107cfe441108c1fcd33bf353ff64 869fe3c216864900d84f12268d41e3132a024626 Mtrunk Hidden in there is that this is SVN revision 7305. Please investigate and fix. :-) Thanks! Arnold
Re: texinfo.tex - part header in long table of contents
> > I saw the problem. I've committed a change that should fix the problem. > > The new version of texinfo.tex should be at > > ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex in a few minutes. > > Much thanks! I'll try it out. That part's fixed. Much thanks! Unfortunately, there's now a different problem (or else I didn't notice it before). See page vii in the TOC, for Chapter 9: 9 Functions 185 9.1 Built-in Functions ...185 9.1.1 Calling Built-in Functions .185 9.1.2 Numeric Functions ..186 9.1.3 String-Manipulation Functions ..187 9.1.3.1 More about \ and & with sub(), gsub(), and gensub()..196 9.1.4 Input/Output Functions .199 It used to produce something like this: 9.1.3.1 More about \ and & with sub(), gsub(), and gensub() ....196 Thanks, Arnold
Re: texinfo.tex - part header in long table of contents
Gavin Smith wrote: > On Thu, Aug 03, 2017 at 08:36:52AM -0600, arn...@skeeve.com wrote: > > Hi. > > > > Using texinfo.tex 2017-06-04.19, the part header in a table of > > contents can come out at the bottom of a page. It'd be better if > > it came out at the top of the next page. To reproduce: > > > > git clone git://git.savannah.gnu.org/gawk.git > > cd gawk > > ./bootstrap.sh && ./configure && make -j > > cd doc ; make gawk.pdf > > > > Examine page vii of the table of contents and you'll see that the > > > > Part II: Problem Solving with awk > > > > is at the bottom of the page. It'd look better at the top of > > the next page. > > I saw the problem. I've committed a change that should fix the problem. > The new version of texinfo.tex should be at > ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex in a few minutes. Much thanks! I'll try it out. Arnold
texinfo.tex - part header in long table of contents
Hi. Using texinfo.tex 2017-06-04.19, the part header in a table of contents can come out at the bottom of a page. It'd be better if it came out at the top of the next page. To reproduce: git clone git://git.savannah.gnu.org/gawk.git cd gawk ./bootstrap.sh && ./configure && make -j cd doc ; make gawk.pdf Examine page vii of the table of contents and you'll see that the Part II: Problem Solving with awk is at the bottom of the page. It'd look better at the top of the next page. Thanks! Arnold
Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]
"David Kaspar [Dee'Kej]" wrote: > I guess I didn't make myself clear. By default the vanilla source code is > used during build inside mock, no modifications to it are currently there. > So, when I try the build for 4.1.4, it uses the texinfo.tex shipped with > gawk. There shouldn't be any way for mock to download some older > texinfo.tex from somewhere else. The reason why it is older in the gawk.log > is that I was trying to find out which commit started to cause this. I have > found it, and I have put that log to pastebin. That's why it has older > timestamp than current source tarball. :) I see now. > I'm actually starting to think that something has changed inside Texinfo > > > I will look into this more tomorrow, and I will discuss this with our > maintainer of Texinfo. Great. Sounds like the right way to go. > > I don't have the cycles to try to mess with SRPMs and so on, especially > > as I don't run an RPM-based distribution. > > > No problem, I understand. :) I will try to find some fix/workaround, I > will keep you updated if needed. Thanks for understanding. I appreciate the effort and am glad that 4.1.4 will get into Fedora soon. Thanks, Arnold
Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]
Hi David. You need to figure out how to get mock to use the texinfo.tex shipped with gawk. Mock is stil using an older version. I support building the doc with what I ship. But not otherwise. It may be that you need to move to Texinfo 6.1 (or even the just released Texinfo 6.3) for the latest Fedora. I don't know. Using the texinfo.tex in the tarball is the way to go. You may need to move to the newer Texinfo anyway since that package has an updated and smarter texindex program which gawk's doc probably needs. Inisde mock, you can try setting the TEXINPUTS environment variable to have the gawk doc directory in it first: TEXINPUTS=$PWD/doc:$TEXINPUTS make -C doc/ pdf or some such. I don't have the cycles to try to mess with SRPMs and so on, especially as I don't run an RPM-based distribution. HTH, Arnold "David Kaspar [Dee'Kej]" wrote: > Hello guys, > > I was in a hurry yesterday, so I have accidentally sent the wrong log > file... :-/ Today, I looked into this more: > > * I am able to create documentation if I normally use 'make -C doc/ pdf' or > 'cd doc && make pdf && cd ..' for gawk-4.1.4 in my Fedora 24. > * The problem occurs when I try to build it inside mock [1] for Fedora 24 > (and higher), I'm trying to do rebase for F26. > * If I try to build it for F23 in mock, it passes. IOW, using newer > versions of 'texi2dvi' inside mock (for F24+) results in compilation fail. > * When it fails, it produces only partial documentation, with Index and > everything behind it missing. > * When I use the 'texi2pdf' instead of 'make pdf' in the specfile, I'm able > to see at which line this occurs. > * I've used git-bisect to find a commit where the build starts to fail, > it's this commit: > > [upstream||gawk] ~ [3e762b6 $] # git last > * commit 3e762b6f62061974d152dd251f3e83cacca073e3 (HEAD, refs/bisect/bad) > | Author: Arnold D. Robbins > | Date: 12 months ago > | > | Update infrastructure files. > > * This helped me narrow it to file causing the issue: doc/texinfo.tex > (using older version of texinfo.tex with the first failing commit allows > build to pass). > * Reading through changes in the texinfo.tex, there was some bigger update > to how Index is being produced, if I'm not mistaken. > * Running the build with refs/bisect/bad commit and with 'texi2pdf' shows > me, that the compilation of PDF stops at line number 38144 of gawk.texi > (which has @cindex right above it). > > So, I have updated the pastebin log, so you can check it out yourself here: > http://pastebin.com/skxGpHnL > > Unfortunately, I'm not so good with TeX to be able to pinpoint the problem > more closely, but if you need anything more from me, I can help. :) I can > also provide you with the srpm if you would like to build it / try it > yourself. > > - > [1] https://github.com/rpm-software-management/mock/wiki > - > > Best regards, > > David Kaspar [Dee'Kej] > *Associate Software Engineer* > *Brno, Czech Republic* > > RED HAT | TRIED. TESTED. TRUSTED. > Every airline in the Fortune 500 relies on Red Hat. > Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]
Gavin Smith wrote:
> On 12 September 2016 at 18:52, wrote:
> > Hi.
> >
> >> there seems to be a regression for the documentation of gawk. I'm not able
> >> to compile the PDF version of it with current version 4.1.4. I was able to
> >> compile it in the same way for 4.1.3.
> >>
> >> There's a lot of output during compilation, and unfortunately I do not have
> >> time to look at it now... :-/ Here's the link to the gawk.log:
> >>
> >> http://pastebin.com/skxGpHnL
> >
> There looks nothing wrong with that output: it finishes processing the file:
>
> [477] [478] [479] [480] [481] [482] [483] [484] [485] [486]
> (GNU Free Documentation License) [487] [488] [489] [490] [491] [492] [493]
> [494] [495] (Index) [496] [497] [498] )
> Here is how much of TeX's memory you used:
>
> ...
>
> Output written on gawk.pdf (508 pages, 1740511 bytes).
Looking at the raw paste data:
(./gawk.texi (/home/dkaspar/Downloads/gawk-4.1.4/doc/texinfo.tex
Loading texinfo [version 2013-02-01.11]:
But looking at what I put into the tarball:
$ grep version texinfo.tex
\def\texinfoversion{2016-02-05.07}
This is the cause. David - this is in your court.
Thanks,
Arnold
Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]
Hi. > there seems to be a regression for the documentation of gawk. I'm not able > to compile the PDF version of it with current version 4.1.4. I was able to > compile it in the same way for 4.1.3. > > There's a lot of output during compilation, and unfortunately I do not have > time to look at it now... :-/ Here's the link to the gawk.log: > > http://pastebin.com/skxGpHnL I always use cd doc ; make pdf and that works flawlessly for me. I have never used `make -C doc/ pdf' and I don't know why that fails. In fact, it works just fine for me too (Ubuntu 16.04). Looking at your log, it looks like you're not getting the texinfo.tex file distributed with gawk but a rather older one. I'm adding the texinfo list, maybe they can shed some light. > Question: If you fix this issue, will it be in git only, or will you > prepare new tarball? Can you just change your procedure to use 'cd doc; make pdf' ? Or can you help determine why it's not working? Especially since it does work for me... Any fix would likely just be in git since this is the first time such an issue has ever been raised. Thanks, Arnold
makeinfo --docbook bug with index
Hi. In docbook output, given something like this input: @node Concept Index @unnumbered Index @printindex cp @bye The generated docbook is Index This isn't valid docbook. It should be The tag could be but that is a minor quibble. Removing the @node and @unnumbered don't help, then we get the tag before the tag and it needs to come after it. Thanks! Arnold
Re: texinfo.tex indexing bug
Hi Karl.
k...@freefriends.org (Karl Berry) wrote:
> Finally getting back to:
>
> Date: Tue, 03 Dec 2013 22:56:13 +0200
> ...
> @cindex @r{@{foo@}} program
> Which should be indexed under { ends up being indexed under |
>
> Same is true for just @cindex @{, BTW.
>
> The problem, I believe, is with texindex, which is not prepared to
> handle braces as text as far as I could tell. Thus in texinfo.tex I
> chose to use | since at least it is between, in ASCII terms, { and }.
> Had to do something so it wouldn't just bomb out.
>
> Fixing texindex ... well, a patch would be welcome :). (There appear to
> be assumptions in texindex.c about balanced braces. Short of completely
> rewriting the program, perhaps the simplest workaround would be to
> output special sequences for { and } and transliterate. Or maybe I'm
> missing some escape mechanism.)
>
> sorry,
> karl
I will start looking at the code for texindex.c. It doesn't look
impossible.
As a hypothetical question, if I rewrote texindex in awk and it
functioned as a drop-in replacement, would you take it? If so, would
you require fully portable awk, or could I take advantage of stuff
that is only in gawk?
Thanks,
Arnold
makeinfo does not diagnose successive @item in @table
Hi. Given something like @table @asis @item foo @item bar Lot of decriptive text here ... @end table The second @item should really be @itemx but makeinfo does not diagnose this. It is a problem if you're producing docbook. Thanks, Arnold
texinfo.tex: @cartouche kills indentation
Hi. In the current texinfo.tex, if you wrap stuff in @cartouche, anything that is embedded, like @quotation or @example, loses the indentation that should be added, and is instead formatted flush left. Thanks, Arnold
Re: docbook conversion issue: nesting of formatting
Hi Eli.
> > The first issue has to do with nesting. Texinfo, like TeX, is quite
> > general about letting you nest one thing inside another. Docbook,
> > on the other hand, is quite picky and context sensitive. For example,
> > something like
> >
> > The term @dfn{@command{awk} program} refers ...
> >
> > produce this:
> >
> > The term awk program refers
> > ...
> >
> > The problem is that ... is not allowed to appear
> > inside
>
> Is this a real-life example? Because if it is, I don't understand how
> "@command{awk} program" ended up in @dfn, since the latter is supposed
> to be used for introducing new terminology, which this phrase isn't.
Yes, it's a real example. Here is the full paragraph:
The term @command{awk} refers to a particular program as well as
to the language you use to tell this program what to do. When we
need to be careful, we call the language ``the @command{awk}
language,'' and the program ``the @command{awk} utility.''
This @value{DOCUMENT} explains both how to write programs in the
@command{awk} language and how to run the @command{awk} utility.
The term @dfn{@command{awk} program} refers to a program written
by you in the @command{awk} programming language.
I can, and probably will, work around this by changing it to say
... The term ``@command{awk} program'' referss to ...
But the general issue of context sensitivity in Docbook remains.
I can find other examples, I'm pretty sure.
Thanks,
Arnold
Re: texinfo 5.2 dist creates directories that are 777
> Aharon Robbins writes: > > > Something's messed up somewhere. Ubuntu 12.04: > > > > $ umask 022 > > $ tar -xpzf /usr/local/src/Gnu/texinfo-5.2.tar.gz Andreas Schwab wrote: > You explicitly told tar to ignore umask. No surprise. So -p is more than just "preserve modification time"?!? That's a new one on me. OK, thanks. Arnold
texinfo 5.2 dist creates directories that are 777
Hi. Is it a bug or a feature that the Texinfo 5.2 tarball extracts with directories being world writable? Thanks, Arnold
@option should maybe use @w
Hi. I just noticed a case, using texinfo.tex 2012-11-08.11, where
@option{--posix} got line broken between the second hyphen and the
`posix'; perhaps @option should use @w around it's argument?
Thanks!
Arnold
Very long document title is not broken on title page
Hi. I'm using texinfo to write a paper and it happens to have a fairly long title. As a result it simply runs off the page on the title page instead of being broken across multiple lines like I would have expected. To reproduce, take a document and use @title AWK As A Major Systems Programming Language --- Revisited and look at the title page. Please cc me on any answers as I'm not subscribed to the bug-texinfo list. Thanks! Arnold Robbins (The gawk guy)
