bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: incorrect @math spacing for PDF output with an empty macro


From: Gavin Smith
Subject: Re: incorrect @math spacing for PDF output with an empty macro
Date: Wed, 26 Oct 2022 09:44:05 +0100

On Wed, Oct 26, 2022 at 02:44:17AM +0200, Vincent Lefevre wrote:
> > In theory, there could be better output if we could change the size
> > of spaces inside of @w, but I doubt that there is a good way of
> > achieving this in TeX.
> 
> I had looked at tex.stackexchange.com and found
> 
>   https://tex.stackexchange.com/questions/574783/stretch-spaces-within-a-box
> 

That is asking the same question as you.  As you noted, there isn't
a solution.

It seems a fundamental limitation of TeX.  Hboxes do not have any
kind of stretch derived from their contents.

(It might be interesting to consider how a replacement system might
do things differently, not that that helps us with texinfo.tex.
I imagine that the hbox could be set in a range of widths to obtain
a badness at each width, then this badness-width function would feed
into the paragraph optimization somehow.)

> but the accepted answer seems incorrect, or not answering the
> general issue.

Unfair criticism IMHO.

> So
> 
> https://mirror.ibcp.fr/pub/CTAN/macros/latex/contrib/nolbreaks/nolbreaks.sty
> 
> might be a solution if applicable in the context of Texinfo (it
> is quite short and in the public domain, so it could be adapted
> if need be).

Great, now can you explain how it all works?!  Not worth the trouble
in my opinion.

> but
> 
>   \binoppenalty=10000
>   \relpenalty=10000
> 
> solved the issue in all my LaTeX documents.

Good idea.  You could do the same in Texinfo:

@tex
\globaldefs=1
\binoppenalty=10000
\relpenalty=10000
@end tex

> However, for the Info output at least (and I assume that this is
> also the case for the HTML output), @w is really necessary. See
> the differences:
> 
> @@ -1586,8 +1586,8 @@
>            mpfr_rnd_t RND)
>       Set ROP to the square root of OP rounded in the direction RND.  Set
>       ROP to −0 if OP is −0, to be consistent with the IEEE 754 standard
> -     (thus this differs from ‘mpfr_rootn_ui’ and ‘mpfr_rootn_si’ with N
> -     = 2).  Set ROP to NaN if OP is negative.
> +     (thus this differs from ‘mpfr_rootn_ui’ and ‘mpfr_rootn_si’ with
> +     N = 2).  Set ROP to NaN if OP is negative.
>  
>   -- Function: int mpfr_rec_sqrt (mpfr_t ROP, mpfr_t OP, mpfr_rnd_t RND)
>       Set ROP to the reciprocal square root of OP rounded in the
> @@ -1595,8 +1595,8 @@
>       NaN if OP is negative.  Warning!  Therefore the result on −0 is
>       different from the one of the rSqrt function recommended by the
>       IEEE 754 standard (Section 9.2.1), which is −Inf instead of +Inf.
> -     However, ‘mpfr_rec_sqrt’ is equivalent to ‘mpfr_rootn_si’ with N =
> -     -2.
> +     However, ‘mpfr_rec_sqrt’ is equivalent to ‘mpfr_rootn_si’ with
> +     N = −2.
>  
>   -- Function: int mpfr_cbrt (mpfr_t ROP, mpfr_t OP, mpfr_rnd_t RND)
>   -- Function: int mpfr_rootn_ui (mpfr_t ROP, mpfr_t OP, unsigned long

I strongly agree.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]