local picture not found anymore
Having a file picture.jpg worked fine. Now it results in inclusion of "The picture package by Heiko Oberdiek". Suddenly file searching doesn't start with the current directory anymore but somewhere in the /tex-chain. Were the significant changes here? Something to do with Luatex? I didn't follow the developments for the last few months, so I may have missed an important change. Hans van der Meer
Found this one with a lucky guess.
The macro call \doiffile{picture} does find a usable picture file (I guess picture.pdf) in my tex-tree.
My conclusion would be that the search no longer starts in the current directory but does a global search first. That used to be different.
Why the change? My guess will be that Taco as Luatex's shepperd might shine some light here.
Hans van der Meer
On 4 feb. 2013, at 19:19, "H. van der Meer"
Having a file picture.jpg worked fine. Now it results in inclusion of "The picture package by Heiko Oberdiek". Suddenly file searching doesn't start with the current directory anymore but somewhere in the /tex-chain.
Were the significant changes here? Something to do with Luatex? I didn't follow the developments for the last few months, so I may have missed an important change.
Hans van der Meer
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
On Mon, Feb 4, 2013 at 7:52 PM, Meer H. van der wrote:
Found this one with a lucky guess. The macro call \doiffile{picture} does find a usable picture file (I guess picture.pdf) in my tex-tree. My conclusion would be that the search no longer starts in the current directory but does a global search first. That used to be different. Why the change?
I had a similar (yet unresolved) problem, see thread "ConTeXt inputs files from TEXMF/doc" from October 2012: http://thread.gmane.org/gmane.comp.tex.context/78692 I'm not sure if that was really a change, but it probably isn't intentionally so. My wild guess is that pdf takes precedence over jpg (ConTeXt would probably first test if picture.pdf is found and only if that one wouldn't be, it would try picture.png or jpg). In any case ConTeXt should not even search in doc folder for files to be included as a picture. If those PDFs from doc folders would be excluded, most such problems would go away, I believe. You probably included /usr/local/texlive/2012/texmf-dist/doc/latex/oberdiek/picture.pdf? Mojca
On Tue, 5 Feb 2013, Mojca Miklavec wrote:
On Mon, Feb 4, 2013 at 7:52 PM, Meer H. van der wrote:
Found this one with a lucky guess. The macro call \doiffile{picture} does find a usable picture file (I guess picture.pdf) in my tex-tree. My conclusion would be that the search no longer starts in the current directory but does a global search first. That used to be different. Why the change?
I had a similar (yet unresolved) problem, see thread "ConTeXt inputs files from TEXMF/doc" from October 2012: http://thread.gmane.org/gmane.comp.tex.context/78692
I'm not sure if that was really a change, but it probably isn't intentionally so. My wild guess is that pdf takes precedence over jpg (ConTeXt would probably first test if picture.pdf is found and only if that one wouldn't be, it would try picture.png or jpg).
As I said in a recent post (http://article.gmane.org/gmane.comp.tex.context/80617/), I thought that \setupexternalfigures[location=local] would not search the texmf tree at all. But that is clearly not the case.
In any case ConTeXt should not even search in doc folder for files to be included as a picture. If those PDFs from doc folders would be excluded, most such problems would go away, I believe. You probably included /usr/local/texlive/2012/texmf-dist/doc/latex/oberdiek/picture.pdf?
It certainly does not search all files in the doc directory. On TL'12 mtxrun does not find /usr/share/texmf/doc/dvipdfm/something.pdf, i.e., $ mtxrun something.pdf does not return anything. But on minimals, $ mtxrun simpleslides.pdf /opt/context-minimals/texmf-modules/doc/context/third/simpleslides/simpleslides.pdf which should not happen. Aditya
On Tue, Feb 5, 2013 at 12:35 AM, Aditya Mahajan wrote:
It certainly does not search all files in the doc directory. On TL'12 mtxrun does not find /usr/share/texmf/doc/dvipdfm/something.pdf, i.e.,
Maybe just because dvipdfm is excluded from the search, but that's pure speculation. I don't see any doc path in texmfcnf.lua and it's not yet clear to me where it gets added. Mojca PS: I remember times when it used to be difficult to get \externalfigure[cow] working without an extra command. Now it's apparently vice versa ;)
On 2013–02–05 Mojca Miklavec wrote:
PS: I remember times when it used to be difficult to get \externalfigure[cow] working without an extra command. Now it's apparently vice versa ;)
Funnily this is already a complete working minimal example: \externalfigure [example] This compiles with context beyond 2011.11.29 23:11 but fails with 2011.05.18 18:04 and earlier. Marco
On 2/5/2013 10:13 AM, Mojca Miklavec wrote:
On Tue, Feb 5, 2013 at 12:35 AM, Aditya Mahajan wrote:
It certainly does not search all files in the doc directory. On TL'12 mtxrun does not find /usr/share/texmf/doc/dvipdfm/something.pdf, i.e.,
Maybe just because dvipdfm is excluded from the search, but that's pure speculation. I don't see any doc path in texmfcnf.lua and it's not yet clear to me where it gets added.
Mojca
PS: I remember times when it used to be difficult to get \externalfigure[cow] working without an extra command. Now it's apparently vice versa ;)
i uploaded a beta i think something was introduces when something with url based inclusions was adapted ... i now treat an url different and because a 'not found image' then can give an 'html' file which confuses the backend i do some extra checking in that variant .. somewhat messy Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 5 feb. 2013, at 00:22, Mojca Miklavec
On Mon, Feb 4, 2013 at 7:52 PM, Meer H. van der wrote:
Found this one with a lucky guess. The macro call \doiffile{picture} does find a usable picture file (I guess picture.pdf) in my tex-tree. My conclusion would be that the search no longer starts in the current directory but does a global search first. That used to be different. Why the change?
I had a similar (yet unresolved) problem, see thread "ConTeXt inputs files from TEXMF/doc" from October 2012: http://thread.gmane.org/gmane.comp.tex.context/78692
I'm not sure if that was really a change, but it probably isn't intentionally so. My wild guess is that pdf takes precedence over jpg (ConTeXt would probably first test if picture.pdf is found and only if that one wouldn't be, it would try picture.png or jpg). In any case ConTeXt should not even search in doc folder for files to be included as a picture. If those PDFs from doc folders would be excluded, most
such problems would go away, I believe. You probably included /usr/local/texlive/2012/texmf-dist/doc/latex/oberdiek/picture.pdf?
No, I did call \doiffile{picture} without any path components and the aforementioned file comes out first. One more observation: having put a file picture.pdf in the current directory makes \doiffile{picture} find that one. I conclude therefore that the search is first for file type pdf in all paths and only after that for another file type. Preferably in my eyes would have been the other way around: first priority of the search on a picture file of any acceptable type, and on failing that the same in all directories subsequently in the search path. But, this might be called a matter of taste. Hans van der Meer
participants (6)
-
Aditya Mahajan -
H. van der Meer -
Hans Hagen -
Marco Patzer -
Meer H. van der
-
Mojca Miklavec