Jean-Marc Lasgouttes wrote:
Angus Hmmm. I don't think I am suggesting 'too smart'. I'm suggesting
Angus that we augment these tokens understood by the converters
Angus string const token_from($$i); string const
Angus token_base($$b); string const token_to($$o); string const
Angus
Angus Leeming wrote:
I therefore suggest a new token '$$orig_i', being the name of the original
file from which '$$i' was copied into the temp directory. Ok?
For me, yes.
Now, Georg, could you expand on your ideas for when this magic should and
should not be invoked? I'm afraid I don't see
Georg Baum wrote:
Angus Leeming wrote:
I therefore suggest a new token '$$orig_i', being the name of the
original file from which '$$i' was copied into the temp directory. Ok?
For me, yes.
Now, Georg, could you expand on your ideas for when this magic should
and should not be invoked?
Angus Leeming wrote:
Let me try and get my head around the various possibilities. Let's store
the .fig file in the lyx document as 'images/img1.fig'. In turn, this .fig
file references 'raw.eps', so the path to 'raw.eps' from the document
directory is 'images/raw.eps' and the absolute path is
Georg Baum wrote:
Angus Leeming wrote:
Let me try and get my head around the various possibilities. Let's store
the .fig file in the lyx document as 'images/img1.fig'. In turn, this
.fig file references 'raw.eps', so the path to 'raw.eps' from the
document directory is 'images/raw.eps' and
Angus Leeming wrote:
Georg Baum wrote:
Angus Leeming wrote:
2. Export-Latex
buffer.tex will include the snippet:
\input{images/img.pstex_t}
It is the user's responsibility to generate 'images/img.pstex_t'
correctly.
No. This is 1.3 behaviour, 1.4 creates
Georg Baum wrote:
Angus Leeming wrote:
Georg Baum wrote:
Angus Leeming wrote:
2. Export-Latex
buffer.tex will include the snippet:
\input{images/img.pstex_t}
It is the user's responsibility to generate 'images/img.pstex_t'
correctly.
No. This is 1.3 behaviour, 1.4
Am Donnerstag, 21. Oktober 2004 20:38 schrieb Angus Leeming:
Georg Baum wrote:
Angus Leeming wrote:
Georg Baum wrote:
No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and
'images/img.eps.' This is alo a case where the converter is called
on
the original file and
Jean-Marc Lasgouttes wrote:
> Angus> Hmmm. I don't think I am suggesting 'too smart'. I'm suggesting
> Angus> that we augment these tokens understood by the converters
>
> Angus> string const token_from("$$i"); string const
> Angus> token_base("$$b"); string const token_to("$$o"); string
Angus Leeming wrote:
> I therefore suggest a new token '$$orig_i', being the name of the original
> file from which '$$i' was copied into the temp directory. Ok?
For me, yes.
> Now, Georg, could you expand on your ideas for when this magic should and
> should not be invoked? I'm afraid I don't
Georg Baum wrote:
> Angus Leeming wrote:
>
>> I therefore suggest a new token '$$orig_i', being the name of the
>> original file from which '$$i' was copied into the temp directory. Ok?
>
> For me, yes.
>
>> Now, Georg, could you expand on your ideas for when this magic should
>> and should
Angus Leeming wrote:
> Let me try and get my head around the various possibilities. Let's store
> the .fig file in the lyx document as 'images/img1.fig'. In turn, this .fig
> file references 'raw.eps', so the path to 'raw.eps' from the document
> directory is 'images/raw.eps' and the absolute
Georg Baum wrote:
> Angus Leeming wrote:
>
>> Let me try and get my head around the various possibilities. Let's store
>> the .fig file in the lyx document as 'images/img1.fig'. In turn, this
>> .fig file references 'raw.eps', so the path to 'raw.eps' from the
>> document directory is
Angus Leeming wrote:
> Georg Baum wrote:
>
>> Angus Leeming wrote:
>>> 2. Export->Latex
>>> buffer.tex will include the snippet:
>>> \input{images/img.pstex_t}
>>> It is the user's responsibility to generate 'images/img.pstex_t'
>>> correctly.
>>
>> No. This is 1.3 behaviour,
Georg Baum wrote:
> Angus Leeming wrote:
>
>> Georg Baum wrote:
>>
>>> Angus Leeming wrote:
2. Export->Latex
buffer.tex will include the snippet:
\input{images/img.pstex_t}
It is the user's responsibility to generate 'images/img.pstex_t'
correctly.
>>>
Am Donnerstag, 21. Oktober 2004 20:38 schrieb Angus Leeming:
> Georg Baum wrote:
>
> > Angus Leeming wrote:
> >
> >> Georg Baum wrote:
> >>
> >>> No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and
> >>> 'images/img.eps.' This is alo a case where the converter is called
on
> >>>
What to do if the XFig picture *includes* an EPS figure? Our new,
improved handling of the conversion of such XFig files to EPS,PSTEX_T
in the tmp directory doesn't work as it did in LyX 1.3.x, because the
included EPS figure is not moved.
One solution is to reference the EPS figure in the
Angus Leeming [EMAIL PROTECTED] writes:
What to do if the XFig picture *includes* an EPS figure? Our new,
improved handling of the conversion of such XFig files to EPS,PSTEX_T
in the tmp directory doesn't work as it did in LyX 1.3.x, because the
included EPS figure is not moved.
...
If
Andreas Vox wrote:
Angus Leeming [EMAIL PROTECTED] writes:
What to do if the XFig picture *includes* an EPS figure? Our new,
improved handling of the conversion of such XFig files to
EPS,PSTEX_T in the tmp directory doesn't work as it did in LyX
1.3.x, because the included EPS
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Is such a strategy possible? Thoughts?
Andreas Looks like this is getting a mess. This looks as if LyX has
Andreas to outsmart all possible converters ...
Yes, I really think we should not try to be too smart (and I am guilty
of that
Jean-Marc Lasgouttes wrote:
Andreas Is such a strategy possible? Thoughts?
Andreas Looks like this is getting a mess. This looks as if LyX has
Andreas to outsmart all possible converters ...
Yes, I really think we should not try to be too smart (and I am
guilty of that sometimes).
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote:
Andreas Is such a strategy possible? Thoughts?
Andreas Looks like this is getting a mess. This looks as if LyX has
Andreas to outsmart all possible converters ...
Yes, I really think we should not try to be
Angus Leeming [EMAIL PROTECTED] writes:
Alternative A)
Leave the xfig file where it is and force all converters to
understand a '-d' flag for the output directory.
Nope. Bad idea for all sorts of reasons. The main one being that you
are using the directory in which your important files
Andreas Vox wrote:
Angus Leeming [EMAIL PROTECTED] writes:
Alternative A)
Leave the xfig file where it is and force all converters to
understand a '-d' flag for the output directory.
Nope. Bad idea for all sorts of reasons. The main one being that
you are using the directory in
Jean-Marc Lasgouttes wrote:
Angus Hmmm. I don't think I am suggesting 'too smart'. I'm
suggesting Angus that we augment these tokens understood by the
converters
Angus string const token_from($$i); string const
Angus token_base($$b); string const token_to($$o); string const
Angus
Am Dienstag, 19. Oktober 2004 13:56 schrieb Angus Leeming:
What to do if the XFig picture *includes* an EPS figure? Our new,
improved handling of the conversion of such XFig files to EPS,PSTEX_T
in the tmp directory doesn't work as it did in LyX 1.3.x, because the
included EPS figure is not
Georg Baum wrote:
Is such a strategy possible? Thoughts?
As I understand it, this means that fig2pstex.sh, which is supposed to
convert from fig to pstex, modifies its input. I don't like that. Please
enlighten me if this is a misunderstanding.
No, you understand right. The alternative is
What to do if the XFig picture *includes* an EPS figure? Our new,
improved handling of the conversion of such XFig files to EPS,PSTEX_T
in the tmp directory doesn't work as it did in LyX 1.3.x, because the
included EPS figure is not moved.
One solution is to reference the EPS figure in the
Angus Leeming <[EMAIL PROTECTED]> writes:
< What to do if the XFig picture *includes* an EPS figure? Our new,
< improved handling of the conversion of such XFig files to EPS,PSTEX_T
< in the tmp directory doesn't work as it did in LyX 1.3.x, because the
< included EPS figure is not moved.
Andreas Vox wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> < What to do if the XFig picture *includes* an EPS figure? Our new,
> < improved handling of the conversion of such XFig files to
> EPS,PSTEX_T < in the tmp directory doesn't work as it did in LyX
> 1.3.x, because the <
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> < Is such a strategy possible? Thoughts?
Andreas> Looks like this is getting a mess. This looks as if LyX has
Andreas> to outsmart all possible converters ...
Yes, I really think we should not try to be too smart (and I am
Jean-Marc Lasgouttes wrote:
> Andreas> < Is such a strategy possible? Thoughts?
>
> Andreas> Looks like this is getting a mess. This looks as if LyX has
> Andreas> to outsmart all possible converters ...
>
> Yes, I really think we should not try to be too smart (and I am
> guilty of that
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
Andreas> < Is such a strategy possible? Thoughts?
>>
Andreas> Looks like this is getting a mess. This looks as if LyX has
Andreas> to outsmart all possible converters ...
>> Yes, I really think we
Angus Leeming <[EMAIL PROTECTED]> writes:
< > Alternative A)
< > Leave the xfig file where it is and force all converters to
< > understand a '-d' flag for the output directory.
<
< Nope. Bad idea for all sorts of reasons. The main one being that you
< are using the directory in which your
Andreas Vox wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> < > Alternative A)
> < > Leave the xfig file where it is and force all converters to
> < > understand a '-d' flag for the output directory.
> <
> < Nope. Bad idea for all sorts of reasons. The main one being that
> you < are
Jean-Marc Lasgouttes wrote:
> Angus> Hmmm. I don't think I am suggesting 'too smart'. I'm
> suggesting Angus> that we augment these tokens understood by the
> converters
>
> Angus> string const token_from("$$i"); string const
> Angus> token_base("$$b"); string const token_to("$$o");
Am Dienstag, 19. Oktober 2004 13:56 schrieb Angus Leeming:
> What to do if the XFig picture *includes* an EPS figure? Our new,
> improved handling of the conversion of such XFig files to EPS,PSTEX_T
> in the tmp directory doesn't work as it did in LyX 1.3.x, because the
> included EPS figure is
Georg Baum wrote:
>> Is such a strategy possible? Thoughts?
>
> As I understand it, this means that fig2pstex.sh, which is supposed to
> convert from fig to pstex, modifies its input. I don't like that. Please
> enlighten me if this is a misunderstanding.
No, you understand right. The
38 matches
Mail list logo
