You are not bypassing the latex bundle, you are simply indicating to the latex bundle what "engine" you want it to use to do the compiling, just as for instance you can tell it to use latexmk.pl instead of plain pdflatex. texMate.py will still be utilized, and the compilation window produced. All that changes is that your custom shell script is called under the hood instead of pdflatex, and that script does what is required of it.

I think Brad's reluctance stems from the fact that there are hundreds of tex packages, and we'd rather not implement a special compilation process for each of them within texMate.py, unless it is something that would benefit a large number of users. For instance this is why we support pstricks. I've lost the beginning of this thread, but is this pst-pdf to be treated just as if pstricks had been included, or is it a whole new beast requiring a new set of compiling directives? If it is the latter, then a better approach would be to get those directives incorporated in latexmk.pl for instance, in which case you would want to contact the author of that program. Since latexmk.pl specializes in performing all steps necessary to a latex file to produce a final output, it would fall much more naturally under its responsibilities, and then this would benefit people not using TextMate as well.

Haris

On Nov 14, 2008, at 12:06 AM, Denilson Barbosa wrote:

Thanks for the reply. As a quickfix this would alleviate the immediate problem, but create another, much worse: By bypassing the actual latex bundle (I mean, the compilation routines in texMate.py) one loses all of its functionality, including the compilation window that shows the nice summary of what happened during the execution of (pdf)latex. Among other things, you'd have to look into the .log file yourself to find any errors in your source files, defeating the purpose of using textmate instead of the command line to run (pdf)latex.

Handling pst-pdf could be easily implemented in a nice and elegant way inside the bundle. This would be a simple addition to run_latex (if I recall correctly the function name) in texMate.py to check if pst-pdf is included in the master file. Similar checks are made there for many packages already (including pstricks), so that different settings can be used when calling (pdf)latex. I can't see pst-pdf being any different.

If implemented in this way, one would get back the nice results shown in the compilation window, which is produced by the procedure that parses the output produced by (pdf)latex. The parsing step could be done just on the final call to pdflatex on the main file.

This seems easy enough to do for those who maintain the bundle. Not so for the majority of people who use it, including me. Being python illiterate I could only roughly understand what the bundle does, but not make this change.

Denilson.

On Thu, Nov 13, 2008 at 2:23 PM, Brad Miller millbr02@luther.edu wrote:

...

I am curious to know how many people such an extension would benefit. I think one of the nice things about the Bundle as it stands now is that it does the things that the majority of people want pretty well. And... it is extensible enough for cases like this to be handled elegantly by the user. For example: These lines could be re-written placed in a script file in your home directory somewhere: latex <file.tex> dvips -Ppdf -o <file-pics.ps> <file.dvi> ps2pdf -dAutoRotatePages=/None <file-pics.ps> <file-pics.pdf> pdflatex <file.tex>

The lines above would need to be re-written to use the TM_FILENAME environment variable as follows: #!/bin/bash filebase=`basename -s .tex ${TM_FILENAME} latex ${TM_FILENAME} dvips- -Ppdf -o $filebase-pics.ps $filebase.dvi ps2pdf -dAutoRotatePages=/None $filebase-pics.ps $filebase-pics.pdf pdflatex ${TM_FILENAME} rm $filebase-pics.ps

Now, at the top of your latex file you can put the line: %!TEX TS-program = /path/to/my/script From now on the LaTeX bundle will use your script to typeset your file. Because the script is written using TM_FILENAME it will work for any files you want to do this with. If this is a common case, then I think it would be good to add to the Bundle directly but if this is something only used by 1 or 2 people then I think the solution above is the way to go. Brad

...

Thanks

Denilson

-- Brad Miller Assistant Professor, Computer Science Luther College --

Denilson Barbosa

Haris Skiadas Department of Mathematics and Computer Science Hanover College

On Nov 17, 2008, at 4:02 AM, enas wrote:

I shall take advantage of this thread to report a little bug that I never bothered reporting, thinking I was the only one to play with that.

So, an even more elegant way to include pstricks commands using pdflatex is by using the pdftricks package.

This works in the following way:

• You include the pdftricks package

• You include, in the preambule, the following

\begin{psinputs} ... \end{psinputs}

where ... contains all the includes of your pstricks figures (most notably, you include there the pstricks package).

• enclose any pspictures into a pdfpic environment

• run pdflatex with the -shell-escape option. The pdftricks package

will take care of converting the content of each pdfpic environment to an eps and then pdf, then include the result in the running document, which is then processed as usual with pdflatex.

Personally, that option is the perfect one when I have to deal with pstricks (not a heavy user though).

The problem is that I cannot get TextMate to compile with pdflatex, even when pdflatex is specified as engine. I'm not asking for any special compilation process, just want to use the regular pdflatex engine (that's the whole point). The thing is that the LaTeX bundle scans the included packages, finds in the \begin{psinputs}... \end{psinputs} part a call to the pstricks package, and then switches automatically to the latex engine (that's how I understood it anyway).

I consider that to be bad behaviour, because that package is not actually loaded. For example (I didn't try), I guess the current state of the package would fail with a LaTeX file that contains code to conditionally load packages depending on the engine used (\ifpdf ... \else ... \fi). I think we should let the user the responsibility to chose his engine, and then stick to it.

We are probably being too smart for our own good on this one, but I don't see another easy way to go about it, unless we decide not to try to detect the need for the dvips route.

Note that you can always dictate which engine you want TextMate to use by a directive such as the following at the top of the file:

%!TEX TS-program = pdflatex

If you just add this as your first line, then TextMate should be using pdflatex for the compilation. Does that fix your problem?

Haris

Best wishes,

enas

On 14 Nov 2008, at 11:53, Charilaos Skiadas wrote:

...

You are not bypassing the latex bundle, you are simply indicating to the latex bundle what "engine" you want it to use to do the compiling, just as for instance you can tell it to use latexmk.pl instead of plain pdflatex. texMate.py will still be utilized, and the compilation window produced. All that changes is that your custom shell script is called under the hood instead of pdflatex, and that script does what is required of it.

I think Brad's reluctance stems from the fact that there are hundreds of tex packages, and we'd rather not implement a special compilation process for each of them within texMate.py, unless it is something that would benefit a large number of users. For instance this is why we support pstricks. I've lost the beginning of this thread, but is this pst-pdf to be treated just as if pstricks had been included, or is it a whole new beast requiring a new set of compiling directives? If it is the latter, then a better approach would be to get those directives incorporated in latexmk.pl for instance, in which case you would want to contact the author of that program. Since latexmk.pl specializes in performing all steps necessary to a latex file to produce a final output, it would fall much more naturally under its responsibilities, and then this would benefit people not using TextMate as well.

Haris

On Nov 14, 2008, at 12:06 AM, Denilson Barbosa wrote:

...

Thanks for the reply. As a quickfix this would alleviate the immediate problem, but create another, much worse: By bypassing the actual latex bundle (I mean, the compilation routines in texMate.py) one loses all of its functionality, including the compilation window that shows the nice summary of what happened during the execution of (pdf)latex. Among other things, you'd have to look into the .log file yourself to find any errors in your source files, defeating the purpose of using textmate instead of the command line to run (pdf)latex.

Handling pst-pdf could be easily implemented in a nice and elegant way inside the bundle. This would be a simple addition to run_latex (if I recall correctly the function name) in texMate.py to check if pst- pdf is included in the master file. Similar checks are made there for many packages already (including pstricks), so that different settings can be used when calling (pdf)latex. I can't see pst-pdf being any different.

If implemented in this way, one would get back the nice results shown in the compilation window, which is produced by the procedure that parses the output produced by (pdf)latex. The parsing step could be done just on the final call to pdflatex on the main file.

This seems easy enough to do for those who maintain the bundle. Not so for the majority of people who use it, including me. Being python illiterate I could only roughly understand what the bundle does, but not make this change.

Denilson.

On Thu, Nov 13, 2008 at 2:23 PM, Brad Miller millbr02@luther.edu wrote:

...

I am curious to know how many people such an extension would benefit. I think one of the nice things about the Bundle as it stands now is that it does the things that the majority of people want pretty well. And... it is extensible enough for cases like this to be handled elegantly by the user. For example: These lines could be re-written placed in a script file in your home directory somewhere: latex <file.tex> dvips -Ppdf -o <file-pics.ps> <file.dvi> ps2pdf -dAutoRotatePages=/None <file-pics.ps> <file-pics.pdf> pdflatex <file.tex>

The lines above would need to be re-written to use the TM_FILENAME environment variable as follows: #!/bin/bash filebase=`basename -s .tex ${TM_FILENAME} latex ${TM_FILENAME} dvips- -Ppdf -o $filebase-pics.ps $filebase.dvi ps2pdf -dAutoRotatePages=/None $filebase-pics.ps $filebase-pics.pdf pdflatex ${TM_FILENAME} rm $filebase-pics.ps

Now, at the top of your latex file you can put the line: %!TEX TS-program = /path/to/my/script From now on the LaTeX bundle will use your script to typeset your file. Because the script is written using TM_FILENAME it will work for any files you want to do this with. If this is a common case, then I think it would be good to add to the Bundle directly but if this is something only used by 1 or 2 people then I think the solution above is the way to go. Brad

...

Thanks

Denilson

-- Brad Miller Assistant Professor, Computer Science Luther College --

Denilson Barbosa

Haris Skiadas Department of Mathematics and Computer Science Hanover College

Haris Skiadas Department of Mathematics and Computer Science Hanover College