Message-Id: <m0yopYA-000S3xC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Date: Wed, 24 Jun 1998 10:31:01 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Int2TeX v1.00 was released
References: <m0yoVka-000S3zC AT inti DOT gov DOT ar>
In-reply-to: <Pine.SUN.3.91.980624111838.23442D-100000@is>
Precedence: bulk

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
 
> On Tue, 23 Jun 1998, Salvador Eduardo Tropea (SET) wrote:
> 
> > > Just set LFN=n before running makeinfo, and it will generate 8+3 names 
> > > automagically.
> > 
> > Yes but they can't be compressed because makeinfo generates:
> > 
> > intinfo.100
> > intinfo.101
> > 
> > and gzip names both as intinfo.10z, that's why the converter must do
> > some extra work.
> 
> I don't think that would be necessary.  This should do the job:
> 
> 	set LFN=n
> 	makeinfo -o intinfo int2texi.txi
> 
> (Alternatively, use the "@setfilename intinfo" command at the beginning 
> of the converted Texinfo file.)
> 
> This causes makeinfo to NOT use the .info extension and instead produce
> intinf-1, intinf-2, ..., intin-99, inti-100, etc.  And then you compress
> them into intinf-1.gz etc., which info.exe should grok.  If that doesn't
> work, it's a bug in makeinfo or in info, so please tell me. 

It seems to work OK, I never noticed this feature.
 
> > But I sent to Magico a code that converts the names to:
> > intin100.inz, intin101.inz, etc and fixes the indirect table of the
> > first info file.
> 
> I don't think such work-arounds should be necessary when makeinfo
> has a way of creating usable files by itself.

Well, files called xxxxx.i1, etc are usable. I can't see a bug here, that why I 
never asked about it.
 
> I would also suggest to ask questions about such problems here before
> you decide that a given problem needs such work-arounds.  It might be
> that a solution is already available, or that there's a bug in the
> ported package that should be corrected.
 
Perhaps you are right but:
1) My work around was faster than asking ;-)
2) The compression step was needed, so renaming files and patching the table 
wasn't a big deal.

SET 
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013