Il 13/09/2011 14:43, Richard Heck ha scritto:
On 09/12/2011 07:52 PM, Tommaso Cucinotta wrote:
-bool Buffer::doExport(string const& format, bool put_in_tempdir,
- bool includeall, string& result_file) const
+bool Buffer::doExport(string const& target, bool put_in_tempdir,
+ bool includeall, string& result_file) const
And here, I guess I'd prefer a function that took the format and
destination as arguments, where the latter might be empty. Then
doExport can be called one way from LFUN_BUFFER_EXPORT and a different
way (with the destination) from LFUN_BUFFER_EXPORT_AS.
In case I add a new LFUN, calling a new method with a different
prototype (one more argument, i.e., the destination filename or folder),
then how would that plug into the machinery that I see in GuiView.cpp
(L3147) ?
d.asyncBufferProcessing(argument,
doc_buffer,
_("Exporting ..."),
&GuiViewPrivate::exportAndDestroy,
&Buffer::doExport,
0);
- string filename = latexName(false);
- filename = addName(temppath(), filename);
- filename = changeExtension(filename,
- formats.extension(backend_format));
+ if (filename.empty()) {
+ filename = latexName(false);
+ filename = addName(temppath(), filename);
+ filename = changeExtension(filename,
+ formats.extension(backend_format));
+ }
Is it worth setting the export_folder in this case, too, to the
document folder? That might allow for some simplifications elsewhere.
At least, one won't have to check if export_folder is empty and do
different things in the two cases.
I tried to not interfere with the original logic when no output folder
was set. One difference that I would see between the 2 cases (and which
might motivate keeping some distinction between the 2 cases) is due to
already existing image files. Say that you include a "graph.eps" in your
document. Now, when exporting to LaTeX without any export folder, the
file would already be there, i.e., no need to copy nor to complain
because it already exists. When we export to a different folder, we
should copy the file there. However, what should we do if the file
already exists ? Simply overwrite it ? Prompt the user ? Allow for
changing the file-name ? Fail the export ?
for (; it != en&& status != CANCEL; ++it) {
string const fmt = formats.getFormatFromFile(it->sourceName);
+ string fixedName = it->exportName;
+ while (fixedName.substr(0, 3) == "../")
+ fixedName = fixedName.substr(3, fixedName.length() - 3);
+ FileName fixedFileName = makeAbsPath(fixedName, dest);
+ fixedFileName.onlyPath().createPath();
vector<ExportedFile>::const_iterator const en = files.end();
Why are we stripping the "../"? Are we just throwing it away, or....?
I guess maybe a comment would be good.
That's tricky: I noticed EmbeddedObjects.lyx was referring to some files
with a path like "../images/whataever.png". The export of these was
failing because the code was using filetools.cpp:makeAbsPath(), which
unfortunately was unable to deal with such type of relative paths, as
pointed out in filetools.cpp:
// Note that basePath can be a relative path, in the sense that it may
// not begin with "/" (e.g.), but it should NOT contain such constructs
// as "/../".
// FIXME It might be nice if the code didn't simply assume that.
I just thought that, in these cases (relative paths going upwards in the
directory tree, as compared to the location of the .lyx which is being
exported), if we export to a given folder, then we could discard the
"../" part of the paths (which in other parts of the code comes up
encoded as a "\lyxdot \lyxdot /" for reasons that are outside of my
reach). For example, when exporting EmbeddedObjects.lyx to /tmp/, those
image files are copied to
/tmp/images/whatever.png, and not to /images/whatever.png.
However, I didn't think sufficiently about complex cases when we might
be exporting a complex set of .lyx documents with master/child
relationships, where perhaps some images of some children might be
located in a relative folder up the tree. For example:
master.lyx
images/diagram.eps
children/chapter1.lyx (referring to ../images/diagram.eps)
etc... Also, another question I have is what should we do with absolute
pathnames. If the original .lyx embeds a reference to an image by
absolute path, then should we create a copy of that image into the
destination folder ? Should we have another option controlling these
kind of details in the export process ?
+ runparams.exportdata->addExternalFile(tex_format, writefile,
+ exportfile);
case LISTINGS: {
Was this also a separate bug?
at a glance, I would say yes. And, I'm not sure whether in other cases
there might be some addExternalFile() calls missing there. What is a
simple test that I can do in order to explicitly detect whether this is
a bug in the current trunk ?
- latex_str += prepareFile(runparams);
+ string file_path = prepareFile(runparams);
+ if (!runparams.export_folder.empty()) {
+ /// Relative pathnames starting with ../ will be sanitized
+ /// if exporting to a different folder
+ while (file_path.substr(0, 17) == "\\lyxdot \\lyxdot /")
+ file_path = file_path.substr(17, file_path.length() -
17);
+ }
+ latex_str += file_path;
As a general matter, I wonder if this is worth doing anyway. It would
make what we export "portable", in some sense, wouldn't it?
yes, as explained above, the idea would be:
1) I export to a folder
2) I compress the folder
3) I send it to the publisher (e.g., if it wants latex sources).
The wonderful thing is that LyX already would put in the exported folder
only what I actually use and need, and for example for the images, it
would put only the finally produced .eps, and not the original .fig or
.odg or whatever image sources, etc.
However, for the issue of the relative paths, see my notes above.
This will be very nice to have.
Ok, then I'll try to rework it a little (let's try to commit the "well
cooked" feature). In the mean time, I would appreciate further comments
on the above issues.
Thanks,
T.
