January 2010 - ntg-pdftex - NTG Mailing Lists

About SyncTeX and output-directory option
by Jérome Laurens 26 Jan '10

26 Jan '10

Hi fellows, I have just subscribed to the list in order to give, as the SyncTeX developer, more informations about the question raised earlier by Martin Reinders titled "...SyncTeX and output-directory option" and brought to my attention by Karl Berry. (BTW, sorry for breaking the message thread) As noticed by Martin, since TeXLive 09 the .synctex file is always created in the same directory as the pdf output. This is the only way to tell a pdf viewer that there exists some synctex information around. But, as pointed out in Martin's mail, the problem is that all the input file names are recorded relative to the current directory according to pdftex, which is not the current directory according to the pdf viewer. The consequence is that the relative file names recorded in the .synctex file are broken and useless if we do not know the original input directory. We can consider that this is a limitation in synctex code. However, this is (partly) intentional due to the following reasons 1) I don't know for sure how to deal with paths in a OS independent way (actually synctex code already contain parts dedicated to windows OS) 2) I have not made my mind on how to manage this problem properly 3) There is a poor man's workaround implemented in frontends like iTeXMac2 AFAIR Martin proposed to apply a post processing perl script to change in the .synctex.gz file the relative paths to the "appropriate" values. Unfortunately, this breaks forwards synchronization and will certainly break backwards synchronization too if we further move the pdf output file and its synctex.gz companion to another directory. So this solution is not satisfying. Let me explain what is point 3) above when the main input file is main.tex First we can assume that output-directory is - by pdftex design - a subdirectory of the folder containing main.tex If the full path of the output file is /foo/bar/main.pdf, then synchronization from view to source may work as follow if /foo/bar/main.tex exists then assume that all relative input file names in the .synctex file are relative to /foo/bar else if /foo/main.tex exists then assume that all relative input file names in the .synctex file are relative to /foo else if /main.tex exists then assume that all relative input file names in the .synctex file are relative to / else no synchronization info is available No need to modify the .synctex file, this will solve -in general- the problem when implemented in the synctex aware pdf/dvi viewer. BTW, I tend to use "Factory" as output directory name: pdflatex --output-directory "Factory" main.tex Adopting such a rule would render document sharing more friendly: frontends could use something like if there exists a "Factory" folder then pdflatex --output-directory "Factory" main.tex else pdflatex --whatsover main.tex Also, when trying to synchronize forward from ./main.tex, a front could do something like if ./main.pdf exists use if else if ./Factory/main.pdf exists use it else no forward synchronization is available Moreover, when intermediate tools are used to create input material, like for example graphic charts form statistical data, the graphic file can go to this Factory folder such that the front end just has to launch pdflatex --output-directory "Factory" --input-directory "Factory" main.tex In short, my suggestion would be to somehow hard code "Factory" (or any appropriate name) as output directory name. regards Jerome Laurens, temporarily listening to pdftex

6 5

[pdftex-Bugs][4302] transparency bug: missing /ExtGState in Resources of Form XObject
by pdftex-bugs＠sarovar.org 20 Jan '10

20 Jan '10

Bugs item #4302, was opened at 2010-01-18 16:32 >Status: Closed Priority: 3 Submitted By: Alexander Grahn (grahn) Assigned to: Nobody (None) Summary: transparency bug: missing /ExtGState in Resources of Form XObject Category: None Group: None >Resolution: Invalid Initial Comment: In the attached example a Form XObject is created from a savebox containing transparent objects. The Form XObject is later used by \pdfrefxform\pdflastxform. When loaded in AR-7, the resulting PDF cannot be displayed but causes the error message: Could not find the Extended Graphics State named 'pgf(a)CA0.5'. (AR-7 is more verbose with regard to PDF errors.) The reason is that the XObject produced is broken. At some point in the content stream of the XObject, the graphics state is modified to set the transparency of subsequent fills and strokes: /pgf(a)CA0.5 gs /pgf(a)ca0.5 gs Although the operands pgf(a)CA0.5 and pgf(a)ca0.5 are defined in an ExtGState Dictionary as 1 0 obj << /pgf(a)CA0.5 << /CA 0.5 >> /pgf(a)ca0.5 << /ca 0.5 >>>> endobj the corresponding /ExtGState key is missing in the Resources dictionary of the XObject. Instead, it is put to the Resources dictionary of the Page object. But there it is useless, because it is not used in the content stream of the page. pdfTeX-Version: 1.40.10 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-01-20 09:46 Message: thanks for confirming. ---------------------------------------------------------------------- Comment By: Alexander Grahn (grahn) Date: 2010-01-20 09:44 Message: After all, it is not a pdftex bug. I found out that PGF/TikZ adds resources such as /ExtGState and /Pattern, used in the graphics, to the /Resources dict of the /Page object. In order to make such resources accessible to the graphics encapsulated in a Form XObject too, one has to once more add a reference to the /Resources dict, this time to the Form XObject to be created, by means of the `resources {...}' argument of \pdfxform. See the attached example file `transs_ok.tex'. I think this bug can be closed. Sorry for the noise. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0

[pdftex-Bugs][4302] transparency bug: missing /ExtGState in Resources of Form XObject
by pdftex-bugs＠sarovar.org 20 Jan '10

20 Jan '10

Bugs item #4302, was opened at 2010-01-18 17:32 Status: Open Priority: 3 Submitted By: Alexander Grahn (grahn) Assigned to: Nobody (None) Summary: transparency bug: missing /ExtGState in Resources of Form XObject Category: None Group: None Resolution: None Initial Comment: In the attached example a Form XObject is created from a savebox containing transparent objects. The Form XObject is later used by \pdfrefxform\pdflastxform. When loaded in AR-7, the resulting PDF cannot be displayed but causes the error message: Could not find the Extended Graphics State named 'pgf(a)CA0.5'. (AR-7 is more verbose with regard to PDF errors.) The reason is that the XObject produced is broken. At some point in the content stream of the XObject, the graphics state is modified to set the transparency of subsequent fills and strokes: /pgf(a)CA0.5 gs /pgf(a)ca0.5 gs Although the operands pgf(a)CA0.5 and pgf(a)ca0.5 are defined in an ExtGState Dictionary as 1 0 obj << /pgf(a)CA0.5 << /CA 0.5 >> /pgf(a)ca0.5 << /ca 0.5 >>>> endobj the corresponding /ExtGState key is missing in the Resources dictionary of the XObject. Instead, it is put to the Resources dictionary of the Page object. But there it is useless, because it is not used in the content stream of the page. pdfTeX-Version: 1.40.10 ---------------------------------------------------------------------- Comment By: Alexander Grahn (grahn) Date: 2010-01-20 10:44 Message: After all, it is not a pdftex bug. I found out that PGF/TikZ adds resources such as /ExtGState and /Pattern, used in the graphics, to the /Resources dict of the /Page object. In order to make such resources accessible to the graphics encapsulated in a Form XObject too, one has to once more add a reference to the /Resources dict, this time to the Form XObject to be created, by means of the `resources {...}' argument of \pdfxform. See the attached example file `transs_ok.tex'. I think this bug can be closed. Sorry for the noise. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0

[pdftex-Bugs][4302] transparency bug: missing /ExtGState in Resources of Form XObject
by pdftex-bugs＠sarovar.org 18 Jan '10

18 Jan '10

Bugs item #4302, was opened at 2010-01-18 17:32 Status: Open Priority: 3 Submitted By: Alexander Grahn (grahn) Assigned to: Nobody (None) Summary: transparency bug: missing /ExtGState in Resources of Form XObject Category: None Group: None Resolution: None Initial Comment: In the attached example a Form XObject is created from a savebox containing transparent objects. The Form XObject is later used by \pdfrefxform\pdflastxform. When loaded in AR-7, the resulting PDF cannot be displayed but causes the error message: Could not find the Extended Graphics State named 'pgf(a)CA0.5'. (AR-7 is more verbose with regard to PDF errors.) The reason is that the XObject produced is broken. At some point in the content stream of the XObject, the graphics state is modified to set the transparency of subsequent fills and strokes: /pgf(a)CA0.5 gs /pgf(a)ca0.5 gs Although the operands pgf(a)CA0.5 and pgf(a)ca0.5 are defined in an ExtGState Dictionary as 1 0 obj << /pgf(a)CA0.5 << /CA 0.5 >> /pgf(a)ca0.5 << /ca 0.5 >>>> endobj the corresponding /ExtGState key is missing in the Resources dictionary of the XObject. Instead, it is put to the Resources dictionary of the Page object. But there it is useless, because it is not used in the content stream of the page. pdfTeX-Version: 1.40.10 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4302&group_id=106

1 0