Am Montag, 24. Mai 2004 13:52 schrieb Angus Leeming:
>
> No, it's a definite improvement over what we have. Shove it in.
I did extend it to cover the include inset as well. Now the external,
graphics and include inset write every file to the temp dir, and
Exporter::Export() copies the files and
Angus Leeming wrote:
> Georg Baum wrote:
>
>>
>> I think this is a clean solution. However, I don't like the way how
>> the file overwriting prevention works:
>>
>> - The "cancel" button is mislabelled: It does not cancel the export,
>> but does not copy the file. Any idea for a better name?
>>
Georg Baum wrote:
>
> I think this is a clean solution. However, I don't like the way how
> the file overwriting prevention works:
>
> - The "cancel" button is mislabelled: It does not cancel the export,
> but does not copy the file. Any idea for a better name?
> - There should be a fourth butto
Am Samstag, 15. Mai 2004 14:45 schrieb Georg Baum:
> The only clean
> solution that I can imagine is to introduce a switch in the external
> template that tells wether a file is "input like" or "includegraphics
> like", because the template is the only place where this is known. Any
> other ide
Angus Leeming wrote:
> Georg Baum wrote:
>
>> it does not need to be copied either. The only clean solution that I
>> can imagine is to introduce a switch in the external template that
>> tells wether a file is "input like" or "includegraphics like",
>> because the template is the only place wher
Georg Baum wrote:
> Am Montag, 10. Mai 2004 15:49 schrieb Angus Leeming:
>> > What do you think? Should I use the hack described above and
>> > collect the data in latex(), or should I do it in validate(), and
>> > how should I pass the files to Exporter::Export()?
>>
>> However you think it shou
The patch was incomplete, the missing bit is attached.
Georg
diff -p -r -U 4 -X excl.tmp lyx-1.4-clean/src/outputparams.h lyx-1.4-cvs/src/outputparams.h
--- lyx-1.4-clean/src/outputparams.h 2004-05-14 19:53:31.0 +0200
+++ lyx-1.4-cvs/src/outputparams.h 2004-05-14 18:27:49.0 +0200
@
Am Montag, 10. Mai 2004 15:49 schrieb Angus Leeming:
> > What do you think? Should I use the hack described above and collect
> > the data in latex(), or should I do it in validate(), and how should
> > I pass the files to Exporter::Export()?
>
> However you think it should be done best.
Here com
Lars Gullik Bjønnes wrote:
> | Yes, I do not really see what this
> | BufferList::updateIncludedTeXfiles does. Maybe lars knows...
>
> :-)
>
> Some old ugly code that I didn't write.
> The whole master - sub docs stuff sorely needs a rewrite.
> (next development round)
Actually, along these lin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Georg> Closer examination of the consequences showed that I would have
| Georg> to change a lot if I were to go this way. E. g. makeLaTeXFile
| Georg> is called by BufferList::updateIncludedTeXfiles (why is that
| Georg> needed? InsetInclude::late
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Mittwoch, 12. Mai 2004 15:02 schrieb Jean-Marc Lasgouttes:
>> > "Georg" == Georg Baum <[EMAIL PROTECTED]>
>> writes: I always thought that this prepareFile thing was ugly.
>> Isn't there some way to split it in two (compute the
Am Mittwoch, 12. Mai 2004 15:02 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
> I always thought that this prepareFile thing was ugly. Isn't there
> some way to split it in two (compute the name and do the conversions)?
One can use a stripped down version
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc suggested to collect the filenames in validate()
Georg> instead. Unfortunately this has also problems: We get the
Georg> filename in latex() as a byproduct. If we want it in
Georg> validate(), we have to duplicate the logic i
Am Montag, 10. Mai 2004 15:49 schrieb Angus Leeming:
> That said, I'm interested in how you see this all working in an ideal
> design. My picture of how this will work in the future is that we
> should separate the 'generation of the exported files' step from the
> 'export the latex to file' ste
> What do you think? Should I use the hack described above and collect
> the data in latex(), or should I do it in validate(), and how should
> I pass the files to Exporter::Export()?
However you think it should be done best.
That said, I'm interested in how you see this all working in an ideal
Currently, DVI export does not handle included graphics. They stay in the
temp dir and are deleted on exit, so the .dvi file is useless for documents
containing graphics. In order to change this, two steps are required:
1) Write relative graphics filenames in the .tex file. This is now trivial.
16 matches
Mail list logo
