I am working on one project in which i have one config file. What exactly i am doing right now is i have about 20 sources and indexes in my file.And new will be added with the time.Now i am searching on particular index by specify its name.But my problem is with the time some indexes are not in use any more but config content related to it is still there inside config file.So what i actually want to do is,making one file which contain only source and index information .Then refer that content into main config file.Is there any way to doing this?
There are no "include" option supported currently in Sphinx config file, but there is scripting support (or shebang style) which you could use in your Sphinx setup: http://www.ivinco.com/blog/scripting-in-sphinx-config/
Hope this helps.
Related
Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
Hello,
I'm an eclipse plugin development newbie looking for pointers to get me started on a particular project.
I am trying to build an eclipse plugin that will automatically construct a working set from a text file that simply consists of a list of file path names. The files/items need not share any parent directories. The rough idea is represented in the following diagram:
I am not asking for the solution to this task. That's the over-arching goal. To achieve that goal, I want to conquer some smaller goals first.
With that in mind, here's the smaller goal I'm currently trying to tackle:
In Eclipse, how can I prompt the user for a single file's path, and then add that file to an existing working set?
I'm not sure where to start. Should I work directly off of the existing org.eclipse.ui.workingSets extension point? Or should I use a collection of other extension points? How do I convert strings into something that can be added to a working set? Do I write code that directly modifies the workingsets.xml file?
Even with a much simpler goal, I still feel quite overwhelmed with the vastness of eclipse extension options. There are probably many ways to go about implementing something like this, but I just need one to get started.
Thanks a bunch!
To manipulate working sets you use the working set manager interface IWorkingSetManager. Get this with:
IWorkingSetManager manager = PlatformUI.getWorkbench().getWorkingSetManager();
From this you can get a particular working by name with:
IWorkingSet workingSet = manager.getWorkingSet("name");
The contents of a working set is an array of IAdaptable objects:
IAdaptable [] contents = workingSet.getElements();
You add to the contents by adding to this array and setting the contents:
IAdaptable [] newContents
.... get new array with old contents + new contents
workingSet.setElements(newContents);
A lot of Eclipse objects implement IAdaptable, for a file in the workspace you would use IFile. You can use dialogs such as ResourceSelectionDialog to select resources from the workspace.
Using Robohelp 10 html help. how can i map a topic from a merged (child) .chm to the master? User needs to press F1 and get the topic from the child .chm. I tried editing the Master's .ali file and changing the Alias entry, like this:
<Alias name="Test" link="child.chm::/test.htm">
Can't figure out the format to refer to the child.chm correctly. In the child or Master itself, if i use
<Alias name="Test" link="test.htm">
(assuming i put the actual .htm file inside that respective project and i'm not merging them, just testing with that single .chm), it works fine. I know the name parameter is correct, i just can't get the master to understand to look into the child to get the test.htm file. The old examples mention a redirect file, but how do i do that with this xml format? JUST LOOK AT THE EXAMPLES ROBOHELP MAKES WHEN YOU DEFINE A WORKING ONE, THEY ARE IN THE .ali file. Is that what i'm missing? YES Do i put the mapping into the child at all? NO
Defining context mappings Creating Context-Sensitive Help for Applications works fine in a standalone CHM, but in a merged help system one can run into problems when trying to open a Slave topic though the master CHM.
The process requires you to make changes to your map and alias files outside RoboHelp, and also to add a "redirector" topic to the master .chm file — so it is not straightforward.
Please see Context IDs in Merged Help.
So, you have to decide which one of the solutions is working for your needs.
Pete Lees mentioned some years ago "... that the HelpwareGroup.com site doesn't explain that the ALIAS section of the .hhp file must contain at least one bookmark-free reference to the redirect.htm file. If every redirect line in the section has a bookmark appended to it then the context help call will fail. So to fix the problem, add the following two lines to your .hhp file ...":
[ALIAS]
Dummy_Unused=redirect.htm
[MAP]
#define Dummy_Unused 0
I have a large amount of code that I'm running doxygen against. To improve performance I'm trying to break it into modules and merge the result into one set of docs. I thought tag files would do the trick, but either I have it configured wrong or I'm misunderstanding how it works.
The directories are laid out:
root +
|-src+
| |-a
|
|-doc+
|-a.dox
|-main.dox
|-main.md
|-output+
|-a+
| |-html
|-main+
|-html
In addition to 'a' there are other peer directories but am starting with one.
a.dox generates output and a tag file into root/doc/output
OUTPUT_DIRECTORY=output/a
GENERATE_TAGFILE = output/a/a.tag
INPUT=../src/a
main.dox just inputs the markdown file that has a mainpage tag and refers to the other projects tag file.
OUTPUT_DIRECTORY=output/main
INPUT = main.md
TAGFILES=output/a/a.tag=output/a/html
Should this merge or link all the docs under main where I can browse 'a' globals, modules, pages, etc? Or does this only generate links to 'a' if I explicitly cross-reference a documented entity in 'a' from inside of 'main'?
If this should work, any thoughts on where my syntax is incorrect? I've tried various ways to define TAGFILES, is the output directory relative to the main.dox file? To the a.tag file? Or to the a/html directory?
If I'm off base an TAGFILES don't work this way, is there another way to merge sets of doxygen directories into one?
Thanks.
I suggest you read this topic on how I recommend to use tag files and the conditions that should apply: https://stackoverflow.com/a/8247993/784672
To answer your first question: doxygen will in general not merge the various index files together (then no performance would be gained). Although for a part you can still get external members in the index by setting ALLEXTERNALS to YES.
Doxygen will (auto)link symbols from other sources imported via a tag file. So in general you should divide your code into more or less self-contained modules/components/libraries, and if one such module depends on another, then import its tag file so that doxygen can link to the other documentation set. If you run doxygen twice (once for the tag file and once for the documentation) you can also resolve cyclic dependencies if you have them.
In my case I made a custom index page with links to all modules, and made a custom entry in the menu of each generated page that linked back to this index (see http://www.doxygen.nl/manual/customize.html#layout) how to add a user defined entry to the navigation menu/tree.
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.