Version 0.3.0 is a significant revision of libvisualid, breaking both ABI and API compatibility with previous releases. The psueodorandom-number-generation routines have been rebuilt around GLib's (Mersenne Twister) generator, which means that the VisualID glyphs output for a given will almost certainly be different from previous releases. The up side to this is that the PRNG is now decoupled from the host platform; this means that it should work consistently across different platforms, and that interference between the libvisualid PRNG and the host platform's native PRNG can be eliminated. The sense of the `probability' functions has been inverted with regard to previous releases, and several probabilities have thusly been inverted, to produce more sensible behaviour. The public PRNG routines have been moved into a new subordinate library, libvirand. Also included in libvirand is general-purpose, arbitrarily-weighted discrete-value generator class (VirandGenerator). All of the more basic PRNG-related features in libvirand have been made re-entrant by the inclusion of a GLib `GRand' object in function argument-lists. libvisualid's pseudo-random glyph- and subglyph-selection mechanisms have been been rewritten to use the libvirand facilities via a new `VisualID_Generator' class that encapsulates all state used in generating VisualID_Glyph objects. It is thus now possible to generate multiple glyphs simultaneously without interference from (or to) either each other or subroutines using the host-platform's PRNG. The way that input strings are converted into PRNG seeds has changed: rather than condensing the input strings into a 4-byte hash and using that as a seed, strings can be used directly as seeds via the new virand_set_seed_string() routine. Neither the libvisualid library nor either of the included applications (mkvisualid and edit-visualid) now assume that input strings are file-paths, and leading and leading directories are thus no longer automatically stripped before processing; this means that the onus of trimming paths to only the relevant part is now born by the caller. Another new library, liblevenshtein, is also now included with libvisualid: it is a simple, modular toolkit for computing `edit distances' between pairs of strings. Liblevenshtein is based on the Levenshtein algorithm, with modifications to allow for edit-operations to weighted in application-specific ways. Version 0.2.1 is a bug-fix release following-up on 0.2.0, and is binary-compatible with it; changes include: * Automatic complexity-limiting is actually enabled. * A divide-by-zero bug affecting the rendering of line-glyphs with exactly one `rib' sub-glyph has been fixed. * Under-reporting of the complexity added to Line-glyphs by multiple `ribs' has been fixed. * Two issues in the best-common-substring logic used to associate file-names with pre-existing VisualID-glyphs for other, related files have been resolved: memory-leaks have been fixed, and strings that were treated as circular are now treated correctly. * The VisualID Explorer now renders glyphs with a fixed 1:1 aspect-ratio, scaled without distortion to fit the available drawing-area. Version 0.2.0 is a significant revision of libvisualid, though the user-interface of the `mkvisualid' command remains mostly unaltered; visible changes include: * A new "--base-weight" option has been added, to set the default weight for generators in the probability-set; it's possible to disable all generators with "--base-weight=0" and then easily enable only specific generators. * A new "--autocache-dir" option has been added, allowing the glyph-cache directory to be specified. * The "--autocache" and "--output" options can now be used simultaneously (in the future, the `autocache' files will be in a different format capable of storing glyph-structures with all attribute-data intact, instead of just storing renditions). * If the path specified via the "--output" option exists and is a directory, then a file is created in that directory with a name according to the input name. A new `VisualID Explorer' demo-application has been added, using GTK+ with several alternate GUIs defined using Glade. The libvisualid library contains several new features, including: * visualid_complexity(), a function providing overall complexity-metrics for VisualID glyphs. * visualid_set_cachedir(), a function that allows the global cache-directory to be changed. * Automatic limiting of overall glyph-complexity: an integer in constants.c (complexity_max) controls the maximum glyph-complexity, having a default value of 5000 (a measure of something akin to `number of brushstrokes'). * As the result of everything having been refactored using GObject (cf. details below), we finally have a way to *deallocate* VisualID glyph-structures! * Some bugfixes. This release of the libvisualid library is binary-incompatible from all previous releases, and is source-incompatible in a few minor ways: * exec_generator() has been renamed to visualid_draw_path(). * generate_child() has been split into two special-purpose functions: - visualid_glyph_new(), for producing root glyphs, - visualid_glyph_spawn(), for producing and assigning subordinate glyphs. * All of the class-specific generator-functions have been reworked to have the same parameters as visualid_glyph_spawn(). Aside from the above changes, libvisualid should be source-compatible in every meaningful way. The `generator' structs have been converted into GObject classes, including a base `VisualID_Glyph' class; the existing structs have been preserved for the time being, but this marks the beginning of API-redesign whereby terminology will be corrected and the API will be reformed into something more fit for general consumption (e.g.: public names put into a namespace). The naming of the structs in 0.1.x as `*_generator' was somewhat inappropriate, and due to some misinterpretation of some ambiguous text in the essay: while the `*_generator' structs /are/ data /related/ to generators, the `gen_*' function itself (not the data that it produces) /is/ the generator. The term, "glyph", has been chosen for the base-class in the VisualIDs `shape grammar' by analogy with written-language grammar where `glyphs' of typography are realisations of abstract `characters'; the `characters' of the shape-grammar would then be the classes per se: `radial', `spiral', `figure', `line', etc. Version 0.1.2 is a bug-fix follow-up to 0.1.1, and is binary-compatible with it: * The symmetry- and spiral-generators' weights where accidentally coupled in mkvisualid, such that "--symmetry" set weights for *both* the symmetry generator *and* the spiral generator, and "--spiral" did nothing. * Decreased the probability of child-glyphs being used in the along-a-path generator from 100% to 80%, in accord with the table on page 10 of the VisualIDs essay. Version 0.1.1 is a minor (bug-fix) follow-up to the initial 0.1 release, correcting various minor errors in both design and implementation and adding (or enabling) minor features that were missing (or disabled) in 0.1, for example: * The `spiral' generator has been enabled in the `mkvisualid' utility, with a "--spiral" ("-i") option to control its weight in the randomiser. * In general, more care has been taken to ensure that, by default, the glyph-generation algorithms used by the mkvisualid utility are identical to those used by the library routines. * The "-s" abbreviated option was mistakenly aliased to both "--symmetry" and "--shape"; "-s" has been granted to "--shape", with "-y" being the new shorthand for "--symmetry". * There is a new "--outline-width" ("-O") option that allows specification of the thickness of the white outline that provides contrast when glyphs are rendered over dark backgrounds; this was previously fixed at 50% of the foreground stroke-width. * The `perfect fit' logic that automatically scales glyphs to fit perfectly on their canvases now works significantly better, and even supports non-round line-joint/-cap types. libvisualid 0.1.1 is binary-incompatible with 0.1, but should be source-compatible in every meaningful way; the libtool library-version has been updated so that 0.1 and 0.1.1 shared libraries can coexist for the benefit of any applications that have already been built with and linked against 0.1.