tl;dr question:
What is the actual algorithm doxygen uses to find images referenced to in doxygen comments? And the corollary, what's considered best practice which won't break in future doxygen versions?
Details:
We're trying to institute a policy where any images associated with doxygen comments should be localized to the reference, which means we'll have images distributed throughout the source tree. Obviously, we need to make sure that we refer to the images appropriately and that doxygen can find them to produce the correct documentation.
The doxygen documentation states:
doxygen will look for files in the paths (or files) that you specified after the IMAGE_PATH tag
However, in my tinkering I've come to the conclusion that this doesn't seem strictly correct. Here are some experimental results:
================================================
Experiment
File system configuration:
/full/
path/
doxygen.cfg
to/
this/
header.h
images/
image.png
other/
images/
image.png
The doxygen config file is in the "root" of the tree (i.e., /full/path/) and doxygen is executed from this same folder.header.h references images/image.png located in the same tree (/full/path/to/this). There is an identically named image file located elsewhere in the tree. header.h has the line:
#file html [filename]
reference where [filename] is one of the following:
image.png
images/image.png
./images/image.png
/full/path/to/this/images/image.png
Then I play with the IMAGE_PATH variable.
Case 1:IMAGE_PATH = (i.e., no path defined).
"Wrong" image loaded (other/iamges/image.png)
no image
no image
Correct image loaded
Case 2: IMAGE_PATH = /full/path (path provided to root, but not full path to header file).
Correct image loaded
Correct image loaded
Correct image loaded
Correct image loaded
Case 3: IMAGE_PATH = /full/path/other (path provided to root which does not include the header file).
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
Correct image loaded
================================================
Inferred Algorithm Properties
Relative paths only work if the relative path is in the tree rooted in a path specified in IMAGE_PATH.
In the case where the image file name can resolve into different images, doxygen appears to pick the one "closest" to the reference.
First thing first... thanks for posting this, I was starting to think I was missing something obvious. Now I know there are at least two of us...
I was attempting to include a picture in a markdown file; this may explain the slightly different results I got. Also, I tested with \image command only. At first I only got a long series of "image not found" warnings, but eventually I reached some consistent positive results suggesting that:
The image is only found when IMAGE_PATH setting points directly to the folder where the image is (no parent folder). The manual slightly hints towards this by suggesting that IMAGE_PATH may ba a collection of paths or files
IMAGE_PATH can be expressed as a full path or relative to the location where DOXYGEN is run
Moreover, in order for the image to be "found", the file name and path should match a part of the actual full name and path of the image
For instance, given a markdown page and an image in the following folders:
/some-path/work/my-page.md
/some-path/work/images/some/more/folders/the-image.png
In order to copy the page while running DOXYGEN in the "work" folder, IMAGE_PATH should be set as one of the following:
/some-path/work/images/some/more/folders/the-image.png
/some-path/work/images/some/more/folders
images/some/more/folders/the-image.png
images/some/more/folders
In all cases, the image can be successfully referenced in the markdown page as either "the-image.png" or "folders/the-image.png", "more/folders/the-image.png" etc. The criteria is the reference matching part of the actual file path and name (while one could expect the image reference to be relative to the markdown file it appears in - this seems wrong).
I say again, these tests were conducted using a markdown file, and it's possible in this case the mechanics be different from the one applicable to images referenced in source files.
In html documentation, images were replaced with the broken image icon.
After two days of trial and error, I found out that the reason was in the set text direction (Project->OUTPUT_TEXT_DIRECTION), it should be None, not LTR. The documentation was carried out in two ways:
#image html my_picture.png
Related
I am using a Batch script to merge different PDFs in one complete file.
%gsc% -dBATCH -sDEVICE=pdfwrite -sPAPERSIZE=letter -dEPSFitPage -o %dsk%%zus%%ext% %mfd% %pth%tmp\pdfmarks
%dsk%%zus%%ext%: Path and name of final (complete) document
%mfd%: Path and name of docs to be merged (c:\test\1.pdf c:\test\2.pdf ...)
%pth%tmp = path to the pdfmarks file
Additionally, I am creating a pdfmark document inside the script which gs uses to create the bookmarks. But unfortunately, some of the docs I am merging, have already their own bookmarks and I did not yet find a solution how to ignore those. GS should only use the bookmarks inside the pdfmarks file.
How can this be done?
Firstly; you are not 'merging' PDF files when you use Ghotscript's pdfwrite device. The process is described in detail here
The important point is that the way the input file(s) are constructed has no bearing on the way the output file is constructed. If any other software you use relies on the file being constructed in a particular fashion it may not work on the output PDF file.
The -dEPSFitPage switch only has any effect when the input is an EPS file. If you want to 'fit' PostScript or PDF files then you need to use -dPDFFitPage, -dPSFitPage or just -dFitPage. However, all of these rely on you first selecting a media size, and then preventing it being altered by setting -dFIXEDMEDIA. For EPS files you would more normally use -dEPSCrop which sets the media size to the EPS declared BoundingBox.
You can prevent the PDF interpreter reading the Outlines tree (which you are calling Bookmarks) and then creating a pdfmark from it to pass to the pdfwrite device by using the -dNO_PDFMARK_OUTLINES switch which oddly isn't documented, presumably an oversight.
I'm using emacs 25.3.1 with Org mode version 9.1.9. I'm trying to ensure that the comments produced by the org-babel-tangle function and preceding the source block content in the tangled file contain the relative path to the original org file and not the absolute path. Although the documentation states that the org-babel-tangle-use-relative-file-links variable, which defaults to t, ensures this precise behaviour, I keep getting the absolute path in the links (e.g. # [[file:~/Projects/my_project/my_project.org::*setup.py][setup.py:1]]).
I tried setting this variable to nil but it didn't change anything. When manually changing the links with the relative path ( e.g. # [[file:../my_project.org::*setup.py][setup.py:1]]), invoking org-babel-detangle to integrate changes to the tangled file back to the original org file actually worked (with an additional interaction in the mini-buffer: No match - create this as a new heading? (y or n)).
Is there any way to get this relative path automatically from org-babel-tangle or is this a bug? This is a fairly important question if you think about projects with several contributors to a version controlled repository where
not everybody uses org-mode
obviously not everybody's working copy is located at the same absolute path on its own computer.
I’m using Doxygen 1.8.10 (on Windows) to generate LaTeX files, and MiKTex 2.9 to generate a PDF. The PDF is functional, but not very pretty. I’ve figured out how to customize the title page (I added graphics and non-default text) and how to get the images into the PDF.
But... how do I change the styling for things such as the color of URLs (which are just text in the Doxygen comments, and then Doxygen turns them into \href items)?
**** I believe I need to change something in the hyperref package’s config or what Doxygen writes to the .tex files, but I’m not sure which approach is right, nor how to do either one...
I’ve created a custom_doxygen.sty file, and assigned it to the LATEX_EXTRA_STYLESHEET. I assume that it’s being picked up by Doxygen because Doxygen is successfully picking up my custom LATEX_HEADER file, which is in the same directory as the custom_doxygen.sty file. But what I don’t know is what to put into the custom_doxygen.sty file?
If I run everything as default (that is, no LATEX_EXTRA_STYLESHEET), the following code gets written to the refman.tex file:
% Hyperlinks (required, but should be loaded last)
\usepackage{ifpdf}
\ifpdf
\usepackage[pdftex,pagebackref=true]{hyperref}
\else
\usepackage[ps2pdf,pagebackref=true]{hyperref}
\fi
\hypersetup{%
colorlinks=true,%
linkcolor=blue,%
citecolor=blue,%
unicode%
}
And what I need is for the “urlcolor” to also be blue (its default in the hyperref package is magenta—an odd choice for sure).
I tried just basically copying what was in the refman.tex file to the custom_doxygen.sty file (and making sure that the custom_doxygen.sty file is assigned to the LATEX_EXTRA_STYLESHEET setting in my Doxyfile) and adding a “urlcolor=blue,%” to the setup section, but there’s no change in the output.
If I manually edit the refman.tex file (that is, I add "citecolor=blue,%" to the \hypersetup) after it's output from Doxygen, and then use the edited file as input to MiKTeX, I get the desired output.
So a workaround could be to just script the desired change and run the script every time. But it would be certainly be better to get Doxygen to write the necessary configuration. Plus, there are other things I want to customize (such as the font of explicit html hrefs), so I'd like to learn how to do things properly.
Is there a simple way to add something like the {Back to Worg's index} to every .org page in a directory which I plan to publish with org-publish-project-alist? Is this accomplished with a #+ tag, or some definition in the .css file?
I looked at how they did it on Worg, and it doesn't look like CSS.
There are a few ways you might be able to do so.
Create a generic file that only includes the details you want in each file. For example:
[[./index.org][Back to index]]
Then use #+include: <filename> at the location in your file where you want the line. (See Include Files)
Alternately you could define a macro in a setupfile (See In-Buffer Settings) that is the definition of the link (or multiple link choices)
#+macro: toIndex [[./index.org][Back to index]]
In both cases it is worth noting that the relative paths are based on the exported file. So a [[../index.org]] will always point to the index.org file in the parent directory, no matter where the setupfile is.
Upon numerous searches, I am here to see if someone has any idea on how I should go about tackling this issue.
I have a folder with sub-folders. The sub-folder containers each has files of different file types e.g. pdf, png, jpeg, tiff, avi and word documents.
My goal is to write a code in C# that will go into the subfolder, and combined all the files into one pdf using the name of the folder. The only exception is that a file such as avi will not be pdf'ed in which case I want a nudge as to which folder it is and possibly file name. I am trying to use the form approach, so that you can copy in the folder pathname and also destination of the created pdf.
Thanks.
to start, create a FolderBrowserDialog to get the root folder. Alternatively just make a textbox in which you paste the folder name ( less preferred since the first method gives you nicer error-handling straight out of the box )
In order to iterate through, see How to: Iterate Through a Directory Tree
To find the filetype, check System.IO.FileInfo.Extension for each file you iterate through. Add those to list with the data you need. ( hint, create a list of objects in which your object reflects the data you need such as path, type etc,... ). If its an avi don't toss it in the list but flash a warning (messagebox?) instead.
From here the original question gets fuzzy. What exactly do you need in the pdf. Just the filenames and locations or do you actually want to throw the actual contents of the file in pdf?