Paul A. Rubin wrote: > John, > > John Pye wrote: >>> Works fine for me here. Keep in mind that there are at least three >>> PDF file formats defined within LyX, because different compilation >>> methods (ps2pdf, pdflatex, dvipdfm) have different requirements. On >>> my box those are designated pdf, pdf2 and pdf3 respectively, and I'm >>> pretty sure that's standard across installations. If you create a >>> converter from DOT to pdf3, say, and then use View -> PDF (pdflatex) >>> to see the output (which is creating pdf2 output), presumably >>> something will break. >> >> I tried this many times but no success. I am aware of the pdflatex (etc) >> issue. It is not called 'pdf3' on my system, it is called 'PDF >> (pdflatex)'. > > Should be both: in Tools -> Preferences -> File formats, if I > highlight 'PDF (pdflatex)', that's the entry in the 'GUI name', while > the entry in 'Format' is pdf2. FWIW, if you want to do a file export > from the command line, you use pdf2 as the argument to the export > flag. Shouldn't have anything to do with the converter working or not, > though, so long as the converter entry points to the right output GUI > name. > >> That is the standard on Fedora and Ubuntu systems, if not >> elsewhere, so I don't think you're right about 'pdf3' etc. >> >> This converter system is way too delicate IMHO: if you get it wrong, you >> get minimal and rather cryptic error messages. > > I tend to agree here, to the extent that if LyX gets an error message > from an external command, it should forward it to the user. I don't > think that's always the case, though. I suspect that sometimes LyX > runs an external process and the child process exits with a nonzero > error code but not much else. LyX can't tell you what it doesn't know > (i.e., LyX is not an academic). > >> It's also impossible for >> someone to help to diagnose a problem, because you can't just "sent me >> your config file" (AFAIK) and you can't tell what stuff is different on >> my system compared to your system. > > Actually, you can send a piece of an appropriate config file. In your > LyX home directory, there's a file named 'preferences'. It should > contain a line defining the DOT file type and additional lines for > each related converter you added. Mine read as follows: > > \format "dot" "dot" "Dot" "" "auto" "auto" "vector" > \converter "dot" "pdf2" "dot -Tpdf $$i -o $$o" "" > > Note that this is exactly what I entered in the "all-powerful GUI". :-) > >> FWIW, I think that rather than an all-powerful GUI for editing >> converters, file formats, etc, these things should be stored in flat >> platform-specific configuration files that can be packaged for >> distribution as 'plugins' eg a set of LyX configuration files + linux >> package dependences = support for Graphviz in LyX. This would take the >> voodoo out of the job of getting LyX working with various different file >> formats, and allow end-users to make use of *the tools they know >> already* in order to get extra features working with LyX. I say this, >> but I'm not going to come and help, so you best ignore me here :-) >> > > Well, it would not be hard for someone to provide a patch file that > one could apply to the preferences file. The user would have to know > how to merge in a patch file (or else LyX would have to provide a > patch merge utility). Unfortunately, these things are not entirely > one-size-fits-all, even within operating systems. For instance, my > converter above works because I have the dot executable on my system > command path. Otherwise I need to provide the path to it someplace -- > which means your plug-in installer needs to detect the location of dot > on my system, or else open up a dialog and ask me to locate it.
I think that that is the wrong approach. It is the job of the person writing the plugin to specify the correct location for 'dot' or whatever else. LyX should not take on the job of going out and finding all the necessary tools.= The usual solution for this problem is to provide a '#include' type functionality for configuration files. For example, in the case of Apache on Fedora you have /etc/httpd/conf/httpd.conf which contains: > # > # Load config files from the config directory "/etc/httpd/conf/conf.d". > # > Include conf.d/*.conf This mechanism allows external packages to drop files in the /etc/httpd/conf.d directory as required, to add new behaviour to Apache. This means that package managers are not required to *patch* files already installed in the system, which is always a bad idea (how to safely un-patch the file if it has been modified since originally being patched?) http://httpd.apache.org/docs/1.3/mod/core.html#include Another approach is that of Gedit, which has a little file format *.gedit-plugin. Any files having this extension contained in /usr/lib/gedit-2/plugins/, or in ~/.gnome2/gedit/plugins/ are loaded and run when gedit starts, allowing the loaded code to add functionality of Gedit via a particular plugin API. http://live.gnome.org/Gedit/PythonPluginHowTo#head-09e0d6a68df136e82b89fd8a4d340c5439ccbfc1 A similar system could be used for configuration of LyX. The advantage here is that platform specific stuff can be done by the packagers. For example, on Ubuntu, you know that if you install the package 'graphviz' then the program 'dot' will be installed in a standard location on PATH. So it's just a question of creating a package that contains a file in /etc/lyx/conf.d/graphviz.dot with dependencies on the Ubuntu 'graphviz' package (so that installing the lyx-plugin-graphviz' package forces the system to first install graphviz). This approach allows Linux (Ubuntu, Fedora, SUSE, etc) release engineers to do all the platform-specific stuff in a safe way, while still permitting user customisation as well. Note that there might also need to be some kind of 'lyx-reconfigure' program provided, as well. All of this would also work fine with Fink on Mac, if desired. This only leaves Windows as a bit of a special case, with its lack of a proper package manager. > > If the converter entries above don't work on your system, it's > possible that either LyX (more precisely, the child shell it spawns) > can't find the dot executable or else lacks permission to run it. Try > the following. Open a LyX doc with a dot image embedded and try View > -> PDF (pdflatex), which I gather will fail silently. With LyX still > running, open a terminal and navigate to the LyX temporary directory. > Verify that a copy of the DOT file sits there, probably with the name > mangled by LyX. Assuming so, run the converter from the terminal, > using exactly the syntax of your converter entry (but substituting the > mangled file name for $$i and the same name with a pdf extension for > $$o). In my case that means 'dot -Tpdf <mangled name>.dot -o <mangled > name>.pdf'. If it fails, maybe you'll get a helpful error message in > the terminal window. It is not the problem that LyX can't access the dot executable, because when I create a converter for DOT->PNG everything works perfectly. Problems arise when I set DOT to be a vector format and create only the DOT->PDF (pdflatex) converter. In this case, I get a blank two-page document, instead of the one-page document containing a Graphviz diagram that I get with DOT->PNG. I will try again and see what is appearing in the temp dir, if anything. Cheers JP
