squib 0.9.0 → 0.10.0

data/docs/args/expansion.rst

@@ -0,0 +1,3 @@
+.. :orphan:
+
+All of these options support arrays and singleton expansion (except for **range**). See :doc:`/arrays` for deeper explanation.

data/docs/args/layout.rst

@@ -0,0 +1,6 @@
+.. :orphan:
+
+layout
+  default: ``nil``
+
+  entry in the layout to use as defaults for this command. See :doc:`/layouts`.

data/docs/args/output_dir.rst

@@ -0,0 +1,6 @@
+.. :orphan:
+
+dir
+  default: ``_output``
+
+  The directory for the output to be sent to. Will be created if it doesn't exist. Relative to the current directory.

data/docs/args/range.rst

@@ -0,0 +1,6 @@
+.. :orphan:
+
+range
+  default: ``:all``
+
+  the range of cards over which this will be rendered. See :ref:`using_ranges`

data/docs/args/transform.rst

@@ -0,0 +1,51 @@
+.. :orphan:
+
+angle
+  default: ``0``
+
+  Rotation of the in radians. Note that this rotates around the upper-left corner, making the placement of x-y coordinates slightly tricky.
+
+crop_x
+  default: ``0``
+
+  Crop the loaded image at this x coordinate. Supports :doc:`/units`.
+
+crop_y
+  default: ``0``
+
+  Crop the loaded image at this y coordinate. Supports :doc:`/units`.
+
+crop_corner_radius
+  default: ``0``
+
+  Radius for rounded corners, both x and y. When set, overrides crop_corner_x_radius and crop_corner_y_radius. Supports :doc:`/units`.
+
+crop_corner_x_radius
+  default: ``0``
+
+  x radius for rounded corners of cropped image. Supports :doc:`/units`.
+
+crop_corner_y_radius
+  default: ``0``
+
+  y radius for rounded corners of cropped image. Supports :doc:`/units`.
+
+crop_width
+  default: ``:native``
+
+  Width of the cropped image. Supports :doc:`/units`.
+
+crop_height
+  default: ``:native``
+
+  Height of the cropped image. Supports :doc:`/units`.
+
+flip_horiztonal
+  default: ``false``
+
+  Flip this image about its center horizontally (i.e. left becomes right and vice versa).
+
+flip_vertical
+  default: ``false``
+
+  Flip this image about its center verticall (i.e. top becomes bottom and vice versa).

data/docs/args/trim.rst

@@ -0,0 +1,11 @@
+.. :orphan:
+
+trim
+  default: ``0``
+
+  the margin around the card to trim before putting into the image
+
+trim_radius
+  default: ``0``
+
+  the rounded rectangle radius around the card to trim before putting into the image

data/docs/args/wh.rst

@@ -0,0 +1,12 @@
+.. :orphan:
+
+width
+  default: ``:deck`` (the width of the deck)
+
+  the width of the box. Supports :doc:`/units`.
+
+
+height
+  default: ``:deck`` (the height of the deck)
+
+  the height of the box. Supports :doc:`/units`.

data/docs/args/xy.rst

@@ -0,0 +1,12 @@
+.. :orphan:
+
+x
+  default: ``0``
+
+  the x-coordinate to place, relative to the upper-left corner of the card and moving right as it increases. Supports :doc:`/units`.
+
+
+y
+  default: ``0``
+
+  the y-coordinate to place, relative to the upper-left corner of the card and moving downward as it increases. Supports :doc:`/units`.

data/docs/arrays.rst

@@ -0,0 +1,77 @@
+Squib Thinks in Arrays
+======================
+
+When prototyping card games, you usually want some things (e.g. icons, text) to remain the same across every card, but then other things need to change per card. Maybe you want the same background for every card, but a different title.
+
+The vast majority of Squib's DSL methods can accept two kinds of input: whatever it's expecting, or an array of whatever it's expecting. If it's an array, then Squib expects each element of the array to correspond to a different card.
+
+Think of this like "singleton expansion", where Squib goes "Is this an array? No? Then just repeat it the same across every card". Thus, these two DSL calls are logically equivalent::
+
+  Squib::Deck.new(cards: 2) do
+    text str: 'Hello'
+    text str: ['Hello', 'Hello'] # same effect
+  end
+
+But then to use a different string on each card you can do::
+
+  Squib::Deck.new(cards: 2) do
+    text str: ['Hello', 'World']
+  end
+
+.. note::
+
+  Technically, Squib is only looking for something that responds to ``each`` (i.e. an Enumerable). So whatever you give it should just respond to ``each`` and it will work as expected.
+
+What if you have an array that doesn't match the size of the deck? No problem - Ruby won't complain about indexing an array out of bounds - it simply returns ``nil``. So these are equivalent::
+
+  Squib::Deck.new(cards: 3) do
+    text str: ['Hello', 'Hello']
+    text str: ['Hello', 'Hello', nil]  # same effect
+  end
+
+In the case of the :doc:`/dsl/text` method, giving it an ``str: nil`` will mean the method won't do anything for that card and move on. Different methods react differently to getting ``nil`` as an option, however, so watch out for that.
+
+
+.. _using_ranges:
+
+Using ``range`` to specify cards
+--------------------------------
+
+There's another way to limit a DSL method to certain cards: the ``range`` parameter.
+
+Most of Squib's DSL methods allow a ``range`` to be specified. This can be an actual Ruby ``Range``, or anything that implements ``each`` (i.e. an Enumerable) that corresponds to the **index** of each card.
+
+Integers are also supported for changing one card only. Negatives work from the back of the deck.
+
+Some quick examples::
+
+  text range: 0..2  # only cards 0, 1, and 2
+  text range: [0,2] # only cards 0 and 2
+  text range: 0     # only card 0
+
+Behold! The Power of Ruby Arrays
+--------------------------------
+
+One of the more distinctive benefits of Ruby is in its rich set of features for manipulating and accessing arrays. Between ``range`` and using arrays, you can specify subsets of cards quite succinctly. The following methods in Ruby are particularly helpful:
+
+  * `Array#each <http://ruby-doc.org/core-2.2.0/Array.html#method-i-each>`_ - do something on each element of the array (Ruby folks seldom use for-loops!)
+  * `Array#map <http://ruby-doc.org/core-2.2.0/Array.html#method-i-map>`_ - do something on each element of an array and put it into a new array
+  * `Array#select <http://ruby-doc.org/core-2.2.0/Array.html#method-i-select>`_ - select a subset of an array
+  * `Enumerable#each_with_index <http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-each_with_index>`_ - do something to each element, also being aware of the index
+  * `Enumerable#inject <http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-inject>`_ - accumulate elements of an array in a custom way
+  * `Array#zip <http://ruby-doc.org/core-2.2.0/Enumerable.html#method-i-zip>`_ - combine two arrays, element by element
+
+Examples
+--------
+
+Here are a few recipes for using arrays and ranges in practice:
+
+.. raw:: HTML
+
+  <script src="https://gist.github.com/andymeneely/25b0da2a84ab906bd44b.js"></script>
+
+
+Contribute Recipes!
+-------------------
+
+There are a lot more great recipes we could come up with. Feel free to contribute! You can add them here via pull request or `via the wiki <https://github.com/andymeneely/squib/wiki>`_

data/docs/backends.rst

@@ -0,0 +1,20 @@
+Vector vs. Raster Backends
+==========================
+
+Squib's graphics rendering engine, Cairo, has the ability to support a variety of surfaces to draw on, including both raster images stored in memory and vectors stored in SVG files. Thus, Squib supports the ability to handle both. They are options in the configuration file ``backend: memory`` or ``backend: svg`` described in :doc:`/config`.
+
+If you use :doc:`/dsl/save_pdf` then this backend option will determine how your cards are saved too. For `memory`, the PDF will be filled with compressed raster images and be a larger file (yet it will still print at high quality... see discussion below). For SVG backends, PDFs will be smaller. If you have your deck backed by SVG, then the cards are auto-saved, so there is no ``save_svg`` in Squib. (Technically, the operations are stored and then flushed to the SVG file at the very end.)
+
+There are trade-offs to consider here.
+
+* Print quality is **usually higher** for raster images. This seems counterintuitive at first, but consider where Squib sits in your workflow. It's the final assembly line for your cards before they get printed. Cairo puts *a ton* of work into rendering each pixel perfectly when it works with raster images. Printers, on the other hand, don't think in vectors and will render your paths in their own memory with their own embedded libraries without putting a lot of work into antialiasing and various other graphical esoterica. You may notice that print-on-demand companies such as The Game Crafter `only accept raster file types <http://help.thegamecrafter.com/article/38-supported-file-types>`_, because they don't want their customers complaining about their printers not rendering vectors with enough care.
+* Print quality is **sometimes higher** for vector images, particularly in laser printers. We have noticed this on a few printers, so it's worth testing out.
+* PDFs are **smaller** for SVG back ends. If file size is a limitation for you, and it can be for some printers or internet forums, then an SVG back end for vectorized PDFs is the way to go.
+* Squib is **greedy** with memory. While I've tested Squib with big decks on older computers, the `memory` backend is quite greedy with RAM. If memory is at a premium for you, switching to SVG might help.
+* Squib does **not support every feature** with SVG back ends. There are some nasty corner cases here. If it doesn't, please file an issue so we can look into it. Not every feature in Cairo perfectly translates to SVG.
+
+.. note::
+
+  You can still load PNGs into an SVG-backed deck and load SVGs into a memory-backed deck. To me, the sweet spot is to keep all of my icons, text, and other stuff in vector form for infinite scaling and then render them all to pixels with Squib.
+
+Fortunately, switching backends in Squib is as trivial as changing the setting in the config file (see :doc:`/config`). So go ahead and experiment with both and see what works for you.

data/docs/bleed.rst

@@ -0,0 +1,13 @@
+Always Have Bleed
+=================
+
+.. note::
+
+  TODO: Under construction
+
+* Always plan to have a printing bleed around the edge of your cards. 1/8 in is standard
+* Have a safe zone too
+* Layouts make this easy (see the built-in layouts)
+* Can use png overlays from templates to make sure it fits
+* Trim option is what is used everywhere in Squib
+* Trim_radius also lets you show your cards off like how they'll really look

data/docs/build_groups.rst

@@ -0,0 +1,47 @@
+Group Your Builds
+=================
+
+Often in the prototyping process you'll find yourself cycling between running your overall build and building a single card. You'll probably be commenting out code in the process.
+
+And even after your code is stable, you'll probably want to build your deck multiple ways: maybe a printer-friendly black-and-white version for print-and-play and then a full color version.
+
+Squib's Build Groups help you with these situations. By grouping your Squib code into different groups, you can run parts of it at a time without having to go back and commenting out code.
+
+Here's a basic example:
+
+.. raw:: html
+
+  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
+  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/gist-embed/2.4/gist-embed.min.js"></script>
+  <code data-gist-id="bda48487e3b8c9d15edb" data-gist-file="build_groups.rb"></code>
+
+Only one group is enabled by default: ``:all``. All other groups are disabled by default. To see which groups are enabled currently, the :doc:`/dsl/groups` returns the set.
+
+Groups can be enabled and disabled in several ways:
+
+  * The :doc:`/dsl/enable_group` and :doc:`/dsl/disable_group`  DSL methods can explicitly enable/disable a group. Again, you're back to commenting out the *enable_group* call, but that's easier than remembering what lines to comment out each time.
+  * When a ``Squib::Deck`` is initialized, the `environment variable <https://en.wikipedia.org/wiki/Environment_variable>`_ ``SQUIB_BUILD`` is consulted for a comma-separated string. These are converted to Ruby symbols and the corresponding groups are enabled.
+
+Note that the environment variables are intended to change from run to run, from the command line (see above gist for examples in various OS's).
+
+.. note::
+
+  There should be no need to set the SQUIB_BUILD variable globally on your system.
+
+Don't like how Windows specifies environment variables? One adaptation of this is to do the environment setting in a ``Rakefile``. Rake is the build utility that comes with Ruby, and it allows us to set different tasks exactly in this way. This Rakefile works nicely with our above code example:
+
+
+.. raw:: html
+
+  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
+  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/gist-embed/2.4/gist-embed.min.js"></script>
+  <code data-gist-id="bda48487e3b8c9d15edb" data-gist-file="Rakefile"></code>
+
+
+Thus, you can just run this code with commands like these::
+
+  $ rake
+  $ rake pnp
+  $ rake color
+  $ rake test
+  $ rake both

data/docs/colors.rst

@@ -0,0 +1,64 @@
+Specifying Colors & Gradients
+=============================
+
+Colors
+------
+
+by hex-string
+^^^^^^^^^^^^^
+
+You can specify a color via the standard hexadecimal string for RGB (as in HTML and CSS).  You also have a few other options as well. You can use:
+
+  * 12-bit (3 hex numbers), RGB. e.g. ``'#f08'``
+  * 24-bit (6 hex numbers), RRGGBB. e.g. ``'#ff0088'``
+  * 48-bit (9 hex numbers), RRRGGGBBB. e.g. ``'#fff000888'``
+
+
+Additionally, you can specify the alpha (i.e. transparency) of the color as RGBA. An alpha of ``0`` is full transparent, and ``f`` is fully opaque. Thus, you can also use:
+
+  * 12-bit (4 hex numbers), RGBA. e.g. ``'#f085'``
+  * 24-bit (8 hex numbers), RRGGBBAA. e.g. ``'#ff008855'``
+  * 48-bit (12 hex numbers), RRRGGGBBBAAA. e.g. ``'#fff000888555'``
+
+The ``#`` at the beginning is optional, but encouraged for readability. In layout files (described in :doc:`/layouts`), the ``#`` character will initiate a comment in Yaml. So to specify a color in a layout file, just quote it::
+
+  # this is a comment in yaml
+  attack:
+    fill_color: '#fff'
+
+
+by name
+^^^^^^^
+
+Under the hood, Squib uses the rcairo `color parser <https://github.com/rcairo/rcairo/blob/master/lib/cairo/color.rb>`_ to accept around 300 named colors. The full list can be found `here <https://github.com/rcairo/rcairo/blob/master/lib/cairo/colors.rb>`_.
+
+Names of colors can be either strings or symbols, and case does not matter. Multiple words are separated by underscores. For example, ``'white'``, ``:burnt_orange``, or ``'ALIZARIN_CRIMSON'`` are all acceptable names.
+
+by custom name
+^^^^^^^^^^^^^^
+
+In your ``config.yml``, as described in :doc:`/config`, you can specify custom names of colors. For example, ``'foreground'``.
+
+Gradients
+--------
+
+In most places where colors are allowed, you may also supply a string that defines a gradient. Squib supports two flavors of gradients: linear and radial. Gradients are specified by supplying some xy coordinates, which are relative to the card (not the command). Each stop must be between ``0.0`` and ``1.0``, and you can supply as many as you like. Colors can be specified as above (in any of the hex notations or built-in constant). If you add two or more colors at the same stop, then the gradient keeps the colors in the in order specified and treats it like sharp transition.
+
+The format for linear gradient strings look like this::
+
+  '(x1,y1)(x2,y2) color1@stop1 color2@stop2'
+
+The xy coordinates define the angle of the gradient.
+
+The format for radial gradients look like this::
+
+  '(x1,y1,radius1)(x2,y2,radius2) color1@stop1 color2@stop2'
+
+The coordinates specify an inner circle first, then an outer circle.
+
+In both of these formats, whitespace is ignored between tokens so as to make complex gradients more readable.
+
+If you need something more powerful than these two types of gradients (e.g. mesh gradients), then we suggest encapsulating your logic within an SVG and using the :doc:`/dsl/svg` method to render it.
+
+Examples
+--------

data/docs/conf.py

@@ -0,0 +1,287 @@
+# -*- coding: utf-8 -*-
+#
+# Squib documentation build configuration file, created by
+# sphinx-quickstart on Sat Jan 23 21:56:41 2016.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+import sphinx_rtd_theme
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Squib'
+copyright = u'MIT License'
+author = u'Andy Meneely'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = u'0.9.0'
+# The full version, including alpha/beta/rc tags.
+release = u'0.9.0'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+highlight_language = 'ruby'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'sphinx_rtd_theme' # https://github.com/snide/sphinx_rtd_theme
+html_style = 'css/squibdocs.css'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+html_extra_path = ['../samples']
+
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Squibdoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'Squib.tex', u'Squib Documentation',
+     u'Andy Meneely', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'squib', u'Squib Documentation',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'Squib', u'Squib Documentation',
+     author, 'Squib', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False