Technical specification

Events happening in the community are now at Drupal community events on www.drupal.org.
njivy's picture
Posted by njivy on June 12, 2006 at 3:10am

Our technical specification is available through Writeboard.com. (Ask for the password.) We finished the technical spec on May 30 and excised one line on June 6, 2006.

Comments

Low-fidelity text version of the spec

Posted by njivy on June 12, 2006 at 3:25am
njivy's picture
  1. Drupal
    1. The code must meet Drupal's coding standards.
    2. (Removed) The code must satisfy code-style.pl.
    3. The code should use existing Drupal APIs.
    4. The code must be compatible with the development version of
      Drupal.
    5. A copy of the code must be stored in Drupal's CVS
      repository.
    6. The student must maintain a project-type page on Drupal.org.
    7. The code must be at least one of the following:
      1. A Drupal module
      2. A Drupal theme
      3. A Drupal theme engine
      4. An improvement to the "core" of Drupal
    8. Installation of the code, in final form, should not require
      patches to Drupal's core.
  2. Google
    1. The student must comply with Google's Summer of Code student
      guidelines.
    2. The mentors must comply with Google's Summer of Code mentor
      guidelines.
  3. Project communication
    1. The student must send emails to the mentors at least once per
      week that either contain or link to a status report.
    2. The status report should describe the following:
      1. The student's recent progress
      2. The student's current tasks
      3. The student's challenges, both current and expected
  4. DruTeX
    1. The DruTeX system must include an image filter to convert
      instances of LaTeX environments into the corresponding style
      of image (see the original spec for examples).
    2. Filtered LaTeX equation-style and equations-style
      environments must include a named anchor--e.g. <equation
      id="equation-id"></equation> produces <a
      name="equation-id"></a>.
    3. Filtered LaTeX references must include a hyperlink to the
      corresponding named anchor--e.g. \ref{equation-id} produces
      <a href="#equation-id"></a>.
    4. The inline filtering system must not interpret \$ as the
      boundary of a LaTeX environment.
    5. The inline filtering system must use the Drupal input filter
      API.
    6. The inline filtering system must permit a site administrator
      to configure each filter instance separately.
    7. Each filter instance's configuration options must include the
      following:
      1. DPI
      2. Conversion method:
        1. dvipng
        2. ImageMagick
        3. custom shell command
      3. Name of template
      4. Authorized LaTeX commands
    8. The DruTeX system's global configuration options must include
      the following:
      1. Location of directory for temporary files
      2. Location of directory for storing filter and image
        results
      3. shell command to perform dvipng conversion
      4. shell commands to perform ImageMagick conversion
    9. The inline filtering system must remove or disable
      unauthorized LaTeX commands before executing LaTeX commands.
      1. The DruTeX system must include an HTML-to-LaTeX filter.
      2. The DruTeX system must include a LaTeX-to-HTML filter.
      3. If the site administrator identifies a LaTeX-to-image
        conversion tool in the configuration options, the inline
        filtering system must use the image filter. Otherwise, the
        inline filtering system must use LaTeX-to-HTML.
      4. The DruTeX system must include an API that enables other
        Drupal modules to add LaTeX environments.
      5. The DruTeX system must provide for each node a menu callback
        that returns a LaTeX document containing the node's content.
      6. If the site administrator identifies a LaTeX-to-PDF
        conversion tool in the configuration options, the DruTeX
        system must provide for each node a menu callback that
        returns a PDF document containing the node's content.
      7. The DruTeX system must control user access to LaTeX menu
        callbacks.
      8. The DruTeX system must control user access to PDF menu
        callbacks.
      9. The DruTeX system should include a function that converts a
        node's content to raw LaTeX (not a LaTeX document).
  5. Documentation
    1. The DruTeX system must include online user documentation
      describing how to use the DruTeX system.
    2. The DruTeX system must include developer documentation
      describing how external modules can hook into the system.
    3. The DruTeX system must include a file called "INSTALL.txt"
      describing how to install the system.

Test cases

Posted by njivy on June 28, 2006 at 1:31pm
njivy's picture

dfg, I need test cases for paragraph math, Eukleides, gnuplot, and chemistry rendering environments. The technical spec lacks examples of these types.

SoC 2006: DruTeX

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: