Re: @documentlanguage and locale file
On Wed, Sep 28, 2022 at 01:24:00PM -0700, Raymond Toy wrote: > The manual says: > > For TeX, this command causes a file txi-locale.tex to be read (if it > exists). > > But when I run texi2pdf maxima.texi, I get > > ./maxima.texi:4: Cannot read language file txi-ru.tex. > > Which is true, but I was expecting TeX to ignore this. txi-ru.tex is distributed with Texinfo and needs to be placed in a directory where TeX will find it.
Re: microtype for texinfo
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
@documentlanguage and locale file
The manual says: For TeX, this command causes a file txi-locale.tex to be read (if it exists). But when I run texi2pdf maxima.texi, I get ./maxima.texi:4: Cannot read language file txi-ru.tex. Which is true, but I was expecting TeX to ignore this. maxima.texi (for Russian) is basically: \input ../texinfo @setfilename maxima.info @documentencoding UTF-8 @documentlanguage ru @include include-maxima.texi @bye include-maxima.texi includes all the various sections of the maxima manual. -- Ray
Re: Info reader - issues finding first index entry
On Wed, Sep 28, 2022 at 08:21:45PM +0100, Charles Reilly wrote: > A fix is attached. Thanks, committed in 79c29a9b2e0.
Re: leading and trailing spaces in brace commands
On Tue, Sep 27, 2022 at 08:10:57PM +0100, Gavin Smith wrote: > On Tue, Sep 27, 2022 at 09:26:15AM +0200, Patrice Dumas wrote: > > > I'm not sure if it would be correct to ignore spaces for other commands: > > > @math, @value, @verb... Almost every command could be different. It > > > seems quite simple to say that these spaces are ignored for > > > BRACE_arguments > > > commands but not for others, although needless to say I haven't fully > > > explored the consequences of this idea by trying to implement it. > > > > That's exactly what the implementation does currently, but my point is > > that some of these cocmmands should not be in BRACE_arguments but in > > another class, either one already existing, or a new one. > > OK, some commands could move to BRACE_arguments if we want to ignore spaces > in their arguments. I do not have example of such cases, actually. > @math isn't currently in BRACE_arguments and as spaces don't need to be > ignored for @math (I haven't checked whether they are or not), it's fine > to leave it out. And it is best if it remains in BRACE_context too, the code may be changed, but for now it is expected there and I think that it makes sense. > I see you have made some changes to the command types. @value and @verb are > now BRACE_other (along with @w). I guess @value is special because it > is expanded immediately, and @verb and @w also are handled uniquely. @value is also special because it should contain flags names only. > I looked through command_data.txt and your list of commands > where spaces around arguments can be kept - @dmn, @key, @indicateurl, > @titlefont - appears sensible to me. I don't know how easy it would be > to change any of these. Would you be moving them to BRACE_style_other? I think that @indicateurl should go to BRACE_style_other, @key could too, even if it is less clear. I would propose to add another category for @titlefont and @dmn for brace commands that are not style commands, do not have spaces ignored and are not special enough to be explicitly in BRACE_other. Maybe BRACE_misc. -- Pat
Re: Info reader - issues finding first index entry
On 27/09/2022 8.20 pm, Charles Reilly wrote:
On 27/09/2022 6.58 pm, Gavin Smith wrote:
On Tue, Sep 27, 2022 at 06:07:08PM +0100, Charles Reilly wrote:
Hi,
Using info I have had some issues with finding the first entry in the
index.
For example, try running "info gzip". The first entry in the concept
index
for gzip is "bugs". Some example searches:
ibugs - Succeeds
ibu - No entries containing 'bu'.
Ibugs - No entries containing 'bugs'.
Ibu - No entries containing 'bu'.
It seems that the index-search only finds the first entry if it is an
exact
match. The virtual-index never finds the first entry.
Four similar tests for the second index entry, "concatenated files", all
succeed.
I'm using info version 6.7. A similar bug was reported previously:
https://lists.gnu.org/archive/html/bug-texinfo/2010-07/msg00015.html
A bug like this was fixed in March 2022. This was reported here:
https://lists.gnu.org/archive/html/bug-texinfo/2022-02/msg00105.html
and fixed on 2022-03-09. It was a different issue that was reported
in 2010.
Thank you, I missed that. I've built the latest source from savannah
and tried again. Now I get:
ibugs - Succeeds
ibu - Succeeds
Ibugs - No index entries containing 'bugs'.
Ibu - Succeeds
Everything works except a virtual index with an exact match on the first
index entry.
There is also still a slight weirdness with the index search. Normally
after a search with a single result, entering ',' for the next result
gives something like "No more index entries containing 'concat'". But
if the result was the first one in the index it gives "No index entries
containing 'bu'", without the "more". This is no great problem but it
does suggest something odd is going on.
A fix is attached.From d1601d65ebe662f9097319fdded54f989349 Mon Sep 17 00:00:00 2001
From: Charles Reilly
Date: Wed, 28 Sep 2022 16:31:13 +0100
Subject: [PATCH] Reliable index searches for first index item
---
info/indices.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/info/indices.c b/info/indices.c
index 5dfcf3091c..349775b1d2 100644
--- a/info/indices.c
+++ b/info/indices.c
@@ -33,7 +33,7 @@ int show_index_match = 1;
static REFERENCE **index_index = NULL;
/* The offset of the most recently selected index element. */
-static int index_offset = 0;
+static int index_offset = -1;
/* Whether we are doing initial index search. */
static int index_initial = 0;
@@ -264,7 +264,7 @@ DECLARE_INFO_COMMAND (info_index_search,
/* If the search failed, return the index offset to where it belongs. */
if (index_offset == old_offset)
-index_offset = 0;
+index_offset = -1;
}
/* Return true if ENT->label matches "S( <[0-9]+>)?", where S stands
@@ -472,11 +472,11 @@ DECLARE_INFO_COMMAND (info_next_index_match,
/* If that failed, print an error. */
if (!result)
{
- info_error (index_offset > 0 ?
+ info_error (index_offset >= 0 ?
_("No more index entries containing '%s'") :
_("No index entries containing '%s'"),
index_search);
- index_offset = 0;
+ index_offset = -1;
return;
}
@@ -825,7 +825,7 @@ create_virtual_index (FILE_BUFFER *file_buffer, char
*index_search)
cnt = 0;
- index_offset = 0;
+ index_offset = -1;
index_initial = 0;
index_partial = 0;
while (1)
--
2.30.2
Re: Info reader - issues finding first index entry
It's a simple fix. Do you accept git patches? On 27/09/2022 8.20 pm, Charles Reilly wrote: On 27/09/2022 6.58 pm, Gavin Smith wrote: On Tue, Sep 27, 2022 at 06:07:08PM +0100, Charles Reilly wrote: Hi, Using info I have had some issues with finding the first entry in the index. For example, try running "info gzip". The first entry in the concept index for gzip is "bugs". Some example searches: ibugs - Succeeds ibu - No entries containing 'bu'. Ibugs - No entries containing 'bugs'. Ibu - No entries containing 'bu'. It seems that the index-search only finds the first entry if it is an exact match. The virtual-index never finds the first entry. Four similar tests for the second index entry, "concatenated files", all succeed. I'm using info version 6.7. A similar bug was reported previously: https://lists.gnu.org/archive/html/bug-texinfo/2010-07/msg00015.html A bug like this was fixed in March 2022. This was reported here: https://lists.gnu.org/archive/html/bug-texinfo/2022-02/msg00105.html and fixed on 2022-03-09. It was a different issue that was reported in 2010. Thank you, I missed that. I've built the latest source from savannah and tried again. Now I get: ibugs - Succeeds ibu - Succeeds Ibugs - No index entries containing 'bugs'. Ibu - Succeeds Everything works except a virtual index with an exact match on the first index entry. There is also still a slight weirdness with the index search. Normally after a search with a single result, entering ',' for the next result gives something like "No more index entries containing 'concat'". But if the result was the first one in the index it gives "No index entries containing 'bu'", without the "more". This is no great problem but it does suggest something odd is going on.
Re: microtype for texinfo
On Wed, Sep 28, 2022 at 05:01:18PM +0100, Gavin Smith wrote:
> On Tue, Sep 27, 2022 at 06:41:44PM -0600, Karl Berry wrote:
> > 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".
>
> Well, the default would be not to have the line at all, and it's not incorrect
> not to have it, while it may be incorrect to have it for tt environments, as
> you have said. So removing the line would be a quick way to stop bad output
> for tt environments, if there is any.
As I said in another mail, this is not an issue in the generated LaTeX,
most likely, as microtype is already disactivated in monospace
environments:
\AtBeginEnvironment{GNUTexinfopreformatted}{\microtypesetup{activate=false}}
\AtBeginEnvironment{verbatim}{\microtypesetup{activate=false}}
We could unset microtype for the bitmap fonts issue, though.
> I did not see microtype listed at
>
> https://ctan.org/pkg/latex-tools or https://ctan.org/pkg/required
>
> Should it be thought of as a core part of LaTeX that is present everywhere
> that LaTeX is or is it more of an optional extra?
It is optional, but in debian it is in texlive-latex-recommended which
is very likely to be installed if texlive is installed. etoolbox is
in texlive-latex-recommended too, for instance. We use titleps, for
example, which is in texlive-latex-extra which is less likely to be
present.
--
Pat
Re: microtype for texinfo
On Tue, Sep 27, 2022 at 06:41:44PM -0600, Karl Berry wrote:
> 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".
Well, the default would be not to have the line at all, and it's not incorrect
not to have it, while it may be incorrect to have it for tt environments, as
you have said. So removing the line would be a quick way to stop bad output
for tt environments, if there is any.
I did not see microtype listed at
https://ctan.org/pkg/latex-tools or https://ctan.org/pkg/required
Should it be thought of as a core part of LaTeX that is present everywhere
that LaTeX is or is it more of an optional extra?
> 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.
We don't enable it for \texttt at all at current in texinfo.tex.
Re: microtype for texinfo
On Tue, Sep 27, 2022 at 08:20:17PM +0100, Gavin Smith wrote:
> On Tue, Sep 27, 2022 at 09:38:30AM +0200, pertu...@free.fr wrote:
> > ... 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.
>
> It is just a consequence of using T1 encoded fonts, which aren't used
> everywhere in texinfo.tex, only for special characters. In the LaTeX
> the T1 encoded fonts have to be used everywhere otherwise @DH{} and the
> like don't work. There's no easy way to use a different font for @DH{}
> specially without providing our own definitions of these glyph commands.
> See where \ecfont is used in texinfo.tex.
Ok, thanks. That means that we could make different choices with
respect to microtype. But I think that we should prominently document
that it is very much advidsed to have cm-super installed, for some
glyphs in Texinfo TeX, as it is already documented, and for the whole
document for LaTeX output.
> > On my debian I can remove the cm-super
> > package and also the cm-super-minimal package and texi2pdf still works
> > well and produces ogonek accented characters.
>
> Do @DH{} and other glyph commands work?
Yes, but bitmap fonts are used.
> In texinfo.tex, a different font is used for ogonek for certain letters
> only - A, a, E, e. Did you test it with one of those characters?
I tested with:
ð @th{} þ a @'e é @DH{} @ogonek{a} @ogonek{b}
'a' and 'é' are always rendered with a scalable font. When cm-super is
installed, all the glyphs are rendered with a scalable font, including
@ogonek{b}. When cm-super is not installed, all the glyphs (except for
'a' and 'é') use bitmap fonts (my criteria is that they pixelate when I
zoom).
In documents with lot of glyphs like that, and with cm-super not installed,
there could be a risk to get the microtype error with Texinfo TeX I get
with LaTeX output:
pdfTeX error (font expansion): auto expansion is only possible with scalable
fonts.
--
Pat
Re: microtype for texinfo
On Tue, Sep 27, 2022 at 04:22:44PM -0600, Karl Berry wrote:
> 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.
That is already possible, simply use a @latex block in the Texinfo
preamble, it will be after the builtin preamble and before
\begin{document}. But this does not allow to substitute \usepackage
in the builtin preamble.
> 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).
Ok.
> 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.
At least on debian, cm-super is not much installed automatically as a
dependency. It is a Suggest of texlive-fonts-extra and a dependency of
texlive-full. So I do not expect casual users to have it installed
unless it is documented in the Texinfo manual (which is already the
case, it is documented in the Texinfo manual). cm-super-minimal isn't
much more installed (I think I got it as a python3-matplotlib Suggest)
and does not allow to have scalable fonts used in Texinfo TeX for the
ec glyphs, not in LaTeX output from Texinfo code with [T1] {fontenc}.
> 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.
Ok.
> 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.
I will add to the LaTeX.pm specific TODO. It is up to Gavin, but
usepackage configuration for LaTeX output will probably not be for the
next release.
--
Pat
Re: microtype for texinfo
On Tue, Sep 27, 2022 at 04:22:45PM -0600, Karl Berry wrote:
> 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?
Not the typewriter thing, another error.
When I do not have cm-super installed, for the texinfo manual, I get, with
pdflatex on the LaTeX file generated from texinfo by texi2any:
! pdfTeX error (font expansion): auto expansion is only possible with scalable
fonts.
...shipout:D \box_use:N \l_shipout_box
\__shipout_drop_firstpage_...
l.143 \end{titlepage}
I get that with another 'complex' rather artificial test manual, but I
couldn't manage to reproduce with a simpler case. This issue is visible
on internet, and the answer is:
Use
usepackage[T1]{fontenc}
usepackage{lmodern}
Or install the cm-super fonts.
It is also explained in the microtype documentation:
! pdfTeX error (font expansion): auto expansion is only possible with scalable
fonts.
Automatic font expansion has been improved in pdfTEX 1.40, in that it now not
only works with Type 1 fonts but also with TrueType, OpenType and even non-
embedded fonts. The above error message indicates either that you are trying to
apply expansion to a bitmap (pk) font, which is still not possible, or that the
font
isn’t found at all, e.g., because of missing map entries.
So, it is a known issue, the question is what do we do for the LaTeX
generated by texi2any, and in the Texinfo documentation.
> 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.
This typewriter issue easily done in LaTeX output and already
implemented with LaTeX output generated by texi2any like
\AtBeginEnvironment{verbatim}{\microtypesetup{activate=false}}
> 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.
I am not talking about a bug on LaTeX side, but on the LaTeX generated
from Texinfo, that is, the code in texi2any to generate LaTeX.
You answered that already in detail, actually, in another mail.
--
Pat
