Re: makeinfo 7.1 misses menu errors

[Karl Berry]

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.

Re: makeinfo 7.1 misses menu errors

[Karl Berry]

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
it without great chance of messing up the manual.

Also, it feels painful to have to set a config file variable at all to
get a useful feature which has always been enabled by default. Indeed,
having better error messages was one of the primary advantages of C
makeinfo over Elisp texinfo-format-buffer, umpteen years ago.

My point is that some users may want to have menus that do not follow the
sectioning structure, it is perfectly correct, 

I understand. But my point is that, although it can be correct in
theory, in practice it is 99.99% (at least) caused by a mistake, not
intentional.  Therefore it sure seems to me that makeinfo should follow
the 99.99% case, not the .001% case, just because of some theoretical
possibility.

The new features to support normally-structured manuals are great, but
because they are so new, they can't yet be used for manuals intended to
be widely distributed.  I could not use them for automake, for example,
without causing tremendous trouble with all the distros and users using
older makeinfos. Which will be the case for many years yet.

I agree that setting CHECK_NORMAL_MENU_STRUCTURE on is best for most
manuals.  However, it would lead to emitting warnings for correct, even
if rare cases, which I find very unfortunate.  

I understand the principle, but for me the lossage in practice is even
more unfortunate (by far). It sure seems to me that the "rare" case
should be the one to have to make the config file setting. Indeed, the
very fact of making that config file setting would helpfully alert
contributors and builders that "this is not a normally-structured
manual".

I dearly hope you will reconsider. --thanks, karl.

Re: makeinfo 7.1 misses menu errors

[Karl Berry]

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 possible to change the error location to be the

To my mind, the precise message is not critical. The existing messages
work well enough to let the manual author find what needs to be
fixed. Sure, they could be improved, but let's not have "perfect" be the
enemy of "good enough". --thanks, karl.

Re: makeinfo 7.1 misses menu errors

[Karl Berry]

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
to me (including in the old C makeinfo). But they indicate perfectly
well "there is a problem with the sectioning+menus related to node XYZ".
It was not hard to figure it out once I knew that. I had no clue there
was a problem until someone using makeinfo 6.x told me.

This said, I have not studied in detail how to restructure the code
to improve the warnings.

Not critical, it seems to me. The critical thing, IMHO, is to give us
back the warnings as they stand by default, so bad manuals don't get
unwittingly distributed. Which is what is surely happening and will
continue to happen.  --thanks, karl.

Re: makeinfo 7.1 misses menu errors

[Karl Berry]

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,
https://lists.gnu.org/archive/html/help-texinfo/2023-07/msg4.html

and my understanding of Patrice's reply is that the config setting
was no longer intended to be needed in 7.1:
https://lists.gnu.org/archive/html/help-texinfo/2023-07/msg5.html

And in fact my example document from 2023 does get a warning in 7.1.
So that is good.

My new report is about a similar, but not identical, case which
still does not get a warning in 7.1. I presume(d) it should (i.e., a bug).

Thanks,
Karl

Re: Texinfo.tex, problem with too-long table inside @float

[Karl Berry]

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

Re: overfull box in printed toc with @/

[Karl Berry]

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 out to ftp.gnu.org? --best, karl.

overfull box in printed toc with @/

[Karl Berry]

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 (65.62492pt too wide) in paragraph at lines 3--3
 [][][]@textrm foofoo@texttt \DeclareRobustCommand{@textttsl cmd@texttt }[@text
ttsl num@texttt ][@textttsl default@texttt ] |

The subsection title is painfully long, but it has to be, so I inserted
an @/ to allow a line break. The break happens but the line before the
break gets an overfull box, although no text is near the margin.
I'll attach the pdf I got (and .log, what the heck). --thanks, karl.



txilongsec.pdf
Description: Adobe PDF document


txilongsec.log
Description: Binary data

Re: toc multiline section titles misaligned in TeX

[Karl Berry]

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.

Re: toc multiline section titles misaligned in TeX

[Karl Berry]

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 improvement. Thanks.

to narrow this space, leading the spacing after 2.10 and following
would be narrower (say 0.5 em rather than 1 em).  

So if there are 10+ sections, there would be 1.5em (instead of 2em)
between 2.1-2.9 and the text, and 1em between 2.10 and the text?
Yes, that could well look better. Have to see it to really know.

Another option might be to use (say) .75em as the constant additional
space, so there would be 1.5em for 2.1 and .75 for 2.10.

I feel strongly that the text of the section titles should align.
I don't have strong feelings about the space between the section numbers
and titles. Indeed, I've always thought it was rather too much, e.g.,
the 1.1..1.6 cases in your example look to me like they could be
tightened (a little, not a lot).

Thanks again,
Karl

Re: toc multiline section titles misaligned in TeX

[Karl Berry]

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 has been in
texinfo.tex from the beginning is that the toc does not align correctly
when there is 10+ sections (at any level below chapter). I remember
noticing this in 1985 or so but never getting around to fixing it :).

It didn't seem right to just always leave enough space for a two-digit
section number, since few documents have so many sections. But if any
sectional unit within a given chapter has >=10 items, I think all should
be typeset with the two-digit spacing, else it would look weirdly wrong.

Because of the way toc's are formatted with texinfo.tex, with big
divisions between chapters, I think it would look best to do the >=10
check per chapter, but doing it for the whole document is also a viable
option.

Here's an example. The title "subsec10" is indented more than "subsec1"
through "9", which is definitely wrong. "subsec21" is indented at the
same level as "subsec1"..9, but IMHO it should be indented at the level
of "subsec10" like all the other subsecs.

The same happens at @section and @subsubsection levels.

If you don't feel like working on it, clearly life goes on :), but it
seemed an opportune moment to mention it. --thanks, karl.



secmany.texi
Description: Binary data


secmany.pdf
Description: Adobe PDF document

toc multiline section titles misaligned in TeX

[Karl Berry]

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 chap
@chapter Some very long chapter title with lots and lots and plenty of extra 
words to see where it breaks

@node sec
@section A very long section title with lots and lots and plenty of extra words 
to see where it breaks

@node subsec
@subsection A very long subsection title with lots and plenty of lots of extra 
words to see where it breaks

@bye



try.pdf
Description: Adobe PDF document

Re: Take account of splitting option in gendocs.sh

[Karl Berry]

+   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 the past, only texi2html supported split=chapter. Hence the
hardwiring of various things.

 else
   # should take account of --split here.
-  CONDS="/%%ENDIF.*%%/d;/%%IF  *HTML_SECTION%%/d;/%%IF  *HTML_CHAPTER%%/d"
+  CONDS="/%%IF.*%%/d;/%%ENDIF.*%%/d;"

Should the comment now be something like
# No split output, so delete all conditionals.
?

--

Copyright  2022 Free Software Foundation, Inc.

On the usual triviality front, the copyright year in gendocs_template
apparently didn't get updated along with everything else.

 Please make sure the copyright date is consistent with the document
 and that it is like this: "2001, 2002", not this: "2001-2002". -->

That comment has been obsolete for a couple for decades.
1) rms agreed to allow ranges; 2) only a single year is listed (which is
ok for web pages). It goes against the copyright listing at the top of
the file, so rather confusing.

That's what I see. I didn't actually try it, sorry. --thanks, karl.

htmlxrefversion stale

[Karl Berry]

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

Re: microtype for texinfo

[Karl Berry]

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 default fonts,
meaning [T1] and EC/cm-super.

cm-super contains cyrillic and lm doesn't.
OTOH, there's a claim that lm has more accented and other assorted glyphs.
https://tex.stackexchange.com/questions/1390/
I don't imagine either of these are critical factors for Texinfo.

Best,
Karl

Re: microtype for texinfo

[Karl Berry]

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 "recommended"
TeX packages. It's 60+mb and that just seemed too big. It's been that
way since 2005 or so and no one has complained. Which surprises me, but
I guess relatively few people use TeX, and relatively few of those would
be cognizant of bitmap vs. outline fonts, and those who are, just
install what's needed.

cm-super-minimal includes only the 10pt ("1000") fonts. That's
something, but not enough for any nontrivial LaTeX document. 

He's willing in principle to suggest that cm-super[-minimal] become part
of the recommended TeX packages, but I'm not sure that is warranted.

If nothing changes, I guess the implication is that microtype should not
be used by default, since the fonts in Debian will not be scalable.
(No idea what other distros do, but Debian is probably enough to be a
stopper.)

If you want any action to be taken, let me know. --thanks, karl.

P.S. I certainly understand not bothering to individually configure each
\usepackage line as I mentioned in passing before, but I surmise it
would be useful to have a way for users to say "replace the entire
default preamble with this string".  Even including the \documentclass.

Since there are a zillion ways to do any particular job in LaTeX, seems
useful to provide a general way to support "ok, if you want to choose
all the packages yourself, you can".

Re: microtype for texinfo

[Karl Berry]

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 :(.
(That error message is coming from the pdftex program.) -k

Re: microtype for texinfo

[Karl Berry]

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 document".

I do still think it would be better for texinfo.tex to turn off \texttt
microtype for displayed typewriter environments, or not enable it at all
for \texttt. 

FWIW ... -k

Re: microtype for texinfo

[Karl Berry]

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 thing, or in general?

In general, there are no "issues" with using microtype. The microtype
LaTeX package author (Robert Schlicht) goes to a great deal of effort to
make it work seamlessly. The LaTeX format cannot enable it by default
due to compatibility, that's all.

Regarding typewriter: I reiterate the need to turn it off for display
environments. I haven't had a chance to look for the example to prove it
yet, but it is most certainly needed (do you really doubt me?). In
LaTeX, this amounts to calling \microtypesetup{activate=false} at the
beginning of verbatim/other tt-default environments.

For texinfo.tex, either this should be done or the typewriter font not
enabled for microtype.

but my feeling is
that this is the symptom of something wrong being done with fonts
selection in the LaTeX output, not an issue with microtype as such.

There is "nothing wrong" with font selection in LaTeX that I can
imagine. What are you talking about?

Of course things can easily be misconfigured at any level, causing every
kind of problem. That doesn't mean there is something "wrong" per se.
There is sure no bug to fix on the LaTeX side, anyway. --best, karl.

Re: microtype for texinfo

[Karl Berry]

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

Ultimately, whether outline fonts are used or not depends on the
contents of pdftex.map (for pdftex) or psfonts.map (for dvips), which
list .tfm filenames and corresponding outline fonts. The behavior you're
seeing sounds normal/expected to me, as far as I understand it.

So, my question is how does Texinfo TeX select scalable fonts for the
letters that exists in cm fonts, while LaTeX does not?  Is there a way
to have LaTeX select the same scalable fonts as TeX (even when cm-super
is not installed)?

It is the [T1] option you are giving to {fontenc} which ends up using
the ec fonts, which require cm-super for outline. Without the [T1],
LaTeX uses the original cm* fonts (as texinfo.tex does), which does not
depend on cm-super (but also results in many characters being
unavailable, hyphenation of words with accented characters not working
right, and so on).

At any rate, I don't think it's necessary for us to worry about
this. Any practical usage wants outline fonts, and thus cm-super is
required (short of entirely changing the fonts being used). If someone
goes to the trouble of removing cm-super, well, they're asking for
bitmaps, so they're getting what they ask for.

I would not advise removing the [T1]. That will cause more trouble than
it solves. Along the lines of what Gavin said, I think it's more
useful/important for the LaTeX output from Texinfo to be "normal" LaTeX
than to try to perfectly replicate texinfo.tex. That won't be doing
users any favors.

By the way, a separate issue: as soon as the LaTeX backend is availabl,
people will surely want to run xelatex or lualatex and use ttf/otf
fonts, which means getting rid of the {fontenc} call entirely. (And
using \usepackage{fontspec}\usepackage{unicode-math} instead.) So
whether {fontenc} is included should be configurable. Maybe each one of
those default \usepackage's should be configurable, for that matter. I
can imagine people wanting different euro symbols, for example.

Best,
Karl

Re: microtype for texinfo

[Karl Berry]

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 speculating about. It would destroy compatibility, since every
existing document would be typeset differently. Among other things. (And
for the same reason, I'm still not sure it's a good idea to enable it in
Texinfo by default either, but since Texinfo usage is relatively
limited, maybe it's ok.)

As for cm-super, there is only one cm-super package / set of
fonts. texinfo.tex uses cm-super just for a few characters (eth, thorn,
ogoneks, and so on) that don't exist in the cm fonts. Actually
texinfo.tex (and LaTeX) use the EC .tfm files for the needed fonts;
cm-super provides the Type 1 fonts on the backend for those metrics.

BTW, neither microtype nor cm-super are part of core LaTeX, in the sense
that they are maintained by other people, and LaTeX can be successfully
used without them. Microtype is entirely optional, and cm-super is not
always needed, depending on encodings and font formats that are
used. --best, karl.

Re: microtype for texinfo

[Karl Berry]

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
are not stretched to the text width.  

Microtype can change things even in this kind of case.

I didn't notice any problems with vertical alignment in code
examples with this change.

I guess I'll have to try to dig out my old examples that failed with
LaTeX.  LaTeX verbatim is effectively the same as Texinfo
@example/verbatim in this regard -- no filling, no stretching -- and
microtype definitely screwed up the left margin and/or character
alignment on occasion. The letters A and V starting a line were
particularly susceptible, as I recall.

It will take me some time to figure this out. It was a lot of years ago
that I turned it off in LaTeX verbatim blocks.

could question whether we want to add the @microtype command that is
only used with texinfo.tex.  

Well, I agree with you, but many commands started life as variables
(@set kbdinputstyle and such) and were changed (at Patrice's
suggestion/request/demand, as I recall :) because it seemed better to
have uniform treatment of such customizations across both texinfo.tex
and texi2any. I don't think any such @set variables are left as the
recommended way to change things?

Admittedly (most of?) those could/did have an effect in HTML too.
I suppose one could make a theoretical argument that someday HTML might
support microtype (though personally I hope not).

However, I don't see an alternative.

@set tximicrotype on|off

But I think keeping it a command, as you have it, is preferable, for
consistency. --thanks again, karl.

Re: microtype for texinfo

[Karl Berry]

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 interest lies.

Karl, can you please add that to your patch?  

Thus, I don't think it's worth the trouble to add support when it's only
protrusion. So I won't be working on this. Sorry.

Having a uniform behaviour for all major TeX

I believe texinfo.tex still supports Knuth's original "tex", which of
course does not have any microtype support, though maybe that does not
count as a "major engine" nowadays :).

BTW, separate from any microtype questions, at one time LuaTeX could
have different output (line breaking) from the other engines in obscure
cases. I don't know if that's still true, but I suspect so. I've
forgotten the details, unfortunately. Nothing to do about it, anyway.
--best, karl.

Re: microtype for texinfo

[Karl Berry]

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 lead to variant output between (dvi)-TeX, pdfTeX
and possibly LuaTeX 

pdftex and luatex would normally have the same output. Any dvi engine,
including xetex, would differ.

which might be undesirable.

In a theoretical way, maybe. But in practice, for most documents, the
only TeX output that matters is pdf (i.e., not dvi).

As I described in my original mail, microtype typically reduces the
amount of manual rewriting necessary to avoid overfull boxes.  Of course
this won't be apparent just running on existing manuals, since the
authors have already (hopefully) done all rewriting to get clean output,
but for new and changed text, it can make a big difference in how much
useless scutwork is required.

I know it would help me a lot in the Texinfo manuals that I'm still
maintaining. 

The main thing that would be useful beyond the patch is what I mentioned
before -- it would be great to turn on microtype for \texttt, but then
turn it off again for @example and @verbatim. But if you don't want to
bother with it, the patch as it stands would be quite helpful.

I find it hard to judge whether the output is an improvement.  

The aesthetic thing to look for (if you want to) is more even word
spacing from line to line. There are some examples of the principle at
the end of the memoriam for Zapf by Peter Karow (the first person to
implement hz [not for TeX]).
https://tug.org/TUGboat/tb36-2/tb113zapf-karow.pdf

However, as I said, I don't advocate for this because of the aesthetics,
but because of the practical benefit of reducing rewriting of text.

The most notable change is that many less lines appear to be
hyphenated.

That's an improvement in itself. It's also an indication that TeX 
has more options for line breaking, i.e., it could use the hyphenations,
so that the chances of overfull lines are reduced.

is a lot of enthusiasm for this feature.

Well, I have great enthusiasm for it :). So ... please?  It seems
harmless if it's off by default.

We can hardly expect a groundswell of enthusiasm at this late date --
microtype is 30 years old and hardly anyone outside the TeX world knows
it exists.  Nevertheless, authors would appreciate Texinfo being able to
avoid more overfull lines with less manual work.

Thanks,
Karl

Re: \lastlinefit -> new underfull hboxes

[Karl Berry]

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!

microtype for texinfo

[Karl Berry]

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 way to turn it
on/off within a document, just in case, although in practice, I have
found that I always want it.  It's most useful with the fonts used in
running text, not so much for titles and headings.

There are two main aspects to "microtypography", font expansion and
margin kerning (aka protrusion). I've found that it is the font
expansion part which is useful; it's available in LuaTeX and pdfTeX (not
XeTeX and not Knuth's original TeX). Although XeTeX supports margin
kerning, I've found that is not worth the trouble on its own and don't
recommend bothering with any XeTeX support.

Below is some code to enable both fontexpansion and margin kerning,
using plain.tex conventions. (This code is public domain -- I wrote it,
using other pd sources.) It can get much fancier, but so far this has
sufficed for me. It will need adjusting for texinfo.tex of course, but I
don't think you will find it difficult: administrivia like different
font control sequences, change the \mtpln prefix to \mttxi or some such,
different engine test, etc.

The code below does not change the typewriter font (\tentt for plain).
Although doing so would be extremely helpful for running text that
includes lots of typewriter, as Texinfo documents often do, it is
critical to then turn off microtype in typewriter displays like
@example. Otherwise the fixed-spacing alignment is visibly disturbed. I
think it would be worth doing this for Texinfo, if you have time and
energy for it.

The pdftex manual describes the primitives tersely. The microtype package
manual goes into tons of detail at every level, and has values for more
characters, etc., if desired. (Also values for additional fonts, but
that's not an issue for Texinfo.)
https://ctan.org/pkg/pdftex
https://ctan.org/pkg/microtype

Hope this is useful,
Karl

%
\input iftex.sty
\ifluatex
  \adjustspacing=2
  \def\mtplnfontexpand#1{%
\expandglyphsinfont#1 20 20 1\relax}
\else
  \pdfadjustspacing=2
  \def\mtplnfontexpand#1{%
\pdffontexpand#1 20 20 1 autoexpand\relax}
\fi 
\mtplnfontexpand\tenrm
\mtplnfontexpand\tensl
\mtplnfontexpand\tenbf

%  protrusion, from Thanh's protcode.tex.
\def\mtplnsetprotcode#1{%
\rpcode#1`\!=200
\rpcode#1`\,=700
\rpcode#1`\-=700
\rpcode#1`\.=700
\rpcode#1`\;=500
\rpcode#1`\:=500
\rpcode#1`\?=200
\lpcode#1`\`=700
\rpcode#1`\'=700
\lpcode#1 92=500  % ``
\rpcode#1 34=500  % ''
\rpcode#1 123=300 % --
\rpcode#1 124=200 % ---
\rpcode#1`\)=50
\rpcode#1`\A=50
\rpcode#1`\F=50
\rpcode#1`\K=50
\rpcode#1`\L=50
\rpcode#1`\T=50
\rpcode#1`\V=50
\rpcode#1`\W=50
\rpcode#1`\X=50
\rpcode#1`\Y=50
\rpcode#1`\k=50
\rpcode#1`\r=50
\rpcode#1`\t=50
\rpcode#1`\v=50
\rpcode#1`\w=50
\rpcode#1`\x=50
\rpcode#1`\y=50
\lpcode#1`\(=50
\lpcode#1`\A=50
\lpcode#1`\J=50
\lpcode#1`\T=50
\lpcode#1`\V=50
\lpcode#1`\W=50
\lpcode#1`\X=50
\lpcode#1`\Y=50
\lpcode#1`\v=50
\lpcode#1`\w=50
\lpcode#1`\x=50
\lpcode#1`\y=0
%\adjustprotcode#1\relax
}
\mtplnsetprotcode\tenrm

%\hsize=2.2in
%\input story
%\bye

\lastlinefit -> new underfull hboxes

[Karl Berry]

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.

In one of my real manuals (latex2e.texi), there are several dozen new
underfull (badness 1) lines, and I expect the same will be true of
other manuals. It's not desirable or practical to rewrite the text. And
setting hbadness=1 will then obscure any new cases that really
should be rewritten.

texinfo.tex has always aimed less at the best possible typeset output
and more at typesetting acceptably in a variety of formats (notably
@smallbook and 8.5x11) with minimal (ideally zero) need for rewriting
text. Since \lastlinefit is a high-level refinement to the appearance,
IMHO it should not be set by default at this late date. If some users
want it, they could do it by hand, or texinfo could offer an option
for it.

Thanks,
Karl

-
\input texinfo

@tex
\global\lastlinefit=500
% 500 -> last line is reported as underfull.
% 0 -> fine.
@end tex

@table @code
@item \foofofoofofofofofofofofofo
and @code{\RequirePackage[margins=1in]@{geometry@}} with the single command
@code{\RequirePackage[landscape,margins=1in]@{geometry@}}.

@end table

@bye

Re: When should we put @key inside @kbd?

[Karl Berry]

@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)
[...]
* texinfo.tex (\kbd): If arg consists of one \key command, be a no op.

I didn't find any discussion of
@key inside @kbd in particular.

There is a thread in bug-texinfo in March 2018, and some mention in
earlier years. (Just grepping for kbd.*key and key.*kbd in the
*texinfo/* mailing list archives; didn't try to read all the msgs.)
Probably yet more from before the archives begin. 

Anyway, we could spend more time looking up past history, but it sounds
like all the decisions have been made, so why bother ... certainly not
anything I want to spend more time exhuming. --happy hacking, karl.

Re: When should we put @key inside @kbd?

[Karl Berry]

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

Re: When should we put @key inside @kbd?

[Karl Berry]

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 always the
upright font, which seems to be what you've implemented now?

This relates to @kbdinputstyle. rms instigated that "different font"
(slanted for typewriter) for @kbd, back in 1997.  See ChangeLog.46 and
texinfo.texi for that. The stuff about @key should be in the ChangeLogs too.

If/Since you are going to undo all that, fine by me, but I suggest
1) to be sure and update the manual with whatever users are supposed to
do to get , and
2) it would seem strange to me for HTML and PDF/DVI output to behave
differently, which is what you seem to have implemented. Or maybe not,
I can't really tell.

Best,
Karl

@L and @l print visible space char in code

[Karl Berry]

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.

I believe this is because the plain TeX definitions of \l and \L are
the active ones, and they typeset character 32. In the cmtt fonts,
character 32 is the visible space, whereas in the cmr (and other cm),
char32 is the weird "Polish bar" character used to construct the Polish
l's. From plain.tex:
\def\l{\char32l}
\def\L{\leavevmode\setbox0\hbox{L}\hbox to\wd0{\hss\char32L}}

The best fix I can think of is for Texinfo to have its own \l and \L
definitions which check for a monospaced context (\ifmonospace) and
switch to an EC typewriter font which provides the Polish l's, as we do
for @DH{} and other characters. Well, I'm assuming the ec fonts have
typewriter Polish l's; I confess I didn't check, sorry.

Thanks,
Karl

%
\input texinfo

@node Test
@top Test

@code{@l{} and @L{}}

@bye
%



pl-l-code.pdf
Description: Adobe PDF document

Re: HTML math options

[Karl Berry]

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 Texinfo mode since Eitan died,
and virtually no one uses the plain TeX mode. I don't know what bits
might have rotted, etc.

and it gives me the output

It does not look that bad to me, given that the (unexpected I guess)
goal is a minimalist "text where possible" math mode -- tex4ht was
developed long before mathml or math existed in Unicode, so had to make
do with what it could (rather like Info, for the same reason).

To get mathml, you can get that too (for latex anyway; not sure what
will happen in plain tex), with the mathml option. It can also output to
mathjax and other things, but I admit the invocations escape my mind.

A basic invocation for LaTeX to get HTML5 and UTF-8 output is:
  htlatex file.tex "xhtml,html5,charset=utf-8" " -cunihtf -utf8"
And httex instead of htlatex for plain TeX, or httexi for Texinfo.
Michal (Hoftich, the main maintainer these days) and I have tried to put
some info on https://tug.org/tex4ht, but plenty is lacking.
I'm sorry the documentation is not better. Life is short.

tex4ht appears to run TeX itself to get information from the
produced dvi, instead of (or as well as?) attempting to parse the
TeX code.

It's "instead of". Which is what makes tex4ht a far more adaptable
system than latex2html, which does try to parse the LaTeX input on its
own, which means it fails once documents get weird enough. But just for
parsing math equations it should work well enough, I suppose. -k

Re: viewport declaration

[Karl Berry]

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 according to the pixels available. (The
way it should have been done in the first place.)

I don't know much about it, or mobile in general. A friend pointed it
out to me. Here is some info about it:
https://www.w3schools.com/css/css_rwd_viewport.asp
https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag

In my experience, for straightforward text pages like makeinfo output,
this viewport decl by itself is enough to make the difference between
"unreadably tiny" and "basically usable" on mobile, without needing to
also insert a bunch of css. --best, karl.

viewport declaration

[Karl Berry]

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.

dejagnu in htmlxref.cnf

[Karl Berry]

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 checkout at the moment.) --best, karl.

--- texinfo/util/htmlxref.cnf   2019-06-11 00:25:12.752729993 -0700
+++ /tmp/hx 2020-03-17 18:18:42.655431188 -0700
@@ -116,4 +116,6 @@
 dddmono${GS}/ddd/manual/html_mono/ddd.html
 
+dejagnunode${GS}/dejagnu/manual/
+
 ddrescue   mono${GS}/ddrescue/manual/ddrescue_manual.html
 

texinfo.tex doubled words, debugging lines doc buglets

[Karl Berry]

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 debugging, especially the second. FWIW ... -k

{every,even,odd}{head,foot}ing customization var doc

[Karl Berry]

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:
  Setting such a customization variable to a value @samp{foo} is similar
  to executing @code{@@@var{cmd} foo}.  
is that these are no-ops.

That is the behavior I observe, anyway, e.g., after
  makeinfo -c everyheading='lft@|ctr@|rt' --html hello.texi
the given strings don't show up anywhere in the output.
Texinfo/Common.pm says they are "only relevant in TeX, and special".

Furthermore, it seems that specifying these config values even with
--pdf has no effect, e.g., the -c makes no difference to the output here:
  makeinfo -c everyheading='lft@|ctr@|rt' --pdf hello.texi
(And I wouldn't expect this to work, since it would take a lot of pain
to pass the setting to TeX.)

Thus, I suggest the documentation would be clearer if it said these are
parsed but ignored by makeinfo, so people don't think they are going to
control, e.g., the HTML head/foot with them. Or, even simpler, don't
even bother to mention them, unless they have some purpose to tp that I
am not seeing.

I surmise the same no-op-ness is true of others in that list, e.g.,
@setchapternewpage, but I didn't do more experiments. --best, karl.

Re: user-defined html in navigation header/footer?

[Karl Berry]

... 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 there? Any advice?

configuration variables like SECTION_BUTTONS but I'm not sure if these
are user-settable

Indeed, seems not, since it is a Perl list ref. Cmdline option like
  -c SECTION_BUTTONS="Contents Index Foo"
results in the not-unexpected
  Can't use string ("Contents Index Foo") as an ARRAY ref while "strict refs" 
in use at /usr/local/gnu/share/texinfo/Texinfo/Convert/HTML.pm line 2187.
Surrounding with brackets makes no difference. I don't recall anything
in TP that will take a cmdling/conf string and treat it as an array ref
(not that that means it isn't there).

Thanks,
Karl

user-defined html in navigation header/footer?

[Karl Berry]

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
USER_NAVIGATION_HTML

It would be inserted wherever the other buttons are.

The thing I want to do (and that would seemingly be nice to have for
just about every package), is a link to the package home page. As in,

-c USER_NAVIGATION_HTML="[https://gnu.org/software/texinfo/;>Home]"

But I can imagine people wanting to have more buttons, or something else
entirely, so just as well to make it a generic feature.

Looking at Convert/HTML.pm, I admit it's not obvious to me where/how to
implement this, but I hope it would not be hard.

Wdyt? --thanks, karl.

Re: When should we put @key inside @kbd?

[Karl Berry]

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

Re: summary possible errors in reading Texinfo manual

[Karl Berry]

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 anything much to do with GUIs. The mouse
remains irrelevant today in standalone info and emacs in terminal mode.

advantage is that it can make the navigation bar shorter and less
likely to wrap across the screen.

Yes.  There are cases where it is rational for the node name (mostly
used and seen online) to be different from the section name (mostly used
and seen in PDF). Although many such differences are IMHO useless (seems
like they are different for the sake of being different), that is not
always so.

For example, in the Texinfo manual, in relatively recent times, even I
(one of the strongest proponents of node=section) chose to make some
names different:

Node: HTML Xref Configuration
22.4.6 HTML Cross-reference Configuration: 'htmlxref.cnf'

It just seemed too verbose and useless to me to write the whole thing
out in the node name, yet the information could be usefully present in
the section name. There are a number of cases (in various manuals) where
the section name is ": ", if you know what I mean.

Decades ago I suggested to rms that the node name default to the section
name (or conversely). He considered and rejected the idea, saying that
authors should think carefully about the two names and their respective
contexts. I disagreed with him then and I disagree with him now, but
he's the boss.  --karl

Re: texinfo not happy with texlive not producing log?

[Karl Berry]

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 might be better off throwing this installation away and trying
again from scratch ...
http://tug.org/texlive/acquire.html

Good luck,
Karl

Re: texinfo not happy with texlive not producing log?

[Karl Berry]

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.

Any idea where does it come from?

It is part of the tetex package.  Maybe try "tlmgr reinstall tetex".
I still have no idea how it could have missed at installation time.
The whole installation should have failed, since formats are ordinarily
built then. I can only wonder what else you are randomly missing ...

You can also get the file individually from
http://tug.org/svn/texlive/trunk/Master/texmf-dist/scripts/texlive/
but it would be a welcome surprise if that was the only thing that's
wrong.  --good luck, karl.

Re: Texinfo 6.2 released

[Karl Berry]

+   = ($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

Re: Idea to support math in HTML output

[Karl Berry]

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 mathml, but that support has not significantly changed
since the original author (Eitan Gurari) died in 2009.

latex2html, by the way, is even more problematic (and, so far as I've
seen in recent years, even less maintained).

MathML support because of security concerns

How can mathml be more of a security concern than a huge javascript
program?!  Oh well, no need to answer :).  And Chrome's decisions re
compatibility are inscrutable anyway, similar to luatex's :).

I am not a fan of MathJax.

Fair enough, no argument here :).

Best,
Karl

Re: Idea to support math in HTML output

[Karl Berry]

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, and that does not count the required XML::LibXML and libxml
and lots more painful, unportable, system/version-dependent stuff.  Thus
I doubt it is feasible or desirable to include it in Texinfo.  Rather,
makeinfo could check if it is installed when it is needed (many Texinfo
documents don't use @math after all), and use it/fall back/whatever.

I wonder about using mathjax (and conditionally incorporating it in the
HTML output, if desired).  The effort to make @math{} strings usable by
MathJax or by LaTeXML seems similar.

e. g., with AsciiMath, which is better to read than the TeX math code. [5]

"Better to read" ... that is highly debatable :).  
Not that it matters now.  -k

Re: Fwd: REVIEW REQUEST - user manual generation

[Karl Berry]

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
http://tug.org/pipermail/tex-live/2016-May/038331.html.

I believe luatex has enhanced the \input primitive so that if the next
character is catcode 1, the filename is terminated by the next catcode 2
token.  I'd like to do this in all the engines (except "tex"), but even
if we did, and got christian to do it in miktex, it would still be a
hassle in texi2dvi to detect whether that support is present.  :(  -k

Re: Fwd: REVIEW REQUEST - user manual generation

[Karl Berry]

<>| are not valid in filenames

They are on Unix.  -k

Re: texi2dvi: fix support for whitespace in working directory

[Karl Berry]

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"
instead of
  case $foo
So that could be the culprit.

The second hunk should definitely be a no-op.  All shell code everywhere
in GNU (autoconf, etc.) depends on
foo=$bar
being handled correctly (no word expansion of $bar).

Or else something unrelated also changed.  -k

Re: another texinfo.tex bug in \scanmacro

[Karl Berry]

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.

(Of course, it would be a lot simpler to avoid trying to control
formatting in the first place, as that is not what Texinfo was ever
designed to do.  But I know people feel the need to do it anyway.)

(Not that I have anything against fixing the issue.  Indeed, I'm glad
Gavin could do so.)

k

Re: makeinfo --docbook bug with index

[Karl Berry]

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
business any more ...  -k

Re: XeTeX encoding problem

[Karl Berry]

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 Han The Thanh (principal author of pdftex) and
Hans Hagen wrote it many years ago, late 90s maybe.  I don't seem to
have any old email that specifically talks about it, though.  Sadly, svn
blame reports "Skipping binary file: 'texinfo.tex'" (even though it's
not a binary file), so can't glean information that way.  I thought that
used to work.  Oh well.  Can keep delving if need be ...

By the way, I don't understand ChangeLog entries like this:

2016-03-23  Masamichi Hosoda  
* doc/texinfo.tex (\pdfgettoks, \pdfaddtokens, \adn, \poptoks, 
\maketoks, \makelink, \pdflink, \done): New Macro.
Add XeTeX PDF table of contents page number link support.

\pdfgettoks and the rest aren't "new macros" here.  Are they?  I don't
see new definitions being added.


I also happened to notice:
  % In the case of XeTeX, xdvipdfmx converts strings to UTF-16.
  % Therefore \txiescapepdf is not necessary.

A string like "\node" (where we don't want \n to be interpreted as a
newline) or unbalanced parentheses won't cause problems?  -k

Re: [help-texinfo] Typing rules in Texinfo manual

[Karl Berry]

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 at present.
Maybe that will change one day.   

In any case, I have no recipe to generate images for TeX fragments using
tex4ht (I'm sure it can be done somehow, but ...), so you may not want
to bother.  I have to be doubtful that generating images is what is
really desired, anyway.  -k

Re: LuaTeX >= 0.85 support

[Karl Berry]

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 thus does not hyphenate normal English by default.  I
don't know how to restore the standard behavior.
  http://tug.org/pipermail/luatex/2016-February/005685.html

Hans told me there is a file luatex-pdf.tex in the ConTeXt distribution
that shows the changes.  I can also send you guys preprints of a couple
of short articles by him for the next TUGboat describing (some of) the
changes, if you want.

If it were up to me, I would simply declare LuaTeX unsupported at least
until 1.0.  It seems that tracking Hans's changes from now on will imply
a huge investment of time and effort, let alone doing it in a compatible
way so that people not running the bleeding edge will keep working as
well.  I don't see that the return is worth it.  But of course, if you
want to, more power to you!

Best,
Karl

Re: Problem with @setcontentsaftertitlepage

[Karl Berry]

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 gave a pointer to a(n implicitly) bug-texinfo
email message and the original impetus for the change (another report
from Akim, as it happens):

... Report from Mahlon Smith,
+   25 Aug 2014 09:42:16; original change made following
+   https://savannah.gnu.org/bugs/?15514.

Congratulations on the release!  -k

Re: XML output and entity undefined

[Karl Berry]

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.  It's not an expected outcome from
my point of view.  -k

Re: request: let Shift+Space scroll backward in info

[Karl Berry]

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

Re: XML output and entity undefined

[Karl Berry]

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 certainly possible.

but rather looks in the system catalog for DTDs, but
that's a wild guess.

Hmm, I just don't get it.  Then no document could ever specify its own
dtd, but that's the whole point of having dtd's in the first place!

In any event, the full line being output is, as we've always done:
http://www.gnu.org/software/texinfo/dtd/6.0/texinfo.dtd;>

Maybe there is some other magical stuff that needs to go in there to
make it be effective.  Too many standards ... -k

XML output and entity undefined

[Karl Berry]

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: http://svn.gna.org/viewcvs/*checkout*/latexrefman/trunk/latex2e.xml
Line Number 10, Column 22:2e unofficial ...

As far as I know this document is not doing anything tricky.  It does use
@LaTeX{} in the @settitle, but the  entity is defined in the
specified dtd 
  http://www.gnu.org/software/texinfo/dtd/6.0/texinfo.dtd
as far as I can see.

So something is awry, but sadly it's not apparent to me what it is.
Hopefully it's something obvious?  The Texinfo source is
  http://svn.gna.org/viewcvs/*checkout*/latexrefman/trunk/latex2e.texi 

For context, the project home page is http://home.gna.org/latexrefman.

Thanks,
K

Re: Problem with @setcontentsaftertitlepage

[Karl Berry]

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 using the info from
that run.  People used dviselect to move the toc page(s) to the right
place.

When I eventually changed texinfo.tex to read a .toc from a previous
run, so that @contents could be put in the normal place in the input
file, I also implemented @setcontentsafter... (and
@setshortcontentsafter...) so that people could get the right output
from existing Texinfo files without changing them, via texi2dvi -t
@setcontentsafter...

Whether anyone actually made use of that, I don't know.  I never heard,
one way or another.

I don't think that there's a good reason to use
@setcontentsaftertitlepage in any Texinfo file anyway, 

Indeed, not any more.  I surmise the @set*contentsafter... commands
could be non-implemented by an \errmessage saying "move your @*contents
command".  -k

Re: Problem with @setcontentsaftertitlepage

[Karl Berry]

@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 output whether @setcontentsafter... was used or not.

If you put some text (like, historically, the entire manual :) between
the @end titlepage and the @contents, you would.  -k

Re: span class="nocodebreak" corrupting HTML

[Karl Berry]

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 for a couple of days starting in a few
minutes, so I can't look at it right now.

Maybe it could be included within the parent element, like
--date

I don't see the advantage.  (It also doesn't sound especially easy.)

it if customization of the HTML output (and other) could be done
outside of the Texinfo source instead of adding new commands.

The point is not to customize the output as such, but to reflect the
author's intentions, *as specified by the given Texinfo commands*, as
well as possible.  Just like we do something in the HTML for
@smallexample, and @blockquote, and @kbdinputstyle, and so on.

BTW, I can't say I know for a fact at this point whether the
  span.nocodebreak {white-space: nowrap}
that we output in the makeinfo HTML preamble actually has the effect of
disabling hyphenation.  I hope so.

Best,
K

Re: span class="nocodebreak" corrupting HTML

[Karl Berry]

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 might be a runnable example as part of the
initial submission, or we can create one ... -k

Re: span class="nocodebreak" corrupting HTML

[Karl Berry]

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="nocodebreak" corrupting HTML

On 09/07/15 22:17, Karl Berry wrote:
> PB> There is a small issue at the top of:
> PB> 
> http://www.gnu.org/software/coreutils/manual/html_node/Multi_002dcall-invocation.html
> PB> Due to ... being added inside meta tags.
> PB> Is this an issue with the texi or the HTML generation?
> 
> I think this was a bug in the HTML generation, and I further think it
> was fixed in texinfo-6.0 that we just released ... please give it a try
> when and if you can.

Still an issue with texinfo-6.0-1.fc23.x86_64

Also I see mangled URLs in the manual due to the same
... being added inside the  tags.
For example see the external URLs referenced from:

http://www.gnu.org/software/coreutils/manual/html_node/Options-for-date.html#Options-for-date

thanks,
Pádraig

braces in xrefs failure with texinfo.tex

[Karl Berry]

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 2016-01-11.19):
  ./refbrace.tex:4: Missing @endcsname inserted.
   
 @indexrbrace 
  @}->{@indexrbrace 
  ...
}
   a@}
b
  @xrefX ...@expandafter @Xthisreftitle @csname XR#1

Passing on since I saw it.  I can't delve into it right now, but if you
don't have time I can get to it eventually.  --thanks, k.


Trivial example file:
--
\input texinfo
@setfilename refbrace.info

@xref{a@}b}.
@xref{c@{d}.

@bye

Re: XeTeX encoding problem

[Karl Berry]

I know there are "virtual fonts" in the TeX world 

TeX virtual fonts (that is, .vf files) are irrelevant to the current
discussion. -k

Re: XeTeX encoding problem

[Karl Berry]

> 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:
http://unix.stackexchange.com/questions/14027/what-fonts-are-good-for-unicode-glyphs

This comparison is more comprehensive (includes many proprietary fonts):
https://en.wikipedia.org/wiki/Unicode_font#List_of_Unicode_fonts.
(You can click the "chars" column to sort by that.)

I don't think any single font, such as DejaVu or GNU Freefont
(=Times-ish), would be at all desirable to set as the default from a
design point of view.  The GNU Unifont listed there, which has far more
glyphs than any other, is bitmap-based and unusable for any purpose
except last-ditch fallbacks.  (The Noto font listed there apparently is
neither complete nor officially released.  I'd never heard of it before.)

At any rate, people do not expect to see anything like those as output
from Texinfo, even if one wanted to assume such things were installed.
The lmodern font in M's patch is the best choice in that regard.

As far as I know, the Unicode consortium intends and expects
applications to implement per-block or per-script font switching, rather
than expect fonts provide 100% of Unicode, which would be unrealistic in
the extreme.  And I believe that (switching) is what web browsers do.  -k

Re: XeTeX encoding problem

[Karl Berry]

> 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 for every character.  That sounds like just
shunting the problem off in another direction, not actually solving it.

Really solving it is not a trivial matter and there is no simple
dozen-line patch that will overcome it.

 > However, if the native Unicode support is disabled,
 > the Japanese characters cannot be used in this way.

Well, they *could* be.  We could choose a font with CJK support and make
the definitions in texinfo.tex just as we define existing chars.  In
principle it is possible to make definitions for any and all Unicode
characters in texinfo.tex.  -k

Re: XeTeX encoding problem

[Karl Berry]

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 characters
outside the base font is lost, as far as I can see.  Yes, you get some
characters "for free" (the ones in the lmodern*.otf fonts now being
loaded instead of the traditional cm*) but you also lose some characters
(the ones that aren't in lmodern).

(something like ``Table of Contents'' broken etc.)

That can be fixed in other ways, without resorting to native UTF-8.

CJK characters can not be used without native UTF-8 support.

They still won't work without loading a font that has them (at the right
time, without interfering with other fonts already loaded, etc.).  Not
simple.  There are no CJK characters in lmodern, unless I'm totally
missing them.

Trying to write code to automatically load fonts per Unicode block (or
some such) seems like a horrendously difficult problem.  Nothing in the
TeX world has solved it, to my knowledge.

Anyway, it's up to Gavin whether to install your patch.  I don't have
strong feelings about it.  Just pointing out that there are both gains
and losses.

Best,
Karl

Re: luatex problems with texinfo.tex

[Karl Berry]

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 this tiny chunk of code, I'd be
tempted to just use the fully-qualified names (unicode.utf8.char,
string.byte, string.gsub) instead of defining and then using
abbreviations -- especially since they are only used once, I think.
But that's just me.

Thanks,
Karl

HAVE_MSVC_INVALID_PARAMETER_HANDLER test unquoted

[Karl Berry]

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 variable is used unquoted in
several places.  I don't know if it's supposed to be guaranteed to be
set, but if so, evidently that guarantee is failing.  Maybe
gl_MSVC_INVAL needs to be changed somehow.

Alternatively, here is a simple diff that quotes the instances that grep
found.  No guarantees from me as to completeness :), and I didn't
increment the serial numbers for the sake of not cluttering the patch.

?

k

diff --git a/m4/close.m4 b/m4/close.m4
index 310f076..a0da1e9 100644
--- a/m4/close.m4
+++ b/m4/close.m4
@@ -8,7 +8,7 @@ AC_DEFUN([gl_FUNC_CLOSE],
 [
   AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_CLOSE=1
   fi
   m4_ifdef([gl_PREREQ_SYS_H_WINSOCK2], [
diff --git a/m4/dup.m4 b/m4/dup.m4
index 4fb0d30..6dfa7ca 100644
--- a/m4/dup.m4
+++ b/m4/dup.m4
@@ -8,7 +8,7 @@ AC_DEFUN([gl_FUNC_DUP],
 [
   AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_DUP=1
   fi
   dnl Replace dup() for supporting the gnulib-defined fchdir() function,
diff --git a/m4/fdopen.m4 b/m4/fdopen.m4
index 685a1bb..45eea6a 100644
--- a/m4/fdopen.m4
+++ b/m4/fdopen.m4
@@ -9,7 +9,7 @@ AC_DEFUN([gl_FUNC_FDOPEN],
   AC_REQUIRE([gl_STDIO_H_DEFAULTS])
   AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_FDOPEN=1
   else
 dnl Test whether fdopen() sets errno when it fails due to a bad fd 
argument.
diff --git a/m4/fstat.m4 b/m4/fstat.m4
index 29f9b81..7295627 100644
--- a/m4/fstat.m4
+++ b/m4/fstat.m4
@@ -9,7 +9,7 @@ AC_DEFUN([gl_FUNC_FSTAT],
   AC_REQUIRE([gl_SYS_STAT_H_DEFAULTS])
 
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_FSTAT=1
   fi
 
diff --git a/m4/raise.m4 b/m4/raise.m4
index 71c1f4c..820687d 100644
--- a/m4/raise.m4
+++ b/m4/raise.m4
@@ -13,7 +13,7 @@ AC_DEFUN([gl_FUNC_RAISE],
   if test $ac_cv_func_raise = no; then
 HAVE_RAISE=0
   else
-if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
   REPLACE_RAISE=1
 fi
 m4_ifdef([gl_SIGNALBLOCKING], [
diff --git a/m4/read.m4 b/m4/read.m4
index 5a18c11..632f015 100644
--- a/m4/read.m4
+++ b/m4/read.m4
@@ -8,7 +8,7 @@ AC_DEFUN([gl_FUNC_READ],
 [
   AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_READ=1
   fi
   dnl This ifdef is just an optimization, to avoid performing a configure
diff --git a/m4/write.m4 b/m4/write.m4
index d9b93f9..0a345a9 100644
--- a/m4/write.m4
+++ b/m4/write.m4
@@ -8,7 +8,7 @@ AC_DEFUN([gl_FUNC_WRITE],
 [
   AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
   AC_REQUIRE([gl_MSVC_INVAL])
-  if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
+  if test "$HAVE_MSVC_INVALID_PARAMETER_HANDLER" = 1; then
 REPLACE_WRITE=1
   fi
   dnl This ifdef is just an optimization, to avoid performing a configure

Re: luatex problems with texinfo.tex

[Karl Berry]

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 support, all the engine
support, etc., to take account of native UTF-8.

The only drawback is that documents may look slightly different
between tex/pdftex and luatex/xetex due to different glyphs being
used, 

There are other drawbacks.  you have to switch to a UTF-encoded font,
and nothing in texinfo.tex is ready to do that now.  Nor is it easy to
do.  Furthermore, even if it were done, any character not present in the
font would simply be lost.

Also, clearly the native UTF-8 support in xe/luatex must be disabled for
Texinfo documents that are *not* in UTF-8, so there needs to be a way to
disable the UTF-8 interpretation anyway.

Does anyone know how to check whether luatex or xetex is being used
in TeX?

\luatexversion
\XeTeXrevision
See, e.g., ifxetex.sty, ifluatex.sty, ifplatform.sty.

You also want to know if (for luatex) the output is PDF (ifpdf.sty, good
luck reading that one), which gets more complicated.  And upcoming
incompatibilities in luatex will make the situation worse, as I wrote
you before, Gavin.

Is there a simple correspondence between
naming of 8-bit Computer Modern and the super fonts?

I wouldn't call it "simple".  There is code in texinfo.tex now
(\etcfont) to use cm-super, via the ec* and tc* tfms, for various
characters not present in CM, such as eth, thorn, ogoneks (@DH{}, @TH{},
etc.).  Switching to it for everything does not seem like a good idea to
me, since it is certainly possible to have a usable TeX installation
without cm-super at all.  And, I fail to see how cm-super solves
anything about UTF-8.

Do you know of any way to go back to byte-wise input instead
of input by UTF-8 characters?

Of course it's possible (and I think it is the right thing to do),
otherwise the millions of TeX documents not written in (not to mention
predating) UTF-8 and Unicode could not be processed by those engines.
However, I'm afraid I don't have simple chunks at hand for the job.  I
wish I did.  But you can look up the documentation and figure it out at
least as well as I can.  -k

Re: luatex problems with texinfo.tex

[Karl Berry]

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 not redefine \S, but I can easily imagine it
might happen somewhere along the way.)

Of course, that should really be done for all such plain control
sequences used "internally", but life being what it is ... -k

Re: [bug #46481] install-info can "corrupt" dir file if interrupted.

[Karl Berry]

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 back to whatever
best-possible-attempt otherwise.  To save Gavin the time, trouble, and
exposure of trying to implement it.  This is not a new problem.  One
would sure think it's been solved somewhere already in GNU and can be
reused.

mthl> There is a big difference between the behavior expected at
compile time and install time.

Oh, whatever.  Using gcc was just an example.  Same thing if I type
"make install" and hit CTRL-C (or CTRL-\ or kill -9 from another
terminal or unplugging the computer or whatever) in the middle of
installing some huge binary: I don't expect it to remain uncorrupted.
And, in practice, I believe that it is likely to get corrupted.

You will want every installation operation to be
atomic to garantee the integrity of the system.

Sure, I agree it is desirable, but I don't believe it is, in fact,
implemented by much of anything, except (I suppose) at the
package-manager level.

What's different about the dir file is that it amalgamates stuff from
many packages, and isn't easy to reconstruct (e.g., can't just type
"make install" again).  Thus I can see that in principle it is worth
extra trouble to try to preserve.  But I'm not volunteering to implement
it, so it's just an opinion ... -k

Re: [bug #46481] install-info can "corrupt" dir file if interrupted.

[Karl Berry]

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 previously-existing foo.o.
It's not clear to me that there is really a bug here, although it's
unfortunate that there are repercussions at the package managers.

3) all that said, writing to a temp file and renaming is at least
viable, although rather a pain and susceptible to many hard-to-pin-down
bugs, if gavin wants to deal with it.  gnu libc, or latest posix,
certainly cannot be assumed, and it's usually unclear from documentation
what functions imply what prerequisites, unfortunately.  Maybe there is
a gnulib module that already does the job.  -k

Re: Broken zh_CN cross-references

[Karl Berry]

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 space.

k

[bug #46083] DeclareUnicodeCharacter breaks if used twice for same character

[Karl Berry]

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 texinfo.tex to provide a command like
\ProvideUnicodeCharacter, for documents to use, which would only define the
char if not defined.  Except it won't be defined except in new texinfo.tex, so
it won't help you unless you distribute it, so back to square one.

By the way, I doubt merely using Unicode math characters will result in
coherently readable math in HTML (unless the math is really simple).  Texinfo
has never had support for any of the attempts (many have come and gone ...) to
get math in HTML.

Good luck,
k


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: texinfo 6.0 texindex problem?

[Karl Berry]

> 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: it is not clear to me either that \mathopsup in Texinfo is better
indexed under m, or that \ in general is better off ignored.

Wrt the general point: as far as I can imagine, the (vast) majority of
manuals indexing \ sequences would be for C-style \n, \r, etc.  As a
reader, I would certainly expect those to be indexed under \.

Wrt \mathopsup: since \ is a special character in Texinfo, I actually
found it reasonable and useful to have all the \sequences used in
Texinfo end up together in the index.  That way people can easily see
all those special \sequences.  There is no other easy way.

Of course, in regular TeX manuals, it is better to ignore the \ on
control sequence names, just as it is better to index Texinfo command
names without the @.  But there are relatively few Texinfo manuals
relating to TeX.

k

Re: Inconsistent space after raw regions

[Karl Berry]

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

Re: [bug #46083] DeclareUnicodeCharacter breaks if used twice for same character

[Karl Berry]

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.  Although just always using the 10pt size
doesn't seem like the end of the world either :).

It depends on what glyphs are available in the fonts.

There are lots of check marks in lots of fonts, including the ubiquitious
Zapf Dingbat ... but not in any font we are currently loading, and
adding another (just for this) does not seem worth it to me.

The document at http://ctan.org/pkg/comprehensive (or, hopefully,
"texdoc comprehensive" from the command line) is the most thorough
reference to finding availabilty of symbols I know of.  Of course it's
about LaTeX rather than plain TeX, so the actual \commands won't work,
but at least it's possible to then find the fonts, print the font table
to find the character, etc.

Best,
Karl

Re: The defaults for Info

[Karl Berry]

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 both
places.  But whatever.  -k

Re: The defaults for Info

[Karl Berry]

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, not just
Info files.)

Philosophically, I think there is a consistency, simplicity, and
universality in making the defaults be "mode line in reverse video,
everything else untampered with" which is lacking with any other policy.

However, I recognize this is not a popular stance nowadays, , so I can
only encourage you to do whatever you think is best for most users.

Re the header line, I also have been annoyed by its spilling over to a
second line, wasting precious screen real estate.  However, hiding it
completely feels somehow problematic to me.  Maybe another option would
be to truncate it at the screen width.

Karl

P.S. IMHO, hide-note-references (and all similar things in Emacs that
effectively reformat the Info file) is a misfeature that shouldn't exist
at all.  Not that I expect that to happen.  Certainly I think hiding
should not be default.

Re: [bug #46083] DeclareUnicodeCharacter breaks if used twice for same character

[Karl Berry]

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
once.

3. Of course we want you to be able to use the latest texinfo.tex.  It
seems to me that we could make the error message conditional.  That way
you could turn it off when you knowingly redefine characters.

Though it seems that either you're using the newest texinfo.tex, so you
don't need to make your own definitions, or you're using an older
texinfo.tex, in which case there is no error.  Are you trying to make
your manual work across multiple versions of texinfo.tex?  Avoidance of
such dependence is precisely why texinfo.tex is recommended to be
included in all source distributions ...

FWIW.  -k

Re: The defaults for Info

[Karl Berry]

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 than the pointers.  Go figure ...

However, I guess it could all be abbreviated for display, like
  foo.info:curnode, n:nextnode, p:prevnode, u:upnode
where the "[npu]:" are literal.  Not sure if that's a good idea,
just a stray thought.

It does seem like the boring "File: " and "Node: " prefixes could be
eliminated, since the filename is self-identifying.

Another weird idea that comes to mind is to truncate the pointer node
names so that the total length of the line stays under the terminal
width ... k

Re: texi2dvi changes

[Karl Berry]

+  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 mischance something other than a regular file exists by that
name, it's still desirable to catch it.)

Seems fine, except I'd explicitly mention that the .fl[s] index is the
problem.  Otherwise the user is left with a complete mystery.  As in:

report 'WARNING!!  The fl index may typeset as garbage!' # goes to stderr

It might even be worth adding:
report 'Use env TEXI2DVI_USE_RECORDER=no as a workaround.'
since anyone who gets this message is likely to just want to get on with
life, not delve into all the maddening details.

thanks,
karl

Re: texi2dvi changes

[Karl Berry]

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 TEXI2DVI_USE_RECORDER is yesmaybe (line 1530).

Excuse my opinion, but this seems like the worst possible outcome.  This
way, an existing document that uses an fl index (as discussed, they
exist) will silently typeset garbage with a new texi2dvi.  Thus, with
the yesmaybe default, I strongly believe that texi2dvi should give a
definite error in the case of both the recorder being used and the fl
index being used.

Also, since the only workaround for this case would be to set
TEXI2DVI_USE_RECORDER, I am back to suggesting that it be in the help
message.  Or change the default to nomaybe, I guess, but as already
discussed, the recorder file seems more reliable in general.

Another approach, though suboptimal IMHO, would be for texinfo.tex and
makeinfo to reject up front an attempt to "@defindex fl".  That would be
better than "successfully" typesetting junk.  (I did my tests with the
texinfo.tex currently in the repo, FWIW.)


On another front: evidently some grep for openout is not being redirected.
(Looks like that's the case in check_openout_in_log_support.)
With attached, stdout from  texi2dvi indexfl.texi  starts with
\openout0 = `dum.dum'.

Best,
Karl

P.S. Triviality: I know you are English, but I think it's better to use
American spelling consistently, when the original is in Am.Eng., to avoid
unnecessary inconsistencies for future readers.  Just as I would use
"behaviour" with an original that was in UK.Eng.  Whatever ...



indexfl.texi
Description: Binary data

Re: texi2dvi changes

[Karl Berry]

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}
\end{document}


Standard process:
latex bibsimple
bibtex !$
latex !$
latex !$

(Or pdflatex.)

xampl.bib should be in your tex distribution, it's the example bib that
comes with bibtex, but just in case, it's also attached.

k



xampl.bib
Description: Binary data

Re: Page breaks before @example

[Karl Berry]

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 really be \penalty100
or something.  It's not a horrendous break.

k

Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Karl Berry]

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 a shell
script.  There is no special attempt to make a "Windows equivalent" of
it that is not a shell script.  Thus it cannot be used by people on
native Windows without any Unix tools installed.  This has never been a
problem.

Vincent, my question to you: is there any chance of you moving away from
MSYS?  Supporting such an old, non-free, Windows-based system
nontrivially complicates the code, affecting everyone.  As we have seen,
here and before, at great length.

k

[bug #45912] texindex 5.9.93 does not support -o argument

[Karl Berry]

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 -o in the
new awk texindex, because as far as i knew/know it had been used exactly zero
times in all of texinfo's long history, and it had no useful purpose we could
think of, either.  it wouldn't help you with your .fl[s] woes anyway.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Karl Berry]

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 up to me.

2) I already expressed my opinion to Gavin that it is worth mentioning
the envvar in the help message.  I see nothing to be gained by keeping
it "secret".  In my experience, points like this can cause a lot of
unnecessary frustration when the available options are not documented
and, for whatever reason, the default behavior is not working right.
Which is not unlikely with complicated scenarios such as just have been
introduced.

k

[bug #45859] Problems viewing Latin-1 Info file when Latin-1 locale is not installed

[Karl Berry]

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 this means it has to be solved at a higher
level.

surely there are more useful improvements to make with (tex)info than to spend
time worrying about, let alone doing a substantial rewrite for, a case of an
8-bit info file (which shouldn't be created in the first place) being read on
a system without 8-bit locales (which is utterly inane IMHO).

by the way, i ran across a program called "luit" which, if i understood it
right, converts 8-bit encodings to utf-8 on the fly somehow.  i think it might
be for precisely this case, but i admit i'm not sure.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Karl Berry]

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 removing it now, even
though it is definitely a significant complication.

Possible problem: a *.fls file meets the *.??s glob pattern for sorted
index files. Probably not a problem.

I have used, and still use, an fl index in actual documents.  So it
seems like it is in fact a conflict, unfortunately.  I doubt there is
any portable way to specify the recorder file name.  Sigh.  -k

Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Karl Berry]

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

Re: Argument of \\ has an extra } ??

[Karl Berry]

\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 index files to use @ instead
of \ for the escape character, as should have been done from day one,
but the new texindex has to get far more widely deployed.)

I wonder if there's any way for texindex to output something that is
very likely to work with a bundled texinfo.tex file regardless of
its version.

Of course that would be nice in theory, but barring a kludge like the
above, I don't see how.  Perhaps just a failure of imagination.  Anyway,
I don't think it is so unreasonable for people to avoid using an ancient
texinfo.tex with the new texindex.  If that causes more old
texinfo.tex's to get updated, that's a good thing.

k

P.S.
\gdef\\#1pt{#1}}

Indeed.  I wish Knuth hadn't done that (it was one of the last changes
he ever made to plain.tex), but of course it was never up to us and
certainly isn't going to change now.

Re: Column balancing for short indices

[Karl Berry]

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
counterexample.  -k

Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Karl Berry]

At this point, I guess I have to conclude it is better to use -recorder
if it is available.

k

Re: [bug #45759] Can't find Texinfo::ModulePath

[Karl Berry]

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.)

Re: scrolling behaviour of newer info has changed

[Karl Berry]

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 more as informational than
an error.

3) The inconsistency with Emacs is unfortunate.  Maybe Emacs would be
willing to change behavior too.

--karl

Re: Bug#793067: Bug#792328: info: can no longer find the Emacs manual

[Karl Berry]

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 oppose it.  I just proposed (part of) a way to do it.

Change info reader node search method as follows:
* if a node is going to be followed, first search *in*the*current*directory*
  for the respective info file, and if that fails search INFOPATH.

I don't oppose that either.  Sounds good to me.  (It seems orthogonal to
the dir file, which is ordinarily how users would see the different
available manuals, as far as I can imagine it.  Also orthogonal to the
question of external cross-references to unversioned manuals.  Anyway.)

Best,
Karl