This page last updated: Sep 14, 2007

About Chromista:

• Hub for "designer graphics" — 2D formats characterized by heavy use of fills, colors, gradients, fonts.
• Very different from Rhizopod, which deals more with stroked engineering line drawings.
• Similar stream / database dual-form using YAML to express a data structure.

Introduction

Chromista is the hub designed to provide access to 2D "designer graphics."  The connected formats are well suited for web and print design, including things like icons, diagrams, and  artwork, though they may also contain images and text.  These formats focus more heavily on presentation than numerical accuracy.  While it is certainly possible to represent engineering graphics in this form, it is not well suited to editing because there are fewer geometric primitives.  Similarly, if you are trying to create artwork with fills and gradients, the engineering drawing nature of Rhizopod will be too restrictive.

However, exchanging information is what VectorSection is all about, so it is desirable to convert at least parts of each type of graphics to another.  The Chromista hub will enable very lossless exchange of print and web vector graphics, as well as providing a target format for new applications and an easily accessible data structure for simple scripting tasks.  Furthermore, once it is connected to Rhizopod, it will be possible to use the conversion programs as a print/publication system which is accessible in either batch or interactive environments.

Target Formats

The following is a preliminary list of formats targeted for connection to the Chromista hub.  It is very "subject to change without notice"™.

• .xar
• .wix
• .svg
• .ps
• .eps
• .pdf
• .ai
• .fig?

Design

This is a very informal specification process.  The following is the basic roadmap.

Goals

You may wish to compare/contrast the below to the XAR format.

Vectors:  (obviously)

Human Readable:  All data will be stored in YAML.

Random Access:  While it must be able to be represented in a stream format, the order of elements within this stream is not significant beyond the basic header.

Atomic:  This mostly goes without saying given the above.

Explicit:  As much as is practical, all of the information about a file is present and readable within the database.

Minimally Referential:  While references will be needed for practicality, it is desirable to have as much as possible about a given entity close to that entity.  Compatibility with connected formats will dictate the details here (both in favor of and against references.)

Structure and Layout

Chromista will have the same dual-form (stream and directory database) as Rhizopod.  The stream allows connectors to talk to each other directly and the database enables real-time interoperability and atomic access to entities and properties.

One of the implications of this is that strategies which depend on stream order cannot be used directly.  (PostScript and PDF refer to this as the "graphics state".)  For example, setting a state such as the color in postscript (while xara uses scope?) cannot be done based on the order of the stream.  Support for some type of scope may be necessary in order to integrate with xar/ps/pdf, but best compatibility with Rhizopod will come from using "styles" to represent the scope/state of a given entity's attributes.

The database-style of layout also prevents the use of backreferences, though these may be employed in crs2xar as a space optimization at some point.  Reusable records, on the other hand, are fair game and may even be able to be represented via symlinks.

Rhizopod (CAD) Compatibility

While 100% compatibility with Rhizopod is not feasible, maintaining per-entity or per-feature compatibility wherever possible will allow the most code-reuse and make the crs<->rzp link much simpler.  In the database form, this compatibility could even introduce the possibility of live interoperability between the two hubs via symlinks.

Coordinate System

A right-handed* coordinate system is required to make Chromista entities compatible with Rhizopod entities.  It appears that SVG is odd-man-out in the set, so a right-handed system will be used in Chromista.  For best two-way conversion to SVG, it may be desirable to translate everything (including viewport and page location) across the X-axis (simply negating all y-values.)  The exact implementation here largely depends on Inkscape and other SVG viewers/editors.

Aside:  Right-handed meaning that the origin is in the lower left with the X-axis positive to the right and the Y-axis positive upward.  This is commonly used in mathematics.  A left-handed coordinate system is commonly used for screen coordinates (due to a historical accident related to frame buffers?), with the origin in the upper left and the Y-axis positive downward.  The handedness is determined by orientating your thumb along the Z-axis (out of the page/screen) and aligning your knuckles to the X-axis.  Your fingers curl toward the Y-axis.

Entity/Feature Compatibility

This is the main reason that VectorSection is necessary.  While similarities to Rhizopod here would be *nice*, similarities to all of the "designer graphics" formats connected to Chromista will yield the greatest development efficiency.  The path of least resistance has yet to be determined, but will likely require per-entity and per-feature decisions.

Cross-Platform Issues

Little Endian .xar Data

Both the crs2xar and xar2crs connectors will be built with forced Little Endian encoding/decoding.  For Perl code, this is easy.  I need to investigate how this is done in C.

Compiled vs. Interpreted Code

The low-level external format implementations (xar, svg, ps, pdf, ai) will be best handled by using, adapting, or building a compiled (probably C) library which encapsulates the details of the format specifications.  In the case of .xar and .pdf formats, this will be a necessity because of the speed penalty of handling byte-by-byte records in an interpreted language.  In the case of .svg and .ps, it is most likely a matter of convenience in that other projects have already implemented parsers, validators, etc. in the form of C libraries.

The cross-platform implications of this (given portable code in the libraries) are simply a matter of distribution and installation.  Most prospective users on Windows systems will not have a compiler or know how to use it.  I anticipate the Windows build/distribution issues to be fairly trivial, but I have no immediate plans to provide installable binaries for this platform myself.

Old Macs

The legacy Mac (pre OS-X) system may not be a targeted platform.  This is mostly on account of anticipated low demand (is this the case?), but some technical challenges also exist.  Anything is possible, but at-a-glance consideration of demand vs. difficulty suggests that it is not a worthwhile goal.

Feature Comparison

I've started tabulating the features of the chromista-connected formats and figuring out how they overlap as well as how they will mesh with the Rhizopod features.  The table is here.