>> I suggest
>>
>> ```
>> '@asis' needs braces here; say '@itemize @asis{}'.
>> ```
>
> I do not like much that option, because we do not have any idea why
> the user ended up using '@itemize @asis'. Maybe with @asis, it will
> be in general the case that @asis{} is correct, but with other
>
> Here is another proposal, which seems much clearer to me, but is
> probably too long:
> @itemize command argument with omitted braces should not require an
> argument, but @asis does. Use braces for @asis
I suggest
```
'@asis' needs braces here; say '@itemize @asis{}'.
```
IMHO it is not
>> (Note that "cmp" is documented not to work with "use locale" for UTF-8
>> strings: [...]
>
> Thanks. This is very confusing to me, then, as it is not told that way
> in perllocale, especially the section: [...]
Perhaps Bruno Haible can help?
Werner
>>You can undefine a macro FOO with ‘@unmacro FOO’. It is not an
>>error to undefine a macro that is already undefined. For
>>example:
>>
>> @unmacro foo
>>
>> However, this doesn't work.
>
> I don't know if this is a regression as the code for this error
> message existed as
>> An alternative is not to have such a variable but just to have an
>> option to collate according to the user's locale. Then the user
>> would run e.g. "LC_COLLATE=ll_LL.UTF-8 texi2any ..." to use
>> collation from the ll_LL.UTF-8 locale. They would have to have the
>> locale installed that
In the texinfo manual of version 7.1 I can find the following about
`@unmacro`:
You can undefine a macro FOO with ‘@unmacro FOO’. It is not an
error to undefine a macro that is already undefined. For example:
@unmacro foo
However, this doesn't work. This input document
```
> Nobody is arguing for "codepoint-order" sorting,
OK, I obviously misunderstood, thanks for the clarification.
Werner
>
>> > Besides, which German are you talking about? There are several
>> > German-based locales, each one with its own local tailoring.
>>
>> It doesn't matter.
>
> If this "doesn't matter", then why do you insist on this?
I mean, it doesn't matter which German collation you use, any will do.
>> [...] Neither collation corresponds to Unicode codepoints.
>
> That's exactly what we should not do.
I strongly disagree.
> People who read German don't necessarily live in Germany, and
> Texinfo is not a general-purpose system for typesetting documents,
> it is a system for writing software
>> OK, no tailoring. I wasn't aware of those differences, thanks for
>> pointing me to it.
>>
>> Hopefully, we agree that `@documentlanguage` should set a
>> language-specific collation for the index.
>
> Without tailoring, this basically means collation according to
> Unicode codepoints.
Uh
>> ... there is probably a misunderstanding on my side. I don't know
>> what you mean with 'tailoring', please give an example.
>
> This subject is too large and complicated for me to answer this
> question here. So I will refer you to the relevant Unicode spec:
>
>
>> > I don't recommend to tailor index sorting for the language
>> > indicated by @documentlanguage, either.
>>
>> This surprises me. Why not? For some languages, the alphabetical
>> order differs enormously from English.
>
> Because indices in a Texinfo document should not depend on details
>
> I don't recommend to tailor index sorting for the language indicated
> by @documentlanguage, either.
This surprises me. Why not? For some languages, the alphabetical
order differs enormously from English.
Werner
> I've made a change to support @tex (and other block commands) on the
> second line of the input file (version 2023-09-12.17). Please let
> me know if it works.
It works! Thanks for the really quick fix.
Werner
> ```
> luatex foo.texinfo
> ```
>
> the `@tex` environment within this file works just fine, and file
> `foo.lua` is correctly loaded. However, saying
Oops, I accidentally attached a wrong version of file `foo.texinfo`.
Here is the correct one.
Werner
\input texinfo
@tex
[texinfo.tex version 2023-08-13.14]
Please consider the attached files. If I say
```
luatex foo.texinfo
```
the `@tex` environment within this file works just fine, and file
`foo.lua` is correctly loaded. However, saying
```
luatex bar.texinfo
```
which includes file `bar.itexi`, I get an
>>> In the particular manual, there are lots of anchors that contain
>>> colons but most of them are not referenced via @ref. (For whatever
>>> reason.)
>>
>> How curious!
>>
> Yeah, I don't really know the history of this. It's a document that
> was, possibly, in Scribe, that was later
> It was the functional change. I re-reverted, fixed, merged the two
> changes in one commit and reapplied in
> 1a21355dd1b50a796e35d9fc55c76b94424b126e
It works now, thanks.
Werner
[1bc5824f2c4aa1d633d62210f1bc7daa210f620c]
[LANG=en_US.UTF-8
LANGUAGE=de]
[perl v5.26.1]
After a standard compilation and installation on my openSUSE GNU/Linux
box I see latin1-encoded strings on my UTF-8 console.
```
> makeinfo --help
Aufruf: makeinfo [OPTION]⦠TEXINFO-DATEIâ¦
Ãbersetzt
> I think the output does not necessarily look ideal. You can see in
> the attached screen clip, in chapter 2, the spacing is very wide
> from 2.1 through to 2.9. I wonder if it would be sensible to try to
> narrow this space, leading the spacing after 2.10 and following
> would be narrower
> 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.
Well, it's not illogical – they are indented by a small amount
instead. If you use, say, `@bsixpaper`, this gives better output
IMHO,
>> If I say `man fc-list`, I get the new manpage version. However, if
>> I say `info fc-list`, I get the old manpage version, i.e., the
>> manpage from `/usr/share/man` gets displayed. This smells fishy.
>
> Can you check the output from "man -a fc-list", as info calls man
> with the -a
>> cannot confirm, builds fine here (Arch Linux). What OS/compiler are
>> you using?
>
> Attached is my `config.log` file. I've tries two compilers, gcc
> 7.5.0 and gcc 10.4.0, with the same result. The error is completely
> mysterious; it shouldn't happen at all actually.
The problem is
```
>> parsetexi/api.c: In function 'set_debug':
>> parsetexi/api.c:1037:3: error:
>> 'debug_output' undeclared (first use in this function)
>>debug_output = value;
>>^~~~
>
> cannot confirm, builds fine here (Arch Linux). What OS/compiler are
> you using?
Attached is my
[info compiled from git on 2022-11-29]
I have a manpage `fc-list.1` twice on my system:
/usr/share/man/man1/fc-list.1.gz (old)
/usr/local/share/man/man1/fc-list.1 (new)
>From `set | less`:
MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man
[c8d9edd94d9b1a3e675e811208d9e66eaf9a7daa]
The sequence
```
./autogen.sh
./configure
make
```
aborts with
```
libtool: compile: \
cc -DHAVE_CONFIG_H \
-I. -I./parsetexi -I. -I./gnulib/lib -I./gnulib/lib \
-DDATADIR=\"/usr/local/share\" \
-D_REENTRANT -D_GNU_SOURCE
>> I've reverted the change in version 2023-03-21.06. We may be able
>> to find some other solution for the @cindex/@item issue.
>
> I have changed texi2any too.
Thanks to both of you!
Werner
>> What about introducing a new flag, something like
>>
>> ```
>> @set txiindexinpara
>> ```
>>
>> that restores the previous behaviour? At least on the `texinfo.tex`
>> side this shouldn't be too difficult. However, I have no idea about
>> `makeinfo` and `texi2any`...
>
> I've reverted the
>> > This was a deliberate change to make index commands terminate
>> > paragraphs.
>>
>> Well, it stayed completely undocumented...
>
> It is in NEWS, but not in a released version admittedly.
OK, but there isn't a single word in the Texinfo manual that index
commands now automatically end a
> (The correct syntax is "@findex foo" not "@findex{foo} but this is
> not the main point.)
Oops, sorry.
> This was a deliberate change to make index commands terminate
> paragraphs.
Well, it stayed completely undocumented...
> This was intended for input like the following: [...] so that
[texinfo.tex 2023-03-13.20]
Consider the following snippet.
```
\input texinfo
@findex{foo}
@code{foo},
@findex{bar}
@code{bar},
@findex{baz}
@code{baz}
@bye
```
This no longer works as expected – with version 2022-12-19.22 the
output is OK (I didn't bisect to find the exact last working
>> Mhmm, more tests show that for `@code{foo--bar}` there is no
>> `@discretionary` after the two hyphens. Is this intentional?
>
> Yes, it is. This was to stop hyphenation in @option{--option}.
OK. I guess it isn't easily possible to make TeX insert a
discretionary after two hyphens in the
>> However, I've tried to fix it in commit bdb7f23072 (texinfo.tex
>> version 2023-01-11.18).
>
> It works, thanks!
Mhmm, more tests show that for `@code{foo--bar}` there is no
`@discretionary` after the two hyphens. Is this intentional?
Additionally, I wonder whether the same logic should
> However, I've tried to fix it in commit bdb7f23072 (texinfo.tex
> version 2023-01-11.18).
It works, thanks!
Werner
[texinfo.tex 2023-01-08.15]
Consider the following input.
```
\input texinfo
@tracingall
@tracingonline0
@code{foo-bar}
@code{foo-bar-baz}
@bye
```
For the first `@code` I get the following.
```
...@texttt f
...@texttt o
...@texttt o
...@texttt -
...@texttt b
...@texttt a
...@texttt r
> Microtype output looks great but having faster processing runs will
> really make a difference for users too, helping them to work on
> their manuals more. I think we should turn microtype off by
> default.
I disagree. In most cases, the speed difference is not really
important, I believe.
> All the characters work with "@documentencoding UTF-8". UTF-8 is
> supposed to be the default input encoding but evidently this isn't
> the case for XeTeX and LuaTeX.
OK.
> I have tested the change below both with and without the
> @documentencoding declaration as well as with
[texinfo.tex 2022-12-19.22]
Consider this input file
```
\input texinfo
·
@bye
```
(the character is U+00B7, MIDDLE DOT). Only pdfTeX produces this
character; both XeTeX and LuaTeX silently discard it.
If you replace '·' with, say, 'Æ' (U+00C6, LATIN CAPITAL LETTER AE),
both XeTeX and
> \let-\normaldash <---
> \let_\realunder <---
>
> the two marked lines
Thinko. Only `\normaldash` needs to be fixed.
Werner
> More diagnostic [...]
The problem is that for LuaTeX it is not sufficient setting
`\hyphenchar` to -1 to disable hyphenation at explicitly inserted `-`
characters...
The simplest solution is probably to change in this code
```
\ifallowcodebreaks
\let-\codedash
\let_\codeunder
\else
> As can be seen, luatex ignores `@allowcodebreaks false`.
More diagnostic: For this input file
```
\input ltluatex
\input nodetree
\NodetreeSetOption[verbosity]{3}
\NodetreeRegisterCallback{postline}
\input texinfo
@allowcodebreaks false
@code{foo-bar}
@bye
```
'nodetree' shows the
[texinfo.tex 2022-12-17.18]
[LuaTeX, Version 1.15.0 (TeX Live 2022) Development id: 7509]
Consider this input file `luatex.texi`.
```
\input texinfo
@afivepaper
@set txicodequoteundirected
@set txicodequotebacktick
@allowcodebreaks false
This is a long-long-long-word and another
> It took me a while but I understand the problem with nesting is that
> \nohyphenation restores hyphenation too soon.
Not really: It is rather that `\font` within the group has a different
value than outside the group. For this reason, the group's `\font`
value must be set via `\aftergroup`,
8b01d1ad9125b3b7b2ec0 Mon Sep 17 00:00:00 2001
From: Werner Lemberg
Date: Thu, 15 Dec 2022 18:28:00 +0100
Subject: [PATCH 1/2] texinfo.tex: Make `\nohyphenation` work as expected.
After leaving a group, `\font` is usually a different font. Before this
patch, the action of `\nohyphenation` was nev
> Attached are two patches that fix both issues. Note that the bug with
> no hyphenation in `@t` is at least 20 years old...
And here's a better fix for the `@t` issue.
Werner
>From 7753a129ddafbc5ccdae62bb130620883764a526 Mon Sep 17 00:00:00 2001
From: Werner Lemberg
Date: Th
s definitely a bug :-)
Attached are two patches that fix both issues. Note that the bug with
no hyphenation in `@t` is at least 20 years old...
I've also attached a sample document, together with an image of it.
Werner
>From 414d2fd0d06383d6574163cdee564175a87a15c2 Mon Sep 17 00:00:00 2001
> The commands were clearly based on the corresponding LaTeX commands,
> which we should take as authoritative.
OK.
> LaTeX \verb doesn't break on a space, so Texinfo @verb shouldn't
> either. I am going to revert the changes to texinfo.tex and look at
> using in the HTML output. (Sorry.)
> We should assume that spaces inside @verb are important and should
> be apparent to the reader. This may not be the case if we allow
> line breaking before or after spaces.
I agree, a situation like
```
foo
bar
```
is ambiguous. However, AFAICS, the main usage of `@verb` is having an
easy
>> As can be seen in the attached output, there is no hyphen in the
>> split word. I consider this a bug, since there is zero reason for
>> such a surprising (and undocumented) behaviour.
>
> A hyphen could be confusing as it may be treated as a literal part
> of the code. I doubt this has
[texinfo.tex 2022-12-04.16]
Consider this example.
```
\input texinfo
This is a @code{Long@-Long@-Word};
this is a @code{Long@-Long@-Word};
this is a @code{Long@-Long@-Word};
this is a @code{Long@-Long@-Word};
this is a @code{Long@-Long@-Word};
this is a @code{Long@-Long@-Word};
this is a
>> Please also fix `makeinfo` so that `@verb` doesn't create overlong
>> lines in info files.
>
> This is not immediately easy for me to do. @verb is treated
> sensibly when the argument does not contain a newline but multiple
> lines in its argument confuse texi2any. This is something I will
Even the simplest input file `foo.texi`
```
\input texinfo
foo
@bye
```
processed with `PDFTEX=xetex texi2pdf foo.texi` fails with
```
This is XeTeX, Version 3.141592653-2.6-0.94 (TeX Live 2022) (preloaded
format=xetex)
restricted \write18 enabled.
entering extended mode
(./z.texi
>> I disagree, since this means that two input characters map to the
>> same output character, which is against the term 'verbatim', isn't
>> it? Additionally, you get the wrong values if you do a
>> cut-and-paste operation.
>
> Is there a reason you can't use @set txicodequote*?
Of course I
>> It turns off hyphenation but allows breaking at spaces. It no
>> longer obeys line endings.
>
> Perfect, thanks a lot for the quick fix!
Please also fix `makeinfo` so that `@verb` doesn't create overlong
lines in info files.
Werner
>> I am going to try to make a couple of changes to texinfo.tex and will
>> post back.
>
> I have committed the change at the end of this message.
>
> It turns off hyphenation but allows breaking at spaces. It no
> longer obeys line endings.
Perfect, thanks a lot for the quick fix!
> I
>> @verb is a rarely used command AFAIK.
>
> Indeed. However, there is no other way in Texinfo to get a
> non-indented, verbatim-like environment. Too bad that
> `@exampleindent` (for `@example`) is not intended to be used in the
> middle of a document, since there is no possibility to restore
>> (1) ` and ' are changed to curly quotes,
>> (2) the text gets hyphenated, and
>> (3) the line break gets obeyed.
>>
>> IMHO, (1) shouldn't happen. While it can be configured with
>> `txicodequoteundirected` and `txicodequotebacktick`, it changes the
>> input without these two flags set.
[texinfo.tex 2022-12-03.17]
Consider the following input.
```
\input texinfo
Test Test Test Test Test @verb{@foo@bar bar bar `doodle' doo tiddle di tiddle
toggle di toggle dum
di dum @} Test
@bye
```
(This is a first long line, with a line break after the first 'dum'.)
Is the attached
>> Interesting. Using either evince 41.3 or okular 21.12.3 on my
>> GNU/Linux box, copy and paste works correctly.
>>
>> What PDF viewer is problematic for you?
>
> evince 3.36.10.
OK, thanks.
>> This is a nice idea, since PDF version 1.5 is the standard format
>> of pdftex nowadays. I
>> Since you have a real use case here, and the case of someone trying
>> to use a degree sign without the EC font is only hypothetical, I
>> have instated your proposed definition for \textdegree.
>
> Thanks.
For consistency I think you should apply the following.
Werner
> Since you have a real use case here, and the case of someone trying
> to use a degree sign without the EC font is only hypothetical, I
> have instated your proposed definition for \textdegree.
Thanks.
> I found that copying and pasting produced an extra space before the
> degree sign, like 45
> The work for me.
D'oh, should have been "This works for me."
Werner
>> Well, for cut and paste, `\circ` is *not* an alternative, since it
>> maps to U+25E6 (WHITE BULLET) in font `cmsy10.pfb`. This might not
>> be an issue in math, but for code listings typeset with typewriter
>> it would be really nice to get it right.
>
> Can you give us an idea of when or
> I've often wanted to try to build the Lilypond Texinfo docs to see
> how well they work, but I haven't been able to find easily
> downloadable sources on the Lilypond website. Is there somewhere
> that such sources would be available, or would I need to compile
> Lilypond completely from
>> [...] I think a better solution is below, which retains U+00B0 for
>> copy and paste.
>
> This uses the European Computer Modern fonts, which normally we have
> only used when necessary. Hence, this would have a chance (probably
> small) of breaking for a document with a degree sign on a
> A fixed width degree sign can be got with a little difficulty. It's
> only worth doing this if somebody is actually using degree signs in
> a fixed width context - I don't have much interest in fixing this
> for all of the character definitions.
>
> Please test the patch at the end of this
>> Consistent with what exactly?
>
> to have ° and @textdegree{} give the same output with Texinfo TeX.
OK.
>> Does this map back to U+00B0 for cut and paste?
>
> No. But neither does the current output, which uses ringaccent and
> therefore maps to the corresponding character 'COMBINING
>> ```
>> \input texinfo
>>
>> @code{45°}
>>
>> @code{45@textdegree{}}
>>
>> @bye
>> ```
>
> It is better to be consistent in my opinion.
Consistent with what exactly?
> Here is a proposed patch, it does not use @textdegree but leads to
> the same output as @textdegree{}. It fails in
[texinfo.tex 2022-11-07.17]
I suggest to change the mapping for U+00B0 (DEGREE SIGN) to use
`@textdegree{}`.
```
\input texinfo
@code{45°}
@code{45@textdegree{}}
@bye
```
As this small example document shows, the results look better even
with typewriter IMHO. Of course, the glyph width
> Fixed in
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=fc756d9128170d92cfacb367e2622c991b1ea5c7
Thanks!
Werner
[texinfo 7.0]
[perl 5.26.1]
Two issues.
* Running
```
LANGUAGE=de LANG=en_US.utf8 makeinfo
```
on the command line gives the warning message
```
Wide character in die at /usr/local/bin/makeinfo line 1332.
```
* Unpack the attached tarball and execute
```
LANG=C makeinfo
> I found that there would always be a warning "pdfTeX warning (dest):
> name{} has been referenced but does not exist, replaced by a fixed
> one" with pdftex. I tracked it down to these changes.
>
> The use of \countB appears to conflict with the use of \countB in
> \pdfgettoks. I didn't fully
> A (non-ideal) workaround is to avoid the use of non-ASCII characters
> in the first character of index entries, using accent commands
> instead:
>
> @findex ax
> @findex @'ay
> @findex ux
> @findex @`uy
This helps, thanks.
Werner
> You can avoid the error with @sortas:
>
> @findex @sortas{\\} \\
Aah, nice, didn't think of it. This solution is good enough, thanks.
Werner
> +\ifx\indexsortkey\empty
> + \message{Empty index sort key near line \the\inputlineno}%
> + \xdef\indexsortkey{ }%
> +\fi
>
> Do you think this would help fix this kind of problem?
Yes, thanks. Maybe it makes sense to also emit
Are you trying to index a
> I very much hope that your ideas of half-solving this for half of
> the OSes out there are not shared by the Texinfo maintainers. I
> personally think it wold be shameful to have such a "solution".
For the short term, I very much disagree. Better indexing support can
be quickly added as a
>> * I think it would be OK if the documentation says that i18n
>> support for sorting only works with awk programs that understand
>> `LANG`.
>
> Gawk understands and uses any LC_* and LANG variables that Posix
> requires, if Gawk uses glibc. Otherwise you depend on the
> particular
>> > > > I consider it very bad that `texindex` is locale-dependent.
>> > > > IMHO the proper solution is to make `texinfo.tex` emit a
>> > > > document encoding statement to the (unsorted) index file
>> > > > that in turn gets acknowledged by `texindex`.
>>
>> Sure? No. But I have some
[texindex (GNU texinfo) 6.8dev]
[GNU Awk 4.2.1, API: 2.0]
[openSUSE Leap 15.4]
There are two bugs with texindex, making it basically unusable for
everything except English as the main document language. For the
report below, here is an input file.
```
\input texinfo.tex
@documentencoding
> AFAICS, the only method to get a 'space' index entry is having a
> series of backslashes if 'txiindexbackslashignore' is set.
I have to correct myself. An index entry
```
@findex {}
```
also generates a line
```
\entry{ }{1}{\code {}}
```
However, it gets swallowed by `texindex`, so it
[texinfo.tex 2022-10-18.18]
Consider the following input file
```
\input texinfo.tex
@set txiindexbackslashignore
@findex \\
@findex A
@printindex fn
@bye
```
The created `.fn` file contains
```
\entry{ }{1}{\code {\backslashchar {}\backslashchar {}}}
```
which doesn't make sense, and
>> I tried working on the right margin of the cartouche but I didn't
>> figure it out in the time I spent on it. I didn't really
>> understand what was going on with \hskip in \ctr and other macros.
>
> I've finally fixed it in commit cbd794cbbd, texinfo.tex version
> 2022-10-15.20. Now the
> With Texinfo 6.8 and HTML output, @minus{} is converted to a hyphen
> instead of a real minus character (U+2212 MINUS SIGN).
I think this is the right action for HTML. The main reason, AFAICS,
is to have working copy and paste. In most cases, stuff like '-1'
must be input with a normal
[Now CCing Luigi]
> mtxrun appears to be part of ConTeXt which I don't have installed.
Correct.
> Did you check if \openout lines appeared in the log file with the command?
>
> luatex --fmt=luatex-plain --file-line-error This is LuaTeX, Version 1.15.0 (TeX Live 2022) (format=luatex-plain
>> For testing purposes I generated a 'luatex-plain' format with
>>
>> ```
>> mtxrun --generate
>> mtxrun --script plain --make
>> ```
>>
>> However, using it as
>>
>> ```
>> PDFTEX="luatex --fmt=luatex-plain" texi2pdf foo.texi
>> ```
>>
>> fails with
>>
>> ```
>> texi2dvi: TeX neither
For testing purposes I generated a 'luatex-plain' format with
```
mtxrun --generate
mtxrun --script plain --make
```
However, using it as
```
PDFTEX="luatex --fmt=luatex-plain" texi2pdf foo.texi
```
fails with
```
texi2dvi: TeX neither supports -recorder nor outputs \openout lines in its
Thanks for the push, the results are good now!
>> The PDF file in the last e-mail has five lines in the last
>> paragraph; the image shows six lines.
>
> I can't explain this particularly but it should be no surprise that
> TeX formats paragraphs differently depending on the context.
Well,
> I added some extra space in commit 2d1867cd03. It's probably not
> perfect either but hopefully it will be good enough.
Thanks, but it seems that you haven't called 'git push'...
>> Under some circumstances it seems that `texinfo.tex` allows one
>> more text line, causing even more
[texinfo.tex 2022-09-26.17]
Consider this example (using `image.pdf` from the 'texinfo' git
repository).
```
\input "texinfo.tex"
blablabla blablabla blablabla blablabla
blablabla blablabla blablabla blablabla
@image{image,4cm}
blablabla blablabla blablabla blablabla
blablabla blablabla
> - make cm-super a dependency of texinfo (next version, in Debian)
> that way the package will be pulled in in any case
IMHO that's the way to go.
Werner
series of patches to
fix that.
Werner
>From cb8867beaab487df05d5cac61e34f0c00df0aa14 Mon Sep 17 00:00:00 2001
From: Werner Lemberg
Date: Mon, 26 Sep 2022 13:58:09 +0200
Subject: [PATCH 1/3] * doc/texinfo.tex: Remove trailing spaces.
---
ChangeLog | 4 +
> 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,
I missed that, sorry.
> but (unfortunately) not expansion. In my experience, protrusion has
> little effect;
> 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.
According to the table on page 6 in the current microtype package,
XeTeX *does* support
> However, if `@raggedright` is involved, there are still cases where
> the space after 'Chapter X:' is wider than usual.
It seems that in the definition of `\currentchapterdefs` (or probably
all commands that might influence headers and footers) it is necessary
to reset `\spaceskip` and
>> * If there are many images mixed with text, the top of the text
>> block is vertically jumping a lot.
>>
>> * It is a waste of space. For example, LilyPond's notation
>> reference has more than 900 pages including almost 1700 images; a
>> raised box would save a few pages.
>
>
> Can
> [...] You can see that @code changes the space factor of colon and
> this is not altered inside the heading.
>
> I've commited a change (version 2022-09-17.11) that should fix this,
> at the expense of some extra processing every page to reset the
> space factor codes.
Much better, thanks.
[texinfo.tex version 2022-09-15.17]
I noticed that for unknown reasons the space width between
'Chapter X:' and the following text in the header line varies; see
attached images. Unfortunately, I can't see any logic behind it,
which makes it hard for me to provide a minimum example.
This
> It did make a difference so I have provided an altered definition of
> \raggedbottom. Please try version 2022-09-15.17.
Works, thanks!
Werner
>> As far as I can see, the last thing not obeying the 'text block' is
>> the table of contents. I can't see any reason why this is so –
>> actually, the page number is uncomfortably near to the top line of
>> the TOC, as can be seen on the attached image. [This is with
>> @afourpaper in case
[texinfo.tex version 2022-09-05.20]
>> This probably needs a similar fix as the `@image` environment.
>
> Indeed, in February this year, although I had forgotten this.
> Please try the latest commit.
It works, thanks.
As far as I can see, the last thing not obeying the 'text block' is
the
1 - 100 of 421 matches
Mail list logo
