From c460dc75a10d96fc38011db90fae5bcd8649b743 Mon Sep 17 00:00:00 2001 From: frog Date: Fri, 24 Sep 2004 11:33:42 +0000 Subject: [PATCH] * Added Doc/Website/CodingStyle.html, Developpers.html, DeveloppersPython.html, GdcmDataCvs.html and DownloadVersion0_1.html, DownloadVersion0_3.html. * Some Doc/*.txt Doxygen files (which do not really concern the documentation itself, but the website) moved to html and placed in directory Doc/Website: - Doc/DoxyDevelInstal.txt moved to Doc/Website/Developpers.html - Doc/DoxyInstallation.txt moved to Doc/Website/Installation.html - Doc/DoxyIntroduction.txt included in Doc/Website/Main.html * Doc/DoxyfileDeveloppers, DoxyfileUsers, Makefile.am oldies removed. * CMakeLists.txt changed accordingly. --- Doc/CMakeLists.txt | 11 +- Doc/DoxyDevelInstal.txt | 54 -- Doc/DoxyInstallation.txt | 67 -- Doc/DoxyMainPage.txt | 11 +- Doc/DoxyMainPageUser.txt | 10 +- Doc/DoxyfileDeveloppers | 1067 -------------------------- Doc/DoxyfileUsers | 1085 --------------------------- Doc/License.txt | 2 +- Doc/Makefile.am | 44 -- Doc/Website/CodingStyle.html | 288 +++++++ Doc/Website/Developpers.html | 71 ++ Doc/Website/DeveloppersPython.html | 91 +++ Doc/Website/Download.html | 19 +- Doc/Website/DownloadVersion0_1.html | 82 ++ Doc/Website/DownloadVersion0_3.html | 90 +++ Doc/Website/GdcmDataCvs.html | 46 ++ Doc/Website/Installation.html | 189 ++++- Doc/Website/Main.html | 7 +- Doc/Website/Sidebar.html | 14 +- 19 files changed, 878 insertions(+), 2370 deletions(-) delete mode 100644 Doc/DoxyDevelInstal.txt delete mode 100644 Doc/DoxyInstallation.txt delete mode 100644 Doc/DoxyfileDeveloppers delete mode 100644 Doc/DoxyfileUsers delete mode 100644 Doc/Makefile.am create mode 100644 Doc/Website/CodingStyle.html create mode 100644 Doc/Website/Developpers.html create mode 100644 Doc/Website/DeveloppersPython.html create mode 100644 Doc/Website/DownloadVersion0_1.html create mode 100644 Doc/Website/DownloadVersion0_3.html create mode 100644 Doc/Website/GdcmDataCvs.html diff --git a/Doc/CMakeLists.txt b/Doc/CMakeLists.txt index e5e57d0e..29b9260f 100644 --- a/Doc/CMakeLists.txt +++ b/Doc/CMakeLists.txt @@ -12,18 +12,15 @@ SET(TARGET_DIR #EXTRA_DIST = \ # DoxyfileDeveloppers \ # DoxyfileUsers \ -# DoxyDevelInstal.txt \ -# DoxyIntroduction.txt \ # DoxyPython.txt \ -# DoxyInstallation.txt \ # DoxyMainPage.txt IF(GDCM_DOCUMENTATION) # http://www.cmake.org/pipermail/cmake/2003-April/003673.html # Too bad CMake doesn't support multiline "" - SET(GDCM_DOCUMENTATION_INPUT_COMMON - "${GDCM_SOURCE_DIR}/src ${GDCM_SOURCE_DIR}/Doc/DoxyPython.txt ${GDCM_SOURCE_DIR}/Doc/DoxyInstallation.txt ${GDCM_SOURCE_DIR}/Doc/DoxyIntroduction.txt" + SET(GDCM_DOXYGEN_INPUT_COMMON + "${GDCM_SOURCE_DIR}/src ${GDCM_SOURCE_DIR}/Doc/DoxyPython.txt" ) SET(GDCM_DOCUMENTATION_EXCLUDE_COMMON ) @@ -35,8 +32,8 @@ IF(GDCM_DOCUMENTATION) SET(GDCM_HTML_OUTPUT html.developper ) - SET(GDCM_DOCUMENTATION_INPUT - "${GDCM_DOCUMENTATION_INPUT_COMMON} ${GDCM_SOURCE_DIR}/Doc/DoxyDevelInstal.txt ${GDCM_SOURCE_DIR}/Doc/DoxyMainPage.txt" + SET(GDCM_DOXYGEN_INPUT + "${GDCM_DOXYGEN_INPUT_COMMON} ${GDCM_SOURCE_DIR}/Doc/DoxyMainPage.txt" ) SET(GDCM_DOCUMENTATION_EXCLUDE "${GDCM_DOCUMENTATION_EXCLUDE_COMMON} ${GDCM_SOURCE_DIR@/src/iddcmjpeg.h ${GDCM_SOURCE_DIR@/src/src/gdcmJpeg.cxx" diff --git a/Doc/DoxyDevelInstal.txt b/Doc/DoxyDevelInstal.txt deleted file mode 100644 index 1e61433f..00000000 --- a/Doc/DoxyDevelInstal.txt +++ /dev/null @@ -1,54 +0,0 @@ -/** - * \page DoxyDevelInstal Developpers workspace - * There is no further requirements than the ones of \ref DoxyInstallation. - * But the developpers generally have further needs than the library user - * like : - * - in place debugging (in place as opposed to fully - * installed, i.e. when working in the cvs hierarchy or in the hierarchy - * build from gdcm source tar ball). - * - tests of features - * - test suite usage (typically after code modifications and prior to - * commit). - * . - * In the following we shall assume that gdcm is already compiled- - * BUT not installed- in a directory named GDCM_HOME. - * - * \section DoxyDevelInstalCPlusPlus Working with C++ - * The kernel library uses the environnement variable - * GDCM_DICT_PATH as a path to the location of the default - * Dicom dictionary. Hence if you which to work/debug a code based - * on gdcm, you first need to positionate this variable. When omitting - * this you should get the following message: - * gdcmDict::gdcmDict: can't open dictionary /usr/local/share/gdcm/dicomV3.dic - * - * Suppose you want to launch some C++ demo/test program, that - * gets compiled with the kernel, e.g. PrintHeader. One can do - * - cd GDCM_HOME - * - export GDCM_DICT_PATH=`pwd`/Dicts - * - cd Test - * - ./PrintHeader - * . - * \section DoxyDevelInstalPython Working with Python - * - cd GDCM_HOME - * - ./autogen.sh --enable-python - * - make - * - export PYTHONPATH=`pwd` - * - cd gdcmPython - * - ln -s .libs/pygdcm.so _gdcm.so (this is because automake - * doesn't allow the building of libraries whose name starts with an - * underscore. Since we need the wrapper library to be named _gdcm - * [because swig automaticatily uses this name when building the - * shadow classes], automake generates pygdcm.so and at install stage - * stage renames it to _gdcm.so). - * - You can then use gdcmPython for manual test/demos - * -# cd GDCM_HOME/gdcmPython/demo - * -# python PrintHeader.py - * - You can also run the gdcm test suite, which is written in Python: - * -# first you need to install the Dicom data files used by the - * test suite. The cvs access point is - * :pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public - * and the name of the module is gdcmData. - * Checkout this module in GDCM_HOME directory - * -# cd GDCM_HOME/gdcmPython/ - * -# python testSuite.py - */ diff --git a/Doc/DoxyInstallation.txt b/Doc/DoxyInstallation.txt deleted file mode 100644 index 95a80569..00000000 --- a/Doc/DoxyInstallation.txt +++ /dev/null @@ -1,67 +0,0 @@ -/** - * \page DoxyInstallation Installing gdcm and gdcmPython - * \section DoxyRequirements Requirements - * - For the core C++ library you shall need a C++ compiler with the - * "list" and "map" STL containers. Gdcm is developped and tested under: - * -# GNU/linux (gcc 2.96.x) - * -# Win32/VC++ 6.x - * . - * - For \ref DoxyPythonComplete you shall need: - * -# Python version 2.2.x - * -# Swig version >= 1.3.17x (in order - * to handle C++ member overloading, shadow classes and static methods) - * \htmlonly - *

Rpms for GNU/linux: - * - * swig13-1.3.17-1.i386.rpm, - * - * swig13-1.3.17-1.src.rpm. - *
for Win32 you shall need to compile - * the sources - *

- * \endhtmlonly - * . - * . - * - * \section DoxyInstallLinux Un*x - * \subsection DoxyInstallLinuxCvs Starting from cvs sources. - * - Retrieve the - * - * sources through cvs, - * - cd gdcm - * - ./autogen.sh --help in order to select your preferences - * - ./autogen.sh to launch the usual automake/autoconf - * process e.g. - * -# ./autogen.sh --prefix=/where/ever/you/want - * to configure the script to force installation in a specified - * place. - * -# ./autogen.sh --enable-python to generate the - * python wrappers (a.k.a. gdcmPython) - * -# ./autogen.sh --enable-vtk to generate the - * vtk clases that shallow wrap gdcm, - * -# ./autogen.sh --enable-doxygen to generate the - * doxygen - * based documentation - * . - * . - * - make - * - make instal - * - As usual, you can optionnally: - * -# make clean - * -# make CFLAGS='-g' CXXFLAGS='-DPUB_DICT_PATH=\"/usr/local/share/gdcm/\" -D__STDC_LIMIT_MACROS' - * if you are in hurry and want to omit "-g -O2" default flags - * -# make snapshot - * . - * - * \subsection DoxyInstallLinuxSources Starting from the sources (snapshot). - * The process is exactly the same as the one using the cvs sources - * (see above) except that you shall use ./configure instead - * of ./autogen.sh - * - * \section DoxyInstallWindoze Windows - * - Retrieve the sources through the tarball - * - Launch VC++ by opening the gdcm.dsw workspace. - * - Proceed with building the required projects. - * . - */ diff --git a/Doc/DoxyMainPage.txt b/Doc/DoxyMainPage.txt index c3949ca3..33442b2c 100644 --- a/Doc/DoxyMainPage.txt +++ b/Doc/DoxyMainPage.txt @@ -1,14 +1,5 @@ /** * \mainpage gdcm documentation * - * - \ref DoxyIntroduction - * - \ref DoxyInstallation - * - \ref DoxyPythonComplete - * - \ref DoxyDevelInstal - * - Class Hierarchy - * - Alphabetical List - * - Compound List - * - File List - * - Compound Members - * - File Members + * This is the developpers documentation. */ diff --git a/Doc/DoxyMainPageUser.txt b/Doc/DoxyMainPageUser.txt index 8a495526..f29ee713 100644 --- a/Doc/DoxyMainPageUser.txt +++ b/Doc/DoxyMainPageUser.txt @@ -1,13 +1,5 @@ /** * \mainpage gdcm documentation * - * - \ref DoxyIntroduction - * - \ref DoxyInstallation - * - \ref DoxyPythonComplete - * - Class Hierarchy - * - Alphabetical List - * - Compound List - * - File List - * - Compound Members - * - File Members + * This is the users documentation */ diff --git a/Doc/DoxyfileDeveloppers b/Doc/DoxyfileDeveloppers deleted file mode 100644 index b43ef43e..00000000 --- a/Doc/DoxyfileDeveloppers +++ /dev/null @@ -1,1067 +0,0 @@ -# Doxyfile 1.3.3 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# General configuration options -#--------------------------------------------------------------------------- - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = gdcm - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -PROJECT_NUMBER = - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, -# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en -# (Japanese with English messages), Korean, Norwegian, Polish, Portuguese, -# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. - -OUTPUT_LANGUAGE = English - -# This tag can be used to specify the encoding used in the generated output. -# The encoding is not always determined by the language that is chosen, -# but also whether or not the output is meant for Windows or non-Windows users. -# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES -# forces the Windows encoding (this is the default for the Windows binary), -# whereas setting the tag to NO uses a Unix-style encoding (the default for -# all platforms other than Windows). - -USE_WINDOWS_ENCODING = NO - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = YES - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = YES - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = YES - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = YES - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = NO - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these class will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = NO - -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the -# documentation. - -HIDE_FRIEND_COMPOUNDS = NO - -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. - -HIDE_IN_BODY_DOCS = NO - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = YES - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the -# brief descriptions will be completely suppressed. - -REPEAT_BRIEF = YES - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = NO - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited -# members of a class in the documentation of that class as if those members were -# ordinary class members. Constructors, destructors and assignment operators of -# the base classes will not be shown. - -INLINE_INHERITED_MEMB = YES - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = YES - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. It is allowed to use relative paths in the argument list. - -STRIP_FROM_PATH = - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = YES - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower case letters. If set to YES upper case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# users are adviced to set this option to NO. - -CASE_SENSE_NAMES = YES - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = NO - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = NO - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = YES - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = YES - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like the Qt-style comments (thus requiring an -# explict @brief command for a brief description. - -JAVADOC_AUTOBRIEF = NO - -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. - -MULTILINE_CPP_IS_BRIEF = NO - -# If the DETAILS_AT_TOP tag is set to YES then Doxygen -# will output the detailed description near the top, like JavaDoc. -# If set to NO, the detailed description appears after the member -# documentation. - -DETAILS_AT_TOP = NO - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# reimplements. - -INHERIT_DOCS = YES - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = YES - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = YES - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 8 - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = YES - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = YES - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = YES - -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. - -GENERATE_DEPRECATEDLIST= YES - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consist of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 30 - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources -# only. Doxygen will then generate output that is more tailored for C. -# For instance some of the names that are used will be different. The list -# of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = NO - -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources -# only. Doxygen will then generate output that is more tailored for Java. -# For instance, namespaces will be presented as packages, qualified scopes -# will look different, etc. - -OPTIMIZE_OUTPUT_JAVA = NO - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = YES - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = NO - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = YES - -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. - -WARN_IF_DOC_ERROR = YES - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. - -WARN_FORMAT = "$file:$line: $text" - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -INPUT = ../src DoxyPython.txt DoxyMainPage.txt \ - DoxyInstallation.txt DoxyDevelInstal.txt \ - DoxyPython.txt DoxyIntroduction.txt - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp -# *.h++ *.idl *.odl - -FILE_PATTERNS = *.cxx *.h - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = NO - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = ../src/iddcmjpeg.h ../src/gdcmJpeg.cxx - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories -# that are symbolic links (a Unix filesystem feature) are excluded from the input. - -EXCLUDE_SYMLINKS = NO - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. - -EXCLUDE_PATTERNS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = ../gdcmPython/demo - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command

, where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. - -INPUT_FILTER = - -# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse. - -FILTER_SOURCE_FILES = NO - -#--------------------------------------------------------------------------- -# configuration options related to source browsing -#--------------------------------------------------------------------------- - -# If the SOURCE_BROWSER tag is set to YES then a list of source files will -# be generated. Documented entities will be cross-referenced with these sources. - -SOURCE_BROWSER = YES - -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. - -INLINE_SOURCES = YES - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = YES - -# If the REFERENCED_BY_RELATION tag is set to YES (the default) -# then for each documented function all documented -# functions referencing it will be listed. - -REFERENCED_BY_RELATION = YES - -# If the REFERENCES_RELATION tag is set to YES (the default) -# then for each documented function all documented entities -# called/used by that function will be listed. - -REFERENCES_RELATION = YES - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = YES - -#--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index -#--------------------------------------------------------------------------- - -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. - -ALPHABETICAL_INDEX = YES - -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 5 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. - -IGNORE_PREFIX = - -#--------------------------------------------------------------------------- -# configuration options related to the HTML output -#--------------------------------------------------------------------------- - -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. - -GENERATE_HTML = YES - -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. - -HTML_OUTPUT = html.developper - -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. - -HTML_FILE_EXTENSION = .html - -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. - -HTML_HEADER = - -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. - -HTML_FOOTER = - -# The HTML_STYLESHEET tag can be used to specify a user defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet - -HTML_STYLESHEET = - -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. - -HTML_ALIGN_MEMBERS = YES - -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) -# of the generated HTML documentation. - -GENERATE_HTMLHELP = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). - -CHM_FILE = - -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can -# be used to specify the file name of the resulting .chm file. You -# can add a path in front of the file if the result should not be -# written to the html output dir. - -HHC_LOCATION = - -# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can -# be used to specify the location (absolute path including file name) of -# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run -# the HTML help compiler on the generated index.hhp. - -GENERATE_CHI = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. - -BINARY_TOC = NO - -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the Html help documentation and to the tree view. - -TOC_EXPAND = NO - -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. - -DISABLE_INDEX = NO - -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. - -ENUM_VALUES_PER_LINE = 4 - -# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be -# generated containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript and frames is required (for instance Mozilla, Netscape 4.0+, -# or Internet explorer 4.0+). Note that for large projects the tree generation -# can take a very long time. In such cases it is better to disable this feature. -# Windows users are probably better off using the HTML help feature. - -GENERATE_TREEVIEW = NO - -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. - -TREEVIEW_WIDTH = 250 - -#--------------------------------------------------------------------------- -# configuration options related to the LaTeX output -#--------------------------------------------------------------------------- - -# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will -# generate Latex output. - -GENERATE_LATEX = NO - -# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `latex' will be used as the default path. - -LATEX_OUTPUT = latex - -# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be -# invoked. If left blank `latex' will be used as the default command name. - -LATEX_CMD_NAME = latex - -# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to -# generate index for LaTeX. If left blank `makeindex' will be used as the -# default command name. - -MAKEINDEX_CMD_NAME = makeindex - -# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact -# LaTeX documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_LATEX = NO - -# The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. - -PAPER_TYPE = a4wide - -# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX -# packages that should be included in the LaTeX output. - -EXTRA_PACKAGES = - -# The LATEX_HEADER tag can be used to specify a personal LaTeX header for -# the generated latex document. The header should contain everything until -# the first chapter. If it is left blank doxygen will generate a -# standard header. Notice: only use this tag if you know what you are doing! - -LATEX_HEADER = - -# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated -# is prepared for conversion to pdf (using ps2pdf). The pdf file will -# contain links (just like the HTML output) instead of page references -# This makes the output suitable for online browsing using a pdf viewer. - -PDF_HYPERLINKS = NO - -# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of -# plain latex in the generated Makefile. Set this option to YES to get a -# higher quality PDF documentation. - -USE_PDFLATEX = NO - -# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. -# command to the generated LaTeX files. This will instruct LaTeX to keep -# running if errors occur, instead of asking the user for help. -# This option is also used when generating formulas in HTML. - -LATEX_BATCHMODE = NO - -# If LATEX_HIDE_INDICES is set to YES then doxygen will not -# include the index chapters (such as File Index, Compound Index, etc.) -# in the output. - -LATEX_HIDE_INDICES = NO - -#--------------------------------------------------------------------------- -# configuration options related to the RTF output -#--------------------------------------------------------------------------- - -# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output -# The RTF output is optimised for Word 97 and may not look very pretty with -# other RTF readers or editors. - -GENERATE_RTF = NO - -# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `rtf' will be used as the default path. - -RTF_OUTPUT = rtf - -# If the COMPACT_RTF tag is set to YES Doxygen generates more compact -# RTF documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_RTF = NO - -# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated -# will contain hyperlink fields. The RTF file will -# contain links (just like the HTML output) instead of page references. -# This makes the output suitable for online browsing using WORD or other -# programs which support those fields. -# Note: wordpad (write) and others do not support links. - -RTF_HYPERLINKS = NO - -# Load stylesheet definitions from file. Syntax is similar to doxygen's -# config file, i.e. a series of assigments. You only have to provide -# replacements, missing definitions are set to their default value. - -RTF_STYLESHEET_FILE = - -# Set optional variables used in the generation of an rtf document. -# Syntax is similar to doxygen's config file. - -RTF_EXTENSIONS_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to the man page output -#--------------------------------------------------------------------------- - -# If the GENERATE_MAN tag is set to YES (the default) Doxygen will -# generate man pages - -GENERATE_MAN = NO - -# The MAN_OUTPUT tag is used to specify where the man pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `man' will be used as the default path. - -MAN_OUTPUT = man - -# The MAN_EXTENSION tag determines the extension that is added to -# the generated man pages (default is the subroutine's section .3) - -MAN_EXTENSION = .3 - -# If the MAN_LINKS tag is set to YES and Doxygen generates man output, -# then it will generate one additional man file for each entity -# documented in the real man page(s). These additional files -# only source the real man page, but without them the man command -# would be unable to find the correct page. The default is NO. - -MAN_LINKS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the XML output -#--------------------------------------------------------------------------- - -# If the GENERATE_XML tag is set to YES Doxygen will -# generate an XML file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_XML = NO - -# The XML_OUTPUT tag is used to specify where the XML pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `xml' will be used as the default path. - -XML_OUTPUT = xml - -# The XML_SCHEMA tag can be used to specify an XML schema, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_SCHEMA = - -# The XML_DTD tag can be used to specify an XML DTD, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_DTD = - - -#--------------------------------------------------------------------------- -# configuration options for the AutoGen Definitions output -#--------------------------------------------------------------------------- - -# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will -# generate an AutoGen Definitions (see autogen.sf.net) file -# that captures the structure of the code including all -# documentation. Note that this feature is still experimental -# and incomplete at the moment. - -GENERATE_AUTOGEN_DEF = NO - - #--------------------------------------------------------------------------- -# configuration options related to the Perl module output -#--------------------------------------------------------------------------- - -# If the GENERATE_PERLMOD tag is set to YES Doxygen will -# generate a Perl module file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_PERLMOD = NO - -# If the PERLMOD_LATEX tag is set to YES Doxygen will generate -# the necessary Makefile rules, Perl scripts and LaTeX code to be able -# to generate PDF and DVI output from the Perl module output. - -PERLMOD_LATEX = NO - -# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be -# nicely formatted so it can be parsed by a human reader. This is useful -# if you want to understand what is going on. On the other hand, if this -# tag is set to NO the size of the Perl module output will be much smaller -# and Perl will parse it just the same. - -PERLMOD_PRETTY = YES - -# The names of the make variables in the generated doxyrules.make file -# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. -# This is useful so different doxyrules.make files included by the same -# Makefile don't overwrite each other's variables. - -PERLMOD_MAKEVAR_PREFIX = - -#--------------------------------------------------------------------------- -# Configuration options related to the preprocessor -#--------------------------------------------------------------------------- - -# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will -# evaluate all C-preprocessor directives found in the sources and include -# files. - -ENABLE_PREPROCESSING = YES - -# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro -# names in the source code. If set to NO (the default) only conditional -# compilation will be performed. Macro expansion can be done in a controlled -# way by setting EXPAND_ONLY_PREDEF to YES. - -MACRO_EXPANSION = NO - -# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES -# then the macro expansion is limited to the macros specified with the -# PREDEFINED and EXPAND_AS_PREDEFINED tags. - -EXPAND_ONLY_PREDEF = NO - -# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. - -SEARCH_INCLUDES = YES - -# The INCLUDE_PATH tag can be used to specify one or more directories that -# contain include files that are not input files but should be processed by -# the preprocessor. - -INCLUDE_PATH = - -# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard -# patterns (like *.h and *.hpp) to filter out the header-files in the -# directories. If left blank, the patterns specified with FILE_PATTERNS will -# be used. - -INCLUDE_FILE_PATTERNS = - -# The PREDEFINED tag can be used to specify one or more macro names that -# are defined before the preprocessor is started (similar to the -D option of -# gcc). The argument of the tag is a list of macros of the form: name -# or name=definition (no spaces). If the definition and the = are -# omitted =1 is assumed. - -PREDEFINED = - -# If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then -# this tag can be used to specify a list of macro names that should be expanded. -# The macro definition that is found in the sources will be used. -# Use the PREDEFINED tag if you want to use a different macro definition. - -EXPAND_AS_DEFINED = - -# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line and do not end with a semicolon. Such function macros are typically -# used for boiler-plate code, and will confuse the parser if not removed. - -SKIP_FUNCTION_MACROS = YES - -#--------------------------------------------------------------------------- -# Configuration::addtions related to external references -#--------------------------------------------------------------------------- - -# The TAGFILES tag can be used to specify one or more tagfiles. - -TAGFILES = - -# When a file name is specified after GENERATE_TAGFILE, doxygen will create -# a tag file that is based on the input files it reads. - -GENERATE_TAGFILE = - -# If the ALLEXTERNALS tag is set to YES all external classes will be listed -# in the class index. If set to NO only the inherited external classes -# will be listed. - -ALLEXTERNALS = NO - -# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed -# in the modules index. If set to NO, only the current project's groups will -# be listed. - -EXTERNAL_GROUPS = YES - -# The PERL_PATH should be the absolute path and name of the perl script -# interpreter (i.e. the result of `which perl'). - -PERL_PATH = /usr/bin/perl - -#--------------------------------------------------------------------------- -# Configuration options related to the dot tool -#--------------------------------------------------------------------------- - -# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will -# generate a inheritance diagram (in Html, RTF and LaTeX) for classes with base or -# super classes. Setting the tag to NO turns the diagrams off. Note that this -# option is superceded by the HAVE_DOT option below. This is only a fallback. It is -# recommended to install and use dot, since it yield more powerful graphs. - -CLASS_DIAGRAMS = YES - -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = YES - -# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is -# available from the path. This tool is part of Graphviz, a graph visualization -# toolkit from AT&T and Lucent Bell Labs. The other options in this section -# have no effect if this option is set to NO (the default) - -HAVE_DOT = NO - -# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. - -CLASS_GRAPH = YES - -# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect implementation dependencies (inheritance, containment, and -# class references variables) of the class with other documented classes. - -COLLABORATION_GRAPH = YES - -# If the UML_LOOK tag is set to YES doxygen will generate inheritance and -# collaboration diagrams in a style similiar to the OMG's Unified Modeling -# Language. -UML_LOOK = YES - -# If set to YES, the inheritance and collaboration graphs will show the -# relations between templates and their instances. - -TEMPLATE_RELATIONS = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT -# tags are set to YES then doxygen will generate a graph for each documented -# file showing the direct and indirect include dependencies of the file with -# other documented files. - -INCLUDE_GRAPH = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and -# HAVE_DOT tags are set to YES then doxygen will generate a graph for each -# documented header file showing the documented files that directly or -# indirectly include this file. - -INCLUDED_BY_GRAPH = YES - -# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will -# generate a call dependency graph for every global function or class method. -# Note that enabling this option will significantly increase the time of a run. -# So in most cases it will be better to enable call graphs for selected -# functions only using the \callgraph command. - -CALL_GRAPH = NO - -# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. - -GRAPHICAL_HIERARCHY = YES - -# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are gif, jpg, and png -# If left blank gif will be used. - -DOT_IMAGE_FORMAT = png - -# The tag DOT_PATH can be used to specify the path where the dot tool can be -# found. If left blank, it is assumed the dot tool can be found on the path. - -DOT_PATH = - -# The DOTFILE_DIRS tag can be used to specify one or more directories that -# contain dot files that are included in the documentation (see the -# \dotfile command). - -DOTFILE_DIRS = - -# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_WIDTH = 1024 - -# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_HEIGHT = 1024 - -# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the -# graphs generated by dot. A depth value of 3 means that only nodes reachable -# from the root by following a path via at most 3 edges will be shown. Nodes that -# lay further from the root node will be omitted. Note that setting this option to -# 1 or 2 may greatly reduce the computation time needed for large code bases. Also -# note that a graph may be further truncated if the graph's image dimensions are -# not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH and MAX_DOT_GRAPH_HEIGHT). -# If 0 is used for the depth value (the default), the graph is not depth-constrained. - -MAX_DOT_GRAPH_DEPTH = 0 - -# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will -# generate a legend page explaining the meaning of the various boxes and -# arrows in the dot generated graphs. - -GENERATE_LEGEND = YES - -# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will -# remove the intermedate dot files that are used to generate -# the various graphs. - -DOT_CLEANUP = YES - -#--------------------------------------------------------------------------- -# Configuration::addtions related to the search engine -#--------------------------------------------------------------------------- - -# The SEARCHENGINE tag specifies whether or not a search engine should be -# used. If set to NO the values of all tags below this one will be ignored. - -SEARCHENGINE = NO diff --git a/Doc/DoxyfileUsers b/Doc/DoxyfileUsers deleted file mode 100644 index 86a264e3..00000000 --- a/Doc/DoxyfileUsers +++ /dev/null @@ -1,1085 +0,0 @@ -# Doxyfile 1.3.4 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# Project related configuration options -#--------------------------------------------------------------------------- - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = gdcm - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -PROJECT_NUMBER = - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, -# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en -# (Japanese with English messages), Korean, Norwegian, Polish, Portuguese, -# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. - -OUTPUT_LANGUAGE = English - -# This tag can be used to specify the encoding used in the generated output. -# The encoding is not always determined by the language that is chosen, -# but also whether or not the output is meant for Windows or non-Windows users. -# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES -# forces the Windows encoding (this is the default for the Windows binary), -# whereas setting the tag to NO uses a Unix-style encoding (the default for -# all platforms other than Windows). - -USE_WINDOWS_ENCODING = NO - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = YES - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the -# brief descriptions will be completely suppressed. - -REPEAT_BRIEF = YES - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = NO - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited -# members of a class in the documentation of that class as if those members were -# ordinary class members. Constructors, destructors and assignment operators of -# the base classes will not be shown. - -INLINE_INHERITED_MEMB = YES - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = NO - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user-defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. It is allowed to use relative paths in the argument list. - -STRIP_FROM_PATH = - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = NO - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like the Qt-style comments (thus requiring an -# explict @brief command for a brief description. - -JAVADOC_AUTOBRIEF = NO - -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. - -MULTILINE_CPP_IS_BRIEF = NO - -# If the DETAILS_AT_TOP tag is set to YES then Doxygen -# will output the detailed description near the top, like JavaDoc. -# If set to NO, the detailed description appears after the member -# documentation. - -DETAILS_AT_TOP = NO - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# reimplements. - -INHERIT_DOCS = YES - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 8 - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user-defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources -# only. Doxygen will then generate output that is more tailored for C. -# For instance, some of the names that are used will be different. The list -# of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = NO - -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources -# only. Doxygen will then generate output that is more tailored for Java. -# For instance, namespaces will be presented as packages, qualified scopes -# will look different, etc. - -OPTIMIZE_OUTPUT_JAVA = NO - -# Set the SUBGROUPING tag to YES (the default) to allow class member groups of -# the same type (for instance a group of public functions) to be put as a -# subgroup of that type (e.g. under the Public Functions section). Set it to -# NO to prevent subgrouping. Alternatively, this can be done per class using -# the \nosubgrouping command. - -SUBGROUPING = YES - -#--------------------------------------------------------------------------- -# Build related configuration options -#--------------------------------------------------------------------------- - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = NO - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = NO - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = YES - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = NO - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = NO - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these classes will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = YES - -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the -# documentation. - -HIDE_FRIEND_COMPOUNDS = NO - -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. - -HIDE_IN_BODY_DOCS = NO - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower-case letters. If set to YES upper-case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# users are advised to set this option to NO. - -CASE_SENSE_NAMES = YES - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = NO - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put a list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = YES - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = YES - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = YES - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = YES - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = YES - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = YES - -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. - -GENERATE_DEPRECATEDLIST= YES - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consists of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 30 - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = YES - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = NO - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = YES - -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. - -WARN_IF_DOC_ERROR = YES - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. - -WARN_FORMAT = "$file:$line: $text" - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -INPUT = ../src \ - DoxyPython.txt \ - DoxyMainPageUser.txt \ - DoxyInstallation.txt \ - DoxyPython.txt \ - DoxyIntroduction.txt - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp -# *.h++ *.idl *.odl *.cs *.php *.php3 *.inc - -FILE_PATTERNS = *.cxx \ - *.h - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = NO - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = ../src/iddcmjpeg.h \ - ../src/gdcmJpeg.cxx - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories -# that are symbolic links (a Unix filesystem feature) are excluded from the input. - -EXCLUDE_SYMLINKS = NO - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. - -EXCLUDE_PATTERNS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = ../gdcmPython/demo - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command

Gdcm coding style (and other religious/agnostic beliefs)

+ +

+* Introduction:
+   The following coding style intends to ease the work of developpers
+   themselves but also of users who will study, maintain, fix, and extend
+   the code. Any bread crumbs that you can drop in the way of explanatory
+   names and comments will go a long way towards helping other readers and
+   developers.
+   Keep in mind that to a large extent the structure of code directly
+   expresses its implementation.
+                                                                                
+* Language:
+ - C++ (for the kernel) and Python (for the wrappers).
+ - all the names (variables, members, methods, functions) and comments
+   should be based on English. Documentation, guides, web site and other
+   informations should be in English.
+   Make sure you use correct (basic) English and complete, grammatically
+   correct sentences for comments and documentation.
+                                                                                
+* General layout:
+ - Each line of code should take no more than 79 characters. Break the code
+   across multiple lines as necessary.
+ - Methods and functions should keep a reasonable number of lines when
+   possible (a typical editor displays 50 lines). Avoid code duplication.
+   Always prefer creating a new method or function to duplication.
+   A high indentation level generally suggests the need for a new
+   method or function.
+ - All the code should be properly indented. The appropriate indentation
+   level is three spaces for each level of indentation. DO NOT USE TABS.
+   Set up your editor to insert spaces. Using tabs may look good in your
+   editor but will wreak havoc in others, or in external tools (e.g. side
+   by side diffs).
+ - The declaration of variables within classes, methods, and functions
+   should be one declaration per line. Provide them with default values
+   and don't rely on compilers for default initialization.
+                                                                                
+* Naming conventions:
+ - Generalities:
+   In general, names are constructued by using case change to indicate
+   separate words, as in ImageDataSize (standing for "image data size").
+   Underscores are not used. Variable names are chosen carefully with the
+   intention to convey the meaning behind the code. Names are generally
+   spelled out; use of abbreviations is discouraged.
+   [Note: abbreviation are allowable when in common use, and should be in
+    uppercase as in LUT or RGBA.]
+   While this does result in long names, it self-documents the code.
+ - Naming Files:
+   Files should have the same name as the class, with a "gdcm" prepended.
+   Header files are named .h, while implementation files are named either
+   .cxx or .txx, depending on whether they are implementations of templated
+   classes. For example, the class gdcm::Document is declared and defined
+   in the files gdcmDocument.h and gdcmDocument.cxx.
+ - Naming Class Data Members, Methods, and Functions:
+   Class data members are named beginning with a capital letter as in
+   GroupPixel.
+   Global functions and class methods, either static or class members, are
+   named beginning with a capital letter, as in GetImageDataSize().
+ - Naming Local Variables:
+   Local variables begin in lowercase. There is more flexibility in the
+   naming of local variables although they still should convey some
+   semantics.
+                                                                                
+* Classes:
+ - Don't use the inline keyword when defining an inline function
+   within a class definition.
+ - As stated in the "Naming conventions" section, class data members
+   are named beginning with a capital letter as in GroupPixel.
+   But the parameter names of method should be named with a lowercase
+   letter (in order to distinguish at a glance data members, from parameters
+   and also to avoid potential collisions with data members):
+      void A::SetGroupPixel( int groupPixel )
+      {
+         GroupPixel = groupPixel;
+      }
+ - Do not repeat the virtual keyword when overriding virtual base methods
+   in declaration of subclasses:
+     class A
+     {
+        virtual void foo(...);
+     };
+     class B: public A
+     {
+        void foo(...);          // and not: virtual void foo(...);
+     };
+ - The public, protected, private declarations should be at the
+   same indent level as the class. Use
+     class A
+     {
+     private:
+        void foo(...);
+     public:
+        void bar(...);
+     };
+ - Method and functions devoided of arguments should not use the void
+   notation. Use
+     SomeType Header::GetPixelData()
+   and not
+     SomeType Header::GetPixelData(void).
+                                                                                
+* Use of braces:
+ - Braces must be used to delimit the scope of an if, for, while, switch, or
+   other control structure. Braces are placed on a line by themselves, and
+   at the same indentation level as the control structure to which they
+   belong:
+      for (i=0; * i<3; i++)
+      {
+         ...
+      }
+   or when using an if:
+      if ( condition )
+      {
+         ...
+      }
+      else if ( other condition )
+      {
+         ...
+      }
+      else
+      {
+         ....
+      }
+   You can choose to use braces on a line with a code block when
+   the block consists of a single line:
+      if ( condition ) { foo=1; }
+      else if ( condition2 ) { foo=3; }
+      else { return; }
+   or
+      for (i=0; i<3; ++i) {x[i]=0.0;}
+   Methods and functions should follow the same usage of braces:
+      void File::ParsePixelData()
+      {
+         ...
+      }
+
+* Special layout:
+ - Avoid code mixed with comments on a single line. Instead, prepend the
+   logical blocks of code with the concerned comments.
+ - Use parantheses around conditions e.g. with an if statement:
+      if ( someLocalVariable == 2 ) { ... }
+ - Add spaces around parantheses, or braces. Use
+      if ( someLocalVariable == 2 ) { ClassMenber += 1; }
+   and not
+      if (someLocalVariable == 2) {ClassMenber += 1;}
+ - Add spaces around each side of the assignement operator, and
+   around binary operators used in boolean expression. Use
+      someLocalVariable = ClassMember * 2;
+      if ( someLocalVariable == 2 || ClassMember == 2 ) ...
+   and not
+      someLocalVariable=ClassMember*2;
+      if ( someLocalVariable==2||ClassMember==2 ) ...
+                                                                                
+* Miscelaneous:
+ - Don't use underscores. Don't use tabs. Don't use control characters
+   like ^M. Anyhow, cvs is configured to reject such commits.
+ - Comments should be in C++ style ("// ...", two slashes, per line). Don't
+   use C style comments ("/* ... */").
+ - The last line of a file should terminate with "\n".
+ - Returned arguments of methods and functions should not be wrapped with
+   parantheses. Use
+      return iter->second;
+   but do not use
+      return ( iter->second );
+                                                                                
+* Debugging and Verbose modes:
+   Never use std::cout. Instead use the gdcmDebug class through the
+   global instance dbg. Example:
+      #include "gdcmDebug.h"
+      ...
+      {
+         dbg.Verbose(3, "Local function name: entering.");
+         ...
+      }
+    will send the message to std::cout when dbg.Debug() is called
+    in your main.
+                                                                                
+* Documentation:
+   The Doxygen open-source system is used to generate on-line documentation.
+   Doxygen requires the embedding of simple comments in the code which is in
+   turn extracted and formatted into documentation. See
+      http://www.stack.nl/ dimitri/doxygen/
+   for more information about Doxygen.
+ - Documenting a class:
+   Classes should be documented using the class and brief doxygen commands,
+   followed by the detailed class description:
+      /**
+       * \class Header
+       * \brief Header acts as container of Dicom elements of an image.
+       *
+       * Detailed description of the class is provided here
+       * ...
+       */
+   The key here is that the comment starts with /**, each subsequent line has
+   an aligned *, and the comment block terminates with a */.
+ - Documenting class members and inline methods:
+   All the members and the inline methods should be documented within
+   the class declaration as shown in the following example:
+      class Header
+      {
+         /// True when parsing was succesfull. False otherwise.
+         bool Readable = false;
+                                                                                
+         /// \brief The number of lines of the image as interpreted from
+         /// the various elements encountered at header parsing.
+         int NumberOfLines = -1;
+                                                                                
+         /// Predicate implemented as accessor around \ref Readable.
+         bool IsReadable() { return Readable; }
+      };
+ - Documenting a Method:
+   Methods should be documented using the following comment block style
+   as shown in the following example:
+                                                                                
+      /**
+       * \brief  Within the Dicom Elements (parsed with the public and private
+       *         dictionaries), look for the element value representation of
+       *         a given tag.
+       * @param  group Group number of the searched tag.
+       * @param  element Element number of the searched tag.
+       * @return Corresponding element value representation when it exists,
+       *         and the string "gdcm::Unfound" otherwise.
+       */
+      std::string Document::GetEntryByNumber(guint16 group, guint16 element)
+      {
+         ...
+      }
+                                                                                
+* External includes and C style:
+ - Only the C++ standard library and the STL includes should be used.
+   When including don't use the .h extension (use #include 
+   instead of #include ).
+ - Don't use the C standard library. Don't include stdio.h, ctype.h...
+   Don't use printf(), sprinf(), FILE*...
+ - Don't use the NULL notation (either as macro, or as const int NULL=0).
+   A pointer that doesn't refer to an object should simply be defined as
+      DataPointer* MyDataPointer = 0;
+                                                                                
+* Basic types:
+ - Assume T is a given type. When declaring or defining with the
+   "pointer to T" notation, the * character must be adjacent to
+   the type and not the variable. That is use
+      T* foo = 0;
+   and not
+      T *foo = 0;
+ - Always define a typedef for a new type and be consistent in usage.
+   Use
+      typedef Header* HeaderPointer;
+      HeaderPointer MyHeaderPointer;
+ - One notorious counter example for non using C style inclusion concerns
+   exact-width integers (since there seem to be no equivalent for C++).
+   When using exact-width integers use the typedef names defined by
+   the Basic ISO C99: 7.18 Integer types i.e.
+      int8_t     int16_t     int32_t     int64_t (signed integers)
+   and
+      uint8_t    uint16_t    uint32_t    uint64_t (unsigned integers).
+   Conversion table is then:
+    unsigned char       -> uint8_t;
+    unsigned short      -> uint16_t;
+    unsigned int        -> uint32_t;
+    unsigned long       -> uint32_t;
+    unsigned long long  -> uint64_t;
+    (signed) char       -> int8_t;
+    short               -> int16_t;
+    int                 -> int32_t;
+    long                -> int32_t;
+    long long           -> int64_t;
+   Hence do not use declarations like "unsigned int".
+   With g++, accessing those typedef is achieved by the following
+      #include 
+

+ + + +

+ + + diff --git a/Doc/Website/Developpers.html b/Doc/Website/Developpers.html new file mode 100644 index 00000000..cf6540f4 --- /dev/null +++ b/Doc/Website/Developpers.html @@ -0,0 +1,71 @@ + + + + + Gdcm Developpers + + + + + +

Gdcm Developpers

+ +First you should be familiar on how to +recompile, install and test +gdcm from the +sources obtained with cvs. +
+ +Please adopt the +coding style. +
+ +

CVS policy

All the commits should be atomic. They must preserve the compilation + in order to prevent checkouts with broken code. +
All the commits must correspond to a state of the code where ctest + runs and has no failing subtest. Always run ctest before commiting. +
+ Notes: +
- you can start ctest in verbose mode through the command + ctest -V >& log +
- you can start a single test through ctest with + ctest -R FailingTestName -V >& log +
+

+ + +

Compiler flags policy

+When working with gcc please use the following flags when +configuring the cmake variable CMAKE_CXX_FLAGS +
+-g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter + -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated + -Woverloaded-virtual + + + +

Sending the result to kitware's dashboard (optional)

+Use ctest -D Experimental. +
+The results should appear in + + Kitware's dashboard +under the name of your machine (uname). For ease of use you can +change the SITE variable in your CMakeCache.txt to something more +accurate such as: GDCM-my_machine_name. The entry will then be within +the "Experimental Builds" entry. + + + +

+ + + diff --git a/Doc/Website/DeveloppersPython.html b/Doc/Website/DeveloppersPython.html new file mode 100644 index 00000000..26d394be --- /dev/null +++ b/Doc/Website/DeveloppersPython.html @@ -0,0 +1,91 @@ + + + + + GdcmPython + + + + + +

Python wrappers for gdcm

+ + +

Working with Python

cd GDCM_HOME +
export PYTHONPATH=`pwd` +
cd gdcmPython +
ln -s .libs/pygdcm.so _gdcm.so +
(this is because automake doesn't allow the building of libraries + whose name starts with an underscore. Since we need the + wrapper library to be named _gdcm [because swig automaticatily uses + this name when building the shadow classes], automake generates + pygdcm.so and at install stage stage renames it to _gdcm.so). +
You can then use gdcmPython for manual test/demos +
1. cd GDCM_HOME/gdcmPython/demo +
2. python PrintHeader.py +
+

+ + +

+  Depending on the cmake flags you used in order to compile gdcm could
+  be wrapped in two ways:
+  - the first python wrappers of gdcm uses Swig (http://www.swig.org). These
+    are the one generated when using autogen.sh --enable-python.
+    The entry point here is the file gdcmPython/gdcm.i which uses the
+    Swig syntax. As the last lines of this file (the ones starting
+    with the %include directive) only some classes are wrapped for python.
+    In theory only the library interface (basically the classes gdcmHeader
+    and gdcmFile) should be wrapped, but the time being some additional
+    classes are added (just to make sure those classes are Swig compatible:
+    swig is here used as some link checker!?).
+    Since gdcm is written in C++, Swig will produce two different outputs:
+      -- some C based low level wrapper (see gdcmPython/gdcm_wrap.c)
+      -- some Python based object oriented so called "shadow classes" (see
+         file gdcmPython/gdcm.py)
+    We also added the file gdcmPython/__init__.py which is the one that
+    actually gets loaded when one uses the gdcmPython Python package.
+    The file __init__.py loads the Swig generated shadow classes (gdcm.py)
+    but will only re-export the interface of gdcm which corresponds to
+    the lines :
+       gdcmHeader = gdcm.gdcmHeader
+       gdcmDictSet = gdcm.gdcmDictSet
+       gdcmFile = gdcm.gdcmFile
+       [etc.]
+    Hence this whole Swig wrapping process is quite odd since we shall
+    wrap more classes (%include in swig.i) that eventually get exported to
+    the final user by gdcmPython/__init__.py.
+  - the second python wrappers uses the vtk (http://public.kitware.com/VTK/)
+    native wrappers i.e. the binary vtkWrapPython. But it should be noticed
+    that the purpose is here a bit different than the one of the Swig
+    generated Python wrappers. When using vtkWrapPython the goal is to
+    wrap a single vtk class namely vtkGdcmReader as defined in files
+    vtk/vtkGdcmReader.h and vtk/vtkGdcmReader.cxx (and of course those
+    files are hand made vtk oriented wrappers of gdcm).
+    Those wrappers are the one generated when using
+       autogen.sh --enable-python --enable-vtk
+  - In order to understand the difference between both wrappers you should
+    compare both demo scripts gdcmPython/demo/vtkGdcmDemo.py and
+    gdcmPython/demo/vtkGdcmReader.py. The first one only uses the
+    Swig wrapped classes ("from gdcmPython import gdcmHeader') as opposed
+    to vtkGdcmReader.py which also uses vtkWrapPython wrapped classes
+    ("from gdcmPython.vtkgdcmPython import *").
+

+ + +

+ + + diff --git a/Doc/Website/Download.html b/Doc/Website/Download.html index 74006085..3657b80e 100644 --- a/Doc/Website/Download.html +++ b/Doc/Website/Download.html @@ -21,7 +21,8 @@ page.

Packaged distributions of gdcm last stable - version 0.4 + version 0.4 + (February 6 2004)

Please refer to the @@ -92,6 +93,17 @@ with the cvs tag Version0_4 e.g. cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co -r Version0_4 gdcm. + +

Packaged distributions of intermediate version of Apr 20 2004

+ +RPM for rh9 and fc1 (sources and binaries). +

for RedHat 9 +
for Fedora Core 1 +

@@ -100,8 +112,11 @@ with the cvs tag Version0_4 e.g.

- version 0.3 + version 0.3, +
+ version 0.1. +

diff --git a/Doc/Website/DownloadVersion0_1.html b/Doc/Website/DownloadVersion0_1.html new file mode 100644 index 00000000..9e954914 --- /dev/null +++ b/Doc/Website/DownloadVersion0_1.html @@ -0,0 +1,82 @@ + + + + + Gdcm Download Version0_1 + + + + + +

gdcm download of version 0.1

+ + +

Sources +
- For + gdcmPython + a compressed tarball is available + + gdcmPython-0.1.tar.gz. +
- The full sources of version 0.1 can be retrieved + through cvs (see gdcm cvs access) + with the cvs tag April2003 e.g. +
  + cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co + -r April2003 gdcm +. +
+
Win32 + +
- Sorry but the Kernel Win32 packaging starts at version 0.4. +
- Windoze self installer of gdcmPython + + gdcmPython-0.1.win32-py2.2.exe for Win32 (expects Python2.2.x). +
+
GNU/Linux RPM packages + +
- Gdcm kernel + Sorry but the Kernel rpm packaging (both sources and binaries) + starts at + version 0.3. +
- GdcmPython (source and binaries) +
  - Source rpm + + gdcmPython-0.1-1.src.rpm, + requires swig 1.3.17.x [ + + swig13-1.3.17-1.i386.rpm, + + swig13-1.3.17-1.src.rpm] +
  - Binary rpm + + gdcmPython-0.1-1.i386.rpm, + (depends on Python2.2.x) +
  +
+

+ + +

+ + + diff --git a/Doc/Website/DownloadVersion0_3.html b/Doc/Website/DownloadVersion0_3.html new file mode 100644 index 00000000..b25aea66 --- /dev/null +++ b/Doc/Website/DownloadVersion0_3.html @@ -0,0 +1,90 @@ + + + + + Gdcm Download Version0_3 + + + + + +

gdcm download of version 0.3

+ +Please refer to the + News on version 0.3 +for more information on the features of this release + +

Win32 + +
- Sorry but the Kernel Win32 packaging starts at version 0.4. +
- Zipped archive or sources + + gdcmPython-0.3.zip, +
- Windoze self installer of gdcmPython + + gdcmPython-0.3.win32-py2.2.exe for Win32 (expects Python2.2.x). +
+
GNU/Linux RPM packages + +
- Gdcm kernel +
  - Sources in a compressed tarball: + + gdcm-0.3.0.tar.gz. +
  - Source rpm + + gdcm-0.3.0-1.src.rpm, + which requires swig 1.3.17.x [ + + swig13-1.3.17-1.i386.rpm, + + swig13-1.3.17-1.src.rpm] +
  - Binary rpm + + gdcm-0.3.0-1.i386.rpm. +
  +
- GdcmPython (source and binaries) +
  - Sources in a compressed tarball: + + gdcmPython-0.3.tar.gz. +
  - Source rpm + + gdcmPython-0.3-1.src.rpm, +
  - Binary rpm + + gdcmPython-0.3-1.i386.rpm, + (depends on Python2.2.x) +
  +
+

+ +Note: The corresponding sources can be retrieved through cvs (see +gdcm cvs access) +with the cvs tag Version0_3 e.g. +
+cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co + -r Version0_3 gdcm. + +

+ + + diff --git a/Doc/Website/GdcmDataCvs.html b/Doc/Website/GdcmDataCvs.html new file mode 100644 index 00000000..626254df --- /dev/null +++ b/Doc/Website/GdcmDataCvs.html @@ -0,0 +1,46 @@ + + + + + GdcmData access with cvs + + + + + +

Using CVS for retrieval of gdcmData

+ + +To learn more about CVS and to get the CVS programs, please refer to the +CVS Home. + +

GENERAL +
- Repository server: + :pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public +
- Password is anonymous +
+
Linux + + (if your shell is not bash then please adapt the syntax) +
- export CVSROOT=:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public +
- cvs login (at prompt CVS password answer anonymous) +
- cvs checkout gdcmData +
+
Windows (WinCVS 1.2) + +
- Tag general - CVSROOT : + :pserver:anonymous@cvs.creatis.insa-lyon.fr:/cvs/public +
- Tag Ports - check 'For pserver' : 2402 +
+

+ +

+ + + + diff --git a/Doc/Website/Installation.html b/Doc/Website/Installation.html index 2451dd2d..d9a86833 100644 --- a/Doc/Website/Installation.html +++ b/Doc/Website/Installation.html @@ -12,7 +12,7 @@

Requirements

For the core C++ library you shall need a C++ compiler with the "list" and "map" STL containers. @@ -57,49 +57,206 @@

+ +

GNU/Linux walkthrough for the impatient bash user

cd SOMEWHERE +
+ export CVSROOT=:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public + +
cvs login (at prompt CVS password + answer with anonymous) +
cvs co gdcm +
[Optional, for test suite] + cvs co gdcmData +
mkdir gdcmInstall +
mkdir gdcmBin +
cd gdcmBin +
ccmake ../gdcm +
- + Toggle and adjust the required options and parameters +
  + (see below for more info) +
- hit c + (a couple times, until no stars appear, in order configure) +
- hit g (generate makefiles) +
- hit q (quit ccmake) +
+
make +
make install +
[Optional] make test +

Step by step recompilation

Retrieve gdcm the - - sources through cvs. - We shall refer to this source directory as gdcmSources. +
Retrieve the + + sources of gdcm through cvs + and expand them in a source directory that we + shall refer as gdcmSOURCES.
Create a compile directory (e.g. gdcmBin) that we shall refer as gdcmBINARY. - Change working directory to gdcmBINARY.
Invoke ccmake (from gdcmBINARY) with gdcmSources - as source directory. +
[Optional] if you wish to install in a temporary installation + directory, create it. We shall refer to this directory + as gdcmINSTALL. +
Change working directory to gdcmBINARY. +
Invoke ccmake (from gdcmBINARY) with gdcmSOURCES + as source directory e.g. ccmake ../gdcm on Un*ces or + invoke CMakeSetup on Win32 and setup the source directory + and the compile directory.
- Hit "c" for a first automatic configuration of your platteform + Hit c for a first automatic configuration + of your platteform.
Select the options that suite your needs. Basically this means +
Select the options that best suits your needs. Basically this means toggling ON or OFF the following parameters
- GDCM_DOXYGEN - if you wish to generate the doxygen documentation, -
- GGDCM_VTK - if you wish to generate the VTK wrappers, + if you wish to generate the VTK wrappers. + When automatic configuration fails you should manually set up + the cmake variable VTK_DIR.
- GDCM_WRAP_PYTHON if you wish to generate the Python wrappers.
- GDCM_DOXYGEN + if you wish to generate the doxygen documentation, +
Among the other options, you might consider toggling ON or OFF the following parameters
- CMAKE_INSTALL_PREFIX + should be set to gdcmINSTALL. +
- BUILD_EXAMPLES if you wish to generate the C++ gdcm examples,
- BUILD_TESTING if you wish to generate gdcm test suite. When doing so you will - need to retrieve gdcmData i.e. the set of Dicom image used in - the test suite. + need to +
  - retrieve gdcmData + i.e. the set of Dicom image used in the test suite and + expand them in a directory refered as gdcmDATA. +
  - setup cmake GDCM_DATA_ROOT to gdcmDATA. +
  +
- CMAKE_BUILD_TYPE can be set up to Debug + if you plan to use your native debugger. +
- CMAKE_CXX_FLAGS for cautious developpers should be + set to + -g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter + -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated + -Woverloaded-virtual + +
+
+ Hit c a couple times until they are no remaining "*" + (star character) preceeding the values of the gdcm variables. +
+ If you get warnings about + CMake forcing CMAKE_CXX_FLAGS (or other compiler variables) + simply ignore them and hit e to resume configuration. +
+ Hit g in order to generate the makefiles (on Un*x) + or the workspace and project (on Win32). +
+ Hit q to exit from ccmake. +
On Un*x launch make. On Win32 enter the VC++ gdcm.dsw + and lauch a build all. +

+ + +

Installation

+This is an optional stage for developpers. +
+On Un*x proceed with the install stage with make install. + + +

Running the test suite

+The impatient can run the full test suite with make test. +
+For the test suite to be effective, you must have set +BUILD_TESTING to ON when configuring ccmake. +

+
- if you run the tests BEFORE installing then + positionate the environment variable GDCM_DICT_PATH + to gdcmSOURCES/Dicts + (e.g. export GDCM_DICT_PATH=$(gdcmSOURCES)/Dicts) +
- if you run the tests AFTER installing then + positionate the environment variable GDCM_DICT_PATH + to gdcmINSTALL/share + (e.g. export GDCM_DICT_PATH=$(gdcmINSTALL)/Dicts) +
+
Assuming your current working directory is gdcmBINARY + the gdcm tests can be run in three different modes: +
1. Interactive access by number: run + ./bin/gdcmTests + and select the number of the test you wish to run. +
2. Access to a test through it's name : pass the name of the + test as an argument to + ./bin/gdcmTests + e.g. + ./Test/gdcmTests TestAllEntryVerify. +
3. Launch the full test suite : (again we assume the + current working directory is gdcmBINARY) + run ctest. This is equivalent to make test. +
  + ctest supports some options (refer to the + CMake documentation + for other options) : +
  - a verbose mode e.g. ctest -V +
  - argument filtering with regexp e.g. ctest -R print -V + runs the tests containing "print" in their name and + makes a verbose output. +

diff --git a/Doc/Website/Main.html b/Doc/Website/Main.html index d7e43447..457d9d91 100644 --- a/Doc/Website/Main.html +++ b/Doc/Website/Main.html @@ -14,7 +14,7 @@ Gdcm is yet another C++ library dedicated to reading/parsing and writing Dicom medical files.
-GDCMstands as a short for "Grass roots +GDCM stands as a short for "Grass roots DiCoM. @@ -37,14 +37,13 @@ Gdcm is yet another C++ library dedicated to reading/parsing and writing

gdcm targets both GNU/Un*ces and Windows/VC++ (refer to - - requirements + requirements for details).

gdcm comes with a VTK shallow wrapper class vtkGdcmReader (refer to - VtkGdcm.html) + VtkGdcm) to ease the burden of VTK users,

gdcm also comes with gdcmPython diff --git a/Doc/Website/Sidebar.html b/Doc/Website/Sidebar.html index 1365fd30..91a29910 100644 --- a/Doc/Website/Sidebar.html +++ b/Doc/Website/Sidebar.html @@ -87,17 +87,23 @@ - - Documentation + Full Documentation - Developpers + + + Python Developpers + + @@ -107,7 +113,7 @@ - Browsing the sources + Online browsing of sources -- 2.45.2