Re: Displaying images for html output
> Sent: Sunday, November 22, 2020 at 12:46 AM > From: "Patrice Dumas" > To: "Gavin Smith" > Cc: "Christopher Dimech" , "help-texinfo gnu" > > Subject: Re: Displaying images for html output > > On Sat, Nov 21, 2020 at 05:20:00PM +, Gavin Smith wrote: > > On Thu, Nov 19, 2020 at 10:11 PM Patrice Dumas wrote: > > > I think that if the path does not starts with . or .. or is an absolute > > > path, it would make sense > > > 1) to search in include directories (I think that the current directory > > > is always in front of of the search path) > > > 2) to check if the directories and image file exist in the destination > > > directory and if not copy the file > > > > > > For point 2), there could be a customization variable to prevent the > > > copy, that would be off in the default case, but can be turned on for > > > the users who want backward compatibility or do something else by > > > themselves, for instance use links. > > > > That sounds okay, as searching include directories matches what > > happens with TeX. When you say "current directory" this should mean > > the directory containing the Texinfo file, not the working directory > > from which texi2any is run. (What to do when a file in a subdirectory > > is @include'd and then references an image, I don't know.) I got to handle that situation an a daily basis. What I have found is that the include file that references the image got to have a number of Level Variables, so the texinfo can still get to the image. I can share a copy of the code so texinfo can get to the next level for complicated projects. Shall we do it? I have been pushing texinfo to the limit and the code would certainly provide ideas so that texinfo could handle those instances adequately. Regards Christopher > I think that it is the current directory, not the directory containing > the Texinfo file, but I do not think that it matters much. I think that > the point is to copy the image file from where it is found to the > destination directory. > > -- > Pat >
Re: Displaying images for html output
On Sat, Nov 21, 2020 at 05:20:00PM +, Gavin Smith wrote: > On Thu, Nov 19, 2020 at 10:11 PM Patrice Dumas wrote: > > I think that if the path does not starts with . or .. or is an absolute > > path, it would make sense > > 1) to search in include directories (I think that the current directory > > is always in front of of the search path) > > 2) to check if the directories and image file exist in the destination > > directory and if not copy the file > > > > For point 2), there could be a customization variable to prevent the > > copy, that would be off in the default case, but can be turned on for > > the users who want backward compatibility or do something else by > > themselves, for instance use links. > > That sounds okay, as searching include directories matches what > happens with TeX. When you say "current directory" this should mean > the directory containing the Texinfo file, not the working directory > from which texi2any is run. (What to do when a file in a subdirectory > is @include'd and then references an image, I don't know.) I think that it is the current directory, not the directory containing the Texinfo file, but I do not think that it matters much. I think that the point is to copy the image file from where it is found to the destination directory. -- Pat
Re: Displaying images for html output
On Thu, Nov 19, 2020 at 10:11 PM Patrice Dumas wrote: > I think that if the path does not starts with . or .. or is an absolute > path, it would make sense > 1) to search in include directories (I think that the current directory > is always in front of of the search path) > 2) to check if the directories and image file exist in the destination > directory and if not copy the file > > For point 2), there could be a customization variable to prevent the > copy, that would be off in the default case, but can be turned on for > the users who want backward compatibility or do something else by > themselves, for instance use links. That sounds okay, as searching include directories matches what happens with TeX. When you say "current directory" this should mean the directory containing the Texinfo file, not the working directory from which texi2any is run. (What to do when a file in a subdirectory is @include'd and then references an image, I don't know.)
Re: Macro introduces \par in Table of Contents
On Sat, Oct 03, 2020 at 12:18:41PM +0100, Gavin Smith wrote:
> I found that starting a new line, like
>
> @uSubSec{@value{SecLb},
> Probabilistic Characterisation of Microseismicity}
>
> worked with texi2any, but not with TeX.
Works with TeX now with commit 73f61c705.
> As usual with macro handling in Texinfo, this is not easy to fix, and
> any fix risks breaking something else. There is an @xeatspaces macro
> being used around macro arguments that is not being expanded until
> quite late on, which might be better expanded earlier with a given
> value of active newline, but it would be very complicated if not
> impossible to expand this earlier without fully expanding the macro
> arguments at the same time (probably some complex arrangement of
> \expandafter's which would differ depending on the number of macro
> arguments, or repeatedly reading the argument text as a macro argument
> and moving expanded arguments one by one to the end). Even if it's
> possible it's probably better not to try as it would be error-prone
> and hard to understand after the fact.
I didn't follow this approach but I think it is possible. The definition
of \parsemargdef could build up a definition like
\eatspaces{#1},\eatspaces{#2}... as it builds up \paramlist. This would
have to be completely expanded though at some point before \scantokens
runs... so this idea would need more work.
The code for @macro's with 10 or more arguments also looked interesting,
although I've never understood how that code worked (never tested it
either).
